I’m using KNX integration with around ~400 entities, mostly are lights and switches (plugs) objects.
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…
What am I missing?
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.
There was someone recently who wanted to add
sync_state to all entity types - see Support sync_state for all device types - #3 by farmio
How does this manifest? Do you experience any negative side effects of this?
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.
*_state_address 'es will totally remove status feedbacks or they’ll still be updated when someone send telegrams to write GAs objects?
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?
There are even academic papers about “The Fallacy of Premature Optimization”
Right. No GroupValueRead requests are sent to those, only to the (first)