Help requested: any Evohome users with an RFG100 and a HGI80?

[DanD]

Hi,

I'm working on a prototype of code to perform some of the functions of the Honeywell Evohome controller and I need some help with tracking down the exact structure of the commands to request and update the daily setpoint programs for each zone.

To do this I think I need the help of someone with an Evohome RFG100 and a serial device, a HGI80 or equivalent (RFBee etc). They'd need to use the Evohome phone app to make a change to a daily setpoint for one of their zones and then capture the commands that the RFG100 sends to their Evohome controller using the serial device. You shouldn't need to mess with your Domoticz set-up to achieve this. Hopefully, just using a serial client connected to the HGI80 should be sufficient.

Thanks!

Dan

[mschut]

Actually, since today I have both (and an Evohome). I am just changing to the RFG100 because I couldnt get it working stable (on a raspberry).

Glad to help, although I am not sure how and if I could, but willing to try.

Verstuurd vanaf mijn SM-G920F met Tapatalk

[EdddieN]

I got the WiFi version and the HGI80 if it helps.

What are you trying to do?

[DanD]

Hi both,

Thanks for your replies. What I'm trying to do is to fully understand the structure of the messages that the RFG100 sends to the controller when specific changes are made to scheduled setpoints. To be able to do this you'd need the non-wifi controller, a RFG100 and a HGI80 or similar serial device (to capture the messages). In particular, I'd like to capture the messages that are sent when the following changes are a made using the calendar functionality in the app:

• o add a new scheduled setpoint on a day so that it creates an additional weekly setpoint on the controller
  o use the copy function to copy all the setpoints from one day to another

I'm happy to just have the raw serial messages '--- I --- xx:xxxxxx........etc', ie. they don't need to be captured via Domoticz, it can just be via a simple serial client.

I'm currently building a prototype Evohome controller in Python (see my github area) and once I've got this working OK, I hope to be able to add this functionality within the Domoticz Evohome code.

Thanks,

Dan

[HFman]

Hi Dan,

Any progress ? If not, i could supply you i guess.
Have, RFG100, HGI80, and RFBee...

[DanD]

Hi,

Thanks for your message. I managed to make some progress on this a few months ago as I purchased an RFG100 and another user loaned me a controller, but hit a problem with decoding the complete schedule information. I was hoping to be able to decode the scheduling to enable a full backup/restore function. After some extensive testing I came to the conclusion that the messages must contain some relative date information as a restore seemed to sometimes hit problems and get rejected. I've not been able to do much work on my Evohome code for tge last few months, but I'm now ready to restart. I'll take a look at where I left off and post some further details, probably in a couple of weeks.

Dan

[philchillbill]

Hi Dan,

Any progress on this? I have a HGI80 and hate the fact that to mess with schedule data (rather than just editing setpoints/overrides/modes) I still have to use the 'external' TCC solution. If I could edit the schedule just using the HGI80 I'd be thrilled! Let me know if any beta testing would help.

My current homebrew solution is done in python/perl and uses an Alexa linking to Google calendar to spoof infinite future scheduling rather than fixed weekly scheduling. I retrieve today's desired schedule from Google and then use a perl interface to TCC to update the json data for today's zone-scheduling before rewriting to TCC. Doing this every day means TCC always has my correct schedule for 'today'. I'd much prefer just to do that with my HGI80 and take TCC out of the loop if I could.

[philchillbill]

Got me !

I guess I want to future-proof my setup for when Honeywell takes TCC down in a distant future. Hopefully my HGI80 will still be operational then.

[Simon2]

I managed to make some progress on this a few months ago as I purchased an RFG100 and another user loaned me a controller, but hit a problem with decoding the complete schedule information.

Could you tell me what commands you're sending to read/write the schedule information?

I've got an Evohome and want to work on decoding that part of the protocol.

