Difference between revisions of "Eaton Home Heartbeat"

From Bloominglabs
Jump to: navigation, search
(Further work)
 
(9 intermediate revisions by one user not shown)
Line 5: Line 5:
 
Once I got my unit I was able to get a perl script running which outputs useful human-readable data. There are a couple good sites with information about this system but no one has yet posted a monitoring script. Mine is posted at the bottom.
 
Once I got my unit I was able to get a perl script running which outputs useful human-readable data. There are a couple good sites with information about this system but no one has yet posted a monitoring script. Mine is posted at the bottom.
  
I have the base station (comes with a Home key), motion sensor, water sensor, open/close sensor, and power sensor. The "Home key" allows you to receive notifications when you are within range of the base station. When you are out of range this apparently told the base station to call-home and text you when there was a worthy notification. The Home key is also used to program new sensors into the system. Apparently there is a reed-relay in each sensor and the key which allows for simple ZigBee pairing just by sliding the key into the top of each sensor.
+
I have the base station (comes with a Home key), motion sensor, water sensor, open/close sensor, and power sensor. The "Home key" allows you to receive notifications when you are within range of the base station. When you are out of range this apparently told the base station to call-home and text you when there was a worthy notification. The Home key is also used to program new sensors into the system. Apparently there is a reed-relay in both the sensor and the key which allows for simple ZigBee pairing just by sliding the key into the top of each sensor.
  
== Sensor List ==
+
 
 +
== Component List ==
 +
* Base station
 +
* Home key (key ring adapter, has multiple purposes)
 +
* Modem (built in to base station, no longer usable)
 
* Open/Close sensor
 
* Open/Close sensor
 
* Motion sensor
 
* Motion sensor
Line 16: Line 20:
 
* Reminder sensor
 
* Reminder sensor
 
* Remote water shutoff
 
* Remote water shutoff
 
==== Additional parts ====
 
* Home key (key ring adapter, has multiple purposes)
 
* Base station
 
* Broadband gateway
 
 
* Range extender
 
* Range extender
 +
* Broadband gateway extender
  
  
== Connecting with minicom ==
+
Something I did not realize until another Home Heartbeat user clued me in was that the Broadband Gateway Extender also acts like a range extender.
So the first gotcha is that the vendor ID for the base station is unique. It's still just an FTDI USB serial device though and that is easy enough to fix (at least on Linux).  
+
  
 +
 +
== Connecting to the base station's USB port ==
 +
The base station has a USB port which can be used to extend the systems functionality. So the first gotcha is that the vendor ID for the base station is unique. It's still just an FTDI USB serial device though and that is easy enough to fix (at least on Linux).
 +
 +
=== New method for systemd ===
 +
This is for ubuntu/raspbian, or any other unfortunate person inflicted with systemd. Create a new file here:
 +
<br>/etc/systemd/system/multi-user.target.wants/fixhh.service
 +
 +
<pre>
 +
[Unit]
 +
Description=config ftdi for home heartbeat serial
 +
 +
[Service]
 +
Type=oneshot
 +
ExecStart=/sbin/modprobe ftdi_sio
 +
ExecStart=/bin/sh -c "echo '0403 de29' > /sys/bus/usb-serial/drivers/ftdi_sio/new_id"
 +
 +
[Install]
 +
WantedBy=multi-user.target
 +
</pre>
 +
 +
Now you should be set for the ftdi_sio driver to load and recognize your Home Heartbeat serial device on boot. You can initialize it without a reboot with this:
 +
systemctl start fixhh
 +
 +
You should see a new device named similarly to /dev/ttyUSBx where x is a numeric 0-9 depending how many ttyUSB devices you already have attached to your host.
 +
 +
 +
=== Centos 5/6 method with the updated ftdi driver ===
 +
Apparently the newer ftdi_sio module (starting in 2015) silently stopped accepting the option flags "vendor" and "product" as they were intended to be debugging features, not end-user features :-P.  So the new way to get the module to work with this device:
 +
echo "0403 de29" > /sys/bus/usb-serial/drivers/ftdi_sio/new_id
 +
 +
Now you should have a new /dev/ttyUSBx device. The connection settings are <b>38400 8n1</b>, any terminal program will do. The serial interface has a built-in help screen (type ?) with lots of commands. This is all well documented at some of the other sites talking about Home Heartbeat so I won't rehash that here.
 +
 +
=== Old method (centos 5/6) pre-2015, plus udev muckery ===
 
* Add modprobe line for ftdi_sio driver, get vendor and product lines from lsusb (RHEL5/6 and CENTOS 5/6):
 
* Add modprobe line for ftdi_sio driver, get vendor and product lines from lsusb (RHEL5/6 and CENTOS 5/6):
 
** echo "options ftdi_sio vendor=0x403 product=0xde29" > /etc/modprobe.d/ftdi_sio.conf
 
** echo "options ftdi_sio vendor=0x403 product=0xde29" > /etc/modprobe.d/ftdi_sio.conf
Line 39: Line 72:
 
