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

zxdavb · December 31, 2021, 5:02pm

Please send me a packet log of your HA starting up with restore_state: false I still am trying to understand what is going on here…

NB: you should definitely re-bind the TRVs to make sure, as the much more common scenario is that they were simply not bound properly.

Don’t ever edit this file. I can see what you’re trying to achieve, and this is not the way to do it (see below):

You have not expressly identified what you’re trying to achieve, but I think you want to manually add the TRVs as actuators to their respective zones.

The only reason why one would want to do this (other than having a ‘correct’ schema) is to ensure the zones have a heat demand - this is a ‘good’ reason.

To understand the above, you should know that a zone’s heat demand is not available directly (there is no packet to eavesdrop, nor will you get an RP from the controller for any such RQ), but is calculated using the heat demands from the zone’s actuators (when the zone is a Radiator zone).

The proper (supported) way you do this is by adding them to the schema in configuration.yaml, for example:

schema:
  controller: 01:059885
  zones:
    00:
      devices:
        - 04:126354
        - 04:126355
        - 04:126354

… or, this should work too:

      devices: [04:126354, 04:126355, 04:126356]

You are not exactly right - most ‘sniffing’ (I call it eavesdropping) is disabled by default. However, probing (I call it discovery) is enabled by default. If the discovery fails, you can use eavesdropping to learn what you need to know (but beware what I said about about re-binding), and you can get that data from the 01:xxxxxx (schema) attributes.

After you have this data, be sure to turn eavesdropping off. Then hard-craft a system schema as above.

Just be sure to use the ‘thinnest’ schema you can get away with, and leave the rest up to discovery, and do that only after you have checked by re-binding your TRVs.

Note: You must (also) do the above ‘trick’ for the OpenTherm Bridge, as discovery wont work for it:

  schema:
    controller: 01:145038
    system:
      heating_control: 10:048122

This is a limitation of the protocol, there is nothing I can do about it.

(perhaps someone could add the above to the wiki?)

zxdavb · December 31, 2021, 5:37pm

Hmmm… I had thought it was the TRVs, not the zone…

Certainly, you cannot discover the sensor for a zone, if it is the controller (you can via eavesdropping) - there is no need to do this, however (unlike for zone heat demand).

Just create a new zone (assume you have enough unused zones), add the TRVs to it, and then delete the old zone 0 (NB: make sure to copy across any schedule first).

You wont have a zone 0 any more - this is fine.

MDIGIT1971:

  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/parsers.py", line 399, in _parser
    assert seqx[4:6] == "7F" or int(seqx[4:6], 16) < msg._gwy.config.max_zones
AssertionError

I think I know what is going on here… This is the cause of your invalid schema… Hang on…

zxdavb · December 31, 2021, 5:47pm

This feature is simply not working at the moment.

Yes - a known bug - I had a look & I cannot see why it is broken - it appears not to work with daily log files, but works OK if you use a size limit for the rotation policy.

zxdavb · January 1, 2022, 3:50pm

All, there is a new ‘beta’ release - 0.17.2 - testers please.

You can see it by:

go to HACS, then select integrations
use RAMSES_RFs three-dots menu, select Update information, then Redownload
enable Show beta versions, and select 0.17.2 and then DOWNLOAD (then restart HA)

One nice feature is that heat demand for each zone should now match that in the evohome controller’s UI.

There are bugfixes (@MDIGIT1971 & @iMiMx): some zones not picking up the TRVs

There are a lot of new sensors for OTB relays - a lot.

There is a new feature, where you can listen for particular packets in automations.

Version 0.17.1 is considered ‘stable’, although it has a few known bugs.

BuSab · January 1, 2022, 4:27pm

@zxdavb I have some further info on the bad 0008 001 08 packets I see for zone_valve zones:

 RQ --- 18:204306 01:225826 --:------ 0008 001 08 < Corrupt packet: Invalid verb/code for 01:225826 to Rx: RQ/0008

I started seeing these again after a HA restart. After some experimentation it seems:

