This post documents my research into the HHB sensors, complete with pretty pictures. With the exception of the power sensor, these devices are all variations on a similar theme. They all contain the same Atmel ATMega64L MCU and Ember EM2420 ZigBee/802.15.4 wireless chip with supporting devices. There are some minor variations in the area of the board which interfaces with the particular sensor function (magnetic switch for open/close sensor, header for tilt sensor, etc.) The footprint of the ATMega64L and utilized pins are identical across all of the sensors, as is the magnetic reed switch (for HomeKey sensing/registration), crystals, and ZigBee antenna.

Power Sensor

As configured, this sensor simply reports whether or not a load is active on the device plugged in. Device class is reported as (id: 0004). State reports (state: 1) when load is off and (state: 2) when load is turned on.

The internal design leads me to believe that the device was originally intended to me much more fully featured than what was actually shipped:

This is an interesting design, and I believe that it’s capable of a lot more than is being utilized at present. Looking at the front side of the board in this image, you will notice four main sections: The MCU with the ATMega64L and ICSP header, the RF section with the EM2420 ZigBee chip and supporting components, and a bunch of other components. After following traces on the board and consulting a couple of datasheets I realized that these remaining components actually provide two discrete functions. First, the majority of the remaining components allow the sensor to be directly powered via AC mains voltage. This function is primarily provided by U5, which is a LNK305 switching IC. The final function provided is load sensing, which is performed by a large current transformer (CT), which is an AC-1005 5 Amp Current Transformer from Talema India. Output from this CT is converted to DC via a small HD04 Bridge Rectifier which then presumably feeds in to the ATMega64. I was unable to find the specific analog pin which reads this value, though PC0 and/or PC1 are likely candidates.

What this means, ultimately, is that it should be possible to measure actual current consumption for the load plugged into the device rather than simply reporting an “on/off” state condition. The fact that the device configuration available through the HomeKey provides several different sensitivity profiles tells me that the output of the rectifier is indeed being measured. Whether this omission was due to cost cutting efforts, safety concerns, or limitations of the rest of the stack is unknown.

Another interesting point worth noting are the empty footprints at U7 and U8 on the back of the device; this layout is identical to the footprint for the IS62LV256 static RAM used on the base station. Perhaps this was intended to support more advanced load tracking / current consumption metrics?

Moisture Sensor

Sensor utilizes simple dry contacts to determine wet conditions. Device class is reported as (id: 0005). When the pins on the remote sensing puck are shorted, the device reports (state: 2); otherwise it reports (state: 1). This is a transmit-only sensor.

Reminder/Attention Sensor

These two sensors perform nearly identical functions and are absolutely identical physically. Device classes are reported as (id: 0006) and (id: 0007), respectively. I still need to document the state transitions for these two devices. Ultimately I question their usefulness. From a user interaction perspective, they blink a light until the button is pressed. Time between initial trigger and new states is configurable. These sensors both transmit and receive data; they contain a button which sends a message to the base station when pressed, and they also have a single green LED which indicates status.

Motion Sensor

Simple passive infrared (PIR) motion sensor. Device class is reported as (id: 0017). Reports (state: 1) when no motion detected, and (state: 2) when motion has been detected. No additional alerts are transmitted if additional motion occurs within configured delay. After motion is detected, the sensor will send a new (state: 1) alert when no motion has been detected within the configured delay. This is a transmit-only sensor.

Garage/Tilt Sensor

This is a simple tilt sensor. Device class is reported as (id: 0018). Reports (state: 1) when vertical, (state: 2) when tilted to horizontal. This is a transmit-only sensor.

Pictures

[Show as slideshow]

Spent a good deal of time on Saturday working with the Base Station and my collection of sensors. I’ve managed to decipher enough information from both the Serial and ZigBee side of things to come up with a workable solution for my needs.

I picked up an Atmel RZUSBSTICK (Available on Mouser and elsewhere) based upon information from Josh Wright’s published ZigBee documentation. His KillerBee framework was invaluable in my effort to understand the Home Heartbeat’s wireless communication. I’ve ordered a copy of [amazon_link id=”0071666613″ target=”_blank” ]Hacking Exposed Wireless, Second Edition[/amazon_link] in order to delve a bit deeper into this realm, as it’s quite interesting. Josh’s Toorcon slides are a good read as well if you’re interested in this sort of thing. The HHB’s usage of ZigBee is very basic, and took surprisingly little time to decipher once I had the proper tools to monitor the traffic.

I’ve explored three primary avenues for modding the original HHB base station for my needs. The first option involves developing new firmware for the HHB. Since the HHB base station is based upon an Atmel AtMEGA128L, this would certainly be technically possible. If I had more time at my disposal I may have selected this option; starting with an assembly dump of the existing binary image would provide a pretty good start.

The second option involves developing an intermediate device which acts like a Home Heartbeat key but which provides an interface to additional functionality. The device would utilize a simple ZigBee radio to speak with the base station. The base station/key protocol is quite straightforward. This approach has several advantages: the base station basically remains in its unadulterated form, and the new device could provide any number of additional features (internet connectivity for notifications, etc). The Chibi Wireless Board from the fine folks at FreakLabs would be an ideal platform for this effort, as it provides the necessary wireless hardware, is Arduino compatible, has a proven track record (Safecast.org hardware is based upon this board), and is cheap as well – $30 USD for the bare board. I will probably pursue this option in the long term, as it would be an interesting project to work on. I’ve already ordered a couple of Chibi boards with enclosures to experiment with. Check out the site’s wiki as well – Akiba does some amazing work, and the best way to support his efforts are by buying stuff from his store.

The final (and simplest) option involves interacting directly with the base station as a serial client. There is enough information available via serial to interact with the sensors and report on activity. I’ll be basing my solution on this approach using the [amazon_link id=”B005D1U3TY” target=”_blank” ]Arduino Ethernet[/amazon_link] board; stay tuned for build details.

Throughout all of my digging I’ve come to the conclusion that the HomeHeartbeat device and sensors have a lot of hacking potential. As they are all built around the Atmel ATMega microcontroller (ATMega128L and ATMega64L), it should be possible to build out some simple tools to take advantage of all of the available Arduino libraries to build some pretty cool devices. The HomeKey in particular would be fun to hack, with its built-in backlit graphical LCD screen, thumbwheel, and ZigBee radio. I’ll spend some time tomorrow documenting my findings with the HomeHeartbeat sensors; lots of pictures and technical information to share!

Keep the comments coming – I’d love to hear more about how people are using this hardware as well as any crazy ideas that you may have for hacking the hardware. Please respond via comments rather than emailing me directly so that the discussion is not just limited to two people. I’m hearing a lot of duplicate information and requests from people via email. It’s been really cool to see my site traffic picking up over the last couple of weeks!

Well, the good news is that I got an entire day to dissect the HHB base station, and now have a much more thorough understanding of the inner workings of the device. The bad news is that I managed to kill my base station in the process, probably by mercilessly probing for continuity trying to decipher internal device connections. C’est la vie – good thing these things are cheap. I hopped on Ebay and ordered a couple of new base stations in case I manage to kill another one, should be here next week. Read on for full details! Continue reading Hacking Eaton HomeHeartbeat Part 6: Autopsy →