Now you should have a new /dev/ttyUSBx device and possibly a /dev/hh device if you added the udev rule (not required). The connection settings are 38400 8n1, any terminal program will do. The serial interface has a built-in help screen (type ?) with lots of commands. This is all well documented at some of the other sites talking about Home Heartbeat so I won't rehash that here.
 
Now you should have a new /dev/ttyUSBx device and possibly a /dev/hh device if you added the udev rule (not required). The connection settings are 38400 8n1, any terminal program will do. The serial interface has a built-in help screen (type ?) with lots of commands. This is all well documented at some of the other sites talking about Home Heartbeat so I won't rehash that here.
  
== Perl script ==
+
If you find that doing the above doesn't generate a new ttyUSBx device, watch the output of "dmesg" for these errors:
* [[File:Hh.tgz]] - hh.pl - digests the state table from a USB connected base station. It currently has two text-mode types of output and can also generate an html file for easy viewing from a phone. Simply plug into cron using the correct flag and home status can be viewed any time. It also has some email functionality which can be triggered by alarms, however I have not tested that yet.
+
  
 +
[2884971.187297] ftdi_sio: unknown parameter 'vendor' ignored
 +
[2884971.187333] ftdi_sio: unknown parameter 'product' ignored
  
== Further work ==
+
This tells you that you are using the newer ftdi_sio module and you need to use the "New method" listed above to add the device.
One thing I am interested in is being able to build my own sensors which can interface to the system. I already am working on a separate environmental monitoring system for my house however I'd love to reduce its footprint by expanding this nice system. It seems that an ordinary 2.4GHz ZigBee sniffer like the Atmel Raven or Freakduino would allow sniffing of the protocol. Others [http://buzzdavidson.com/?p=331 here] have confirmed that the data is sent unencrypted so it should be feasible to implement their protocol with some sniffing.
+
  
  
==== Hardware ====
+
== Hardware ==
 
The main board common to all of the sensors uses an Atmel ATMega128 with an Ember (Silicon Labs) EM2420 RF chip for the ZigBee duties.
 
The main board common to all of the sensors uses an Atmel ATMega128 with an Ember (Silicon Labs) EM2420 RF chip for the ZigBee duties.
  
