Evohome / Evotouch Wireless protocol?

[DanD]

Hi,

I've had a further read of the HCC80 manual to understand its functionality. Based upon the logs that you've captured it looks as if the HCC80 aggregates the heat demand for the zones that it controls and sends this information to the Evohome controller via a single zone message, Zone 4 in your case. It would be interesting to see whether this is always simply a 0 or 200, or whether the HCC80 varies the overall demand based upon the difference between setpoint and room temperature or whether this is handled by the Evohome controller. Unfortunately, it definitely looks like the HCC80 doesn't send the individual zone demand values to the controller .

PS I re-read your earlier messages and I can now see that you're using Y87 thermostats for each room.

Dan

[jdp80]

Sorry for not responding sooner - struggling with SD card corruption right now!
Haven't had a chance to run any analysis of the zone demand yet, but I will do so as soon as my dev install is running again.

I'm trying to work out why I can't see the Controller in Domoticz even though I've cleared the system a few times.

I think something else is reporting as a controller before the actual Evohome controller does, meaning the call to SetControllerID saves the wrong device.

evohome: HEAT_DEMAND: Controller (0x5b3ff9) DevNo 0x00 0 (0x8)
Does this mean Domoticz thinks my controller is 0x5b3ff9 ? This is either a DTS92 or one of the 4x BDR91s.

[DanD]

Hi,

It does sound like the Domoticz Evohome code might not be recognising the devices in your set-up correctly. In one of the previous logs you sent and in your device list it looked like the controller DeviceID was set to 0x529fa so it's strange that you're also getting messages with 0x5b3ff9 shown as the controller ID. I think the 0x5b3ff9 device is your HCC80 underfloor controller as it is reporting multiple zone temperatures and also heat demand.

When you're able to get it running again, it would be really helpful if you could send one of the logs immediately after starting Domoticz to see the SYSINFO, ZONE_INFO and DEVICE_INFO commands. This should help to work out all the devices that are sending messages.

Dan

[dty]

If anyone is interested, I am very close to having a Raspberry Pi with Busware SCC card working as an EvoHome sniffer with Domoticz. I am currently working on a custom firmware (receive only, at the moment) and have all the radio and packet decoding working. I'm just working on formatting the output in a way that Domoticz expects.

Many, many thanks to everyone on this thread for all the information, hints, tips, pointers, etc. especially to crazydiamond for his initial work and jrosser and hydrogenetic for their working RFBee firmwares which have heavily inspired my SCC firmware!

[rhannink]

Hello,

I have Domoticz with the HGI80 interface connected to a round wireless thermostat. This is all working ok.

Now Iam looking for a new home security system which I can also control (min. arm and disarm and maybe sensor status etc).
Does anyone now if the HGI80 can also communicate with the Honeywell Le Sucre alarm system? It is working on 886 Mhz and it can also be controlled from the Total Connect app via the cloud. But there's nothing on the Internet about an API.

Gr. Remco

[Giuseppe]

If anyone is interested, I am very close to having a Raspberry Pi with Busware SCC card working as an EvoHome sniffer with Domoticz. I am currently working on a custom firmware (receive only, at the moment) and have all the radio and packet decoding working. I'm just working on formatting the output in a way that Domoticz expects.

Many, many thanks to everyone on this thread for all the information, hints, tips, pointers, etc. especially to crazydiamond for his initial work and jrosser and hydrogenetic for their working RFBee firmwares which have heavily inspired my SCC firmware!

I am very interested in the code. May be the CUL code (crazydiamond) get an open base.

[dty]

I am very interested in the code. May be the CUL code (crazydiamond) get an open base.

Well, the good News is that it's now fully working with receive AND transmit, so it's grabbing all the zone information from Evohome by making requests over-the-air. However, as a professional software developer, I'm deeply shocked, embarrassed and offended at the quality of the code I've hacked out, so I'm going to rewrite it and clean it up a load before I publish it online. I will post here when it's ready. Probably a week or so.

