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.
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.
I would like thoughts of the operation modes:
-
auto ->
follow_schedule
(active
is True/False as per schedule) -
off ->
permanent_override
, andactive
=False -
on ->
permanent_override
, andactive
=True -
boost ->
temporary_override
,active
=True,until
= 1 hour from now
Great! I would also add “eco”. All rooms 3 degrees lower.
Please
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
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.