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

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.

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

1 Like

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

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.

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.

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.

Is there a new evohome_cc release you need to push?

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.

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

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

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?

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

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

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


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

and I can change the zone setpoint.

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))

That’s worked as well

@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.

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…

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.

image

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.

1 Like

I would like thoughts of the operation modes:

  • auto -> follow_schedule (active is True/False as per schedule)
  • off -> permanent_override, and active=False
  • on -> permanent_override, and active=True
  • boost -> temporary_override, active=True, until = 1 hour from now
2 Likes