ramses_cc icon indicating copy to clipboard operation
ramses_cc copied to clipboard

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

Open jrb80 opened this issue 9 months ago • 2 comments

The known_list feature does not filter out my next door neighbour's Evohome system. I've tried cleaning the cache a few times but the integration automatically adds it back in despite my controller defined in the known_list .

01_182924 is my controller 01_255872 is my neighbour's

You can see the integration is pulling in their zones, e.g. Back Room, Dining Room (note, I only have one Dining Room!)

Knownlist

jrb80 avatar May 02 '24 10:05 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 will add a unit test for this to the test suite.

zxdavb avatar May 02 '24 17:05 zxdavb

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

zxdavb avatar May 02 '24 17:05 zxdavb

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.

image

jrb80 avatar May 10 '24 08:05 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 avatar May 10 '24 08:05 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...
```

jrb80 avatar May 10 '24 09:05 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?

zxdavb avatar May 10 '24 19:05 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?

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 avatar May 10 '24 20:05 jrb80

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

jrb80 avatar May 10 '24 20:05 jrb80

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.

zxdavb avatar May 11 '24 06:05 zxdavb

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 avatar May 13 '24 10:05 jrb80

Issue resolved in 0.41.20 configuration flow.

jrb80 avatar May 13 '24 10:05 jrb80