The messages appear every 15 mins if HA is restarted with restore_state: true
The messages don’t appear after restarting with restore_state: false, except for three times immediately after starting (and then never again)

zxdavb · January 1, 2022, 4:29pm

@iMiMx @ademobile @rbrommer @MDIGIT1971 You all may have been affected by the 000C bug, and had to add TRVs manually via your hand-crafted schema

you can try 0.17.2 to see if that makes a difference (you can look to see if they appear as actuators in the 01:xxxxxx (config) binary sensor

BuSab · January 1, 2022, 4:37pm

zxdavb:

The proper (supported) way you do this is by adding them to the schema in configuration.yaml, for example:
schema:
  controller: 01:059885
  zones:
    00:
      devices:
        - 04:126354
        - 04:126355
        - 04:126354

Useful post. Can I ask, when devices are added to configuration.yaml like this, does the list need to be a complete device list for that zone? In other words, does it turn off device discovery for that zone completely, or will discovery still happen and supplement this manual list?

zxdavb:

Note: You must (also) do the above ‘trick’ for the OpenTherm Bridge, as discovery wont work for it:
  schema:
    controller: 01:145038
    system:
      heating_control: 10:048122

Is it necessary/advisable to add heating_control to configuration.yaml for a BDR91 boiler control relay?

For me discovery has always resulted in heating_control: null in my schema, but if I turn on eavesdropping I’ve found it gets populated with my boiler relay BDR91. Are there any benefits to adding something like heating_control: 13:032648 to my configuration.yaml?

zxdavb · January 1, 2022, 4:55pm

The first thing you need to know is that there are only two possible options, in order of preference:

start with a cached schema (from a previous run of HA - in .storage/evohome_cc), or
start with a hard-crafted schema (in configuration.yaml), which can be null (empty)

Regardless of which of the two, the system will try to fill in any gaps. Like, if the temperature sensor is missing for a zone, it will try to discover (probe for) that piece of information during start up.

If there are no devices (actuators) for a zone, it will also attempt to discover. However, if there are any devices for a zone it will not - even if that list is incomplete.

But eavesdropping could fix up the missing bits - NB: eavesdropping is not recommended for this.

Yes, see above.

No, as there are other things disovered for a zone, besides the list of devices (child actuators)

No, the list of child actuators will be considered ‘complete’, as above.

zxdavb · January 1, 2022, 5:00pm

No, it is not necessary - and - as a hand-crafted schema should be as thin as possible - it may well be undesirable.

For most systems, the BDR will be simply discovered. If it is not: then you need to understand why it was not, before you take this step.

For example, some systems don’t have a heating_control BDR (and that is OK), so why stick one in there?

@BuSab I would like to see a packet log just to check your system…

No, unlike TRVs in a zone, where it is necessary to get the correct zone demand.

stevieb12345 · January 2, 2022, 9:54am

I’ve updated and have no new errors or warnings.

The boiler and heat demand don’t seem to have changed for me, at the minute my controller service menu says
Appliance, Opentherm bridge 20% which is always correct.
Living Room 1 13%
Living Room 2 13%
Kitchen 0%
Bedroom 0%
Harry’s Room 0%
Spare Room 20%

Home Assistant says

Opentherm bridge 20%
Living Room 1 47%
Living Room 2 47%
Kitchen 0%
Bedroom 10%
Harry’s Room 22%
Spare Room 56%

zxdavb · January 2, 2022, 10:36am

Yes, the heat demands have not been transformed. For example,Spare Room 56% transforms to 20%, which is what you’re seeing in the UI.

The question is: why is it not transforming?

I was going to write how it is working in my production system and you need to check your system, etc…

… but it isn’t working there either!

Fix coming. Thanks for reporting.

MDIGIT1971 · January 2, 2022, 4:37pm

Thanks for the comments on my tour. I tried to help the system by adding the TRVs as actuators to the scheme. What you pointed out configuring the scheme in the configuration file was exactly where I was looking for. I picked it up in the other comments but was not exactly sure where to put it.
I did rebind the TRVs and let the software do its magic but the result stayed the same. Wil do some tests with your comments.

zxdavb · January 2, 2022, 4:40pm

Thanks for a copy of your packet log.

You have identified a regression in ramses_rf - I have since identified, and fixed this bug. Thanks for reporting it. The fix will be included in 0.17.3.

MDIGIT1971 · January 2, 2022, 4:41pm

Will pick this up, will keep posted. Thanks for all the work!

MDIGIT1971 · January 2, 2022, 4:45pm

Hmm… Usefull. I also saw when I was reseaching the matter that the Evhome picked up other socalled devices which I was 100% sure of that I did not have. Also one of them I believe was a boiler relay as was mentioned. Which I found extremely strange since a boiler relay was never attached to this heating system…

zxdavb · January 2, 2022, 5:51pm

There is a fix coming, where you should no longer need to add your TRVs to the schema.

Neighbour? Use a device ID filter, preferably a white list.

MDIGIT1971 · January 2, 2022, 6:48pm

Ive just downgraded from 17.2 to 17.1. HA kept on complaining about there was something wrong with the evohome_cc configuration yaml file. Kept on excluding but could not fix it until the downgrade after that the problem was gone… Indeed the known_list AND the enforce_known_list.

Running 17.1 now but man I am struggeling to understand this indention of these YAML files. Below does not seem to be accepted by HA… Just want to try one thing I see now to remove the - in front of below device identifiers…

schema:
    controller: 01:059885
    system:
      heating_control: 10:030670
    zones:
      00:
        devices:
          - 04:126354
          - 04:126368
          - 04:126378
          - 34:177047
      01:
       devices:
          - 03:075455
          - 04:126322
      02:
        devices:
          - 34:176627
          - 04:126376
      03:
        devices:
          - 04:126366
      04:
        devices:
          - 34:155573
          - 04:126382
      05:
        devices:
          - 34:162993
          - 04:126374

MDIGIT1971 · January 2, 2022, 7:34pm

Was working with 17.1

schema:
    controller: 01:059885
    system:
      heating_control: 10:030670

Upgraded to 17.2 and HA warned there was a problem with above config

2022-01-02 20:31:30 ERROR (MainThread) [homeassistant.setup] Error during setup of component evohome_cc
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/setup.py", line 229, in _async_setup_component
    result = await task
  File "/config/custom_components/evohome_cc/__init__.py", line 105, in async_setup
    register_service_functions(hass, broker)
  File "/config/custom_components/evohome_cc/__init__.py", line 190, in register_service_functions
    if not broker.config[ADVANCED_FEATURES].get(SVC_SEND_PACKET):
KeyError: 'advanced_features'
2022-01-02 20:31:30 INFO (MainThread) [ramses_rf.message] || HGI:010642 | NUL:262142 |  I | puzzle_packet    |      || {'datetime': '2022-01-02T20:31:30.429', 'engine': 'v0.17.1', 'parser': 'v0.17.1'}
2022-01-02 20:31:30 DEBUG (MainThread) [ramses_rf.devices] Creating a Device: 18:010642 (<class 'ramses_rf.devices.HgiGateway'>)
2022-01-02 20:31:30 INFO (MainThread) [ramses_rf.message] || HGI:010642 | NUL:262142 |  I | puzzle_packet    |      || {'datetime': '2022-01-02T20:31:30.429', 'engine': 'v0.17.1', 'parser': 'v0.17.1'}
2022-01-02 20:31:31 INFO (MainThread) [custom_components.hacs] Loaded 11 tasks

Will check again tomorrow…

zxdavb · January 2, 2022, 8:14pm

Yes - the issue is that evohome_cc isn’t loading the right version of ramses_rf.

Fix shortly.

zxdavb · January 3, 2022, 9:32am

Try 0.17.3 (a beta) with this (no zones):

  schema:
    controller: 01:059885
    system:
      heating_control: 10:030670