Hacking Eaton HomeHeartbeat Part 7: Success!

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!

10 thoughts on “Hacking Eaton HomeHeartbeat Part 7: Success!”

  1. I am at the ege of my seat reading this! I am very excited to start getting the technical details. I prefer option 3 the most only because it seems like it is fully utilizing the HHB hardware. Option 2 seems to almost make the HHB station obsolete.

    I agree long term option 1 is the most prized. I currently have a vera2 and zwave modules, as well as some x10 stuff. The reason I am extremely interested in the HHB is because it seems to pick up where the other two leave off and that is home awareness…

    Ideally what I want to accomplish is have the HHB connect to my linux system (ttylinux), in which my linux system will convert the serial interface to tcp socket messages. Similar to what the Mochad project does for the x10 usb interface. I can write the socket interface, I just need to start understanding the HHB serial data to decode it. Also I would like to be able to send data back into the HHB to be reported such as if the alarm is armed, etc.

  2. Glad to hear you’re enjoying the posts! It’s kind of a neat experiment, as I’ve acquired enough microcontroller experience over the last year or so to be able to understand how it all works.

    Regarding option 2, I don’t think I explained the concept well enough. I’m looking at replacing the HomeKey dongle with a custom device; the base station and the rest of the components remain exactly the same. The new device would simply act as a wireless bridge between the base station and the rest of the world. The primary advantage to this approach is that there is a lot more information available via this mechanism than over serial.

    The serial approach should support most of what you are trying to accomplish, though the device is pretty limited in this regard. The base station sends a prompt when any registered device’s state changes, and this state information can be easily queried. Don’t expect too much here though, as a device is either “signalled” or “not signalled”. Other information such as sensor battery level, signal strength, etc is available via ZigBee but is not available over serial. Regardless, the status information could easily be processed and sent out via ethernet using MQTT or whatever protocol strikes your fancy.

    I’d be interested in hearing about your experiences with the vera device. I have quite a few ZWave devices scattered around my house and did a lot of the preliminary work on the Python port of the OpenZwave project. Keep in mind that ZigBee is NOT the same as ZWave – ZigBee operates in the 2.4GHz frequency range, while ZWave is in the 900MHz range. I currently have a crazy mix of ZWave, Insteon, and X10 devices in my house. That’s a subject for another post though 🙂

  3. Hi Steve,

    Several months ago I went on the same mission as you. I got as far as getting on the USB connection and figuring out the commands, and I also sniffed the 802.15.4/Zigbee traffic with a Zena board. I also bought the Chibi Wireless board and did some sniffing using Wireshark, but that did not yield great results, even with some code fixes. The end result is that I have a bunch of sensors (water, motion, power, contact, etc), two HHB stations and keys, but stopped messing with this project before I got something working end-to-end. The traffic over the Zena board was showing some encrypted packets. From some of the notes I took I see that going into test mode and using the “tokdump” command returned some information that showed some “encryption key”, although it seems it is always 0xFFs, and there is a nonce counter that changes. I found the work with Killerbee and figured that would be the next step for me, but never got to it. Just today I decided to Google on this and found you’ve gotten closer to the answer, so I’m really looking forward to your findings.

    Thanks for sharing all of your work,


  4. Edmund,

    I’ve got a basic monitoring solution in place using the USB/Serial port. There’s just enough information available using this interface to report sensor status changes. The ZigBee option is more attractive long-term as there is a lot more detail available via this interface (battery life, signal strength, etc to name a few).

    While sniffing ZigBee traffic I also noticed a couple of packets marked as encrypted as well as quite a few corrupt packets. The corruption is a bit odd as the sensors are all sitting within 1m of each other, though I suppose that it is possible that their close proximity could cause some problems. I’m looking forward to doing some more general ZigBee/802.15.4 research so that I can better interpret what I’m seeing.

    The HomeKeys are really chatty, at least as they are configured out of the box. Most of the ZigBee traffic that I was seeing was between the base station and the HomeKey.

    1. Your work convinced me to dust off my Home Heartbeat hub and a few of the sensors and do some playing again. I was curious about your statement “there’s just enough information available using the serial port to report sensor status changes”. The only way I seem to be able to see sensor status changes, without polling for data, is by toggling debug ( “a” command), but the output is not very readable, so I was wondering if you spent the time decoding this output or you had some other way of being able to detect and interpret the status changes. If you are using the debug output for the status changes, would you mind sharing how to interpret that output? This is an example of what I see for the debug output:
      D=”>14,10 -0 wait:14,10 Mu-0-53/10 ACK:237,14!_0-14 d:53 d:53 d:53 d:53 Mu-0-22/10 eICUH:
      >53,13 -0 _0-53 Mm-55/9 FROM:255 HLO-255-255 Batt.
      Mu-0-22/10 eICUH: i(2) f(0) >53,7 -0 >37,5 -0 _0-53 wait:37,5 Mu-0-53/10 ACK:245,37!_0-37
      >53,6 -0 _0-53 Mm-55/9 FROM:255 HLO-255-255 Batt.
      Mu-0-22/10 eICUH: i(2) f(0) >53,5 -0 >37,11 -0 _0-53 wait:37,11 Mu-0-53/10 ACK:251,37!_0-
      >53,13 -0 _0-53 Batt.
      Mm-55/9 FROM:255 HLO-255-255
      FOB all found 4,0: 01
      == FOB RANGE LOG ==
      0x01 0x01 0x01 0x01 0x01

      Mu-0-22/10 eICUH: i(2) f(0) >53,9 -0 >37,10 -0 _0-53 wait:37,10 Mu-0-53/10 ACK:2,37!_0-37
      >53,3 -0 _0-53 Batt.
      Mm-55/9 FROM:255 HLO-255-255 Mu-0-22/10 eICUH: i(2) f(0) >53,6 -0 >37,10 -0 _0-53 wait:37
      >53,4 -0 _0-53 Batt.
      Mm-55/9 FROM:255 HLO-255-255 Mu-0-22/10 eICUH: i(2) f(0) >53,10 -0 >37,9 -0 _0-53 wait:37
      >53,7 -0 _0-53 Batt.
      Mm-55/9 FROM:255 HLO-255-255 Mu-0-56/10
      >53,13 -0 _0-53 Mu-0-22/10 eICUH: i(2) f(0) >53,8 -0 >37,11 -0 _0-53 wait:37,11 Mu-0-53/1.
      >53,7 -0 _0-53 Mu-0-22/10 eICUH: i(2) f(0) >53,13 -0 >37,5 -0 _0-53 wait:37,5 Mu-0-53/10 ”

      Another thing, I have one of the Atmel RZUSBSTICK boards with the default firmware, is this what you ended up using to snoop on the packets? If so, did you reprogram the RZUSBSTICK? Would you mind sharing some details on this? I would not mind setting it up and see how I can help with this project.

      Just to give you an idea of why I’m interested in this work, I’ve written code to integrate Zigbee thermostats into an open source home automation project called Openhab (http://code.google.com/p/openhab/) and I’d like to integrate the sensors from the HHB as well. I have code to monitor and manage an HAI security system as well and will be integrating that as well with Openhab.


      1. Apologies for leaving you hanging, haven’t had time to write up a proper post about interacting via serial. There’s nothing secret or particularly complex about what I’ve discovered, in fact it’s almost laughably simple.

        I haven’t taken the time to decode the debug information. The most useful and consistent information I’ve found is gathered by polling via the ‘S’ command. Constant polling is not required – the serial port prompts with a message when updates are received (the “STATE=NEW” message in your detail above).

        The data returned by the ‘s’ command is quite simple; it is just 17 fields separated by commas. Of particular interest are fields 2 (binding id), 4 (device class), 5 (state), and 17 (device name). You can find device class and state details in my sensor post. I’ll write up more details when I get some spare time.

        There’s just enough information available with this mechanism to provide basic alerts. If it provided sensor battery level and signal strength it would be a lot more useful. It’s possible that this information is contained in the debug info, something else to play with when time permits.

        Regarding the RZUSBSTICK, I’m just using the default firmware at present, piping data into wireshark using the killerbee tools. I can write up more detail about this if anyone is interested, it is pretty straightforward though. I believe that Atmel also provides some wireless tools that can sniff and decode packets as well, though I haven’t explored this option as it is Windows only. The stick can be updated to allow ZigBee injection capabilities with Travis Goodspeed’s GoodFET device; I’m waiting for my Chibi boards to arrive to play with this aspect of things.

        I think that the KillerBee tools may be slightly buggy, as I saw a lot of bad packets as well as some that were marked as encrypted. As these latter were almost always surrounded by bad packets, I think this is just something in the stack misinterpreting state. More digging is required here.

        OpenHAB is an interesting project, and is one that I’ve had my eye on for a while now. Being Java- and OSGi-based it’s a little bit too similar to my day job though… In any case, you should be able to build a simple plugin for HomeHeartbeat with very little code. Does OpenHAB support MQTT or some other network-based pub/sub model?

        1. Thanks for the info on the sensor status.

          I should have some time this coming weekend to look into sniffing packets with the RZUSBSTICK. I bought a couple of boards from Travis (latest GoodFET boards) and built one, so I should be able to program the RZUSBSTICK if needed. I got the GoodFET board to re-program one of those IM-me devices to turn it into a spectrum analyzer (http://hackaday.com/2010/03/17/im-me-spectrum-analyzer/) and that worked fairly good. I have an extra blank PCB for a GoodFET, if you think you’d like to build one let me know I’ll be happy to mail it to you for free.

          Like I mentioned before, I played with the Chibi and the Wireshark bridge, and the results where not very good, even after applying code fixes to the bridge code. The Zena sniffer was more reliable.

          I picked OpenHAB because I liked the general architecture, it is well written, and fairly easy to extend. I’m also very familiar with OSGi and Java, so it was natural for me. There is no binding for MQTT and the internal event mechanism is based on the OSGi Event Service (it is a pub/sub model but only internal), not MQTT, so if you want to use that you would have to do the integration work, but I can see where it may be interesting to do it. Maybe MQTT support can be added in such a way that the internal OpenHAB events can be posted as MQTT events and vice versa, MQTT events posted as internal OpenHAB events. This could turn into a good way to bring in the IoT concept, which is being considered right now for the project.

          1. Thanks for the GoodFET offer – I sent you details to your personal email, would love to get my hands on one to play with.

            I messed around with the debug log messages a bit more (I recorded several hours worth of serial messages) and still don’t see much useful information. This is a good example of the type of information that I’d love to get from Eaton. Sigh.

            Serial polling is definitely the easiest way to tackle simple integration, but I’d also like to see how far I can get with the ZigBee data. Let me know if you make any progress in this area!

            Thanks for the info about OpenHAB, I may need to take a closer look at the project. I spent some time with the Domogik project last summer and contributed some code. Unfortunately there was just too much churn with that project and I set it aside out of frustration.

            Do you think the problems that you encountered with the Chibi stack were hardware or software related? I’ve heard nothing but good things about the hardware. I’ll be interested in hearing about your experiences with the RZUSBSTICK to see how it compares with the Zena. TI also has some nice RF tools (via their Chipcon acquisition), so that may be another option.

        2. Steve,

          I spent some time messing with this stuff and figured out a few things from the state table (“S” command output). Field 7 holds an OR’ed value that is decoded as:
          0x01 – Sensor in alarm state
          0x04 – Low battery
          This does not show the battery level, but at least lets you know when the battery will need to be changed. Other fields are:
          8 – Device name index. When you set the name of the device using the key you pick a name from a list, the entry number in that list (0 relative) is what gets returned in this field.
          9 – call-me and in-home awareness setting. The first 2 digits apply to the call-me awareness, the second two apply to the in-home awareness. The values are indexes that represent the selection.
          13 – delay index or power sensitivity. For a power sensor, this is a number that corresponds to the entry in the selection for sensitivity (0 relative). Sensors that allow for a delay value will show a number that corresponds to the entry number in the list of possible delays.

          Hope you find this helpful.

  5. I’ll send you the board tomorrow. You’ll have to order a few parts, I’ll include some parts for which I have extras, and you’ll have to solder the PIC processor (QFP package) which turned out not to be so hard after all. Once I built the board, which took about 1 hr or so, I was able to put the firmware in it and re-programmed the IM-me, all without any HW or SW issues at all.

    The Chibi HW is very nice. Is well built and well designed, IMHO. The problem area was the bridge SW to interface it to the Wireshark, that did not work well, which means it was not good as a RF sniffer. Other than that issue, I think you will find the Chibi to be a really nice piece of HW. I can see where it could be suitable to interface to the HHB and sensors.

    BTW, I also have the EATON Home Heartbeat Broadband Gateway, which I hooked up and had working for about a month with the intention of figuring out if I could use it to interface to the HHB base. Unfortunately they killed the service shortly after I got it, and did not spend the time to figure it out. I did save a capture I did using Wireshark (used an Ethernet hub to “tap” in), maybe I’ll go back to it to see if I find anything interesting. The capture is about 105MB uncompressed, but is mostly text, so it should compress very well, let me know if you are interested in that data.

    As for the OpenHAB project, I think you won’t be disappointed if you spend time on it. The folks working on the project are active and the project seems to be well managed. The code is well put together and the projects is fairly active. I’ve been following it now for some time and definitely worth my time. I looked at other similar open source projects and decided this was the one to go with. If you decide to go with it, I’d be happy to share what I know with regards to coding and use of OpenHAB.

Leave a Reply

Your email address will not be published. Required fields are marked *