Evohome / Evotouch Wireless protocol?

[hydrogenetic]

I was interested in the CUL but I thought the lack of source code for the firmware might be a problem at some point so I decided to try the HGI80 instead. I'm guessing with a few mods to the firmware the CUL could actually be made compatible with the HGI80.

I finished the support for the HGI80 in Domoticz which is available at https://github.com/fullTalgoRythm/Domoticz-evohome I will send a patch and see if it gets picked up. The file you would probably be interested in is domoticz/hardware/evohome.cpp

Some brief notes..

Controller demand - same as 0x3150 but the device number (1st byte) appears to be F9/FA/FC for CH/DHW/Boiler.

Cmd Len Payload
0008 002 F90E

This command is interesting because it's the one that the relay monitors to work out how much to switch on and off. C8 appears to be used as all on (also used in other places) I think this causes an immediate switch on of the relay and is probably the only value used for DHW. The relay posts 0x3EF0 with it's on off state (byte 2) also C8 for on. So basically the controller monitors 0x3150 for zone demand, aggregates it and broadcasts 0x0008 with the aggregated demand which fires the relay presumably using TPI. I think there is another message after binding 0x1100 that tells the relay some of its settings.

If you monitor the binding message 0x1FC9 you'll see some of the applicable device number / command combinations that will be sent or monitored along with the corresponding device id. The payload is device number (1 byte) command (2 bytes) device ID (3 bytes) in repeating groups of 6 bytes.

Sometimes parts of a message are masked with FF presumably when something doesn't apply. Anyway most of what I've discovered is published in the source code.

[hydrogenetic]

@r_255: Thanks for the kind words but I think you're maybe giving me too much credit, not that I don't want it

It occurs to me that the requirement for the v23 firmware may well have been related to adding support to control the evohome as I think it's required not just for the HGI80 but also the RFG100. I'm basically using the same control messages from the HGI80 as the RFG100. You can see all those details in the source code link above but I think it will be unlikely to work unless you have firmware v23 or above anyway. I'm also guessing this may well have been the 1st version to ship with the new evohome as I believe that supported the RFG100 out of the box.

The good News is that your evohome is probably flash updatable (I saw a link to a v21 firmware). The bad News is that I haven't seen any evidence that the v23 firmware can be downloaded anywhere. You would basically have to try requesting it from Honeywell support It also stands to reason that the mono evohome will have different firmware than the colour version (and any other applicable hardware revisions could also vary the fw too I guess) so you may need someone with the same type of unit with up to date fw before you can think about extracting it. Looks like it's down to the good people of this forum to find a solution again!

I'm still interested in the CUL/RFBee wireless solution as I'm now wondering if rather than buying a zwave controller or similar solution if I couldn't just roll my own switches based on using our own commands. I was thinking as I already have the HGI80 up and running broadcasting is not a problem and imho (mesh not withstanding) one protocol is as good as another for this type of thing. I think the switch or whatever device could also be made more reliable by using 2 way comms etc.

[XanderF]

I'm using a Raspberry Pi and purchased a Honeywell HGI80 to communicate with my Evohome system from Domoticz. The HGI80 is connected to my Raspberry Pi via USB. It is detected but not attached to ttyUSB0 or any other.

lsusb output:
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 10ac:0102 Honeywell, Inc.
Bus 001 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

/var/log/dmesg output
[ 3.298970] usb 1-1.2: new full-speed USB device number 4 using dwc_otg
[ 3.474606] usb 1-1.2: New USB device found, idVendor=10ac, idProduct=0102
[ 3.492433] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3.508889] usb 1-1.2: Product: TUSB3410 Boot Device
[ 3.515493] usb 1-1.2: Manufacturer: Texas Instruments
[ 3.537013] usb 1-1.2: SerialNumber: TUSB3410
...
[ 11.335965] usbserial: USB Serial support registered for TI USB 3410 1 port adapter
[ 11.349040] usbserial: USB Serial support registered for TI USB 5052 2 port adapter

I've added this to /etc/rc.local:
modprobe ti_usb_3410_5052
echo 10ac 0102 > /sys/bus/usb-serial/drivers/ti_usb_3410_5052_1/new_id

I've added this to /etc/modules:
ti_usb_3410_5052

I'm already using a USB P1 smart meter cable which is attached to ttyUSB0 and working. Any idea why it does not get attached to ttyUSB1?

[XanderF]

Fixed. After executing 'echo 10ac 0102 > /sys/bus/usb-serial/drivers/ti_usb_3410_5052_1/new_id' directly from the shell I noticed firware was missing when I read dmesg. Downloaded ti_3410.fw and copied it to /lib/firmware/.

[hydrogenetic]

Couple of notes...

Where 0xc8 (200) is the max value for a byte this appears to be a percentage i.e. n/0xc8*100 or n/2

