Honeywell CH/DHW via RF - evohome, sundial, hometronics, chronotherm

Share your Projects!
790

Likely. Simple trick is to do what you want via the normal means, whilst capturing a packet log - the answer will be in there.

Unfortunately, discovery is limited for Hometronics - you’ll have to rely upon eavesdropping.

791

For those running Hometronics, could you tell me what you get from:

python client.py execute /dev/ttyUSB0 -x "RQ 01:xxxxxx 2E04 00" -o packet.log

and

python client.py execute /dev/ttyUSB0 -x "RQ 01:xxxxxx 2E04 FF" -o packet.log

where 01:xxxxxx is your controller ID.

792

Here you go

2021-02-28T00:25:41.694444 # evofw3 0.6.8
2021-02-28T00:25:41.751409 000  I --- 18:138267 63:262142 --:------ 7FFF 027 00002E150334807F65766F686F6D655F72662076302E352E3130F7
2021-02-28T00:25:41.810385 000  I --- 18:138267 63:262142 --:------ 7FFF 027 00002E150334807F65766F686F6D655F72662076302E352E31307F
2021-02-28T00:25:41.816333 000 RQ --- 18:138267 01:020766 --:------ 2E04 001 FF
2021-02-28T00:25:41.849312 053 RP --- 01:020766 18:138267 --:------ 2E04 016 FFFFFFFFFFFFFF0000FFFFFFFFFFFF04
2021-02-28T00:25:41.849312 053 RP --- 01:020766 18:138267 --:------ 2E04 016 FFFFFFFFFFFFFF0000FFFFFFFFFFFF04
2021-02-28T00:25:43.589534 066  I --- 00:000606 --:------ 00:000606 30C9 003 00074B
2021-02-28T00:25:44.091534 037  I --- 04:024117 --:------ 04:024117 30C9 003 0007FC
2021-02-28T00:25:45.090215 074  I --- 04:017575 --:------ 04:017575 30C9 003 0007F5
2021-02-28T00:25:48.589939 056  I --- 00:000474 --:------ 01:020766 2309 003 0303E8
2021-02-28T00:25:48.601904 076  I --- 04:017575 --:------ 04:017575 1060 003 00FF01
2021-02-28T00:25:49.089463 074  I --- 00:000558 --:------ 00:000558 30C9 003 000713
2021-02-28T00:25:57.585510
2021-02-28T00:25:57.948462 # evofw3 0.6.8
2021-02-28T00:25:58.019685 000 RQ --- 18:138267 01:020766 --:------ 2E04 001 00
2021-02-28T00:25:58.019685 000 RQ --- 18:138267 01:020766 --:------ 2E04 001 00
2021-02-28T00:25:58.063371 053 RP --- 01:020766 18:138267 --:------ 2E04 016 FFFFFFFFFFFFFF0000FFFFFFFFFFFF04
2021-02-28T00:25:58.063371 053 RP --- 01:020766 18:138267 --:------ 2E04 016 FFFFFFFFFFFFFF0000FFFFFFFFFFFF04
2021-02-28T00:26:00.092549 079  I --- 00:000806 --:------ 01:020766 1060 003 0AFF01
2021-02-28T00:26:00.104430 081  I --- 00:000806 --:------ 00:000806 1060 003 00FF01
2021-02-28T00:26:01.088521 056  I --- 00:000474 --:------ 00:000474 30C9 003 0006C3
793

@zxdavb David, is there a way to send a command like this using the client?

  W --- 04:024117 --:------ 01:020766 0001 005 0900000505
794

Yep… and we enter the world of impersonation.

NOTE: I am afraid you cannot do this with a HGI80.

I will release a new version of evohome_rf that can do this:

python client.py execute /dev/ttyUSB0 -x "W 04:024117 01:020766 0001 0900000505"

… or, in your specific case:

... -x "W 04:024117 --:------ 01:020766 0001 0900000505"

I am curious, why do you want to execute that particular command?

795

Excellent question. I noticed that when I did a TRV cold restart it sent this message (0001 should be RF test according to wiki) so it gave me an idea to try and see if I can use this to test the RF link from my nanoCUL to the Hometronic. Hometronic has a service mode screen like this
image

I tried it with the current client which uses GW adress as a source but it didn’t seem to register and target seem to be in the second addr. field rater than third. So I want to try the exact message and see what happens. It might be a nice tool for diagnostics showing signal strength for those who seem to have issues with their nanoCULs.

796

I wrote that wiki.:slight_smile:

evohome_rf already does a such a test - there was a bug, though, and under certain circumstances these packets were getting dropped - I have fixed it now, and it will be in 0.5.11. It is now called rf_check:

(venv) dbonnes@vm-builder ~/c/evohome (bleeding_edge)> python client.py monitor /dev/ttyUSB0 -x "RQ 01:145038 1F09 00"

