Log is filled with "Error: KNX bus did not respond in time to GroupValueRead request for X/X/XX"

I have got the same errors on HA 0.118.0
Status of lights are read correctly, but all switches appear as “off”, although most of them are on.
Error log is full of
“Error: KNX bus did not respond in time (1 secs) to GroupValueRead request for (x/x/x)”

Same here all switch are off after upgrade to HA 118.0

Same here. All switches are not working with 0.118.0…

seems to be a known issue which is being identified:

I am experiencing the same issue, but the first time exactly one hour after the start of HA. From that point in time on, it’s happening every 60 minute. You can really set the clock on the error events. The Group Addresses in ETS are all set to K/L/-/Ü/- Maybe that help solving the issue. Running on 0.118.5

This bug is fixed in HA 1.0.0 - it is in beta right now, give it a try.

2 Likes

Hi

The same problem here. And I’m running 2021.1.4 as Core on my Raspberry Model 4.

I’m relatively new to HA. But from the beginning (> two months now) I have these warnings regularly. My KNX seems to work. Probably I will miss some measures from time to time. So these warning are just a bit annoying.

KNX warning

These come from *_state_address that are not readable - as in do not respond to GroupValueRead requests from the Line your HA integration is on the bus.
In some (very rare) cases these responses really take longer than 2 seconds. Most times it’s either a misconfigured group address, missing Read-flag or a line couplers filtering problem.

Note the addresses and see if you can read them from ETS (using same line as HA).

If you don’t want to read these addresses at all you can eventually disable state updater for an entity with the sync_state config. This is not available for all platforms.

There is no random generator involved - it should either work or it doesn’t.

Thank you for your answer.

The KNX setup was done a long time ago by a KNX integrator. So I’m a stupid dummy with KNX/ETS.
Below you will find some images of the ETS configuration for 3 devices that were giving an error.
Perhaps you can find the problem in the configuration?

It is also possible that there is a communication problem with my Siemens IP/EIB gateway.
PS: The gateway and my PI are UTP cabled with a static IP address.

After restarting the host, I had these errors today
image

3/1/22 and 3/1/23 : are outputs on the same ABB mini switch. Going to a “voice dialer”
Should I set also the read bit?

9/3/0 is an input/output on my Siemens QAX910 thermostat (for 6 room and radio coupled valves).
9/3/0 is used for setting and reading the “economy temperature”. The flags are set the same as for the other rooms 9/3/1, 9/3/2 and 9/3/3
image

so where do we start… Be aware that I have never seen (I guess) ETS 3 so I have to loosely interpret what I’m seeing.

  • When the Read-flag isn’t set on any communication object in a group address the group address will not respond to a GroupValueRead request → you’ll see the error above.
    It shall only be set on 1 or 0 (if not needed) communication objects in a group address, you’ll get multiple results otherwise and this is not good.
  • Some communication objects are not meant to have a read flag set. It is possible to do so, but they will never respond. You can just try it out from GroupAddress Monitor in ETS (at least in ETS 5…)
  • there are individual addresses 1.1.10 and 1.9.1 visible. These are 2 different lines (1 and 9). If these devices are really separated through line couplers they could filter telegrams. These filters are written by ETS and can be modified with dummy devices in ETS - these are virtual devices (eg. for HA). You’d need to know on which line your interface is. This would be the place to drop the dummy (device number doesn’t matter).
  • if there aren’t multiple lines you’d need a time machine to travel back long time ago and hide your KNX installers weed…

What does this do? Can you show how you configured these addresses in HA?

Thanks for your answer.

I’ve read some KNX doc, and I’ve changed the config of an KNX relay.

Let’s consider the settings of these relays

image

When trying to read this object from within ETS -> I didn’t receive an answer.
After I’ve set the read bit to Yes + download -> I could read the value from within ETS. So I suppose I’ll no longer receive a warning.

But it are relays. Am I wrong that the default setting for a input is “Read flag cleared” and “update flag set”? So is it not better to set the “update flag” and clear the “read flag” for this relay (and leave the write flas set)?

All my relays are configured as switches in the configuration file.
config

To answer your other remarks: I have only a limited number of KNX devices, because my house was built without any KNX or … KNX was initially added by an integrator. But I added later on the (advanced) thermostat. I suppose I’ve chosen another individual address 1.9 to show the difference between his work and mine. But in reality I have only one line. I already said that I’m a dummy.

1 Like

See https://support.knx.org/hc/en-us/articles/115003188089-Flags
These are very different things and there is not one right way for every communication object. Normally defaults are ok, but sometimes they are just not.
The Read-Flag should be set to the communication object that represents the single source of truth for a group address. Sometimes there is none - eg. when there are separate status communication objects - then the status should have the Read-Flag (but should also be linked to a different group address).

The individual address syntax is .. so every device in area 1 line 1 has to have a 1.1.* address. Doing this differently can cause errors, so I’d rather not.