I wasn't able to modify the CUL firmware to my needs, so I ended up writing a completely custom firmware from scratch using hydrogenetic's RFBee firmware as inspiration for the approach and some of the techniques too. But whereas his firmware is compiled using the Arduino IDE and libraries, mine is compiled from scratch using the same system as culfw (mostly because the Arduino IDE doesn't have a way to target the Atmel atmega1284p processor found on the SCC). In fact, I use the culfw makefile with a few changes, so as long as you're happy compiling and flashing culfw onto your SCC, you should be OK installing my firmware.

[Giuseppe]

@dty
That's nice, thanks for your contribution and all others.
I will compare the sniffing results from HGI80, CUL and SCC.

[ettore1969]

Hello to everyone,

after long reading and searching I found that is possible to upgrade my old Evotouch B&W controller with a new firmware in order to get it fully working inside domoticz.
Actually my unit has Firmware Rev. 20 and because of this I can only see Honeywell Device in my Domoticz, without the possibility to interact with they.
Please, can someone that as the firmware V23 for the Black&White old unit share it to me so I can upgrade it ?
I read about the fact the upgrade is to be done in a Windows XP machine. There's other instruction or caution to be taken in order to do a succesfully update ?
Thank you in advance for your attention and help.

[neilcoggins]

Hi all,

Trying to get my EvoTouch (mono w/ firmware v23) working with Domoticz using an RFBee. Here's the details:

EvoTouch system:

• EvoTouch controller
• 7 HR80 TRVs (one in each of 7 zones)
• HC60NG boiler relay

Computer:

• x64 PC running Debian Jessie
• Domoticz v3.5989
• RFBee w/ UARTSee running the custom firmware

So far, Domoticz has created 21 devices (7 zones that match the TRVs, 7 relays that match the TRVs, the boiler relay, the DHW, and -5- zone/setpoint entries that appear to be the EvoTouch controller). All well and good. HOWEVER, I cannot get the Domoticz system to control the temperature of 5 of the zones - only 2 zones are allowing me to set overrides. Any overrides set on the other 5 zones are ignored by both the HR80 for that zone -and- the EvoTouch.

Could it be signal strength (the 2 zones that work are the 2 closest)? I have tried bringing the EvoTouch to within 1m of the RFBee (which is *way* closer than either of the working HR80s) and it didn't change anything. How does the RF signalling work for Overrides in Domoticz - is it RFBee -> EvoTouch -> HR80 or RFBee -> HR80 -> EvoTouch?

Or maybe it is a problem with binding / setup (I think the 2 HR80s all came with the EvoTouch, whereas the others were puchased separately before (to work with 2x CM927Z units that I had previously)?

Help!

[Giuseppe]

@neilcoggings
Try a factory reset and binding for the problem HR80's. What version is their fimware?
You had the same problem with Evotouch version 17, or after upgrade to version 21 or 23?

[neilcoggins]

Hi,

Thanks for the suggestion - I'll try rebinding everything when I get home tonight. All HR80s are reporting 2.03 when they power on.

I haven't upgraded the EvoTouch - mine came (new) with v23 firmware (must have been made just before they released the colour version).

One question - how do you factory reset an HR80? I know how to bind them, but never had to do anything more before...

[Giuseppe]

@neilcoggings
See this document: https://www.kijkvoelbeleef.nl/Renderers ... 177ffb279e chapeter 6

[DanD]

How does the RF signalling work for Overrides in Domoticz - is it RFBee -> EvoTouch -> HR80 or RFBee -> HR80 -> EvoTouch?

It's actually RFBee -> HR80 & RFBee -> EvoTouch. The override works by the RFBee sending a message which is structured exactly as if it has been sent by the controller to the HR80 and the controller also accepts this message (it's a bit like there's two authorised controllers on the system). The controller then queries all devices to check that the HR80 has received the new setting.

Your list of devices sounds a little odd as I wouldn't expect the additional 5 zone/setpoint entries. Could post a screenshot of your devices list in Domoticz? I'm an active developer on the Domoticz Evohome code and hopefully can help. I'm currently working on fully testing the HR80 implementation (firmwares 2.03 and 2.04) in the Domoticz code as I've made a number of updates this year, but have previously only been able to test these on HR92 devices.

Dan

[colintd]

Back in 2013 I hacked a boiler relay to act as an EvoHome sniffer, and reported the details in this thread domoticaforum.eu/viewtopic.php?f=7& ... 892#p62892 .

However, even at the time I wanted to get a system working with a CC110x board, ideally running as part of culfw.

That got shelved for a while, but I've finally got back to it, and have written a module which allows sending and receiving EvoHome messages, including message delimiting on the CUL (so low interrupt rate on the host) and checksum generation/validation (so you only receive valid messages, and when sending the board will automatically add the checksum).

At present I'm just using it as part of my EvoHome protocol sniffer, but I wondered whether anyone would be interested in:

a) testing on a broader range of hardware (currently I've got it running on a tweaked COC v1, and a stock CUL V3),
b) helping integrate as an access device for fhem (I've looked at the source, but haven't yet had time to get a build/test system setup)?

I'm in the process of getting the extension merged into a proper culfw release, but right now I would be happy to send anyone interested, either a build of the CUL_V3 firmware, or the two new files and the couple of minor tweaks required to hook them into a new culfw device variant .

The syntax of the new culfw command for EvoHome is currently as follows:

v[<func>][<hex>] Honeywell EvoHome/EvoTouch mode.

<func> is one of:
l
Listen for EvoHome messages.
Only EvoHome messages with a valid checksum will be returned in this mode.
Messages are reported on receipt as vr<hex> with the valid checksum byte removed.
d
Listen for EvoHome messages as above, but also report aborted receives as v!<code>[<hex>].
This extra information can be useful for debug purpose.
Codes include:

Interference related
F - Framing error, where received data doesn't decode to 1start-8data-1stop at 38,400bps
M - Manchester coding error in received data
C - Checksum error over completed message

Firmware problem
L - Message exceed expected maximum length
O - Overrun, where a second data byte arrived before the ISR processing the first was able to complete

s<hex>
Send out an EvoHome message. No checking is performed on sent data, but a valid checksum is automatically added.

If no <func> is specified, EvoHome reception is disabled.

Responses
va - Successful acknowledgement to request
vb - Attempt to send whilst device busy receiving a message (small timing window, just retry)
v? - Unknown command

And an example of listening output is:

Code: Select all

vr18112BD9112BD910600300FF01
vr1812BF85049C153150020B4C
vr181199CB049C1510600303FF01
vr181199CB1199CB10600300FF01
vr1836D07F36D07F3EF00300C8FF
vr0C7857BF049C1523490101
vr3C049C157857BF2349070105DC00FFFFFF
vr181249B71249B730C903000637
vr1812890712890730C903000662
vr1812890012890030C903000686
vr0C7857BF049C1523490102
vr3C049C157857BF23490702060E00FFFFFF
vr18112BD5112BD530C9030005F2
vr18128900049C1510600303FF01
vr1812890012890010600300FF01
vr181382C3049C152309030A0578
vr0C7857BF049C1523490103
vr3C049C157857BF23490703064000FFFFFF
vr181199D3049C15230903030640
vr0C7857BF049C1523490104
vr3C049C157857BF23490704064000FFFFFF
vr18112BD9049C1510600303FF01
vr18112BD9112BD910600300FF01
vr18128910049C15230903060578
vr0C7857BF049C1523490105
vr3C049C157857BF23490705057800FFFFFF
vr18112BED049C151060030BFF01
vr18112BED112BED10600300FF01