client.py: Starting evohome_rf...
11:08:16.203 Not Using an device filter (an allow_list is recommended)
11:08:16.205 # evohome_rf 0.5.11
11:08:16.257 PktProtocolQos.send_data( I|63:262142|7FFF|01): boff=0, want= I|63:262142|7FFF|01, tout=2021-02-28 11:08:16.307808: RE-SENT (1/24)
11:08:16.310 PktProtocolQos.send_data( I|63:262142|7FFF|01): boff=0, want= I|63:262142|7FFF|01, tout=2021-02-28 11:08:16.360012: RE-SENT (2/24)
11:08:16.362 PktProtocolQos.send_data( I|63:262142|7FFF|01): boff=0, want= I|63:262142|7FFF|01, tout=2021-02-28 11:08:16.412377: RE-SENT (3/24)
11:08:16.416 PktProtocolQos.send_data( I|63:262142|7FFF|01): boff=0, want= I|63:262142|7FFF|01, tout=2021-02-28 11:08:16.466416: RE-SENT (4/24)
11:08:16.470 PktProtocolQos.send_data( I|63:262142|7FFF|01): boff=0, want= I|63:262142|7FFF|01, tout=2021-02-28 11:08:16.520287: RE-SENT (5/24)
11:08:16.481 # evofw3 0.6.7
11:08:16.524 PktProtocolQos.send_data( I|63:262142|7FFF|01): boff=0, want= I|63:262142|7FFF|01, tout=2021-02-28 11:08:16.574478: RE-SENT (6/24)
11:08:16.555 || HGI:140805 | NUL:262142 |  I | puzzle_packet    | 01763... || {'evohome_rf': 'v0.5.11'}
11:08:16.582 || HGI:140805 | CTL:145038 | RQ | system_sync      | 00       || {}
11:08:16.595 || CTL:145038 | HGI:140805 | RP | system_sync      | 0006EF   || {'remaining_seconds': 177.5, '_next_sync': '11:11:14'}
11:08:16.624 || HGI:140805 | CTL:145038 | RQ | rf_check         | 00       || {'zone_idx': '00'}
11:08:16.635 || CTL:145038 | HGI:140805 | RP | rf_check         | 0021     || {'zone_idx': '00', 'rf_strength': 5, 'rf_value': 33}
11:08:16.664 || HGI:140805 | CTL:145038 | RQ | device_info      | 00       || {}
11:08:16.701 || CTL:145038 | HGI:140805 | RP | device_info      | 00000... || {'description': 'Evo Color', 'date_1': '2013-08-01', 'date_2': '2020-08-11', '_unknown': '000002FF0163FFFFFFFF'}

You can see:

  • first the puzzle packet, which is re-transmitted until the gateway wakes up (the bug affected this, 2 re-tramsits instead of 24)
  • then the -x command RQ/1F09 (sync_cycle) and corresponding RP
  • then the first packet when ‘discovering’ a controller, RQ/0016 (rf_check) and teh correpsnding RP
797

All,

If you are using a nanoCUL instead of a HGI80, you must now upgrade evofw3 to v0.6.13 v0.6.14.

  • you must also use the associated board definition file in the Arduino tool, currently v1.06 (older versions will cause issues)
  • see: the ghoti57/evofw3 Wiki on github

The next version of evohome_rf will utilize features from this specific firmware to improve reliability by - inter alia - reducing the baud rate.

If you are board (see what I did there?), you can do it now, because a new version of evohome_cc will be released later today.

798

Sorry - things are delayed - I’ve decided to give DHW some attention.

1 Like
799

In the meantime can I update to the new evofw3 and which host speed to use?

800

You can upgrade now - you can try this in your configuration.yaml (IIRC, it is in 5.9 / 5.10):

evohome_cc:
  serial_port: /dev/ttyUSB0
  serial_config:
    baudrate: 57600  #  default: 115200

Note: only 57600, 115200 are supported, and you must have the coprresponding build of evofw3 on your nanoCUL.

801

That worked perfectly.

I also confirmed that signal strength from my nanoCUL is 5/5 on the Hometronic unit itself when I sent
W 04:024117 --:------ 01:020766 0001 0900000505

Unfortunately it looks like Hometronic is ignoring 2349 messages to alter the setpoint like this
W --- 18:138267 01:020766 --:------ 2349 007 0905AA01FFFFFF
I also tried
W --- 18:138267 01:020766 --:------ 2349 004 0905AA01
but no luck.

802

Hallelujah!

I have finally found how to change the setpoint on Hometronic. To change it you have to send W\2309 and this is what you get

20:06:22.597 -> 000  W --- 18:138267 01:020766 --:------ 2309 003 09055D
20:06:22.645 -> 051  I --- 01:020766 18:138267 --:------ 2309 003 09055D

I wonder if this works on Evohome as well.

Wanted to contribute it to wiki but not sure how.

803

Is there a new evohome_cc release you need to push?

804

If you look in command.py, you’ll see:

    @classmethod  # constructor for 2309
    def set_zone_setpoint(cls, ctl_id, zone_idx, setpoint: float, **kwargs):
        """Constructor to set the setpoint of a zone (c.f. parser_2309)."""
        #  W --- 34:092243 01:145038 --:------ 2309 003 0107D0

        payload = f"{zone_idx:02X}" if isinstance(zone_idx, int) else zone_idx
        payload += temp_to_hex(setpoint)

        return cls(" W", ctl_id, "2309", payload, **kwargs)

There are a whole bunch of these constructors - have a look.

805

The wiki is way out of date, the definitive source of data is in these parsers, and these constructors.

806

So if this is already there why is changing a setpoint on the climate card producing W/2349 instead of W/2309

807

2349 is a superset of 2309

def set_zone_mode(cls, ctl_id, zone_idx, mode=None, setpoint=None, until=None, **kwargs):

vs

def set_zone_setpoint(cls, ctl_id, zone_idx, setpoint: float, **kwargs):

Are you saying the 2349 doesn’t work on Hometronics, where a 2309 does?

808

Yes, 2349 is getting ignored but 2309 changes the setpoint immediately.

809

Well, that’s good information to know, but I have seen another Hometronic system do this:

2021-02-26T10:02:13.426140 045 RP --- 01:095966 18:013457 --:------ 2349 007 06070800FFFFFF
2021-02-26T10:03:23.487968 045 RP --- 01:095966 30:027402 --:------ 2349 007 00070800FFFFFF