Evohome / Evotouch Wireless protocol?

[colintd]

This code is now checked into the trunk of the culfw project, with the default makefile building the support into the CUL_V3_ZWAVE image file.

[r_255]

Hi colintd, thanks for sharing,
I got it up and running at with a culv3, Serial terminal at 115k and vl +cr

@neilcoggins and DanD
I might be wrong, but as far as can remember its rfbee <<.>> evotouch <<.>> hr80

rfbee injects on the evotouch and not direct to the hr80. Atleast that is how i do remember it.

recieve issues can be tested easy just by moving the working hr80 to the area of the non working ones.
but if your evotouch recieves the command well it should be sended out to the hr80's multiple times.

like sugested, i think reseting the hr80's and rebinding will solve this issue also check if your hr80 firmware is 2.03 or above.

Cheers.

[DanD]

@r_255

I might be wrong, but as far as can remember its rfbee <<.>> evotouch <<.>> hr80

rfbee injects on the evotouch and not direct to the hr80. Atleast that is how i do remember it.

Yes, you're correct I was was wrong, sorry. I've done a lot more testing recently, trying (but failing ) to get the HGI80 to communicate directly to any device other than the controller. I'm going to switch over and use a RFBee + UartSBee instead of the HGI80 which I'm sure will solve this problem and keep me very busy with adding further functionality to the Domoticz Evohome code.

Dan

[colintd]

Gald to hear it works for at least one other person!

Hi colintd, thanks for sharing,
I got it up and running at with a culv3, Serial terminal at 115k and vl +cr

[fredh]

Hi all,

apologies ahead if the length of this message exceeds what is considered proper.

TLDR; Why can't I see my BDR91 in the device list in domoticz?

After following this topic on and off for over more than a year I finally decided to give it a try and bought a RFBee and UartSBee. They arrived three months ago.

