Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Thermal problems have been a major bane of computers since the very first computer was plugged into AC power. Despite server rooms with raised white flooring and high-end Leibert air conditioners, and over-clocked gaming rigs with water-cooling on the chipsets, heat continues to be a problem that computer administrators and technicians can’t ignore.
This series of articles explores one user’s trek to build a temperature monitoring and reporting system for his home office. The same concepts outlined in these articles were later used in a corporate setting to monitor and report the temperatures of a server room and a computer lab, and can be recommended to anyone needing to monitor the temperature of rooms or assets consistently.
The series also illustrates how you can take a simple idea for collecting data and expand upon it—programmatically adding different interfaces, monitoring mechanisms, reporting techniques, and so forth.
Note: This series of articles uses Linux as the operating system of choice, with scripts written for the shell (Bash) and in Perl. For the tasks outlined within this series, I found Linux to be ideal. If you are using a different programming platform, or if you are unable to replicate these methods on Linux, you will still gain value from these articles. Where possible, I will point out analog possibilities in Windows and other operating systems.
The Problem
My thermal concern at home was less of a “consumer cooling chipset” problem and more of a “server room without adequate cooling” problem. My home office housed eight PCs—several servers, two desktops, my design Mac, and so on. Unfortunately, the room wasn’t designed to handle the amount of heat generated by the number of machines I crammed into it. It wasn’t long before I had to install supplemental air conditioning (a portable unit, vented to the outdoors), and even that extra gadget had problems keeping the room cool on very warm days.
One persistent problem was that the office temperature could achieve a point of no return, at which the air conditioning could no longer keep up with the heat being generated by the computers. The ambient air temperature would simply continue to rise until I had to shut down all the machines and let the room cool down gradually.
At 70.75 degrees Fahrenheit, I really didn’t have to worry. However, once the temperature of the room approached 77 degrees, trouble was ahead. I needed a way to monitor the room’s temperature constantly and a method to alert me when the temperature started creeping up because I couldn’t be in the room 365/24 to monitor it myself.
Consumer Remote-Monitoring Solutions
My first gambit was to install a remote thermometer in the room, tied to a master display elsewhere in the house. (Companies such as Oregon Scientific make a bunch of remote-thermometer solutions, available from most local retailers.)
The problem with that approach was that it only expanded my monitoring capacity slightly. I still had to be near one of the two thermometers—the remote or the master—to see the office temperature. What I really needed was a program that could monitor the temperature and take action as needed—send me email or SMS, sound an alarm, and the like—when the office temperature needed attention. So, my attention turned to serial, USB, and other peripheral-like connected solutions.
High-Tech Industrial Solutions
I won’t bore you with the details of my search for a connected solution. If I came across a promising possibility, it usually fit into one or more of the following categories, ruling it out as a potential solution for my problem:
- Extremely expensive
- More functionality than I needed (for example, the X10 home monitoring system)
- Proprietary interface that limited my ability to script around the readings
However, I did find a nice, fairly inexpensive, and simple device from B&B Electronics. Their Digital Thermometer & Thermostat with RS-232 Interface, shown in Figure 1, provided a nice serial connection with a manageable interface for reading the temperature off the device.
Figure 1: The B&B Electronics Digital Thermometer & Thermostat with RS-232 Interface (232DTT)
As an added bonus, the 232DTT includes a basic thermostat control—you can set temperature thresholds that enable and disable an on-board relay when triggered. At around $50, the solution wasn’t cheap, but wasn’t overly expensive, either.
Note: Since my purchase of the 232DTT a few years ago, B&B has raised the price to just under $75. This still makes the device a bargain, in my opinion, but might push it out of the affordable range for some people. It still remains one of the few external programmable solutions I could find. (Link to the product on B&B’s site: http://www.bb-elec.com/product.asp?sku=232DTT).
Note: There are other solutions on the market—you should choose one that meets your needs. For example, www.Phidgets.com has a temperature sensor for $11, but it requires an interface kit for an additional $60. Phidgets also has a USB termparture sensor for $90 (http://www.phidgets.com/index.php?module=pncommerce&func=itemview&KID= 115446415574.132.165.37&IID=61). For industrious, tech-savvy readers looking for a homegrown solution, martybugs.net has an excellent series of articles on building your own temperature-sensing circuit. Visit http://martybugs.net/electronics/tempsensor/hardware.cgi for details.
Working with the 232DTT
Using the 232DTT is fairly straightforward. You simply hook it to a serial port that has the DTR and RTS lines set high, for power. If those lines cannot be set or cannot be relied upon to be high, an external 12-volt adapter also can be used to power the device.
Use your favorite communication program to set the port to 9600 baud, 8 data bits, 1 stop bit, and no parity. Now, you’re ready to go. You use a simple command set—akin to the old Hayes modem AT commands—to read the current temperature, set the thermostat registers, and so forth. For example, to read the current temperature, you send the unit the “!0RT” command. The device returns a two-byte response that corresponds to the current reading, but must undergo some translation into Fahrenheit or Celsius to be useful.
Because the device was meant for a wide variety of temperatures, the translation outlined in the device manual is a bit complex. The first of the two returned bytes corresponds to whether the reading is a positive or negative value—unnecessary in our case because the temperature should always be above zero! As long as that assumption holds true, the first character returned should always be NUL, and you can disregard it.
Listing 1 shows the basic calculation for converting the second character to an actual temperature, where R is the character returned from the device:
Listing 1: Equations for converting sensor data to Celsius and Fahrenheit values
C = asc(R) / 2 F = (9 * C / 5) +32
For example, suppose the device returned a period (.). The temperature calculations would then be as shown in Listing 2 (note that a period has an ASCII code of 46):
Listing 2: Equation results for translating a period (.) to Celsius and Fahrenheit values
C = 46 / 2 = 23 F = (9 * 23 / 5) + 32 = 41.4 + 32 = 73.4
Basic Scripting with the 232DTT
Now that I’d found a working sensor, I needed a series of scripts to implement the functionality—monitoring, reporting, alerting, and so on.
You might wonder, why scripts and not application? That is, why write a series of little programs that interact together, instead of a monolithic solution in application form?
The answer lies in flexibility. With a series of scripts, I can fit the scripts together in multiple configurations to design whatever functionality I need at the time. It’s a lesson I learned working at Progeny and around Linux—work with a bunch of little programs that each do one thing well, and you can build whatever application you need. Finally, building an application would put most (if not all) of the work on me. Because my platform of choice for this project was Linux, I had a wealth of little specialty utilities at my disposal to talk to the serial port, translate data, and so on. Other operating systems may not have the sheer number of utilities available, but comparable tools can achieve the same result.
The first utility I needed was a means to get the data from the sensor. Instead of writing my own serial communication routines, I decided to use the well-known and popular Kermit communication package. In this particular case, I chose GKermit, the GPL’d version of the Kermit suite.
Kermit comes with a fairly robust, but completely arcane, scripting language. By using a script, it’s easy to have Kermit perform the following tasks:
- Configure a serial port’s parameters.
- Open a connection with the serial port.
- Send a series of characters to the port.
- Wait for and report a response.
Listing 3 shows such a script.
Listing 3: Kermit script for connecting to a serial port (COM1, or /dev/ttyS0) and reporting the temperature read by the sensor (get_temp.ksc)
# Initialize the port
set port /dev/ttyS0
set speed 9600
# Send read temp command
# and read response
while equal {"v(input)"} {""} {
clear input
output !0RT
input 2
}
# Close port and quit
close
quit
The script is invoked by placing it on the Kermit command line, similar to the following:
get_temp.ksc
Kermit executes, runs the script, displays the character retrieved from the sensor, and quits—perfect for my needs.
Note: Most telecom packages have some type of scripting that will let you perform the same type of actions shown above. If capturing the output of the read temperature command proves problematic, have the telecom application log the session to disk where you can later parse the value out of the log file.
The next step in this process is to translate the returned character into a temperature value. I only need the Fahrenheit value, so the following equation is what I used, where <char> contains the character retrieved from the sensor:
( ord(<char>) / 2 * 9 / 5) + 32
Unfortunately, this is one area where the Linux shell and the abundant utilities available came up short. None of the simple, command-line math tools had a built-in ord() or character-to-decimal-ASCII conversion function. Although there are several ways around this shortcoming—including building my own ASCII table for looking up values—I ended up writing a short Perl script to do the calculation for me (see Listing 4).
Listing 4: Perl script to convert a character received from the sensor into a Fahrenheit value (conv_temp.pl)
#!/usr/bin/perl -w #declare variables my ($temp, $char); $char = (shift @ARGV); $temp = ( ord($char) / 2 * 9 / 5) + 32; print "$tempn";
Now, I had the required pieces to get the temperature from the sensor:
- A communications script to send the “read” command and return the result
- A short script to do the required calculation from character to temperature value
To tie the pieces together, I used a simple Bash shell script, as shown in Listing 5:
Listing 5: Shell script to get the current temperature from the sensor (get_temp.sh)
#!/bin/sh # Get reading from sensor SENSOR='kermit get_temp.ksc' # Convert reading to Fahrenheit and display ./conv_temp.pl $SENSOR
Now that I had a complete script, I could easily schedule it to run at regular intervals, pipe the temperature to other monitoring and reporting utilities, and so on.
Next Time
This article detailed the thermal problem plaguing my home office and how I chose to monitor it—including the hardware and basic scripts to read the current temperature. These same techniques can be used in a variety of applications—from systematically monitoring other connected devices, to collecting data from other systems.
The next article in this series expands on this capability, incorporating a few reporting mechanisms for passing the data on to other programs, systems, and users—while illustrating techniques that can be used for a variety of data collection and distribution purposes.
About the Author
Freelance consultant Steve Schafer has written multiple technology
books and articles. In the business world, he most recently worked
in-house as COO/CFO of Progeny Linux Systems in Indianapolis. Serving
as president and CEO in the company’s startup years, Steve led
Progeny’s business and financial turnaround during the tech crash of
the early 2000s. Prior to joining Progeny, he was a senior title
manager for Macmillan Digital USA, overseeing the operating system
and entertainment software products and tripling Macmillan’s Linux
product line revenue. He partnered Macmillan with Mandrake, bringing
Mandrake’s Linux distribution to the competitive retail market.
