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

[Spaco]

Hey David, hope you’re enjoying your summer. Had this crop up over the last few days. Running latest HA 2021.8.8, evohome_cc 0.11 with the indalo hw uart stick.

Traceback (most recent call last):
  File "/usr/local/opt/python-3.8.8/lib/python3.8/asyncio/events.py", line 81, in _run
    self._context.run(self._callback, *self._args)
  File "/srv/homeassistant/lib/python3.8/site-packages/serial_asyncio/__init__.py", line 411, in _call_connection_lost
    self._protocol.connection_lost(exc)
  File "/srv/homeassistant/lib/python3.8/site-packages/ramses_rf/transport.py", line 465, in connection_lost
    raise exc
  File "/srv/homeassistant/lib/python3.8/site-packages/serial_asyncio/__init__.py", line 114, in _read_ready
    data = self._serial.read(self._max_read_size)
  File "/srv/homeassistant/lib/python3.8/site-packages/serial/serialposix.py", line 595, in read
    raise SerialException(
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)

Evohome stops any updates. HA restart does not help, only a full reboot. I guess maybe an issue with the stick, unless you can think of something else?

[zxdavb (David Bonnes)]

@Mr_Q

There is a continuous flow of errors (EXPIRED/retries) in my homeassistant.log file. Can you help to investigate the cause?

These are WARNINGS for the developer (me) - they will be removed (or at least less numerous) in the next version.

[zxdavb (David Bonnes)]

@sOckhamSter

Hi @zxdavb - any news on the climate zone unavailable status issue at all? Do you need any more debugging information at all that I could provide? Just as a recap, When I set the preset mode of the controller to Eco or Auto, it works initially, but after a delay (15 minutes at least, but not much longer) all zones drop out as unavailable, except the controller status itself. If I set the controller to Off, all zones set themselves to Off and remain available. So it appears to only happen if it’s not off. I use an HGI80. I think you said previously that you had tweaked the timeouts which had caused it?

I am releasing a new version soon - it has many changes - I will look at this after that (but you’ll need to prompt me).

[zxdavb (David Bonnes)]

@Spaco

Evohome stops any updates. HA restart does not help, only a full reboot. I guess maybe an issue with the stick, unless you can think of something else?

This is a hardware error - nothing I can do, unless it is reproducable.

[sOckhamSter]

Thanks, I will remember

[stevieb12345]

I’m going to try out the fake sensor in one room for now, every room I have an HR92 in I have an Aqara temp and humidity sensor optimally placed. Adding the fake sensor isn’t a problem but how do I then make use of it? Does anyone have any clear instructions on this?

Thanks.

[zxdavb (David Bonnes)]

I am about to release a new version - it has been significantly refactored, and there are breaking changes with this feature…

If you haven’t set up sensor faking as yet, I would wait another few days before implementing it.

[stevieb12345]

Ok, I’ll wait till the new release.

[zxdavb (David Bonnes)]

There be dragons here (and faking)

zxdavb released this 1 minute ago

There are very many breaking changes starting from this release (0.14.1, using library 0.14.0), which is also likely to introduce some bugs. I would appreciate testing & feedback, so that I can bugfix and get out a more stable release - now is the time to do it, before the cold weather returns.

For now, report bugs in this forum.

Faking should be much more stable. Support exists here for thermostat faking, and other devices can/will be added simply enough (weather sensors, relays).

Currently, there is no support for faking with a HGI80 (this will come after the current release is stabilised).

Note: the allow_list is now called the known_list.

There is a new entity that display the recommended (minimal) and current schema, and the current device lists, known_list & block_list, as well as any other devices see, but ignored due to filtering, other_list.

Please configure the known_list with all your devices, and set it as a whitelist (enforce_known_list) - your life will be much better if this is done correctly.

Faking has changed, as well as whitelisting device IDs:

evohome_cc:
  # restore_state: false
  # send_packet: true
  serial_port:
    port_name: /dev/ttyUSB0
  config:
    # disable_discovery: true
    # enable_eavesdrop: true
    enforce_known_list: false
    max_zones: 8
  packet_log: /home/dbonnes/home-assistant/.config/packet.log
  schema:
    controller: 01:054173
  known_list:
    - '03:123402': {faked: true}
    - '03:123409': {faked: true}

Logging has changed:

