I’ve been meaning to get around to figuring out how to do this for a while now. Expecting difficulty, I was surprised to find out that it’s a piece of cake.
The BDR91 communicates using Honeywell’s proprietary RAMSES II – a simple, unsecured wireless protocol which is easy to interface with using ready made radio hardware.
There’s a good wiki page here documenting what has been reverse engineered of the protocol (there is no publicly available documentation for it). We’re not going to need to be reading any of that for this venture.
D.I.Y. interfacing with Honeywell home automation products is all based around the HGI80. It’s an official product from Honeywell which provides a “dumb” RAMSES II to TTY bridge.
It outputs all received messages from the airwaves to its TTY interface, from your system, your neighbours system, and your other neighbours system too. All devices use the same frequency. When transmitting it is also able to spoof any device ID one pleases, and transmit any kind of message, as such, it is not something Honeywell is keen to aggressively market. It is a rare and expensive item, sold by only a few niche dealers in mainland Europe.
In this guide we won’t be using an HGI80, instead, we’ll be programming an RFBee with an open source implementation of the HGI80, and using it to spoof the thermostat the BDR91 was previously paired with.
Programming an RFBee as an HGI80
There are a number of open source HGI80 implementations. The one I’m using is here on github. It’s probably not the best but it works and it’s ready-to-go for the RFBee. Here is another one, and another. These are all based on how the HGI80 is observed to behave, and likely don’t fully emulate it, good enough however, for what we want to do here.
I found that EvohomeWirelessFW didn’t readily build or program with the Arduino IDE as was promised, so I’d recommend skipping that and programming it directly with avrdude. The command is:
avrdude -v -p atmega168 -c arduino -P COM4 -b 57600 -D -U flash:w:EvohomeWirelessFW.hex:i -F
If you’d like to save yourself couple of hours of hair-pulling, use my pre-compiled .HEX file. It’s configured for 9600 baud. Many in the Evohome community run it at 115200 which to me seems overkill, and an invitation for errors.
If a direct PC connection is desired, the UartSBee will provide this. Make sure the switch is in the “3v3” position as the RFBee is a 3.3v device.
Spoofing the thermostat
Hypothetically you could pair the BDR91 to the RFBee/HGI80, however this would mean the entire pairing protocol would need to be implemented on the software interfacing to the RFBee/HGI80. It’s too dumb to do it by its self. The firmware ideally would also be re-compiled with a unique device ID.
It’s much easier to spoof a pre-paired thermostat. Before we can do that, we need to know its ID.
Upon opening a terminal program (at 9600 baud if using my image) to the HGI80 or RFBee, you’re likely going to see all kinds stuff spitting out, this is all traffic from your Honeywell system, and likely your neighbours systems too, as well as failed attempts to interpret other non RAMSES II traffic on the airwaves (these lines usually will be suffixed with *INCOMPLETE* or *CHK*).
Above I have highlighted a “boiler on” message from the thermostat to the BDR91. These messages are of the “instruction” – “I” type and are not addressed specifically to the BDR91, instead they’re more a broadcast type. The BDR91 knows the ID of the thermostat, but not vice versa.
Once we’ve found the appropriate message (code 0008, len 002), it’s then simply a case of feeding that straight into the RFBee/HGI80
I - 34:123456 --:------ 34:123456 0008 002 00C8\n <--- ON I - 34:123456 --:------ 34:123456 0008 002 0000\n <--- OFF
So assuming the thermostat ID was observed to be 34:123456, the commands to send would be as above. Don’t send the “<— ON” bit. That’s just for clarity. the ‘\n’ must sent as an actual newline, not as I’ve typed it here.
And that’s it.
You may see the thermostat send values in between 00 and C8 for the second byte of the command. This is to support “variable” boiler control devices. I’ve not been able to figure out how the BDR91 interprets these intermediate values, in some cases it turns on, other times off with no obvious pattern as to how it responds to each value. However it works, I suspect it’s quite involved.
In this instance all we need to know is that C8 (decimal 200) will definitely be on, and 00 will definitely be off.
The 1% TX rule
The RAMSES II protocol has a strict rule that no device may spend more than 1% of the time transmitting. The HGI80 enforces this, whereas open source alternatives do not. This is for a good reason. Don’t spam the airwaves, your neighbours will not forgive you.