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

TheMystery · June 21, 2021, 8:02pm

Toggled the healing to on and off now i have a State, i Will monitor it if it stays this way otherwise i can try the logging maybe tomorrow.

llevering · June 21, 2021, 8:51pm

@zxdavb I can confirm the create_sensor call is fixed as well! Great work!

zxdavb · June 21, 2021, 9:04pm

Beware using this - I should really have taken it out until it is ready for use.

TheMystery · June 22, 2021, 6:40am

This morning i had still a status, so looking good.
I did turn on the heating but than i had no status but i think this comes because the zones need no heat so the are not sending the status so this plugin can’t pick it up?

iMiMx · June 22, 2021, 7:07am

0.10.2 seems to fix my issues, many thanks:

evohome_cc.set_zone_mode works as expected
Boost on Hot Water works (didn’t for me in 0.9)
UI updates immediately after making a change
Climate entities can be updated/nudged and the respective change makes it to the evohome controller

… Can’t comment on state expiring, only just updated, but should be able to later today.

Perhaps one issue, I think the UI used to say ‘heating’ when it was actively heating? It doesn’t seem to, so far, (might be the issue referenced above by @TheMystery)

EDIT: Oh, it does, pulled the trigger too early…

sOckhamSter · June 22, 2021, 7:11am

I’ll update later, but so far things have remained available. I stopped HA, deleted the evohome_cc file and my packet logs, then restarted HA and after that it’s been stable for several hours. I had tried that process with 0.9.15 too but it made no difference. I’ll monitor for another day or so (or until it fails) and update you then.

iMiMx · June 22, 2021, 7:14am

Sometimes I find you need to set:

restore_state: false

Restart, then hash it out and save so it restores state the next time. Has resolved a few random issues between upgrades for me before.

zxdavb · June 22, 2021, 7:29am

To put this into context :

restore_state is false by default,
if restore_state is true, during startup it will load the contents of the .storage/evohome_cc file if one is available,
regardless of the above, it will always overwrite the evohome_cc file with an up-to-date state every sync interval

phdelodder · June 22, 2021, 8:08am

I’ll PM you a log for the unavailable states. using version 0.10.2

Cinamon · June 22, 2021, 8:37am

I have the next error:

Logger: ramses_rf.message
Source: /usr/local/lib/python3.8/site-packages/ramses_rf/message.py:714
First occurred: 10:35:03 (3 occurrences)
Last logged: 10:36:04

061 I --- --:------ --:------ 10:078099 1FD4 003 00F077 < AssertionError
058 I --- --:------ --:------ 10:078099 1FD4 003 00F078 < AssertionError
058 I --- --:------ --:------ 10:078099 1FD4 003 00F079 < AssertionError
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/ramses_rf/message.py", line 706, in process_msg
    create_devices(msg)  # from pkt header & from msg payload (e.g. 000C)
  File "/usr/local/lib/python3.8/site-packages/ramses_rf/message.py", line 545, in create_devices
    [this._gwy._get_device(d) for d in (this.src, this.dst)]
  File "/usr/local/lib/python3.8/site-packages/ramses_rf/message.py", line 545, in <listcomp>
    [this._gwy._get_device(d) for d in (this.src, this.dst)]
  File "/usr/local/lib/python3.8/site-packages/ramses_rf/__init__.py", line 186, in _get_device
    assert dev_addr.type != "--", "invalid device type"
AssertionError: invalid device type

When i don’t add 10:078099 in the allowlist i get the message that he is in the scheme but not in the allow list

zxdavb · June 22, 2021, 12:45pm

Don’t report this as an issue - it is a very simple fix, I will just remove:

assert dev_addr.type != "--", "invalid device type"

I doubt if it will cause you any issues (please let me know if I am wrong).

TheMystery · June 22, 2021, 2:14pm

I noticed that i have 5 orphaned devices at the end of the evohome_cc file.
These 5 devices are in my allow list and are hr92 devices.
1 device from my office that has a fake sensor and 4 in my main zone (living room) where the evohome controller is.

i have already set the parameter restore_state: false to rebuild the evohome_cc file.
this gave a problem with my fake sensor because in the evohome_cc file this was missing in the zone: “is_faked”: true, after manualy adding it back i could sent a temp update.
the orphans came back after a while.

zxdavb · June 22, 2021, 2:35pm

@TheMystery Please send me a packet log

from startup, with
restore_state: false

… and we’ll see what’s going on.

TheMystery · June 22, 2021, 3:10pm

Send you a pm with the packet.log

zxdavb · June 22, 2021, 3:24pm

@TheMystery could you rebind one of the orphans and generate a new schema pls?

At the moment, it looks like your system is simply misconfigured.

TheMystery · June 22, 2021, 3:40pm

But why is the schema good after a fresh reboot? Only after adding the fake is true for the fake sensor and reboot the it Goes wrong.

zxdavb · June 22, 2021, 3:52pm

Send us your evohome_cc section of your configuration.yaml file. Do you have eavesdropping turned on?

TheMystery · June 22, 2021, 4:03pm


evohome_cc:
  scan_interval: 300
  serial_port: /dev/ttyUSB1
  packet_log: /home/homeassistant/packet.log
  advanced_override: true
#  restore_state: false
  config:
    max_zones: 6
  schema:
    controller: 01:155341
  allow_list:
    - 01:155341
    - 04:008512
    - 04:070150
    - 04:070154
    - 04:070160
    - 04:073460
    - 04:108167
    - 04:108169
    - 04:108171
    - 04:108173
    - 13:189740
    - 03:256005

zxdavb · June 22, 2021, 8:17pm

@TheMystery Ah, my mistake. I couldn’t have a good look before (was at work), but have done now…

First: having to manually add is_faked is expected behaviour if you delete the evohome_cc file, or don’t load it - the controller simply does not / cannot know it’s faked - this solution is not elegant, but I’ll address that in time.

From what you sent me, this is the packet that exposes the TRVs:

2021-06-22T16:54:14.708696 048 RP --- 01:155341 18:203293 --:------ 000C 024 00000011121000000011A68900000011A68D00000011A68B

It translates into:

16:54:14.708 || CTL:155341 | HGI:203293 | RP | zone_devices     | 00000... || {'zone_idx': '00', 'device_class': 'zone_actuators', 'devices': ['04:070160', '04:108169', '04:108173', '04:108171']}

… or:

    "zones": {
        "00": {
            "heating_type": "radiator_valve",
            "sensor": null,
            "devices": [
                "04:070160",
                "04:108169",
                "04:108173",
                "04:108171"
            ]
        }

So we know the controller has this information (i.e. there is no need to re-bind), and that it will provide the answer when asked.

Why it didn’t do it under the circumstances you describe is not clear to me, but - if pushed - I’d say it was simply a dropped packet?

However, if the behaviour is reproducible, then I’d love to know why…

There is no way to tell unless you provide me with a log file that is taken when this behaviour occurs. The best logging config may be:

logger:
  default: warn
  logs:
    homeassistant.core: debug
    custom_components.evohome_cc: warn
    ramses_rf.transport: info

zxdavb · June 22, 2021, 8:24pm

Can people report any other bugs - all I have so far is from:

@cinnamon: AssertionError: invalid device type
@TheMystery: AttributeError: 'NoneType' object has no attribute 'encode'

These have both been fixed and will be ‘released’ soon.

Before I push another release - are there any more?