logger:
  default: warn  # prefer warn over info, avoid debug
  logs:
    # homeassistant.core: debug  # to see: Event state_changed, or not
    # homeassistant.loader: info  # You are using a custom integration for evohome_cc...
    # homeassistant.setup: info  # Setting up evohome_cc

    # custom_components.evohome_cc: info  # use info for Schema =

    # ramses_rf: debug  # for engine state
    ramses_rf.message: info   # for MSGs received (incl. sent & subsequently echo'd)
    # ramses_rf.protocol: warn
    # ramses_rf.protocol.protocol: info  # for PKTs sent (excl. retries) & received
    # ramses_rf.protocol.transport: info   # for RF Tx & Rx

    # ramses_rf.devices: debug
    # ramses_rf.systems: debug
    # ramses_rf.zones: debug

[stevieb12345]

I’m getting these errors.

This error originated from a custom integration.

Logger: homeassistant.setup
Source: custom_components/evohome_cc/__init__.py:191
Integration: RAMSES RF (documentation, issues)
First occurred: 15:38:10 (1 occurrences)
Last logged: 15:38:10

Error during setup of component evohome_cc
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/setup.py", line 255, in _async_setup_component
    result = await task
  File "/config/custom_components/evohome_cc/__init__.py", line 85, in async_setup
    await broker.async_load_client_state()
  File "/config/custom_components/evohome_cc/__init__.py", line 191, in async_load_client_state
    await self.client._set_state(**app_storage["client_state"])
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/__init__.py", line 319, in _set_state
    load_schema(self, **schema)  # keep old known_devs?
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/schema.py", line 321, in load_schema
    [
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/schema.py", line 322, in <listcomp>
    load_system(gwy, schema)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/schema.py", line 349, in load_system
    zone = ctl._evo._get_zone(zone_idx, **attrs)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/systems.py", line 587, in _get_zone
    zone._set_sensor(kwargs["sensor"])
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/zones.py", line 555, in _set_sensor
    raise TypeError(f"{self}: {ATTR_ZONE_SENSOR} can't be: {device}")
TypeError: 01:169176_00 (None): sensor can't be: 04:090189

[zxdavb (David Bonnes)]

I’m pushing a fix in the next few minutes.

[zxdavb (David Bonnes)]

Try 0.14.3.

[stevieb12345]

Thanks very much, that worked.

The only thing I have in the logs is.

Logger: ramses_rf.protocol.transport
Source: /usr/local/lib/python3.9/site-packages/ramses_rf/protocol/transport.py:382
First occurred: 16:27:13 (1 occurrences)
Last logged: 16:27:13

Ignoring a non-allowed device_id: --:------, if required, add it to the known_list

[zxdavb (David Bonnes)]

@stevieb12345

How to fake a zone temperature sensor (evohome_cc Wiki))

[zxdavb (David Bonnes)]

@stevieb12345

Ignoring a non-allowed device_id: --:------, if required, add it to the known_list

That shouldn’t happen, but it wont cause a problem, I feel.

[stevieb12345]

Again thanks for your time, I’ll set up one in a room we don’t use much for now.

In the future would it be possible to display if a room is in warm weather saver or cold weather boost?

Can you fake an outside sensor to overcome the slow internet one which is used for cold/warm weather boost?

I already have weather compensation fitted to my boiler to control the boiler set point.

[zxdavb (David Bonnes)]

@stevieb12345

In the future would it be possible to display if a room is in warm weather saver or cold weather boost?

No - there appears no ways to get the controller to provide such information (and I am unaware of any means to craft such a RAMSES packet).

@stevieb12345

Can you fake an outside sensor to overcome the slow internet one which is used for cold/warm weather boost?

TL;DR: No - this applies only to the older evohome controllers that support this feature. Newer controllers use the internet for this data instead.

@stevieb12345

I already have weather compensation fitted to my boiler to control the boiler set point.

I am cautious of the utility of doing this, and having compensation in evohome, except this feature often modulates, where evohome would be restricted to TPI if you’re not using a BDR91 relay (rather than an OpenTherm bridge).

[zxdavb (David Bonnes)]

@stevieb12345 It woudl be useful to know

• if the instruction of teh wiki were sufficient, or needed tweaking (feel free to tweak)
• how you get on with it

[phdelodder (Philippe Delodder)]

Update to v0.14.3, after running for 4h45min(started at 22h35) the state of the controller has become unavailable.

ramses logs

[zxdavb (David Bonnes)]

I really will need a HA log over the time the controller became unavailable.

• where the other entities still available
• what did/can you do to make the controller available again?