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

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

Great! I would also add “eco”. All rooms 3 degrees lower.

Please :wink:

Eco will come - the above only applies to DHW. The only evohome mode that applies to DHW is Away.

Loving the update. Getting this error appearing in the logs…

062 RQ --- 01:210309 10:022270 --:------ 3EF0 001 00 < AttributeError
Unhandled error in exception handler context: {'message': 'Exception in callback SerialTransport._read_ready()', 'exception': AttributeError("'OtbGateway' object has no attribute 'ctl'"), 'handle': <Handle SerialTransport._read_ready()>}

alongside a large number of these (78 within a minute, 4500 over a few days) still appearing:

* PktProtocolQos.send_data(RQ|13:045348|0008|00): boff=2, want=RQ|13:045348|0008|00, tout=2021-03-04 21:25:44.176116: RE-SENT (2/2)
* PktProtocolQos.send_data(RQ|13:045348|0008|00): boff=2, want=RP|13:045348|0008|00, tout=2021-03-04 21:25:44.802077: EXPIRED
* PktProtocolQos.send_data(RQ|13:045348|3EF1|00): boff=1, want=RQ|13:045348|3EF1|00, tout=2021-03-04 21:25:45.133262: RE-SENT (1/2)
* PktProtocolQos.send_data(RQ|13:045348|3EF1|00): boff=2, want=RQ|13:045348|3EF1|00, tout=2021-03-04 21:25:45.662204: RE-SENT (2/2)
* PktProtocolQos.send_data(RQ|13:045348|3EF1|00): boff=2, want=RP|13:045348|3EF1|00, tout=2021-03-04 21:25:46.287811: EXPIRED

Thanks for this - a genuine bug - I don’t yet have a OpenTherm Gateway to dev/text against - anyone who wants to donate one, please do.

I believe I have fixed this bug - will be pushed out presently.

2021-03-04 21:48:46 WARNING (MainThread) [evohome_rf.transport] PktProtocolQos.send_data(RQ|01:145038|0004|01): boff=1, want=RQ|01:145038|0004|01, tout=2021-03-04 21:48:46.384493: RE-SENT (1/2)

The are not ERRORs, they are WARNINGs. They can be disabled in configuration.yaml

logger:
  logs:
    evohome_rf.transport: error

In future, I will make the INFOs and they will not show up by default.

I have an opentherm gateway, how do i use it with your custom component

Trying the new version on my test setup (nanocul) and got the following stack trace:

2021-03-05 07:18:31 ERROR (MainThread) [asyncio] Unhandled error in exception handler
context: {'message': 'Exception in callback SerialTransport._read_ready()', 'exception': AttributeError("'OtbGateway' object has no attribute 'ctl'"), 'handle': <Handle SerialTransport._read_ready()>}
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/asyncio/base_events.py", line 1744, in call_exception_handler
    self._exception_handler(self, context)
  File "/usr/local/lib/python3.8/site-packages/evohome_rf/__init__.py", line 129, in handle_exception
    raise exc
  File "/usr/local/lib/python3.8/asyncio/events.py", line 81, in _run
    self._context.run(self._callback, *self._args)
  File "/usr/local/lib/python3.8/site-packages/serial_asyncio/__init__.py", line 119, in _read_ready
    self._protocol.data_received(data)
  File "/usr/local/lib/python3.8/site-packages/evohome_rf/transport.py", line 409, in data_received
    self._data_received(*create_pkt(line))
  File "/usr/local/lib/python3.8/site-packages/evohome_rf/transport.py", line 664, in _data_received
    self._callback(pkt)  # only wanted PKTs up to the MSG transport's handler
  File "/usr/local/lib/python3.8/site-packages/evohome_rf/protocol.py", line 171, in _pkt_receiver
    [p.data_received(msg) for p in self._protocols]
  File "/usr/local/lib/python3.8/site-packages/evohome_rf/protocol.py", line 171, in <listcomp>
    [p.data_received(msg) for p in self._protocols]
  File "/usr/local/lib/python3.8/site-packages/evohome_rf/protocol.py", line 402, in data_received
    self._callback(msg)
  File "/usr/local/lib/python3.8/site-packages/evohome_rf/message.py", line 575, in process_msg
    create_devices(msg)  # from pkt header & from msg payload (e.g. 000C)
  File "/usr/local/lib/python3.8/site-packages/evohome_rf/message.py", line 391, in create_devices
    this._gwy._get_device(this.dst, ctl_addr=this.src)
  File "/usr/local/lib/python3.8/site-packages/evohome_rf/__init__.py", line 230, in _get_device
    device = create_device(dev_addr, ctl=ctl, domain_id=domain_id)
  File "/usr/local/lib/python3.8/site-packages/evohome_rf/__init__.py", line 211, in create_device
    device._discover()  # discover_flag=DISCOVER_ALL)
  File "/usr/local/lib/python3.8/site-packages/evohome_rf/devices.py", line 745, in _discover
    self._send_cmd(Command.get_opentherm_msg(self.ctl.id, msg_id))
AttributeError: 'OtbGateway' object has no attribute 'ctl'

The odd thing is, I’ve upgrade to the latest version but everything stays on unavailable, if all goes well with previous version everything was detected within 5 minutes. After 30 minutes it stull unavailable.

Am using your latest service_calls branch, with the dhw enhancements, with a nanoCUL - actually seems a bit snappier for me in general detection.

However, I didn’t have much luck with the latest evofw3 (0.6.14) firmware, with or without the baud changes, I’m still running the calibrate branch - and I have to tune the frequency ‘in place’ at my HA box.

Loving this - changing the Target temperature changes it in the settings on the controller, wonderful!

Although it does mean my other-half is likely going to have it on has high as it can go (bl%$dy Australian)… but then I can script it to change it back again :wink:

This bug: AttributeError: 'OtbGateway' object has no attribute 'ctl', has been addressed - I am waiting for any more fixes before I push a news version.

Without a HA log/packet log pair, I cannot help you further.