[Dan Englender] was working on implementing a home automation and security system, and while his house was teeming with sensors, they used a proprietary protocol which was not supported by the open source system he was trying to implement. The problem with home automation and security systems is the lack of standardization – or rather, the large number of (often incompatible) standards used to ensure consumers get tied in to one specific system. He has shared the result of his efforts at getting the two to talk to each other via his project decode345.
The result enabled him to receive signals from Honeywell’s 5800 series of wireless products and interface them with OpenHAB — a vendor and technology agnostic open source automation software. OpenHAB offers “bindings” that allow a wide variety of systems and hardware to be integrated. Unfortunately for [Dan], this exhaustive list does not yet include support for the (not very popular) 345MHz protocol used by the Honeywell 5800 system, hence his project.
The hardware used is plain vanilla – a cheap SDR dongle connected to a Raspberry Pi 3. His code, available on Github, along with OpenHAB, are lightweight enough to run comfortably on the Pi 3. The software side is a bit involved, and his blog post walks you through the code as well as the process he used to accomplish this. The Python- and C-based decoder captures the sensor signals. The sensors states are then sent to OpenHAB (in his case), but can probably be used with other systems too.
And since he wasn’t familiar with RF, SDR’s, Python, GNUradio and all the other bits that he used, he ended up in a lot of blind alleys. This is useful because his resulting blog is a nice walk through for anyone attempting something similar, providing handy tips and pointing out potential pitfalls. Despite trying a lot, he could not get gnuradio to demodulate the transmissions received from his sensors, so he rolled out his own decoder in Python, which makes for some interesting reading about how he reverse-engineered the protocol. Once over the hill, the final part of sending the received data via the Paho MQTT broker to OpenHAB was pretty simple.
If you have some suggestions on how he can optimise his code or use an embedded device such as the Texas CC1101 instead of the SDR, he’s all ears.
I can offer free hardware from domeha.com for your R&D. We want our sensors to be agnostic and RF/LoRa/wifi eqipped, that’s why we don’t even make a hub, and hope that hub makers will think more like webhooks for hardware or build systems like NPM. We also love things like IFTTT and Linux. Seems like it’s always 2 steps forward, 1 step back.
Seriously overpriced hardware.
A bit pricier than other z-wave offerings, however much smaller and better looking than most I’ve seen. And if the battery life stated is true that adds significant value over the zwave motion sensors I currently have.
That’s the way things work – people can decide what they value, and whether the features are worth the price for them. You clearly don’t value the features that these devices offer – that doesn’t mean they are overpriced.
I am just gonna leave this here : https://imgs.xkcd.com/comics/standards.png
But seriously, good job :)
This is neat and all, but if you actually buy an alarm controller (Vista 15p) and the associated RF receiver there already exist 3rd party devices like the alarmdecoder and Envisalink4 that will give you decoded RF data from these sensors… The receivers run in sniffer mode and dump any RF info serial #, loop #, battery status, check in, etc to the key bus… No SDRs or reverse engineering required. It would definitely cost a little more upfront, but on the plus side you wouldn’t need to invest so much time on software and you’d have a proper UL approved security system afterwards…