Blog Archives

Home Heating Hacking Part 2 or How to (Almost) Audit a Furnace

Purpose

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.

Planning

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

 Prototyping

Furnace circuit

Parts

  • 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.
Breadboard

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.
Furnace controller

Furnace controller

Zone Valves

Zone Valves

Testing

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.

Results

  • 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.

Data

Furnace log

Sample output

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.

Resources

Home Heating Hacking Part 1 or How to Measure an Oil Tank

Cross posted from Blogger

Purpose

Oil Tank

not our tank, but a reasonable facsimile

For a while now, I have had this plan to monitor the energy use of our house–primarily the fuel oil for our furnace.  Unless I go out to the tank regularly and check it with a dipstick, I have no idea how fast or slow we are using up the tank.  The above ground tank holds 570 gallons and it lasts us around a year.  Since we live in a temperate rainforest (and the water heater uses the furnace), the furnace is running year round.  I only have a very rough idea of the difference between summer and winter usage.  Last winter we decided it might save some oil to use a space heater, but I could not determine how much of a difference it made.
With this in mind, I made the following mental list of requirements for the first stage of this project:

  • oil tank level sensing
  • enough granularity to see daily usage
  • data logging
  • ability to compare oil usage to outside temperature

Planning

I looked into several potential methods to measure the tank level.

The Rocket

There is really only one product already on the market that is similar to what I want: The Rocket.  It is $120, only reads in 10% increments and just displays on the receiver.  Without hacking the wireless protocol that is being used, there is no way to do automatic data logging and a 60 gallon granularity is not optimal for the analysis I want to be able to do.

Sensors

Here is a summary of the various sensors I considered:
  • Mechanical – while this style of sensor should be very simple and reliable, I didn’t come across any that could be read digitally or were able to read a range of 4 feet.  One may exist, but I suspect they would be fairly expensive.
  • Resistive – While strips exist and provides continuous range, they are not even close to being long enough.
  • Capacitive – There are also capacitance based strips, but they are also too short so I would have to build and calibrate my own.  I also had some concern about a capacitive sensing in fuel oil, but I later learned that this type of gauge is used in some aircraft so it should be safe.  Probably better safe than sorry.
  • Gravitational – Strain gauges are solid state devices that measure weight and are used in scales of all sizes.  I was not sure how hard it would be to get them placed under the tank, so I did not research them very much.
  • Optical – Infrared distance sensors seemed like a simple option, but I didn’t find one that covers a broad enough range for my purpose.  They all seemed to be designed for close range or far range
  • Ultrasonic sensors – there are a lot of different ultrasonic sensors.  There are expensive industrial models and cheap ones that are often used in hobby robotics.  After looking at several different sensors, I picked up a Maxbotix EZ4 (more on these later).
  • Others – I considered a sensor based on light diffraction, but I don’t know how one would work on a tank like this.  There may also be some sort of resonance type that could read from the outside of the tank, but I would guess these would need a bit of calibration if something does exist.
  • I also thought about putting a flow meter on the intake line, but I would also have to have one on the return line and it would not really tell when the tank was getting empty.
  • Thanks to hackaday.com comments, I was pointed to the Jaycar and the Centroid sensors.  The Jaycar needs a half meter of head space–I think it is intended for upright tanks.  Like the Rocket, it uses its own receiver.  The Centroid is hard to find a lot of information on (especially price), but I believe it is a capacitive sensor that can be cut to length.

Prototyping

I started out with the EZ4 sensor mentioned above.  This sensor is versatile and simple to use.  It has circuitry onboard that does most of the work and communicates the results as an analog voltage, PWM or RS232 signal.  The down side of this sensor is that it only offers 1-inch resolution which is about 15 gallons in the middle of the tank, but something that works is better than nothing and I can swap it out later.
I hooked it up to an Arduino Uno board with a 9V battery and tried aiming it down the fill tube which is maybe 8 inches long.  Even holding the sensor an inch or so into the tube, it would only read a small number of inches (can’t remember the exact number) when the tank was clearly under half full.  I realized it was getting interference off of the fill tube and looked up the datasheet again.  It turned out that I got the sensor versions backwards and what I really meant to get was the narrow beam Maxbotix EZ0.
for it’s 0 to 255 inch range and narrow beam so it could be spaced up far enough off of the top of the tank to avoid getting wet from splash back.

The LCD contrast was too a bit low
for the picture, but it says 116

Before I got around to mounting the EZ0, I came across a cheap version of the Ping))) sensor on eBay (2 for about $5 shipped).  These sensors claim centimeter accuracy (about 6.5 gallons in the middle of the tank) and also cover the required range, so they were worth a try.  I hooked one up on a breadboard and brought it out to the tank.  I had to hold it most of the way in the whole, but it gave a reasonable reading: 116cm (about 46″ or almost empty; it was filled the next day).  Once I verified that it would read properly aimed through a PVC adapter, I decided to go forward with this sensor.
The simplicity of this sensor is actually a bit of a strength.  To use it, you pulse a trigger pin and wait for the echo on another pin.  Even though its rated accuracy is a centimeter, accurate timing (and a bit of algorithmic cleanup) can allow for even better precision.  More on the output later on in the software section.

 

 

 

