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

zxdavb · February 28, 2021, 11:11am

I wrote that wiki.

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

zxdavb · February 28, 2021, 3:15pm

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.

zxdavb · February 28, 2021, 5:40pm

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

skundrik · February 28, 2021, 5:49pm

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

zxdavb · February 28, 2021, 6:48pm

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.

skundrik · February 28, 2021, 7:07pm

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.

skundrik · February 28, 2021, 8:14pm

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.

phdelodder · February 28, 2021, 8:27pm

Is there a new evohome_cc release you need to push?

zxdavb · February 28, 2021, 8:59pm

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.

zxdavb · February 28, 2021, 9:07pm

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

skundrik · February 28, 2021, 9:08pm

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

zxdavb · February 28, 2021, 9:12pm

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?

skundrik · February 28, 2021, 9:14pm

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

zxdavb · February 28, 2021, 9:21pm

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

skundrik · February 28, 2021, 9:31pm

Interesting I wonder what their FW version is. Mine says

HCM200d P4 V7.10  UK
14.Sep.2007 12:00
433 V 13    868 V A1
Device No. 01-020766

I put in a quick hack to replace

github.com

zxdavb/evohome_rf/blob/f896871d0d8e612f798db87dd8c305f282d89abf/evohome_rf/zones.py#L799


    """Revert to following the schedule."""
    self.set_override()

def frost_protect(self) -> None:  # 2349
    """Set the zone to the lowest possible setpoint, indefinitely."""
    self.set_override(mode="permanent_override", setpoint=5)  # TODO

def set_override(self, mode=None, setpoint=None, until=None) -> None:
    """Override the setpoint for a specified duration, or indefinitely."""

    cmd = Command.set_zone_mode(self._ctl.id, self.idx, mode, setpoint, until)
    self._gwy.send_cmd(cmd)

@property  # id, type
def schema(self) -> dict:
    """Return the zone's schema."""

    return {
        ATTR_ZONE_TYPE: self.heating_type,
        ATTR_ZONE_SENSOR: self._sensor.id if self._sensor else None,
        ATTR_DEVICES: [d.id for d in self.devices],

with

       cmd = Command.set_zone_setpoint(self._ctl.id, self.idx, setpoint)

and I can change the zone setpoint.

zxdavb · February 28, 2021, 10:04pm

I wonder if it’s because advanced_override is not being supported, rather than W/2349 not being supported?

    @setpoint.setter
    def setpoint(self, value) -> None:
        """Set the target temperature, until the next scheduled setpoint."""
        if value is None:
            self.reset_mode()
        else:
            self.set_override(mode="advanced_override", setpoint=value)

I could change the above to:

    @setpoint.setter
    def setpoint(self, value) -> None:
        """Set the target temperature, until the next scheduled setpoint."""
        if value is None:
            self.reset_mode()
        else:
            self._gwy.send_cmd(Command.set_zone_setpoint(self._ctl.id, self.idx, value))

Yeah - try changing it in setpoint(self, value) instead of in set_override().

Just swap:

self.set_override(mode="advanced_override", setpoint=value)

with:

self._gwy.send_cmd(Command.set_zone_setpoint(self._ctl.id, self.idx, value))

skundrik · February 28, 2021, 10:19pm

That’s worked as well

skundrik · February 28, 2021, 11:13pm

@zxdavb, was there any change in how are devices assigned to zones? All my devices are showing up as orphans and climate cards don’t indicate heat demand (used to say “Heating” on it and had the shading). even though I can see massages being received.

This used to work on 0.4.3.

zxdavb · March 2, 2021, 9:09pm

Not really - do you have old/new log fro me to look at?

Anyway, you use Hometronics (right?), and discovery is not supported by that platform, as far as I know - you’ll have to use a full schema, I think…

You’ll see a schema in your HA log after 24h of eavesdropping - what does it look like - PM me - and I’ll have you test the schema functionality…

zxdavb · March 4, 2021, 8:09pm

So, version 0.5.12 of evohome_cc just pushed - lots of fixes, and a significant improvement to DHW - bug reports are welcome.

The recommended version of evofw3 is version v0.6.14 or later.

Before anyone asks - evohome DHW does not have a concept of away mode- this is a feature of the controller, and DHW ‘inherits’ away mode from it.