* [http://www.datasheetcatalog.com/datasheets_pdf/E/M/2/4/EM2420.shtml EM2420 datasheet] - Note that this chip is for 2.4GHz, the base station will say something about being on channel "0x09" which is a 900MHz ZigBee channel. However the datasheet proves that this is impossible.
+
* [http://www.datasheetcatalog.com/datasheets_pdf/E/M/2/4/EM2420.shtml EM2420 datasheet] - Note that this chip is for 2.4GHz, the base station will say something about being on channel "0x09" which is a 900MHz ZigBee channel. However the datasheet proves that this is impossible, actually it appears Home Heartbeat uses ZigBee channel 14, more in the wireless section below.
 
* [http://www.metageek.net/control4/zigbee-channels/ ZigBee channels]
 
* [http://www.metageek.net/control4/zigbee-channels/ ZigBee channels]
  
 
Additionally, the comments in this thread have some info on getting a serial terminal opened up on an open/close sensor board:
 
Additionally, the comments in this thread have some info on getting a serial terminal opened up on an open/close sensor board:
 
* [http://buzzdavidson.com/?p=331 http://buzzdavidson.com/?p=331]
 
* [http://buzzdavidson.com/?p=331 http://buzzdavidson.com/?p=331]
 +
 +
 +
== Broadband Gateway Extender ==
 +
There has not been much if any information posted elsewhere about this device so I will contribute what I have learned about it here. Firstly the currently most useful feature is that it acts as a range extender for sensors too far away from the base station. It also has an ethernet port for broadband connection to the Eaton service which is now defunct. The brochure for the device advertises that you can both view the current state of your house via their website (which the gateway merely updates) and ALSO make changes to the configuration of your system from there as well. From a usability standpoint this means the broadband gateway acts as a "Home Key" in that it is a control point for configuring your system. This also means that the broadband gateway accepts inbound connections in addition to exfiltrating data.
 +
 +
==== Hardware ====
 +
The board for the gateway extender has the typical ATMega and EM boards for the wireless duties. The ethernet hardware capabilities are handled by a typical RTL IC. The IP functionality appears to be handled by a Rabbit 3000 IC which has a readily available TCP/IP stack available. There are two sets of populated "micro headers" which at first glance appear connected to the ATMega and the Rabbit IC's. Hopefully those will be able to bear more info on this device once I have time to probe them further. Lastly there is a reset button on the board which was not obvious to me from the outside of the enclosure. Further inspection revealed a tiny pinhole on the back of the case which barely provides access.
 +
 +
==== Adding an antenna ====
 +
One thing I hope to remedy is the lack of a proper antenna in my gateway extender. Currently I have about a 60' span to a detached garage that I would love to have Home Heartbeat sensors located within. The vestigial antenna stub on the cases of each Home Heartbeat device is for looks only. Each device uses a PCB mount antenna component which for the intended application is expected. I hope to add an external antenna to my gateway extender however to get some more reasonable distance out of it. I will document that here when that happens.
 +
 +
==== TCP/IP Network ====
 +
Upon plugging in the device to your network it automatically uses DHCP to retrieve an IP address. It does not appear that a static IP can be assigned through configuration of the unit itself. In fact there does not appear to be any configuration one can do to the device at all other than assigning a name to it within the Home Heartbeat system. A quick NMAP scan shows we do in fact have two open ports on the device:
 +
 +
<pre>
 +
PORT    STATE SERVICE
 +
0/tcp    open  unknown
 +
1136/tcp open  unknown
 +
</pre>
 +
 +
Telnetting to either port does not reveal any banners or other useful info. Issuing HTTP, FTP, etc. type commands has not yet revealed anything. The ports do have different behaviors though. Port 0 will accept any input and remains open. Port 1136 immediately closes the connection after any character is entered. Unfortunately since the Eaton service is long defunct it seems fairly difficult to obtain captures of the inbound data format. I would be most interested in the inbound format as the base station already provides all the information we need. Having the gateway inbound data format would seem to allow one to reconfigure their network as desired while remote.
 +
 +
I was hopeful that I would be able to capture the outbound format by sniffing traffic on this device after plugging it in. My goal was to be able to find the IP it was trying to contact,  setup an /etc/hosts entry to redirect it to localhost, setup a Netcat or similar service on the port it wants to talk to, then slowly sus out the data it was trying to exfiltrate. Unfortunately I have yet to see it attempt an outbound connection which seems very strange to me. I'm still hopeful that this method will reveal some more info some day if I can just get the thing to try to call home.
 +
 +
==== More info about the repeater functionalities ====
 +
The base station lists this device slightly differently from all others in the ZigBee binding table:
 +
<pre>
 +
BIND="
 +
BIND=00 00      L      0A      0A      000D6F00000XXXXX--FFFF
 +
BIND=01 00      L      0A      0A      000D6F00000XXXXX--FFFF
 +
BIND=02 00      L      0A      0A      000D6F00000XXXXX--FFFF
 +
...
 +
BIND=12 00      U      0A      0A      000D6F00000XXXXX--77B9  <-- Gateway Extender
 +
</pre>
 +
 +
 +
== Raspberry Pi connectivity ==
 +
I've discovered that these base stations do not work well with the Raspberry Pi model A. My testing was with Raspbian, I've not tested the RPi2 or other distros with it. The RPi can see the FTDI serial interface and recognizes it as a Home Heartbeat device. However when you open the connection (say, using minicom), it's just dead. Sometimes you will get a few garbage characters. The most I've seen is a single incomplete string come across. A powered hub was being used too to prevent power issues common to the model A.
 +
 +
 +
== Wireless Protocol ==
 +
One thing I am interested in is being able to build my own sensors which can interface to the system. I already am working on a separate environmental monitoring system for my house however I'd love to reduce its footprint by expanding this nice system. I received a Freakduino for Christmas 2013 and I've already been able to sniff some of the ZigBee traffic from the system. The ZigBee protocol is really IEEE 802.15.4 and is pretty low level. I will need quite a bit more time doing some parameter sweeps before I can decode any of it. Also an Atmel Raven can sniff the wireless traffic as well if you have one of those instead.
 +
 +
==== My sniffing setup ====
 +
As stated earlier, I'm using a [http://www.freaklabsstore.com/index.php?main_page=product_info&products_id=187 2.4GHz Freakduino] for capturing the RF traffic. I'm using [https://github.com/ninebit/zigbee-surf/blob/master/zigbee-surf.pde this channel-hopping sketch] on my Freakduino to search for an active ZigBee channel and then start dumping packets over its USB port. Then i'm using WSBridge to present a named pipe to Wireshark on OSX from my Freakduino. WSBridge encapsulates the ZigBee traffic in a way Wireshark can read it. It also presents a named pipe (file) which Wireshark can read from for real-time packet interception and decoding. Here is a great tutorial on doing this from top to bottom called "[http://www.freaklabs.org/index.php/Tutorials/Software/Feeding-the-Shark-Turning-the-Freakduino-into-a-Realtime-Wireless-Protocol-Analyzer-with-Wireshark.html Feeding The Shark].
 +
 +
<s>I'm new to the Freakduino but I've managed to hit and overcome some early bugs in my monitoring setup. The main problem I found was that despite setting the Serial (USB) port for 115200bps (baud) I was getting 57600bps out. I had to uncomment some print statements in the sketch on the Freakduino and connect to the serial port to find this out. I'm still unsure why this is happening. Trying other rates had unpredictable results. So far I've been unable to get 115200bps out. To remedy this for the time being I had to recompile WSBridge for 57600bps so it could properly read from the Freakduino. Eventually I hope to get this resolved but for my application right now this is usable.</s>
 +
 +
A requirement for getting a proper baud rate out of a Freakduino is to select the correct type of board to build your sketch against in the Arduino IDE. In this case, it is “Arduino Pro or Pro Mini (3.3V, 8 MHz) w/ATMega328”. RTFM to the rescue.
 +
 +
==== ZigBee channel info ====
 +
The serial output from the base station indicates that ZigBee channel 9 is being used from both the bootloader menu and the Node info command:
 +
node 000D6F0000094B81, channel [0x09], power [0xFF], app [base]
 +
 +
ZigBee channel 9 is a 900MHz frequency (channels 1-10). However the RF chip being used is the EM2420 which is a 2.4GHz ZigBee chip. The 2.4GHz channels are 11-26. Verifying the frequency in use with a sniffer indicates in reality ZigBee channel 14 is being used (at least on my system). If we assume the code in the base station is counting 2.4GHz channels starting from 0 then this would line up correctly with real channel 14 (2420MHz) being listed as 9 by the base station.
 +
 +
==== Home Heartbeat ZigBee Configuration====
 +
The initial appearance after capturing some of of the wireless traffic it appears that it uses a ZigBee star topology. This makes sense in the way this system operates. As I have time to hack away at the wireless protocol I will post more info here.
 +
 +
== Perl script for talking to the base station ==
 +
* [[File:Hh.tgz]] - hh.pl - digests the state table from a USB connected base station. It accepts flags for raw output, extended output, and can also generate an html file for easy viewing from a phone. Simply plug into cron using the correct flag and home status can be viewed any time via a home web server.
 +
 +
The default output only includes sensors, not other devices which are part of the network but do not change state. Example of default output:
 +
<pre>
 +
Sensor Name        Last Event Last Seen Alert Status Configuration 
 +
Motion Sensor      0 hours    3 mins  no alert    No action set 
 +
Kitchen Door        1 hours    17 mins  no alert    Alarm on opened
 +
Toilet              1 hours    12 mins  no alert    Alarm on dry
 +
Front Door          1 hours    21 mins  no alert    Alarm on opened
 +
Basement Floor      1 hours    7 mins  no alert    Alarm on wet 
 +
Dehumidifier        1 hours    18 secs  no alert    Alarm on On   
 +
Garage Door Sensor  1 hours    7 mins  no alert    Alarm on open
 +
</pre>
 +
 +
In the extended output you will notice some additional devices. Example of the extended output:
 +
<pre>
 +
                                                                                                                                                            Name  Update Device    Pending Update ZigBee                   
 +
Device Type                Sensor Name        Last Event Last Seen Alert Status Configuration                                  Record ID Alert Capability ID Index Flag  Parameter Timer          Binding ID ZigBee Mac     
 +
Base Station              N/A                0 secs    0 secs  no alert    Global don't call me / Do not send system info 00        00    0088          00    0000  00        00            FF                       
 +
Modem                      N/A                0 secs    0 secs  no alert    N/A                                            01        00    0080          00    0000  00        00            FF                       
 +
Home Key                  Home Key            2 secs    2 secs  no alert    Beep Alarm / 10 sec battery update            02        00    0040          00    0000  FF        00            00        000D6F0000012423
 +
Motion Sensor              Motion Sensor      0 hours    5 mins  no alert    No action set                                  03        00    0034          00    0000  00        00            01        000D6F000000FF8B
 +
Open/Closed                Kitchen Door        1 hours    19 mins  no alert    Alarm on opened                                05        00    0024          0B    0000  FF        00            03        000D6F0000011651
 +
Water Sensor              Toilet              1 hours    14 mins  no alert    Alarm on dry                                  06        00    0024          05    0000  FF        00            04        000D6F000000AC5F
 +
Open/Closed                Front Door          1 hours    23 mins  no alert    Alarm on opened                                09        00    0024          09    0000  FF        00            08        000D6F000000F23D
 +
Water Sensor              Basement Floor      1 hours    9 mins  no alert    Alarm on wet                                  0A        00    0024          01    0000  FF        00            09        000D6F0000011B85
 +
Power Sensor              Dehumidifier        1 hours    34 secs  no alert    Alarm on On                                    0B        00    00B4          07    0000  01        00            0A        000D6F000000E7E7
 +
Tilt Sensor                Garage Door Sensor  1 hours    9 mins  no alert    Alarm on open                                  0C        00    0024          00    0000  FF        00            0B        000D6F0000012416
 +
Broadband Gateway Extender Gateway Extender    2 secs    2 secs  no alert    N/A                                            0D        00    00C2          00    0000  FF        00            0C        000D6F0000079B21
 +
</pre>
 +
 +
 +
 +
== Request for more data ==
 +
I would be very interested in seeing some output from a base station with a Range Extender (not the Broadband Gateway Extender) or especially the Water Shutoff Controller connected to the system. If you have either of these components please email me (address is at bottom of page). The state table output for these components would allow me to complete my perl scripts to properly identify every component of the system. Also there are some unused fields in the base station state table which I suspect are only used by the water shutoff controller and it would be nice to identify those. More importantly this could also unlock additional functionality in future modifications to the Home Heartbeat system. The water shutoff controller is the only existing "sensor" in the system which can be activated by other sensors in the network which would be a useful feature to be able to unlock in home-made sensor add-ons. In theory I could possibly figure this out by fuzzing the base station with a ZigBee stack loaded onto my Freakduino but it's always easier to have known good examples to work with.
 +
  
 
== Mister House ==
 
== Mister House ==
Line 67: Line 196:
 
Another site with some info. The comments on the articles can be useful:
 
Another site with some info. The comments on the articles can be useful:
 
* [http://buzzdavidson.com/?p=54 http://buzzdavidson.com/?p=54]
 
* [http://buzzdavidson.com/?p=54 http://buzzdavidson.com/?p=54]
 +
* [http://buzzdavidson.com/?p=331 http://buzzdavidson.com/?p=331]
 +
 +
Sniffing ZigBee traffic with a Freakduino board, WSBridge, and Wireshark:
 +
* [http://www.freaklabs.org/index.php/Tutorials/Software/Feeding-the-Shark-Turning-the-Freakduino-into-a-Realtime-Wireless-Protocol-Analyzer-with-Wireshark.html Feeding The Shark]
 +
 +
A good sketch to run on the Freakduino to find your channel and capture ZigBee packets. Note that if you uncomment some of the print statements it may appear that channel "B" is being skipped, this is just a bug in the way print statements are being used.
 +
* [https://github.com/ninebit/zigbee-surf/blob/master/zigbee-surf.pde zigbee-surf.pde]
 +
 +
If you are new to reading raw ZigBee traffic you will want to read the IEEE 802.15.4 spec to understand what Wireshark is showing you:
 +
* [http://www.engineering.uiowa.edu/~mcover/lab4/802.15.4-2003.pdf 802.15.4-2003.pdf]
 +
 +
This paper is a good companion to read along with the IEEE spec to better understand why you are seeing the data you are seeing in the spec and in the traffic dump.
 +
* [http://staff.ustc.edu.cn/~ustcsse/papers/SR10.ZigBee.pdf SR10.ZigBee.pdf]
 +
 +
 +
== Contact ==
 +
I can be reached at dosman at bloominglabs dot org, thanks!
 +
 +
 +
[[Category:Dosman projects]]

Latest revision as of 08:14, 10 November 2019

As will happen I got an email from a home automation store I occasionally buy from. Hiding at the bottom was an advert for a house monitoring system which was being clearanced out. It was a strange product called the Home Heartbeat by Eaton. It's not a security system and it's not a home automation system. It's just for informational purposes as they say. Released around 2006 it came with a half dozen ZigBee connected sensors and a base station which has a modem to call a central notification service ran by Eaton. This apparently allowed the system to send text messages when the home owner was away. So in 2011 the call-home service was discontinued by Eaton and everyone who had the gear who relied on the text messaging service was SOL. However at the end of 2013 there is still a lot of the new-old stock being sold at a super discount.

So the original price of the base station "starter pack" was around $250 and I had the opportunity to pick one up including a door and water sensor for under $50 with shipping which I took advantage of. I did some quick googling and found that the base station was easy to communicate with via it's built in FTDI USB interface. Also most of the data output format had been decoded and documented so I took the chance that I could extend this system with some shell or perl scripting.

Once I got my unit I was able to get a perl script running which outputs useful human-readable data. There are a couple good sites with information about this system but no one has yet posted a monitoring script. Mine is posted at the bottom.

I have the base station (comes with a Home key), motion sensor, water sensor, open/close sensor, and power sensor. The "Home key" allows you to receive notifications when you are within range of the base station. When you are out of range this apparently told the base station to call-home and text you when there was a worthy notification. The Home key is also used to program new sensors into the system. Apparently there is a reed-relay in both the sensor and the key which allows for simple ZigBee pairing just by sliding the key into the top of each sensor.


Contents

[edit] Component List

  • Base station
  • Home key (key ring adapter, has multiple purposes)
  • Modem (built in to base station, no longer usable)
  • Open/Close sensor
  • Motion sensor
  • Water sensor
  • Garage door sensor (tilt sensor)
  • Power monitor sensor
  • Attention sensor
  • Reminder sensor
  • Remote water shutoff
  • Range extender
  • Broadband gateway extender


Something I did not realize until another Home Heartbeat user clued me in was that the Broadband Gateway Extender also acts like a range extender.


[edit] Connecting to the base station's USB port

The base station has a USB port which can be used to extend the systems functionality. So the first gotcha is that the vendor ID for the base station is unique. It's still just an FTDI USB serial device though and that is easy enough to fix (at least on Linux).

[edit] New method for systemd

This is for ubuntu/raspbian, or any other unfortunate person inflicted with systemd. Create a new file here:
/etc/systemd/system/multi-user.target.wants/fixhh.service

[Unit]
Description=config ftdi for home heartbeat serial

[Service]
Type=oneshot
ExecStart=/sbin/modprobe ftdi_sio
ExecStart=/bin/sh -c "echo '0403 de29' > /sys/bus/usb-serial/drivers/ftdi_sio/new_id"

[Install]
WantedBy=multi-user.target

Now you should be set for the ftdi_sio driver to load and recognize your Home Heartbeat serial device on boot. You can initialize it without a reboot with this:

systemctl start fixhh

You should see a new device named similarly to /dev/ttyUSBx where x is a numeric 0-9 depending how many ttyUSB devices you already have attached to your host.


[edit] Centos 5/6 method with the updated ftdi driver

Apparently the newer ftdi_sio module (starting in 2015) silently stopped accepting the option flags "vendor" and "product" as they were intended to be debugging features, not end-user features :-P. So the new way to get the module to work with this device:

echo "0403 de29" > /sys/bus/usb-serial/drivers/ftdi_sio/new_id

Now you should have a new /dev/ttyUSBx device. The connection settings are 38400 8n1, any terminal program will do. The serial interface has a built-in help screen (type ?) with lots of commands. This is all well documented at some of the other sites talking about Home Heartbeat so I won't rehash that here.

[edit] Old method (centos 5/6) pre-2015, plus udev muckery

  • Add modprobe line for ftdi_sio driver, get vendor and product lines from lsusb (RHEL5/6 and CENTOS 5/6):
    • echo "options ftdi_sio vendor=0x403 product=0xde29" > /etc/modprobe.d/ftdi_sio.conf
  • If you want to get fancy add a udev rule like this to /etc/udev/rules.d/50-udev.rules or similar to get a /dev/hh device:
    • ATTRS{idVendor}=="0403", ATTRS{idProduct}=="de29", SYSFS{product}=="HHB Basestation", SYMLINK+="hh", GROUP="uucp", MODE="0660"
  • Next reload ftdi_sio (as root) and it should be picked up correctly now:
    • modprobe -r ftdi_sio
    • modprobe ftdi_sio

Now you should have a new /dev/ttyUSBx device and possibly a /dev/hh device if you added the udev rule (not required). The connection settings are 38400 8n1, any terminal program will do. The serial interface has a built-in help screen (type ?) with lots of commands. This is all well documented at some of the other sites talking about Home Heartbeat so I won't rehash that here.

If you find that doing the above doesn't generate a new ttyUSBx device, watch the output of "dmesg" for these errors:

[2884971.187297] ftdi_sio: unknown parameter 'vendor' ignored
[2884971.187333] ftdi_sio: unknown parameter 'product' ignored

This tells you that you are using the newer ftdi_sio module and you need to use the "New method" listed above to add the device.


[edit] Hardware

The main board common to all of the sensors uses an Atmel ATMega128 with an Ember (Silicon Labs) EM2420 RF chip for the ZigBee duties.

  • EM2420 datasheet - Note that this chip is for 2.4GHz, the base station will say something about being on channel "0x09" which is a 900MHz ZigBee channel. However the datasheet proves that this is impossible, actually it appears Home Heartbeat uses ZigBee channel 14, more in the wireless section below.
  • ZigBee channels

Additionally, the comments in this thread have some info on getting a serial terminal opened up on an open/close sensor board:


[edit] Broadband Gateway Extender

There has not been much if any information posted elsewhere about this device so I will contribute what I have learned about it here. Firstly the currently most useful feature is that it acts as a range extender for sensors too far away from the base station. It also has an ethernet port for broadband connection to the Eaton service which is now defunct. The brochure for the device advertises that you can both view the current state of your house via their website (which the gateway merely updates) and ALSO make changes to the configuration of your system from there as well. From a usability standpoint this means the broadband gateway acts as a "Home Key" in that it is a control point for configuring your system. This also means that the broadband gateway accepts inbound connections in addition to exfiltrating data.

[edit] Hardware

The board for the gateway extender has the typical ATMega and EM boards for the wireless duties. The ethernet hardware capabilities are handled by a typical RTL IC. The IP functionality appears to be handled by a Rabbit 3000 IC which has a readily available TCP/IP stack available. There are two sets of populated "micro headers" which at first glance appear connected to the ATMega and the Rabbit IC's. Hopefully those will be able to bear more info on this device once I have time to probe them further. Lastly there is a reset button on the board which was not obvious to me from the outside of the enclosure. Further inspection revealed a tiny pinhole on the back of the case which barely provides access.

[edit] Adding an antenna

One thing I hope to remedy is the lack of a proper antenna in my gateway extender. Currently I have about a 60' span to a detached garage that I would love to have Home Heartbeat sensors located within. The vestigial antenna stub on the cases of each Home Heartbeat device is for looks only. Each device uses a PCB mount antenna component which for the intended application is expected. I hope to add an external antenna to my gateway extender however to get some more reasonable distance out of it. I will document that here when that happens.

[edit] TCP/IP Network

Upon plugging in the device to your network it automatically uses DHCP to retrieve an IP address. It does not appear that a static IP can be assigned through configuration of the unit itself. In fact there does not appear to be any configuration one can do to the device at all other than assigning a name to it within the Home Heartbeat system. A quick NMAP scan shows we do in fact have two open ports on the device:

PORT     STATE SERVICE
0/tcp    open  unknown
1136/tcp open  unknown

Telnetting to either port does not reveal any banners or other useful info. Issuing HTTP, FTP, etc. type commands has not yet revealed anything. The ports do have different behaviors though. Port 0 will accept any input and remains open. Port 1136 immediately closes the connection after any character is entered. Unfortunately since the Eaton service is long defunct it seems fairly difficult to obtain captures of the inbound data format. I would be most interested in the inbound format as the base station already provides all the information we need. Having the gateway inbound data format would seem to allow one to reconfigure their network as desired while remote.

I was hopeful that I would be able to capture the outbound format by sniffing traffic on this device after plugging it in. My goal was to be able to find the IP it was trying to contact, setup an /etc/hosts entry to redirect it to localhost, setup a Netcat or similar service on the port it wants to talk to, then slowly sus out the data it was trying to exfiltrate. Unfortunately I have yet to see it attempt an outbound connection which seems very strange to me. I'm still hopeful that this method will reveal some more info some day if I can just get the thing to try to call home.

[edit] More info about the repeater functionalities

The base station lists this device slightly differently from all others in the ZigBee binding table:

BIND="
BIND=00 00      L       0A      0A      000D6F00000XXXXX--FFFF
BIND=01 00      L       0A      0A      000D6F00000XXXXX--FFFF
BIND=02 00      L       0A      0A      000D6F00000XXXXX--FFFF
...
BIND=12 00      U       0A      0A      000D6F00000XXXXX--77B9   <-- Gateway Extender


[edit] Raspberry Pi connectivity

I've discovered that these base stations do not work well with the Raspberry Pi model A. My testing was with Raspbian, I've not tested the RPi2 or other distros with it. The RPi can see the FTDI serial interface and recognizes it as a Home Heartbeat device. However when you open the connection (say, using minicom), it's just dead. Sometimes you will get a few garbage characters. The most I've seen is a single incomplete string come across. A powered hub was being used too to prevent power issues common to the model A.


[edit] Wireless Protocol

One thing I am interested in is being able to build my own sensors which can interface to the system. I already am working on a separate environmental monitoring system for my house however I'd love to reduce its footprint by expanding this nice system. I received a Freakduino for Christmas 2013 and I've already been able to sniff some of the ZigBee traffic from the system. The ZigBee protocol is really IEEE 802.15.4 and is pretty low level. I will need quite a bit more time doing some parameter sweeps before I can decode any of it. Also an Atmel Raven can sniff the wireless traffic as well if you have one of those instead.

[edit] My sniffing setup

As stated earlier, I'm using a 2.4GHz Freakduino for capturing the RF traffic. I'm using this channel-hopping sketch on my Freakduino to search for an active ZigBee channel and then start dumping packets over its USB port. Then i'm using WSBridge to present a named pipe to Wireshark on OSX from my Freakduino. WSBridge encapsulates the ZigBee traffic in a way Wireshark can read it. It also presents a named pipe (file) which Wireshark can read from for real-time packet interception and decoding. Here is a great tutorial on doing this from top to bottom called "Feeding The Shark.

I'm new to the Freakduino but I've managed to hit and overcome some early bugs in my monitoring setup. The main problem I found was that despite setting the Serial (USB) port for 115200bps (baud) I was getting 57600bps out. I had to uncomment some print statements in the sketch on the Freakduino and connect to the serial port to find this out. I'm still unsure why this is happening. Trying other rates had unpredictable results. So far I've been unable to get 115200bps out. To remedy this for the time being I had to recompile WSBridge for 57600bps so it could properly read from the Freakduino. Eventually I hope to get this resolved but for my application right now this is usable.

A requirement for getting a proper baud rate out of a Freakduino is to select the correct type of board to build your sketch against in the Arduino IDE. In this case, it is “Arduino Pro or Pro Mini (3.3V, 8 MHz) w/ATMega328”. RTFM to the rescue.

[edit] ZigBee channel info

The serial output from the base station indicates that ZigBee channel 9 is being used from both the bootloader menu and the Node info command:

node 000D6F0000094B81, channel [0x09], power [0xFF], app [base]

ZigBee channel 9 is a 900MHz frequency (channels 1-10). However the RF chip being used is the EM2420 which is a 2.4GHz ZigBee chip. The 2.4GHz channels are 11-26. Verifying the frequency in use with a sniffer indicates in reality ZigBee channel 14 is being used (at least on my system). If we assume the code in the base station is counting 2.4GHz channels starting from 0 then this would line up correctly with real channel 14 (2420MHz) being listed as 9 by the base station.

[edit] Home Heartbeat ZigBee Configuration

The initial appearance after capturing some of of the wireless traffic it appears that it uses a ZigBee star topology. This makes sense in the way this system operates. As I have time to hack away at the wireless protocol I will post more info here.

[edit] Perl script for talking to the base station

  • File:Hh.tgz - hh.pl - digests the state table from a USB connected base station. It accepts flags for raw output, extended output, and can also generate an html file for easy viewing from a phone. Simply plug into cron using the correct flag and home status can be viewed any time via a home web server.

The default output only includes sensors, not other devices which are part of the network but do not change state. Example of default output:

Sensor Name        Last Event Last Seen Alert Status Configuration  
Motion Sensor       0 hours    3 mins   no alert     No action set  
Kitchen Door        1 hours    17 mins  no alert     Alarm on opened
Toilet              1 hours    12 mins  no alert     Alarm on dry 
Front Door          1 hours    21 mins  no alert     Alarm on opened
Basement Floor      1 hours    7 mins   no alert     Alarm on wet   
Dehumidifier        1 hours    18 secs  no alert     Alarm on On    
Garage Door Sensor  1 hours    7 mins   no alert     Alarm on open 

In the extended output you will notice some additional devices. Example of the extended output:

                                                                                                                                                             Name  Update Device    Pending Update ZigBee                     
Device Type                Sensor Name        Last Event Last Seen Alert Status Configuration                                  Record ID Alert Capability ID Index Flag   Parameter Timer          Binding ID ZigBee Mac      
Base Station               N/A                 0 secs     0 secs   no alert     Global don't call me / Do not send system info 00        00    0088          00    0000   00        00             FF                         
Modem                      N/A                 0 secs     0 secs   no alert     N/A                                            01        00    0080          00    0000   00        00             FF                         
Home Key                   Home Key            2 secs     2 secs   no alert     Beep Alarm / 10 sec battery update             02        00    0040          00    0000   FF        00             00         000D6F0000012423
Motion Sensor              Motion Sensor       0 hours    5 mins   no alert     No action set                                  03        00    0034          00    0000   00        00             01         000D6F000000FF8B
Open/Closed                Kitchen Door        1 hours    19 mins  no alert     Alarm on opened                                05        00    0024          0B    0000   FF        00             03         000D6F0000011651
Water Sensor               Toilet              1 hours    14 mins  no alert     Alarm on dry                                   06        00    0024          05    0000   FF        00             04         000D6F000000AC5F
Open/Closed                Front Door          1 hours    23 mins  no alert     Alarm on opened                                09        00    0024          09    0000   FF        00             08         000D6F000000F23D
Water Sensor               Basement Floor      1 hours    9 mins   no alert     Alarm on wet                                   0A        00    0024          01    0000   FF        00             09         000D6F0000011B85
Power Sensor               Dehumidifier        1 hours    34 secs  no alert     Alarm on On                                    0B        00    00B4          07    0000   01        00             0A         000D6F000000E7E7
Tilt Sensor                Garage Door Sensor  1 hours    9 mins   no alert     Alarm on open                                  0C        00    0024          00    0000   FF        00             0B         000D6F0000012416
Broadband Gateway Extender Gateway Extender    2 secs     2 secs   no alert     N/A                                            0D        00    00C2          00    0000   FF        00             0C         000D6F0000079B21


[edit] Request for more data

I would be very interested in seeing some output from a base station with a Range Extender (not the Broadband Gateway Extender) or especially the Water Shutoff Controller connected to the system. If you have either of these components please email me (address is at bottom of page). The state table output for these components would allow me to complete my perl scripts to properly identify every component of the system. Also there are some unused fields in the base station state table which I suspect are only used by the water shutoff controller and it would be nice to identify those. More importantly this could also unlock additional functionality in future modifications to the Home Heartbeat system. The water shutoff controller is the only existing "sensor" in the system which can be activated by other sensors in the network which would be a useful feature to be able to unlock in home-made sensor add-ons. In theory I could possibly figure this out by fuzzing the base station with a ZigBee stack loaded onto my Freakduino but it's always easier to have known good examples to work with.


[edit] Mister House

I would like to work on adding Home Heartbeat support for Mister House if possible. I've never used Mister House but I've been waiting until I had enough sensors (any type, not just Home Heartbeat specific).


[edit] Other sites with info

This site has the base station state table protocol decoded. My script follows their definitions so it should support any sensor I don't have yet.

Another site with some info. The comments on the articles can be useful:

Sniffing ZigBee traffic with a Freakduino board, WSBridge, and Wireshark:

A good sketch to run on the Freakduino to find your channel and capture ZigBee packets. Note that if you uncomment some of the print statements it may appear that channel "B" is being skipped, this is just a bug in the way print statements are being used.

If you are new to reading raw ZigBee traffic you will want to read the IEEE 802.15.4 spec to understand what Wireshark is showing you:

This paper is a good companion to read along with the IEEE spec to better understand why you are seeing the data you are seeing in the spec and in the traffic dump.


[edit] Contact

I can be reached at dosman at bloominglabs dot org, thanks!

Personal tools