The 3B00 cmd is more than just a keep alive for the relay it also synchronises the start of a time period for any relays bound to the message. So if there are 6 cycles an hour i.e. 10 minutes per period then the 3B00 message is sent every 10 minutes presumably synchronised to the controllers clock or something. I've not tried altering the number of cycles which I think may be controlled via the 1100 message but I haven't confirmed that yet (so I also haven't confirmed if the 3B00 time period alters - guessing it does). So basically the controller broadcasts an 0008 demand message with a percentage demand i.e. 0 to 0xc8. The relay is bound to this message during binding so it's looking for the specific command / controller id combination to read its demand. As an example if the demand is 50% (0x64) then the relay will be on for half a time period using the 3B00 message to gauge the start of each period. The relay uses the most recent 3B00 and 0008 messages to generate its on/off periods which it will keep doing either until it receives a new message or goes into fail safe mode (if it hasn't received the appropriate messages within its time-out period).

[hydrogenetic]

So I decided to create an RFBee firmware for Domoticz i.e. one that allows you to use the RFBee in place of the HGI80. I started off using HoneyCommLite but there were some notes about it being too slow to do hex print (which is what I wanted) so I couldn't gauge if it was working properly or not. I decided I wanted to check the registers used for the CC1101 so I opened up my RFG100 as I'm not using it any more. Just to confirm this has a CC1101 and an Atmel AT91SAM9G35 (ARM MCU). I traced the SPI lines from the CC1101 to a set of test pads at the bottom of the RFG100 that get exposed when you slide the bottom cover off. It looks like the test pads are designed to be hooked up via a special connector probably something made with pogo pins that clips to the pcb. I decided that it would be easier to solder something to the test pads than mess around too much although I would have preferred not modifying the unit I managed to get the register values using a cheap logic analyser and sigrok in the end.

Code: Select all

30 //CCx_SRES

02 //CCx_IOCFG0
2e

01 //CCx_IOCFG1
2e

00 //CCx_IOCFG2
0d

07 //CCx_PKTCTRL1
00

08 //CCx_PKTCTRL0
32

0b //CCx_FSCTRL1
0f

0c //CCx_FSCTRL0
00

0d //CCx_FREQ2
21

0e //CCx_FREQ1
65

0f //CCx_FREQ0
b4

10 //CCx_MDMCFG4
7a

11 //CCx_MDMCFG3
f8

11 //CCx_MDMCFG3
83

12 //CCx_MDMCFG2
10

13 //CCx_MDMCFG1
22

14 //CCx_MDMCFG0
f8

15 //CCx_DEVIATN
50

16 //CCx_MCSM2
07

17 //CCx_MCSM1
30

18 //CCx_MCSM0
18

3e //CCx_PATABLE
c3

19 //CCx_FOCCFG
16

1a //CCx_BSCFG
6c

1b //CCx_AGCCTRL2
43

1c //CCx_AGCCTRL1
40

1d //CCx_AGCCTRL0
91

21 //CCx_FREND1
56

22 //CCx_FREND0
10

23 //CCx_FSCAL3
e9

24 //CCx_FSCAL2
2a

25 //CCx_FSCAL1
00

26 //CCx_FSCAL0
1f

29 //CCx_FSTEST
59

2c //CCx_TEST2
81

2d //CCx_TEST1
35

2e //CCx_TEST0
09

36 //CCx_SIDLE

34 //CCx_SRX

There commented with the register names as used in the RFBee firmware. I checked against the ones provided by CD and they seem very similar, async mode, 38k data rate the main differences are a slightly different channel number (FREQ0) a different BW and slightly lower power setting. I'm not sure if the channel number variation is device or region specific. I'd like to check my controller and get the settings off that too but I'm not messing with that yet

There were quite a few hurdles but the firmware is done and I'm testing it with Domoticz I'll post some more info after I upload it.

[r_255]

lol @ Hydrogenetic!
To me you are a hero...

Thanks for sharing your information, sigrok looks very intresting!
Rfbee had problems with missing msg while decoding, something the culv3 stick did not have.

[hydrogenetic]

@r255 thanks it's nice to be appreciated

The RFBee is a pretty limited device it took a bit of re-engineering to get it processing adequately, The HGI80 uses a TDA5250 and a M430F148 MCU (ti 16-Bit Ultra-Low-Power Microcontroller)

[hydrogenetic]

I believe the header flags [5:2] represent a bit packed table (as given in CD's protocol pdf) of all potentially valid packet types / modes.

The bottom 3 bits as stated are dev0, dev1 and dev2. The top 4 bits (from MSB down) are the packet mode as follows W, I, RP and RQ. My guess is this is Write, Info, Response and Request.

A few examples of common modes as follows...

Code: Select all

        //0C 00[0011]00 (03=0B=0001011) RQ      dev1 dev0
        //18 00[0110]00 (06=26=0100101) I  dev2      dev0
        //1C 00[0111]00 (07=23=0100011) I       dev1 dev0
        //2C 00[1011]00 (0B=43=1000011) W       dev1 dev0
        //3C 00[1111]00 (0F=13=0010011) RP      dev1 dev0

Further guess is that dev2 and dev1 may be the difference between a broadcast and point to point addressing with dev0 always given as the source (if dev2 is the broadcast address it's normally just equal to dev0). So a device may broadcast or transmit a setting / value using I, another device may request the setting / value using RQ (with parameters such as the zone number in the payload) and receive a response back via an RP packet and finally it may also be possible to use W to update the setting if applicable. So I may update a setting using a W packet the device could then broadcast the new setting using 18 (I dev0 dev2) where dev2 equals dev0 and finally confirm back using 1C (I dev0 dev1) where dev1 would by my address. Obviously different devices (and fw revisions) support different packet types / modes for a given command. There is a combination of device no / cmd / device address given in the payload of the binding message 1FC9 I think this would correspond with dev2 as well as the command and device number from the payload.

[mouse256]

@hydrogenetic: very cool work indeed.
Just a question: why are you using an RFBEE and not a CUL? I tried hacking culfw once myself to get support for honeywell but never succeeded. Is it easier to work on the RFBEE?

[hydrogenetic]

@mouse256 thanks for the comment

It's a good question, on the face of it the CUL is the better hw i.e. 32u4 processor with more ram and easy to add an external antenna. Both devices are 8MHz so not sure about speed I originally thought the CUL was faster but maybe not. There is always a flip side of course the RFBee should hopefully be lower power as you can use it without the USB interface (the USB interface is apparently built into the 32u4 but I assume you can do away with any voltage regulators that would otherwise drain a battery), project friendly as most of the arduino and power pins are easily accessible for adding sensors and other devices etc. The overall cost is lower and as mentioned it's available without the USB interface which further brings the cost down if you're thinking of adding a 2nd device etc. It's also more readily available where I am so the flip side got it as this was also a sort of test as I'm new to the world of Arduino and wanted to see what I can do and potentially modify this at a latter date to a room temperature sensor. Hopefully others will also create some evohome compatible devices too

The code is now available at https://github.com/fullTalgoRythm/EvohomeWirelessFW

The RSSI measurement is skipped as I'm not currently reading that in via Domiticz (col 1 of the serial output) and I don't support every potential header variation just what was required for the messages I've seen to date. So far it's working ok with Domoticz, it has to request the set point mode (override) periodically just to confirm if it was changed as evohome does not always broadcast changes (just the setpoint on its own). So it's regularly switching to send and polling all the zones (response from the controller is sub second) which is how the RFG100 does it too. It seems to have an acceptable level of packet loss and handles long packets or when the packets come in quickly. I've been benchmarking it against the HGI80 and it seems to be holding its own (the HGI80 will occasionally loose some data too of course) although only time will tell and it would require a more thorough comparison to really see how well it works.

[r_255]

Awesome !!!

Gonna dig up the rfbee and do some reading. But 1st ill have a party


Okay i am set, but i had some compile errors.
After importing the zip into libraries it was fixed.


https://plus.google.com/103500861087395 ... zS6NpmyJE2

[hydrogenetic]

@r_255 Thanks for giving it a go glad you got a result

Honeywell originally stated you need a v23 firmware or later to control the system. Just curious if you have that version and if you had any luck changing the controller modes and set point etc.

[r_255]

Lets start with things that do work :O)

- It picks up setpoint temps from my old evo controller, v21 firmware
- it does gets temp information about the rooms
- gets setpoints that are set on the evo touch controller
- found my zones instantly in domoticz

Well i guess honeywell was right ;o) because i cant controll and am on v .21 on the evotouch controller
and my hr80's are even older, as i did have them on a cm67 as there was no evo system at that time. Also still have the old hc60ng. ( was wrong about having the newer version )

- I can't set temp from domoticz
- it does not pick up radiator nob sets.

I did not had enough time to see what is going on, and wondered how the system works.
Does it inject based on the found evo touch controller or does it mimic the way new evohome controller works ?

I did do some pre work .... :O)
https://plus.google.com/103500861087395 ... YjAsmyAfT7

[r_255]

Today i got ( thanks to a fellow forum member ) the v23 firmware and i can confirm it works with my evotouch, only one thing my hr80's dont get updated .... ! (v2.03)
I am going to have a look, because my setup is fairly old and it might have to do a reconnect.

It sets setpoints to the evotouch with in one or two seconds for each zones, so thats working amazingly fast!
Okay, update... Rebinding did the trick, hr80's are set !!!

this is so cooool!