Originally posted by DanD
View Post
My HGI80 equivalent Domoticz setup without HGI80
Collapse
X
-
Good idea, but no, the 3 bytes at the end of these shorter 7 byte messages always seem to be FFFFFF. The timed overrides are sent in longer 13 byte messages using the same command 0x2349. Most of the known command/message structures are all implemented in the Domoticz EvohomeRadio.cpp code. There are a few of the ones we've decoded still to be added, for example the schedule command 0x0404 and they're on my to-do list, if I ever find sufficient spare time .
Comment
-
-
Originally posted by DanD View PostGood idea, but no, the 3 bytes at the end of these shorter 7 byte messages always seem to be FFFFFF. The timed overrides are sent in longer 13 byte messages using the same command 0x2349. Most of the known command/message structures are all implemented in the Domoticz EvohomeRadio.cpp code. There are a few of the ones we've decoded still to be added, for example the schedule command 0x0404 and they're on my to-do list, if I ever find sufficient spare time .
Comment
-
-
Originally posted by DanD View PostGood idea, but no, the 3 bytes at the end of these shorter 7 byte messages always seem to be FFFFFF. The timed overrides are sent in longer 13 byte messages using the same command 0x2349. Most of the known command/message structures are all implemented in the Domoticz EvohomeRadio.cpp code. There are a few of the ones we've decoded still to be added, for example the schedule command 0x0404 and they're on my to-do list, if I ever find sufficient spare time .
I have had a look at the domoticz code and I'm finding it very hard to decipher how the date and time are formatted for a time based setpoint override. Could you give a me a description of how it's done?
Comment
-
-
Yes, the c++ code is very modular and it can take a very, very long time to hunt down the exact details of command structures.
Hopefully the example timed setpoint override with decode below helps (note-the times are 24h clock):
Code:Example timed setpoint override message (command 0x2349): W --- 18:002858 01:073076 --:------ 2349 013 0104B004FFFFFF320B0D0B07E3 Payload (hex) decode info: 01 : Zone = 2 (n+1) 04B0 : Setpoint = 12.00deg (1200) 04 : Override type = Timed FFFFFF : Additional flags, meaning unknown 32 : Time = 50 (minutes) 0B : Time = 11 (hours) 0D : Date = 13 (day) 0B : Date = 11 (month) 07E3 : Date = 2019 (year)
Comment
-
-
Originally posted by DanD View PostYes, the c++ code is very modular and it can take a very, very long time to hunt down the exact details of command structures.
Hopefully the example timed setpoint override with decode below helps (note-the times are 24h clock):
Code:Example timed setpoint override message (command 0x2349): W --- 18:002858 01:073076 --:------ 2349 013 0104B004FFFFFF320B0D0B07E3 Payload (hex) decode info: 01 : Zone = 2 (n+1) 04B0 : Setpoint = 12.00deg (1200) 04 : Override type = Timed FFFFFF : Additional flags, meaning unknown 32 : Time = 50 (minutes) 0B : Time = 11 (hours) 0D : Date = 13 (day) 0B : Date = 11 (month) 07E3 : Date = 2019 (year)
Excellent, got it working. Along with the cancel override too. Thanks again.
Comment
-
-
For anyone that's interested, there's now a project by zxdavb to use HGI80 on home assistant, see the following forum thread
This uses RF to eavesdrop honeywell-based CH/DHW traffic, including evohome, sundial, hometronics, etc. - it does not use MQTT, node-red, etc. This is beta code. It almost certainly wont break anything, but you never know 😉 NOTE: you will need a USB dongle, either a HGI80 or something running this firmware (~£30) It uses a client library, evohome_rf (WIP) that listens to the RF traffic and maintain a data structure that HA can poll. The long-term plan for this library is to replace yo...
Comment
-
-
I can suggest people check out / contribute to:
which aims to document the RAMSES-II protocol, and also my code at:
An interface for the RAMSES RF protocol, as used by Honeywell-compatible HVAC & CH/DHW systems. - File not found · zxdavb/ramses_rf
which is hoping to be accessible for less experienced coders (it is in Python), for example:
Code:def parser_2349(payload, msg) -> Optional[dict]: # zone_mode assert msg.verb in [" I", "RP"] assert len(payload) / 2 in [7, 13] assert payload[6:8] in list(ZONE_MODE_MAP) assert payload[8:14] == "FFFFFF" return { "zone_idx": payload[:2], "setpoint": _cent(payload[2:6]), "mode": ZONE_MODE_MAP.get(payload[6:8]), "until": _dtm(payload[14:26]) if payload[6:8] == "04" else None, }
Last edited by zxdavb; 7 February 2020, 11:22 AM.
Comment
-
-
I have successfully managed to get an Raspberry Pi,Arduino Nano and CC1101 to drive the evohome python listener. Took some tweaks and it seems to hang whenever I get a "manchester encoding error" which is about once a day.
I am interested in porting the arduino firmware to ESP32, (with the intent of getting rid of the arduino and then the raspberry pi). Is anyone else looking at this?
Comment
-
-
Originally posted by dcreager View PostI have successfully managed to get an Raspberry Pi,Arduino Nano and CC1101 to drive the evohome python listener. Took some tweaks and it seems to hang whenever I get a "manchester encoding error" which is about once a day.
I am interested in porting the arduino firmware to ESP32, (with the intent of getting rid of the arduino and then the raspberry pi). Is anyone else looking at this?
Comment
-
-
Originally posted by dcreager View PostI have successfully managed to get an Raspberry Pi,Arduino Nano and CC1101 to drive the evohome python listener. Took some tweaks and it seems to hang whenever I get a "manchester encoding error" which is about once a day.
I am interested in porting the arduino firmware to ESP32, (with the intent of getting rid of the arduino and then the raspberry pi). Is anyone else looking at this?
There's potentially a much easier way to get the data from the radio
Comment
-
-
-
Comment