Home Heating Monitor Version 1: July-November 2008

As described on the main page this version of the project failed. However, I learned a lot and V1 allowed me to develop V2.

Monitoring the heat pump relays

July, 2008
I measured the LED array on the relay box and the LEDs are on 1/4" centers. I also found that an IR transistor will detect the light produced by both the green and red LEDs on the relay box (though the IR transistors prefer the red LEDs' wavelength).
I created the optocouplers (one for each relay box):

I had some 1/4" O.D. PVC tubing which by chance fits perfectly on T 1-3/4 LEDs. So I cut some tubing pieces 3/4" long and glued them between some flat PVC sheet. Between the tubes I glued some aluminum foil to prevent "crosstalk" - I don't know if an LED's light will affect a neighboring IR xstr thru the tube walls, but the tinfoil is cheap insurance. These tube arrays will fit snugly on the relay box's LED (without glue) and I'll glue the IR xstrs in the other end.
I need some sort of stand-alone controller to continuously monitor the sensors, store the state-change data, and send that data to a PC on demand. Ethernet would be a good way to move the data given that the house is networked. All I need is a stand-alone microcontroller with realtime, several K of Flash, and Ethernet. Simple! :) Now then: Make vs. Buy?

My first thought was to build a custom PCB based on a Microchip part that has integrated Ethernet. Not hard to do, but realized I'd sink a couple weeks into just getting the board going... not the right course for this project. So I'll buy it... there must be an inexpensive pre-built package out there. I did some research and found a few candidates, but none quite right. Then I remembered the "Rabbit" line of controllers, and I ordered one of these:

It's a RabbitCore RCM4010, an all-in-one 60MHz processor with 512K Flash, battery-backed realtime clock, and Ethernet support (all in 2" x 2.5"), with an included development kit (power supply, C compiler, prototyping daughterboard, etc).
For $99 I have everything except the LED sensors!

I figure I'll write a simple embedded app that stores the pumps' on/off state changes with a timestamp and store the data until the PC asks for it. At 6 bytes per event (4 for timestamp + 2 for pump states) the 512K Flash holds 87,000 events - at 100 events/day that's over 2 years' worth of storage.

September, 2008
I've needed to redesign my hardware. Based on the docs claiming the RCM4000 has 5 byte-wide I/O ports, I figured that I'd just have the processor read the IR transistors directly. It turns out that the RCM4000 does indeed have 5 byte-wide I/O ports, however all but one of them (port A) are comitted to stuff like memory, A/D conversion, serial ports, Ethernet, etc, so in reality I only have 8 bits of user I/O.
My solution is to use a pair of MCP23S08 SPI I/O expanders, one for each relay box. I'll use PortA to drive the chips SPI interfaces... easy enough.
October, 2008
I can't get the SPI slaves to work - they always read 0xff (all pins hi) - yet the must work. SPI isn't rocket sience, and I've used it extensively in the past. Something is odd.
After a lot of frustrating experimentation, I found the answer: Buried in the RCM docs is a tidbit that says Port A (the only uncomitted port) can only be set to all-inputs or all-outputs. All the other ports can be set to I/O on a bitwise basis, but Port A is different. I'm starting to regret my choice of basing this project on a Rabbit product. If I had used a Microchip product I'd be done by now... the initial cost savings of the RCM has been many times lost on the time I've spent trying to coerce the Rabbit into doing even the most basic things.
After some pondering, I decided to steal a input-enabled pin from one of the other ports. Had to disable some features to free up that pin, but it works, and I can now talk to my MCP23S08's as expected.
a week goes by...
It turns out that I need a different RabbitCore. I had planned on using the RCM4010's battery-backed EEPROM for data storage, but I can't get it to reliably store data. Several memory blocks get corrupted during power cycle.
After monkeying with this for WAY too long, I'm punting and getting an RCM4000, which has 32MB of Flash... hopefully the Flash will be more reliable.
(Followup: Yes, the RCM4000's Flash is reliable.)

November 7, 2008
At long last, everything seems to be working. The hardware is stable, the firmware is complete (for version 1.0) and my Windows app can control the thing.
Here's the unit all boxed up:

The yellowish PCB is my daughterboard with the MCP23S08's; the green board is the RCM4000. Power comes in at right (black wire), ethernet at the top (blue wire).

Here's the unit installed in the corner of the boiler room:


I included an RS232 port on the bottom of the unit (grey cable) for debug. The unit sends all sorts of data to the RS232 port as it's running, and I can watch it with a PC:

November 22, 2008
I can't get the RCM to find the Ethernet connection. It did connect perfectly in my office, but I can't get it to connect from any other port on my entire home network. Very strange.
Rabbit tech support (which is useless) asked me to RMA the core, and I did, but the replacement has the exact same behavior.

December 18, 2008
Though things went decently well in the development phase, it's become frustratingly clear that the RabbitCore isn't going to work. After wrestling with it for the past couple months (not full time, obviously), I just can't get it to work.
Major problems include: I need to reevaluate my choice of processor for this project. Given all the frustration and wasted time, the Rabbit has NOT been very cost-effective (and, of course, it still doesn't work). Probably time to go back o the drawing board and use something more robust, like a Microchip part (which I'm kicking myself for not using in the 1st place).

This project has failed :(

It turns out that I'll stew about it for 3 years before I start afresh with Version 2 of the project.

Questions? Comments? email me!