Build

Parts

To hold the sensor in place, I cut a disc out of a plastic container and made holes to fit the sender and receiver through.  I started with a #5 plastic container which was quite soft and flexible and then changed out for a more rigid #7 plastic.  Once I determined the sensor would not pick up the sides of the PVC, I started putting everything together.
I used CAT5 to run into the crawl space of the house so there are minimal components outside to weatherproof.  I added an LED for a visual indication that the system had power (and perhaps to ward off anyone who comes by with the idea of siphoning the tank).

soldered up using CAT5

Everything in place

Final test setup

Final test setup

I tested out the system over the full 100′ spool to make sure that it wouldn’t suffer from any issues due to distance.  Ultimately, I used closer to 20′ to get into the house and it would have been shorter but I already had a hole around the corner to use.  I added in a temperature sensor, but I had to use an LM35 I had sitting around because I broke the leads on my TMP36.  I don’t expect most people will know the difference, but basically the LM35 requires a negative voltage in order to read below freezing.  I don’t have any parts around to produce the proper voltage, but I left the sensor in anyway.  Even above freezing, I am getting erratic results, so I intend to replace it (when the weather is a bit warmer) or use a separate temperature sensor.  I have tinkered with intercepting the signal from our Oregon Scientific weather station, but I haven’t had any luck yet (possibly, I need to add an antenna but that is for a different post).

Installed and functioning

Installed and functioning

Software

I tried to keep things simple on the Arduino end since it would not be really easy to access in the crawl space.  Initially, it was coded to take 10 consecutive readings each time and return the total.  This essentially gives an average in millimeters.  This seemed to work great inside, but after a bit of time on the tank it was clear that it wasn’t reading correctly.  The distance returned would often be lower than it should be.  It is possible that I didn’t have the proper delay between readings (supposed to be at least 29 microseconds and I forgot to add in a delay).

sample output

I decided to go down to the crawl space to update the code and made a few changes while I was at it: increased the number of readings each time to 100, return the sum of the 10 median values, also send the min and max values.  The output is simply passed over serial using the XBee to a computer with another XBee on a USB adapter.  I wrote a simple application to allow me to select the COM port and it starts reading the data and inserting it into a simple database.  I put together a basic webpage to output the data by hour and graph the results to visualize daily trends.
16 days of data so far

Oil sensor chart

Math

For those that are interested, there are charts and formulas available for the calculations so I won’t reproduce them here.  The tank has rounded ends, but it would be difficult to account for and accounts for a small enough portion of the volume that I ignore it for now.

Results

All in all, I am very happy with this progress.  There are a few issues that have come up during the process:
  • As I mentioned already, it is not very convenient to bring the laptop down to the crawl space to update the Arduino code.  In addition to that, the jumpers on the XBee shield are not working for me, so I have to disconnect power, carefully remove the shield, plug in the USB to upload, disconnect USB, reattach the shield and plug the power in again.
  • The XBees (at least series 1) are simple to use, but they don’t quite operate the way I had planned.  My hope was to use one receiving module with several senders, but they are designed to be one to one communication.  There may be a way to set one to promiscuous mode, but my current plan is to change out the Uno board for a Spark Core which should be arriving soon.  These boards have integrated wifi and can be programmed over the Internet.
  • The XBees also don’t have the range I had hoped.  I had to move the receiving end as far from the computer as possible to get them somewhat reliable.
  • Sometimes the data jumps around a bit which can be seen on the graph image above.  There are also times that the sensor gets a drop of liquid on it causing misreads.  I have done some cleanup of outlying values, but the moisture problem is not apparent yet.  It could be a bit of condensation, but I suspect it is a stray drop that splashed from the return line.  To fix the problem, I have pulled the sensor off and blown it clear each time.  If the problem goes away as the tank gets lower, I will assume it is splash back, but I haven’t formulated a permanent solution yet.
  • As I mentioned above, the temperature sensor I included doesn’t provide any benefits as it is.  I won’t change it out until the weather is warmer, but if I come up with an easy way to generate a -5V, I may do some more testing in the meantime.
  • I forgot to do a manual measurement to calibrate the distance from the sensor to the top of the tank, so I made a rough guess.  This could make the values off, but I can adjust the head space on the database side if I decide to.  In the future, I may make this a setting on the Arduino side that I can modify over serial communication.

While this project is in stable operation, it is not yet complete.  Besides the improvements just mentioned, I would like to add active anti-theft of some sort.  A couple ideas I have are a tilt switch on the fill cap and a motion sensor and there may be other features I come up with later so I will revisit this part of the system after I get some of the other systems functioning and have some more parts.

Coming soon: Part 2 – How to Audit a Furnace

Update: added a couple commercial sensors to the list.

Update #2: Here is a snippet of messy data before purging.  The values jump all over the place, but the maximum distance read is often in line with what it should be.  Once I removed the sensor and blew it clean, it continues to read fine for a while.  This time I couldn’t see anything on the sensor.

2 weeks

Resources