0.31.7 known_list does not filter out my next door neighbour's Evohome

[jrb80]

0.31.7 known_list does not filter out my next door neighbour's Evohome

[zxdavb]

Please confirm you're using 0.31.7 and not 0.41.x. Please also confirm if this behaviour persists with 0.31.19.

Please show us your working ramses_cc: section from the configuration.yaml file.

I will add a unit test for this to the test suite.

[zxdavb]

Oh - what is the 'status' of these entities in HA's web UI?

[jrb80]

Oh - what is the 'status' of these entities in HA's web UI?

They are all valid entities and I am able to control them (but I haven't dared do that of course!). I created a entities card to show the status of the zones and controller of my neighbour.

[jrb80]

Please confirm you're using 0.31.7 and not 0.41.x. Please also confirm if this behaviour persists with 0.31.19.

Please show us your working ramses_cc: section from the configuration.yaml file.

I am now running the x.20 latest build but it doesn't change anything. Here is my configuration;

ramses_cc:
  serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
  restore_cache:
    restore_schema: true
    restore_state: true
#  packet_log:
#    file_name: evohome_ramses.log
  ramses_rf:
    enforce_known_list: true
    enable_eavesdrop: false
#   disable_qos: true
  known_list:
    01:182924: # Evohome
    18:068640: # Gateway
    07:034680: # Hotwater Cyclinder
    13:182591: # Hotwater Valve
    13:088711: # Heating Valve
    13:014952: # Underfloor Relay
    34:144349: # Underfloor Thermostat
    04:039919: # TRV
    04:039925: # TRV
    04:107297: # TRV
    04:040235: # TRV
    04:040237: # TRV 1
    04:040233: # TRV 2
    22:014453: # DTR4 Thermostat
    04:039921: # TRV
    04:107303: # TRV

[jrb80]

@zxdavb I suspect these log entries are pointing to the problem. The integration is trying (and does) add my neighbours controller into HA and the log complains that my neighbours controller isn't defined in the known_list. It seems like the integration doesn't realise that I already have a controller defined and when it "sees" another it just assumes it should be in the known_list. It seems like the validation check / logic requires some tweaking?

2024-05-10 09:35:05.862 WARNING (MainThread) [ramses_tx.schemas] Best practice is to enforce a known_list (an allow list), but it is empty, so it cant be used 
2024-05-10 09:35:05.862 WARNING (MainThread) [ramses_tx.schemas] Best practice is to provide a known_list and enforce it, configure: enforce_known_list = True
2024-05-10 09:35:05.862 WARNING (MainThread) [ramses_tx.protocol] The known_list SHOULD include exactly one gateway (HGI), but does not (it should specify 'class: HGI')
2024-05-10 09:35:06.929 WARNING (MainThread) [ramses_tx.protocol] The active gateway '18:068640: { class: HGI }' (by filter) SHOULD be in the (enforced) known_list
2024-05-10 09:35:06.938 WARNING (MainThread) [ramses_rf.gateway] GATEWAY: Restoring a cached packet log...
```

[zxdavb]

@jrb80 I feel you haven't answered my question...

What specific version of x.x.20 are you running? 0.31.20 (without config flow) or 0.41.20 (with config flow)? If you're running 0.31.20, did you ever run 0.41.x? If so, what steps did you take to remove your config flow entry?

[jrb80]

@jrb80 I feel you haven't answered my question...

What specific version of x.x.20 are you running? 0.31.20 (without config flow) or 0.41.20 (with config flow)? If you're running 0.31.20, did you ever run 0.41.x? If so, what steps did you take to remove your config flow entry?

v0.31.20 without config flow. Yes I would have tried config flow at some point but I can't remember when as I've bounced versions so many times now.

In terms of changing versions, I simply just "redownload" the integration from the HACS interface, uncomment yaml and restart. I have tried cleaning the cache on a few occasions but that didn't seem to make any difference.

Btw, this problem has been around well before config flow was introduced. I've just ignored the log errors/warnings about not having a known_list as it didn't seem to impact functionality.

[jrb80]

Fyi, my neighbour is three doors down, not directly next door to me. Somewhat impressed on the range of the receiver!

[zxdavb]

The move to a config_flow release (0.41.x) is intended to be a one-way process.

Moving back (0.31.x) is not straight-forward. What special steps did you take?

The safest thing to do would be to switch to 0.41.20. If offers lots of advantages, including changing your known_list without restarting HA. Clearing caches is much easier.

Support for the non-config_flow version will be dropped by next winter.

Otherwise, if there is a ramses_cc section in .storage/core.config_entries, delete it and restart HA. If that doesn't work, you're back to my previous suggestion.

[jrb80]

Upgraded to 0.41.20 with configuration flow and cleared cache. It now seems to be working as expected. My next door neighours entities are now reporting as unavailable as expected.

[jrb80]

Issue resolved in 0.41.20 configuration flow.