KNX doesn't stop syncing when explicitly set into integration config

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…

What am I missing?

Hi :wave:!

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 :grinning_face_with_smiling_eyes:
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.

Removing *_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” :rofl:

Right. No GroupValueRead requests are sent to those, only to the (first) *_state_address.

1 Like