Following up on my oil tank gauge
, the next idea I had was to audit furnace usage. There are three zones that demand heat from the furnace: upstairs, downstairs and the water heater. Now that I can track how much oil we use, I would like to break it down by zone usage. Since thermostat and furnace control systems operate on 24V AC, my plan was to build some basic voltage probes.
There are a few different ways I can think of to read an AC voltage or current from a low voltage circuit:
- Inductive coil – these are great for measuring current on a high voltage line, but they are a bit more expensive than I liked and I only need to detect on and off. I could build one, but it will take a bit of tinkering without an AC power supply for testing. There are split core sensors that can be clipped over a wire, but they run more than $8 each.
- DC power adapters – It is possible that I could find an adapter, but there aren’t a lot of options that run on 24 VAC.
- Optocouplers – these are built specifically for the purpose of interfacing high and low voltage systems without directly connecting them electrically.
- Hall effect current sensor – kind of a cross between optocouplers and inductive sensors. The current is passed near a sensor that senses the amount of electromagnetic force.
I decided to go with an optocoupler for now, but I may come back to inductive sensors in a later iteration. There are many different types of optocouplers (also called optoisolators), but the internal circuitry is pretty simple to understand. One one side, there is an LED (or two) controlled by one circuit and on the other side is some form of light sensitive component (usually a photodiode or phototransistor) and sometimes a few extra components depending on the type of output required. I started designing the circuit around a really basic 4 pin PC123
and ordered some bridge rectifiers for the input side. Before I received these optocouplers, I came across the IL250
which is designed for AC current with LEDs going both directions. This simplifies the input side to just a resistor to limit the current to 50 mA.
IL250 internal circuitry
- 4x IL250 (I got 5 for about $8 on eBay)
- 4x 510 ohm, 2 watt resistors (input current limiter)
- 4x 220 ohm resistors (output current limiter)
- 4x LEDs (The diagram shows red, but I used different colors-more on that later)
- 4x electrolytic capacitors
- speaker wire for furnace hookups
The circuit design is pretty simple. On the input side, there is a 510 ohm resistor to keep the current around 47 to 50 mA. If the voltage was consistent at 24, it would be on the low end of that, but it measures out closer to 27. This chip will take up to 60 mA, so there should be enough of a margin for safety. Initially, I tested the circuit before considering the power on the input resistors. .05 x 24 = 1.2 watt I only had quarter watt resistors on it, but they managed to work for a while with just a bit of discoloration from heat. Once I realized this problem, I disconnected everything for a while while I waited for the new resistors to arrive.
On the output side, positive voltage is connected to pin 5 (collector) through a resistor and LED. A capacitor between pin 4 (emitter) and 5 will help smooth out fluctuations in the output enough to hopefully avoid bad edge triggers.
4 probes on breadboard
I put together 4 probe circuits on a breadboard with a Nano (the one pictured happens to be a Sainsmart Nano
). I did a basic test with a 5V supply on the rail and about 28V (DC) on each of the terminals to ensure the LEDs would like up. Due to the limitation of the XBees (mentioned in my previous post), I did not have what I needed to hook up wireless communication (at least not yet) so I swapped out the Nano for a Raspberry Pi with a T-Cobbler Breakout
from Adafruit. I have been meaning to start experimenting with the GPIO port on the Pi, so this was as good a time as any.
I won’t detail out the full install process for the Pi since it is mostly pretty standard, but I set it up with ngenx as a webserver with PHP, node.js and socket.io, SFTP for updating the web app easily, SSH for remote administration, mySQL and Adafruit’s WebIDE (to try it out). I then wrote a python script that would regularly poll 4 input pins and log any changes to a database (the current version can be seen here
). I then set it up to run as a background process following the instructions here
. I had some problems getting it running properly, but they were mostly due to typos and file permissions. It isn’t a surprise, but +X and +x don’t do the same thing.
When I had a chance, I started by hooking up wires to the zone valves. I ran speaker wire from a shelf over to the valves and hooked up to the terminals that trigger the pump and furnace. These terminals operate as a switch that turns on once the valve has opened part way and turn off before it gets all the way shut. I think it was this timing that threw off my earlier probing, so they worked opposite of the way I wired the circuit. I updated the script to handle this, but I still need to go back and update the circuit so the LEDs are on at the right time instead of being off when each zone is active.
After a couple tweaks to the script, I let it run to collect data. The next day, I had some time to hook up the other wires: one to the furnace terminals labelled thermostat and one to the pump that supplies the water heater (this was the only obvious connection point to that part of the system as everything else appears to be inside the water heater or in metal conduit). I couldn’t simply test out the water heater part since there isn’t a manual trigger for it.
- As I mentioned, the voltages are opposite of what I thought I remembered from probing. The data logging side is fixed through software, but I still want to rework the circuit so the LEDs operate correctly.
- I still have an issue with it starting up with it registered through update-rc.d, so I used rc.local to force it to startup instead. I may look into it at some point, but this method is working for now.
- The thermostat terminals on the furnace controller aren’t as useful as I had hoped. This connection tells the controller unit that heat is needed, but is not a direct indication that the furnace is burning. Somewhere in the controller, it starts and stops the furnace to keep the water between the set temperature range. I have a few ideas to monitor actual burner operation, but I will continue to look into it and cover this in a later post when I have some options detailed out.
- The day after I got all the wires hooked up, the Pi became unresponsive on the network. Following this post, I put in a script to monitor the wireless connection and reinitialize it when it drops. So far this seems to have kept the Pi on the wireless.
- One oddity that shows up in the data is a 10 second on time after each zone valve has been off for roughly a minute. I considered that something is causing the zone valve to miss its stop point and rotate again, but it shouldn’t take a minute to get back around. I will ignore these 10 second results and look into this phenomenon further.
- I may try using Dropbox for updating the web pages instead of FTP.
For now I am just dumping the raw data. Once I have a bit of data collected, I will have a better idea of the metrics I would like to present. The ideas I have so far include: number of times a zone demands heat, average duration that zone is on, total furnace burn time and a basic proportion comparing the zones.