The first challenge was to get a modified version of the firmware onto the RFBee. I took the often mentioned code from hydrogenetic (https://github.com/fullTalgoRythm/EvohomeWirelessFW). I'm already using platformio as my build platform for ESP8266 development. So the first step was to setup the folder structure such that I could build and upload the code from within vscode using platformio. This proved to be remarkably easy. And there I was. All set and ready to monitor my first messages floating around.

That actually worked. Well, kind of.

Code: Select all

# EvohomeWirelessFW v0.8 Copyright (c) 2015 Hydrogenetic
# Licensed under GPL-3.0+ <http://spdx.org/licenses/GPL-3.0+>
---  I --- 20:004081 --:------ 12:121091 0000 001 8E*INCOMPLETE*
---  I --- 04:131552 --:------ 04:131552 30C9 003 0006BB
---  I --- 20:004081 --:------ 12:121091 0000 001 8E*INCOMPLETE*
---  I --- 01:067592 --:------ 01:067592 1F09 003 FF07CB
---  I --- 01:067592 --:------ 01:067592 2309 012 0003E80103E80203E80303E8
---  I --- 01:067592 --:------ 01:067592 30C9 012 0007BC01050902042103069F
---  I --- 04:131550 --:------ 04:131550 30C9 003 000437
--- Unknown header=0xFF


I had an insufferable amount of 'INCOMPLETE' messages and lots of 'Unknown header' reports. See http://pastebin.com/LU17iJvr for a complete log.

Over a period of several weeks I tried several optimisations until I arrived at my current version that is receiving quite well now (http://pastebin.com/P4i46gKE).

Code: Select all

# EvohomeWirelessFW v0.9alpha Copyright (c) 2015 Hydrogenetic
# Licensed under GPL-3.0+ <http://spdx.org/licenses/GPL-3.0+>
---  I --- 04:131554 --:------ 63:262142 12B0 003 000000
---  I --- 04:131554 --:------ 63:262142 12B0 003 000000
---  I --- 20:004081 --:------ --:------ 31D9 003 000001
---  I --- 04:131552 --:------ 01:067592 3150 002 0000
---  I --- 04:157831 --:------ 01:067592 3150 002 0000
---  I --- 04:157837 --:------ 01:067592 3150 002 0000
---  I --- 04:131550 --:------ 04:131550 30C9 003 00093B
---  I --- 01:067592 --:------ 01:067592 1F09 003 FF07CB
---  I --- 01:067592 --:------ 01:067592 2309 012 0003E80103E80208FC0303E8
---  I --- 01:067592 --:------ 01:067592 30C9 012 00080A01050F02093B030684
---  I --- 04:131550 --:------ 01:067592 3150 002 0282
---  I --- 01:067592 --:------ 01:067592 3150 002 FC82
---  I --- 04:157835 --:------ 01:067592 2309 003 0103E8
---  I --- 04:157835 --:------ 01:067592 1060 003 016401
---  I --- 04:157835 --:------ 04:157835 1060 003 006401
---  I --- 04:157835 --:------ 01:067592 1060 003 016401
---  I --- 04:157835 --:------ 04:157835 1060 003 006401
---  I --- 20:004081 --:------ --:------ 31D9 003 000001
---  I --- 01:067592 --:------ 01:067592 0008 002 FC00
---  I --- 13:212992 --:------ 13:212992 3EF0 003 00C8FF
--- RQ --- 04:157835 --:------ 01:067592 0100 005 00656EFFFF
--- RP --- 01:067592 --:------ 04:157835 0100 005 00656EFFFF
---  I --- 04:131552 --:------ 01:067592 12B0 003 000000


Okay, looking good. When not working on the firmware I read up on domoticz integration. So I felt fairly confident that now that my output was nice and clear, it was easy to add it to domoticz.

After plugging the UartSBee into the Pi running domoticz I did a quick smoke test to see if the data was coming in alright. And it all still looked nice and proper. The UartSBee used the FTDI USB chipset. In several places I found reports that this chipset might cause problems on the Pi due to high interrupt rates. In my setup, a Pi 2B running 4.4.38-v7+, I have detected no problems at all.

Next domoticz. I added new hardware choosing 'Evohome USB (for HGI/S80)'. Clicked 'All Sensors' and made a cup of tea. After fifteen minutes or so, I got a nice list of devices for evohome.

devices_list.jpg (93.19 KiB) Viewed 13119 times

Great! I see my controller (a colour, wifi version) and six HR92's (three in zone 1, the living room).

And so I finally come to my question, why don't I see my on/of relay BDR91? I know it's there and communicates. The messages from device 13:212992 are there to prove it. I was expecting a device with matching ID 4F4000 in the domoticz device list. It is not there. Obviously I need to do 'something', or is the BDR91 never present in the device list? I have combed carefully through as much documentation as I could find online but can not find the answer. Can any of you provide a pointer or hint?

Thanks in advance,
Fred

[DanD]

Hi Fred,

Thanks for posting all of the details of your set-up and the logs. They are very helpful in troubleshooting your problem.

The simple answer to your question though is no, the BDR91 won't appear as a separate device in the Domoticz device list. The Domoticz Evohome code currently creates devices for temperature sensors and heat demand relay devices, but not for additional BDR91s unless they are used for switching the boiler or DHW. It looks like your BDR91 is used to control your boiler and this is device no 252. The 'All Sensors' function add all temperature sensor type devices to the device list, but there isn't a similar function to add all relay type devices.

It's great to hear about your success with the RFBee + UartSBee. I've just set one up myself in the last 2 days. Have you had any trouble with sending messages with the device e.g. changing a zone setpoint within Domoticz? Other users have reported some difficulty sending with the FullTalgoRythm firmware and I'm having some problems myself.

Another comment is about the incomplete messages that the RFBee + UartSBee was receiving. I think that these are coming from another non-Evohome system. I think it's likely to be something like a Honeywell CMZone system which uses the same wireless protocol. The device type 12 is used by the CMZone controller, but there may be other devices too. I don't know what device uses type 12.

Dan

[fredh]

Hi Dan,

thanks for your reply. I figured already that the relay would not show up, glad you confirmed it.

Device 252 is the demand as it is requested by my controller indeed. I'm just showing that as the boiler status, although the true status of the BRD may different should it miss a message. Nevermind.

To answer your question I had not tried sending a setpoint. I have done so now, and my controller is NOT picking up the settings I pushed from Domoticz.

Since I have no RFG100/HGI80 or a second combo RFBee/UartSBee I'm improvising a monitoring system using the CUL I had lying around together with the modified firmware from colintd. I was too lazy to restore my Linux VM from backups. But after some tweaking I was able to flash the culfw from Windows 10.

Somewhere this week, when the family is not around to complain , I will conduct some experiments and monitor what is actually being sent by the RFBee.

In het mean time I need to dive into the Domoticz code because the times reported for overrides are off (probably to do with a local time versus UTC mismatch).

Fred

[Giuseppe]

Hi colintd, nice work again. Thanks for sharing
I did flashing CUL V3 with Flip 3.4.7 on Windows 10. Got AtLibUsbDfu.dll not found. Solution: driver from Flip package.

The Busware documentation for Windows is very outdated.

[bruce_miranda]

I had an insufferable amount of 'INCOMPLETE' messages and lots of 'Unknown header' reports. See http://pastebin.com/LU17iJvr for a complete log.

Over a period of several weeks I tried several optimisations until I arrived at my current version that is receiving quite well now

Hi Fred, What changes did you make to the firmware because I too have a lot of Incomplete and Unknown Header messages.

Also when I compare the output of my HGI80 to my RFBee set up side by side, I notice that the HGI80 messages all start with 3 digits whereas the RFBee output always starts with 3 dashes --- why is that? Clearly those digits are not used else the RfBee outputs wouldn't be read by Domoticz.

[bruce_miranda]

Also it appears that the firmware might not entirely be working for all messages.

See output from an HGI80

Code: Select all

084 RQ --- 22:055075 13:050361 --:------ 3EF1 002 0000                         
078 RP --- 13:050361 22:055075 --:------ 3EF1 007 0000370037C8FF               
055  I --- 04:061402 --:------ 01:078710 3150 002 0400                         
084  I --- 04:057587 --:------ 01:078710 2309 003 050320                       
095  I --- --:------ --:------ 12:106131 0008 002 0070                         
045  I --- 01:078710 --:------ 01:078710 0008 002 FC00                         
057  I --- 10:067219 --:------ 01:078710 3150 002 FC00                         
094  I --- --:------ --:------ 12:106131 0008 002 0070                         
057  I --- --:------ --:------ 10:067219 1FD4 003 0054A9                       
095  I --- --:------ --:------ 12:106131 0008 002 0070                         
045  I --- 04:057586 --:------ 01:078710 2309 003 010320                       
045  I --- 01:078710 --:------ 01:078710 0008 002 0200                         
071  I --- 04:133277 --:------ 01:078710 1060 003 00FF01                       
071  I --- 04:133277 --:------ 04:133277 1060 003 00FF01                       
053  I --- 04:098449 --:------ 01:078710 2309 003 0B0320                       


Compared to the RfBee output

Code: Select all

--- RQ --- 22:068154 13:031208 --:------ 3EF1 002 0000                         
--- RP --- 13:031208 22:068154 --:------ 3EF1 007 0000380038C8FF               
---  I --- 04:061760 --:------ 04:061760 30C9 003 00078F                       
--- RQ --- 22:055075 13:050361 --:------ 3EF1 002 0000                         
--- RP --- 13:050361 22:055075 --:------ 3EF1 007 0000370037C8FF               
---  I --- 04:061402 --:------ 01:078710 3150 002 0400                         
---  I --- 04:057587 --:------ *INCOMPLETE*                                     
---  I --- *INCOMPLETE*                                                         
---  I --- 01:078710 --:------ 01:078710 0008 002 FC00                         
---  I --- *INCOMPLETE*                                                         
---  I --- 04:057586 --:------ 01:078710 2309 003 010320                       
---  I --- 01:078710 --:------ 01:078710 0008 002 0200                         
---  I --- 04:133277 --:------ 01:078710 1060 003 00FF01                       
---  I --- 04:133277 --:------ 04:133277 1060 003 00FF01                       
---  I --- 04:098449 --:------ 01:078710 2309 003 0B0320


Whenever the first block is --:----- the RfBee seems to either ignore the message or mark it as INCOMPLETE

[DanD]

Hi Bruce,

Thanks for posting this comparison of messages between your HGI80 and RFBee. I'm also interested in the details of any alterations that Fred has made to the Hydrogenetic firmware to improve the message decoding.

Here are some comments from me on your observations:

Whenever the first block is --:----- the RfBee seems to either ignore the message or mark it as INCOMPLETE

Hydrogenetic's firmware is fantastic, but a few limitations are documented within the firmware itself. It currently only decodes messages which contain 2 deviceIDs and the first position must be populated. Here's the line from the firmware that notes this:

else if(pkt_pos<=6)//ids we only support 2 atm (1,2 or 3 ids are valid)

I'm working on an update to support the range of messages that I observe in my setup which includes the '--:------ --:------ XX:XXXXXX' messages, but progress has been slow. I've had a small breakthrough today and discovered that some of my problems are likely due to using a different compiler/platform to Hydrogenetic. I've tweaked the typing of one or two variables to make it platform independent e.g. switched from byte to uint8_t and this seems to have fixed my transmit problem. I still need to mess with the timing a little, but I think I'm nearly there!

Do you think that your RFBee might be missing some of the messages due to its location or interference, as the missing messages all seem to be from devices other than the controller ie. they don't start with '01:078710'? I've seen similar behaviour with my RFBee for one of my zones andit was cured after I repositioned the RFBee.

Oh, and the 3 dashes at the start of the messages is the RSSI which isn't used by the Evohome code and isn't implemented in Hydrogenetic's firmware either (there's a note in firmware). I'm not planning on adding this functionality.

Dan

[fredh]

Bruce,

I've changed the firmware in the following areas:

• Correctly handle messages with only one parameter;
• After the preamble bit sequence, I sync on 32 bits instead of 16 bits. This causes less 'false starts';
• The 1101 has the capability to 'catch' the actual frequency of the transmission and reports the discovered 'offset'. I'm using the reported offset to adjust the frequency after every message received, using a low pass filter to suppress spikes. Sofar the final frequency will converge to a stable value. The benefit is that the recovered clock signal is of a better quality and thus the sampled value presented to the interrupt service routine is 'better'. This causes less errors in breaking the manchester code and checksum;
• A very, very, very small optimisation to the receiving interrupt service routine shaving a few instructions from the resulting compiled code.

Apart from this I changed the folder structure so that I can build and upload using platformio. If you like I can create a repo on Github so you can play with it.

I still have to look to the sending parts of the code.

Fred

[bruce_miranda]

Hi Dan

thanks for the explanation on this

Code: Select all

---  I --- --:------ --:------ 10:067219 *INCOMPLETE*     

what about this? What's causing this one?

Code: Select all

---  I --- *INCOMPLETE*

[bruce_miranda]

Bruce,

Apart from this I changed the folder structure so that I can build and upload using platformio. If you like I can create a repo on Github so you can play with it.

Fred

Yes please post your version of the code. I've been trying to cure the Incompletes without much success at all.

[fredh]

Ok Bruce (and anyone interested).

I have made the code available at: https://github.com/Red-F/EvohomeWirelessFW/tree/develop.

Notice: this is the develop branch in the repository. I've left the master branch unchanged. So, after cloning make sure you have done

Code: Select all

$ git checkout develop

to enter the develop branch locally.

I have completely switched from the Arduino IDE to PlatformIO. And I have tried to describe as clearly as possible how to build and upload the code to the RFBee/UartSBee combo using PlatformIO. See README.md (or read it on github ).

If any of you is using vscode, there is also a tasks.json included. This means that if you start working in the root folder of project (just enter: "code .") you can build from within the IDE using ctrl-shift-B. To upload from within vscode you press ctrl-p, then enter "task upload" (or just "task u") <ENTER>.

Let me know your experiences.
Fred

ps. my messages are slightly delayed as an admin has to approve of them before they become visible