Remote Temperature Monitoring with Linux
I started this project to record and access temperature readings remotely after I had a conversation with a friend who is in the HVAC business. His job is to make sure the climate indoors is comfortable—not too hot and not too cold, depending on the weather outside. He finds many new installations have startup bugs that must be worked out, because no two installations are exactly the same. The end of the job is the most stressful. A customer calls after he is done and lets him know something is wrong. The customer isn't happy, but he doesn't know where to start looking for the problem because there isn't any good objective information about what is going wrong with the installation.
We agreed that it would help to be able to record the outside temperature and log the readings electronically. This would be one way of improving the troubleshooting process. I then started the search to purchase an off-the-shelf recorder that was inexpensive, easy to install and simple to use. While looking, I found a wide range of commercial products and kits. Some are standalone and some use a PC for displaying and recording temperature data. Each of our three requirements was equally important and I found that most of the products were too expensive for our budget. Ease of installation was typically another problem. Some devices had complicated wiring or the requirement that they be placed where temperature was measured. Many people consider thermostats to be just clutter on a wall, so it wasn't going to be easy to convince them to have another box to record temperature.
Finally, to solve the problems of cost and installation, I looked at the possibility of building a system from components. Following the Linux idea of assembling and integrating tools to get a task done, I looked at using a digital multimeter, a PC and software to make them work together. The digital multimeter with an RS-232 serial port interface would measure temperature using a sensor. The PC would collect the data from the multimeter and process it for display.
I was aware of open-source utilities for the multimeter serial port interface using Linux and had purchased a multimeter earlier for general troubleshooting. We had a retired PC available, so all the components were on hand to build a prototype temperature recording system.
The digital multimeter came with a serial port cable and DOS software. I didn't use the supplied DOS program. There was no way to modify the program to allow temperature measurements with the sensor. Instead, I used QuickBasic to write new software from the ground up. I had the necessary details about the serial port interface for the multimeter, and QuickBasic had all the features I needed. I got a prototype communication program to work, but I ran into memory management issues with DOS and QuickBasic as the application grew in size, especially when I started dealing with the need to display and record data.
It seemed like a big step backward to struggle with memory management at this point. I knew Linux would provide an environment where I wouldn't need to be concerned with memory management, so I looked for a distribution to use as a replacement for DOS.
I found that the most popular Linux distributions weren't appropriate for this application. Even a minimal installation of these distributions would exceed the capacity of the retired PC. The distribution I found that overcame these restrictions was University Linux from Paul Muller. It has small memory and disk requirements. I was able to run it on the retired PC using less than 20MB of DOS formatted hard disk space and 24MB of RAM. Best of all, the distribution is tolerant to power failures. If the power goes out, the PC reboots without causing file corruption problems that need manual help. This saves money and reduces complexity, because I didn't need a UPS to keep the system running during power failures.
Once I configured everything on the PC, there was no need for a keyboard or monitor. I could use a Windows PC and Telnet, along with an Ethernet connection to communicate with the system PC for development and testing. I prefer to write and test incrementally, so I chose Perl for the language for this project. University Linux comes with Perl version 5.003. I couldn't use Perl modules, the application size was too small, so this was a minor inconvenience. University Linux also includes Acme Labs thttpd server. This allowed me to set up the system to use a Web browser for viewing temperature measurements.
I used a Tandy Catalog No. 22-805 digital multimeter that comes with an operating manual, DOS software, wire test leads and serial cable with nine pin connectors. According to the manual, the communication settings are 600 baud, seven data bits, two stop bits and no parity. Important information was left out of the operating manual, but I found what I needed on the Web. The DTR and RTS lines need special attention. The DTR line has to be set low and the RTS line set high for the meter to communicate through the serial port. It is impossible to get data from the meter without the two lines set this way.
I could use only stty for serial communication with this distribution and couldn't explicitly control the DTR and RTS lines in the script. This meant I needed a hardware hack to make things work.
I found that DTR and RTS change from a low to high state when I call stty in the script. This works out okay for DTR, but RTS has to remain low. I realized that the second serial port on the PC has RTS low as it isn't being used. If I connected the multimeter serial interface cable RTS to the RTS pin of the second serial port, the multimeter would be faked into seeing the correct line setting. I simply removed the RTS line from the multimeter and connected it to the second serial port.
With that problem solved, I powered up the multimeter and put together a short test script (serialtest.pl), as follows:
# !/usr/bin/perl # # serialtest.pl # # Script for reading Tandy Model 22-805 meter # through serial port. $port = "/dev/ttyS1"; # set to COM1 system ("stty 600 cs7 cstopb clocal -ixon -echo < $port"); open (SERIALPORT, "+>$port") or die "can't open $port. "; print SERIALPORT ("\n"); # take a reading $R = <SERIALPORT>; # read returned string print "$R" ; close (SERIALPORT); # close port exit 0;
If the script ran successfully, I would get a string with the same reading shown in the multimeter LCD. I set the multimeter to the resistance measurement range and ran the script. The result was:
OH O.L MOhm
A good start! The hardware hack worked. Now it was on to measure a temperature sensor with the multimeter.
I chose an NTC (negative temperature coefficient) thermistor for the temperature sensor. Despite the fearsome sounding name, this is just a small two-wire electronic component that changes electrical resistance with temperature. With a multimeter, the resistance measurement provides information to tell temperature. The thermistor is impossible to wire backward, because it isn't voltage-polarity (+ or -) sensitive. This means one less thing for the technician installing it in the field to worry about.
The thermistor isn't fragile, but the leads to the body can be broken with excessive tugging or bending. I used a two-position terminal block to solve this problem and make the connection to the wiring simple. I placed one thermistor lead and a wire under a screw terminal and then tightened the screw to make a solid mechanical and electrical contact.
With the thermistor connected to the ends of the test leads and the test leads plugged in to the multimeter, I powered up and ran the test script again. The result was a resistance reading:
The numeric portion of the reading is 34.23 with a k after it. The k is an abbreviation for kilo or 1,000. Because the multimeter LCD doesn't have enough characters to display large numbers, it uses a multiplier. In this case 34.23k is 34,230 Ohms.
I found that this reading was very close to 0 degrees C by referencing a table of resistance-to-temperature values supplied by the manufacturer. It matched the temperature reading of another thermometer with a sensor in the general area, so I was confident that this assembled system would work and provide accurate readings.
Now it was time to create a script to to use the data and display the temperature value.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Interview with Patrick Volkerding
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide