keypic

Hacking Eaton HomeHeartbeat Part 8: Sensors

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

Gallery not found. Please check your settings.

15 thoughts on “Hacking Eaton HomeHeartbeat Part 8: Sensors”

  1. Hi Steve,

    I connected a TTL level serial port to an Open/Close Sensor. After some screwing around, I figured out how to get into a test menu. Below are the options in that menu.

    [t] Transmit 100 packets

    [r] Receive packets

    [p] Transmit a pure tone

    [s] Transmit a continuous stream of data

    Change channel to x (hex)

    [tokdump] Dump tokens

    [tokwrite X] Write token X

    [tokread X] Read token X

    [z] Sleep microprocessor

    [m] Memory test (fob and base only)

    [a] ADC test (water and appliance monitor only)

    [|] Start bootloader

    [e][x]it

    If I choose the tokdump, I got the following data:

    > tokdump

    (data shown little endian)

    [FF09]MFG_NVDATA_VERSION FD 02

    [B634]EUI_64 27 C6 00 00 00 6F 0D 00

    [B635]EUI_64_HASH B7 7A 1F 18 21 9D DF 00

    [ED73]MANUFACTURING_STRING FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

    [F262]RADIO_BANDS_SUPPORTED 08

    [E36F]RADIO_CRYSTAL_OFFSET 00

    [FF01]STACK_NVDATA_VERSION FD 02

    [F069]PAN_ID FF FF

    [E772]GRAD_ENABLE_RELAY FF

    [F270]RADIO_TX_POWER FF

    [F263]RADIO_FREQ_CHANNEL 09

    [E56B]ENCRYPTION_KEY FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

    [E965]ID_ASSIGNMENT_ENABLED FF

    [E263]BOOT_COUNT FF FF

    [E769]GRAD_NODE_ID FF FF

    [E563]ENCRYPTION_NONCE_COUNTER FF FF FF FF

    [FF07]RESERVED FF

    [E162]ANALYSIS_REBOOT FF FF

    [E974]ID_AUTHORITY_TAG FF FF FF FF FF FF

    [FF03]STACK_NVDATA_END FF

    [E274]BINDING_TABLE FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

    Perhaps these tokens will be of some value when decoding the data.

    1. Interesting, but unfortunately not very useful. That same diagnostic menu is available on my new base station (but not on the previous station that gave up its life for the cause). Looks like a lot of the fields are either unused or not initialized. It would be interesting to see if changing the encryption keys would have any effect. Ive already confirmed that traffic between these devices is sent unencrypted.

  2. Hi Steve,

    What is the symptoms of your unit that “died for the cause”? I managed to brick and then recover my base unit tonight. Here is what happened. I was playing around with the menus on the serial port and got into the bootloader section. I could not figure out how to get out of this menu, so, I just pulled the power plug with the USB cable still attached. When I reconnected power, none of the LEDs would light up and nothing appeared on the serial port. The unit appeared to be dead. Disconnected for 1/2 hour and still dead. No LEDs and the fob said the unit not available when attached.
    I assumed that upon removing power, it corrupted some of the flash. However, it was really just stuck in bootloader mode.

    Here is how I got it back.
    1. Plug in the power cable and the USB cable. Open a serial console window and connect to the serial port assigned to the USB interface using the usual parameters.
    2. The unit will appear dead. Take a magnet and run it across the top of the unit to trigger the reed relay. Then within about 10 seconds send a ‘?’ to the unit with the serial console. On my unit it returned the bootloader menu.
    3. To exit the bootloader menu. Choose option 3. Which is execute the application. This seems to do a cold boot, and the unit thinks its new again.

    On my unit after doing the above. It was active again. It sees the fob again and appears to be working.

    1. Symptoms? Heh. It’s dead. I was a bit rough with the probes when I was trying to follow traces and managed to short a couple of pins on the ATMega128. OK, maybe more than a couple. The bottom row of pins is pretty much a solid block of solder . Someone with a hot air rework station could probably fix that without much effort. Since I only paid $5 for that base station I’m not stressing too much about it. Worst case I’ll just pull the components on the board to use for other projects; as an added bonus this will also allow me to follow some of the traces that are hidden by other components.

  3. I just bought a Home Heartbeat key and 3 water sensors. Is there a easy way to get a + or – level when one of the sensors is activated. My idea is to use these as sensors for a water leak and then activate a water solenoid and relay for the pump.

    Thanks

    Ron

    1. Ron – the water sensor is a binary sensor – it just reports whether or not the sensor is wet. I suppose you could arrange several sensors on some sort of vertical support to create a crude depth sensor, if that is what you are looking for (though there are specific float sensors available that would be much more accurate for this purpose).

      You didn’t mention whether you got a base station – that is also a required piece to use the HomeHeartbeat stuff without modification.

  4. I do have the base station. Want to use the sensors as leak detectors. What I mean by + or – is a voltage change that I could use to switch the above mention items in my first post.

    Have a Good Day
    Ron.

  5. I have the base station hooked to my Linux box with the addition of the FTDI driver. I would like to hook to a microcontroller instead.

    Are there microcontrolers capable of the FTDI interface? Has anyone done this?

    Is there a cable that can be plugged into the home base that will result in a different interface, say maybe RS232?

  6. The FTDI interface is simply a TTL-level serial to USB adapter. The easiest way to interface the HHB with an external microcontroller would be to open the device and solder new lines directly to the Tx/Rx pins of the FTDI chip. To my knowledge there is no cable that does what you are asking for; the existing interface requires a USB host. There is no technical reason why you could not build such a beast if you were opposed to opening the base station, but there are much more direct routes to the serial data.

    1. Thanks Steve,

      Lets assume that my goal is to take an unmodified base station, and plug the usb port directly into a microcontroller’s USB port the same way I plug it into my Linux workstation. Is there a microcontroller capable of this FTDI protocol?

      If this is not possible, my fallback position is to use a Linux capable device such as a router with USB and simply install the FTDI driver on it.

      I am not a Arduino user, but I read somewhere that some of the models have an FTDI chip on it for its usb port. Could these be used in the fashion that I speak?

      And for reference, I am writing a client/server application that permits monitoring of HHB sensors from the web.

      1. As I said, it’s technically possible – you would need a microcontroller which could act as a USB host as well as a driver that understood how to interact with the FTDI device. There are several Atmel devices that speak USB natively (see http://www.pjrc.com/teensy/ for an example) Take a look at the “Code Library” section on that site, it’s quite possible that this is a solved problem. I have several Teensy devices that I’m using in various projects, they work quite well and the company is extremely knowledgeable and responsive. Let me know what you discover…

        1. Here is my solution. Take one Linksys NSLU2, add OpenWrt 10.03 ‘backfire’, and install the ftdi_sio module, and there you have it. A little ash scripting later, and I have a working HHB Internet server. If I had to make a hundred of these it wouldn’t be cost efective, but then I just had an NSLU2 collecting dust.

        2. Hi Steve,
          Have you had any luck with getting HHB online or at least sending text messages? I have one and looking for ways to get text or email notifications out from the HHB.
          Thanking you in advance.

          1. Paul,

            Im currently using a Raspberry Pi to talk to my HHB. It acts as a bridge device between my custom home automation system and other devices. More of a proof of concept at this point but it is functional.

            In my case, software running on the rPi listens to the HHB, 1-wire, and X10 wireless and re-transmits events via MQTT. Another application listens for MQTT events and forwards them to Cosm for graphing. You could do something similar to send SMS text or email.

            Raspberry pi is a nice little embedded Linux board which costs $30. They are hard to find right now due to demand.

  7. Hi Steve,
    How are you reading the events from the HHB? Do you just enable the debug log and read status from that? Also, are you able to write data back to the HHB such as to communicate with the Keyfob? Just curious on how far you got with it. I have a debian linux system that I am running for my home automation system, but have not integrated my HHB into it yet.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>