So far all I've been able to determine is:
000C will return the actuator ID for each zone
0016 might be a ping that returns the RSSI at the controller (or it's just returning uninitialised data in the second byte)
0006 is... something

After some extensive testing I came to the conclusion that the messages must contain some relative date information as a restore seemed to sometimes hit problems and get rejected.

The NiagaraAX driver documentation implies that there's some kind of sequence number for when the schedule information was last updated (to avoid requesting it all again over RF). You probably need to increment this if you're changing it.

[DanD]

Hi Simon,

The schedule information command is 0x0404. I need to update my EVOHOME_CONTROLLER.PY code in Github at some point as I did get a bit further with identifying and implementing more of the Evohome commands before I shelved this work. I was really using this program as a quick way to explore and document the Evohome commands, as although many of them are in the Evohome Domoticz code, it's not very accessible for most users.
Here's the list that's in my current unpublished version:

Code: Select all

Com_SYSI = 0x10E0                 # Evohome Command SYSINFO
Com_BIND = 0x1FC9                 # Evohome Command BIND
Com_SYNC = 0x1F09                 # Evohome Command SYNC
Com_NAME = 0x0004                 # Evohome Command ZONE_NAME
Com_SETP = 0x2309                 # Evohome Command ZONE_SETPOINT
Com_SETM = 0x2349                 # Evohome Command ZONE_SETPOINT_MODE
Com_TEMP = 0x30C9                 # Evohome Command ZONE_TEMP
Com_UNK1 = 0x0100                 # Evohome Command ZONE_UNK1 (unknown)
Com_UNK2 = 0x0008                 # Evohome Command ZONE_UNK2 (unknown)
Com_UNK3 = 0x0009                 # Evohome Command ZONE_UNK3 (unknown)
Com_UNK4 = 0x1100                 # Evohome Command ZONE_UNK4 (unknown)
Com_UNK5 = 0x0005                 # Evohome Command ZONE_UNK5 (unknown)
Com_UNK6 = 0x0006                 # Evohome Command ZONE_UNK6 (unknown)
Com_DATE = 0x313F                 # Evohome Command DATE_TIME
Com_HEAT = 0x3150                 # Evohome Command HEAT_DEMAND                        
Com_SCHD = 0x0404                 # Evohome Command SCHEDULE

Dan

[Simon2]

Do you have some example messages for 0x0404?

I've tried various length request messages but it's not returning a response.

[DanD]

Hi Simon,

Here's a bit more info. The following example is a 0x0404 message exchange which occurs shortly after startup between an RFG100 and a non-wifi controller

Code: Select all

13/04/2017 18:55:06 045 RQ --- 30:060058 01:037519 --:------ 0404 007 00200008000100
13/04/2017 18:55:06 045 RP --- 01:037519 30:060058 --:------ 0404 048 0020000829010368816DCCC10D8030084051A0881DA8078F3D398303388B733A8A9A686CDACF8D1F7822FF1C2A5272C9
13/04/2017 18:55:09 045 RQ --- 30:060058 01:037519 --:------ 0404 007 00200008000203
13/04/2017 18:55:09 045 RP --- 01:037519 30:060058 --:------ 0404 048 002000082902034D92F36E79CE73DB161FEFD649A4468D6F57F0143C054FC133F00C3C03CFC04BE025F01278093C07CF
13/04/2017 18:55:10 045 RQ --- 30:060058 01:037519 --:------ 0404 007 00200008000303
13/04/2017 18:55:11 045 RP --- 01:037519 30:060058 --:------ 0404 038 002000081F0303C173F01CBCE9FD6DEF9EB6D9D87AEF697BE70578015E80178D77014CCE19AA

This example is a 0x0404 message exchange which occurs after copying a daily schedule on the app between the RFG100 and non-wifi controller:

Code: Select all

14/04/2017 09:13:53 045  W --- 30:060058 01:037519 --:------ 0404 048 0020000829010468816DD0CD0D80200C86E1B6D49FC42518C283474FCEE000DEDDC239DD80151451A0F1E3F8A67DD240
14/04/2017 09:13:54 045  I --- 01:037519 30:060058 --:------ 0404 007 00200008290104
14/04/2017 09:13:54 045  W --- 30:060058 01:037519 --:------ 0404 048 0020000829020454DEC144631F4295E8BC5BDFD936E97F6E6988E6B634061E038F81C7C013E009F00478023C073C073C
14/04/2017 09:13:56 045  I --- 01:037519 30:060058 --:------ 0404 007 00200008290204
14/04/2017 09:13:56 045  W --- 30:060058 01:037519 --:------ 0404 048 00200008290304073C073C059E024FB357FE4EB3D7F9AF35EF6E3D17DB2AB1D9B9E4EDA66D8F5776DB7C9F6DE93EDBDE
14/04/2017 09:13:58 045  I --- 01:037519 30:060058 --:------ 0404 007 00200008290304
14/04/2017 09:14:00 045  W --- 30:060058 01:037519 --:------ 0404 048 002000080C0404FB42DDD27D83BF00896D372AB3D7F9AF35EF6E3D17DB2AB1D9B9E4EDA66D8F5776DB7C9F6DE93EDBDE
14/04/2017 09:14:00 045  I --- 01:037519 30:060058 --:------ 0404 007 002000080C0400

Hence, you can probably work out the approach I was using to try and implement a back-up/restore. I used the first example to request all schedules from the controller and then attempted to restore these using the second example. However, using this approach I managed to crash the controller on more than one occasion and didn't manage to decode the structure of the schedule information except for some of the simple message structure pieces.

Hope these are helpful.

Dan

[Simon2]

The request message "00 20 00 08 00 01 00" is:

Code: Select all

00 = Zone
20
00
08
01 = Block index
00 = Total blocks (0 on initial request)

The response message "00 20 00 08 29 01 03" is:

Code: Select all

00 = Zone
20
29 = Length of block in bytes
08
01 = Block index
03 = Total blocks
.. = Block data

Concatenate all the blocks together (I don't know what happens if the schedule changes while you're receiving it).

The data is zlib compressed. After uncompressing it there are a variable number of records of size 20 bytes.

Each record consists of 32-bit little endian words.
The first word is always zero.
The second word is the zone number.
The third is the day of the week (0 = Mon, 6 = Sun).
The fourth is the time of day in minutes since midnight.
The fifth is the temperature in hundredths of a degree.

The temperature value appears to contain garbage in the top two bytes (although in your example read data it happens to contain the temperature again). On mine it varies each time I change the schedule.

I suspect the controller may crash if you don't fill these with zero when setting it, but your example has 0xEF 0xEF and other values. Alternatively if you modified any of the content then it may crash when it fails to uncompress it.

I haven't tried writing an updated schedule to the controller but it looks like the same process in reverse, except that you start off with the total blocks and its final response has a total blocks of 0.

Here's a script to decode the request and response data you provided: https://gist.github.com/nomis/4e534ddd0 ... a04610c7fa

[DanD]

Hi Simon,

Excellent detective work! I'll have a mess with the temperature field to see if there's any obvious meaning to the remaining bits. I'm still a little puzzled why some of my previous attempts at restoring using these messages might have upset the controller as they don't seem to contain anything specific to the day when the schedule was requested. I'll re-check my notes, but I thought that my testing was something like the following:

1. request a zone's schedule
2. alter the zone's schedule on the controller
3. restore the previous schedule

It is possible though that I might have messed up the data string I was attempting to restore.

Regards,

Dan

[Simon2]

I've managed to set the schedule data for a zone on my controller.

(I edited my earlier post because the second word is actually the zone number, not zero. That's what I get for initially testing on zone 0...)

When compressing the data the maximum window size accepted is 16384 bytes but the compression level can be 9, e.g.:

Code: Select all

cobj = zlib.compressobj(level=9, wbits=14)
data = cobj.compress(data)
data += cobj.flush()

It looks like the RFG100 incorrectly pads its last (shorter) message with the content of the previous block of data. This is not required and can be omitted.

[DanD]

Building on the information that Simon's shared I've now developed a couple of simple Python scripts to backup and restore the Evohome controller schedules via ASCII files.

https://github.com/Evsdd/Evohome_Schedule_Backup
https://github.com/Evsdd/Evohome_Schedule_Restore

I'm not quite sure how best to add this functionality into Domoticz at present, but hope to be able to.

Dan

[philchillbill]

Dan,

Absolutely and positively magnificent of you ! This will make a *lot* of people very happy as it reduces reliance on TCC even more.

A quick and dirty way of getting this functionality 'into' Domoticz might just extend the JSON command possibilities with an &schedule=XXXXXX for the idx in question. The XXXXXX could be something very simple like '1_480_2000_1320_1500__2_450_1950' etc (using _ and __ as separators needs no special URL encoding) where 1 is day number, 480 mins since midnight is 8AM, 2000 is 20.00 deg, 1320 mins since midnight is 10PM, 1500 is 15.00 deg. The __ before the 2 starts a new day number, etc, etc. Simple to parse and simple to generate from any script external to Domoticz.

Just an idea of course, but it would allow changing Evohome schedules per zone using Domoticz as a bridge between JSON and the HGI80 in much the same way as it is a bridge today for &setpoint=XXXX and &mode=XXXX, with the one difference that they are currently visualised in UI elements in Domoticz while &schedule is not (yet).