Hello,
I’m using KNX integration with around ~400 entities, mostly are lights and switches (plugs) objects.
With sensors and binary_sensors I’m able to set sync_state as wanted ( init or a false, depending on needs ), but lights, switches, climate and any other entity type lacks of this parameter.
So i decided to disable, into KNX global configuration menu, the default syncing of objects and rely on sync_state value override, when available: to my surprise continues anyway to send GroupValue_Read queries every 60 minutes and on each reload of the integration. This is annoying since it floods the bus with unneeded telegrams…
This option seems to have not the effect the attached info says - for a long time as there have been no changes there since about a year. Imho it should be removed.
It could cause to miss something relevant in devices who are unable to keep up reading a heavy list of coming telegrams, especially those with limited computational or buffer related resources…
Apart from that i think it could be a good practice to keep the bus the “cleaner” possible.
Unfortunately I’m still not so good in programming, otherwise this would be a nice opportunity to contribute to open source community!
Rest assured, we are very gently reading those values
Do you have any devices that can’t keep up? Afaic we are very well respecting the KNX specification regarding telegram rates (for tunnelling this is more a concern of your tunnelling server, not the client - routing is different).
If you don’t want to have HA query GAs, you can just not configure *_state_address where possible - only those (with the one unfortunate exception of climate.temperature_address) are read.
They are updated on write addresses too - for most things. cover position is one exception - here the state address is handled independently from the write address to be able to display current position while still knowing target position.
You can also use “passive addresses” - just configure a list of GAs to an _address. The first will be used to send to, the rest only to update. Just like in ETS.
May I ask again which devices have problems with the telegram load from the state updater? And which connection method you are using?
It was just mine concern, i haven’t linked - at the moment - any missed command to telegram flooding, but wanted to avoid any possible source of congestion in advance.
So, those passive addresses will never receive GroupValue_Read queries from the integration?
!
