Difference between revisions of "Eaton Home Heartbeat"
(→Hardware) |
|||
| (6 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 | + | 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. |
| + | |||
== Component List == | == Component List == | ||
| Line 29: | Line 30: | ||
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). | 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 41: | 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. | ||
| + | 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. | ||
| + | |||
| + | |||
| + | == 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. | ||
| Line 50: | Line 88: | ||
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 == | == 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. | 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: | 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: | ||
| Line 64: | Line 110: | ||
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. | 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, then slowly sus out the data it was trying to exfiltrate. Unfortunately I have yet to see it attempt an outbound connection which | + | 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 ==== | ==== More info about the repeater functionalities ==== | ||
| Line 82: | Line 123: | ||
</pre> | </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 == | == 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 | + | 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 ==== | ==== ZigBee channel info ==== | ||
| Line 92: | Line 143: | ||
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. | 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==== | ==== 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. | 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 == | == 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. | * [[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: | The default output only includes sensors, not other devices which are part of the network but do not change state. Example of default output: | ||
| Line 134: | Line 182: | ||
== Request for more data == | == 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. | + | 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. |
| Line 150: | Line 198: | ||
* [http://buzzdavidson.com/?p=331 http://buzzdavidson.com/?p=331] | * [http://buzzdavidson.com/?p=331 http://buzzdavidson.com/?p=331] | ||
| − | Sniffing ZigBee traffic with a | + | 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] | * [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 | + | 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] | * [https://github.com/ninebit/zigbee-surf/blob/master/zigbee-surf.pde zigbee-surf.pde] | ||
| Line 165: | Line 213: | ||
== Contact == | == Contact == | ||
I can be reached at dosman at bloominglabs dot org, thanks! | 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!
