KNX - States change after some time even if they are correctly set

pridi · November 8, 2022, 12:31pm

I’m becaming crazy. I have some lights (62) connected to the KNX bus. Even if I set their states like in the documentation, after one hour their states change without have commanded them.

- name: "light_1_kitchen"
  address: "0/0/1"
  state_address: "0/1/1"

I know from the documentation that:

The HA KNX integration uses configured state_address or *_state_address to update the state of a function. These addresses are read by GroupValueRead requests on startup and when there was no incoming telegram for one hour (default sync_state ).

How can I set the *_state_address inside the yaml file?

I’m sure that the ETS (not sure about HA) is writing the states of the lights. When I command them from Home Assistant, after one hour they return to the previous state.

I’ve tried also to use the “expose” method like described in the docs, but at this point, after one hour, the switches on the dashboard start flashing like crazy…

Do you have ideas?

farmio · November 8, 2022, 1:11pm

Hi !

You have done that

The light actuator should write its state. HA only consumes it. ETS doesn’t send anything to the bus except for configuration (and debug).

Now HA sends something to the bus, but that is not what you want (and probably, hopefully not what the docs say). This can be used for non-KNX lights to have eg. a status in visualizations. You seem to create a loop.

You should check why your 0/1/1 doesn’t represent the actual state of your light (which you set via 0/0/1).

pridi · November 8, 2022, 3:13pm

Hi farmio, thank you very much for your prompt answer!
I will follow your suggestion to check the diagnosis of the KNX bus, but as you can see from the picture below (sorry for the Italian), the actuator is comanding the light to turn on/off and it’s also setting the state of the light “luce 1 cucina”…

Do you suggest other tests to do?

Thank you again!!

farmio · November 8, 2022, 3:25pm

Open “Diagnostics” - “Group monitor” and make a Read-request for 0/1/1 - see what it reports - or maybe if multiple devices answer.

Or just check if multiple group objects connected to 0/1/1 have the read-flag set (only max. one per GA should have it)

pridi · November 8, 2022, 5:42pm

As you suggested I’ve tried to diagnose by reading the 0/1/1 state- As you can see it is set only by the actuator “01523 4 Uscite”. The last two lines of the screenshot are the phisical buttons I have in the plant that set the output of the actuator to switch on the light.

When you say

check if multiple group objects connected to 0/1/1 have the read-flag set (only max. one per GA should have it)

you mean that in the next image something is not correctly configured?

The strange thing is that I see the change in the state in HA only after one hour or so…

farmio · November 8, 2022, 7:52pm

There seem to be multiple things sideways.

Here I can’t see much (eg. the time or the answer payload is missing), but what I can see is that ETS (I assume) has got the address 15.15.3 - which is not on the same area/line as the actuator. I don’t know what interface you are using, but look at how to configure its tunnel endpoint addresses. They should be 1.0.x (assuming that your interface - or all your devices - is on 1.0.y)

Did you press those buttons manually? Why is there no status update to 0/1/1 then when you toggle that light?

exactly. One GA should not have multiple group objects with a read flags assigned.
Find information about flags here: https://support.knx.org/hc/en-us/articles/115003188089-Flags
I’m not sure what those 5 objects are or do as I don’t understand their descriptions, but it seems not right - for once that all have a read flag - and also that none has a write flag (so everyone answers, but no one listens )

It’s not strange. You said it yourself in the first post. HA sends a Read-request once an hour to the state_address. Objects with a read-flag will answer that - but if you have multiple then you will probably get multiple answers, not only from the one device that actually knows the state of the light.

What is strange is that you can’t see the other devices answer in the group monitor. I don’t know why that is.

pridi · November 9, 2022, 7:11am

Thank you again farmio!

Regarding your questions:

My bad, the 15.15.3 was the address I’ve not configured for HA (when you configure in UI of HA the KNX module I’ve left the default one!). I’ve now set to 1.0.90: I have one principal line at the base floor with addresses 1.0.x and a secondary line at the first floor with 1.1.x. Do I have to register HA in ETS with a specific address? This is not shown in the docs…

No, I didn’t press the buttons manually. As you suggested I’ve only made a Read-request inside the diagnostic of ETS for 0/1/1 and the results are in the following image:

the first is HA (with the wrong address, now fixed to 1.0.90)
the second line is the actuator output to switch on the light
the third and the fourth are the buttons, linked to the actuator

it means that I should revome the R flag for the buttons (“Pulsanti Eikon”) and keep only the reading for the actuator ("1.0.3 015523 4 Uscite)?

farmio · November 9, 2022, 7:50am

This is only used für routing, for tunnelling it has no effect. You’ll have to set the tunnel endpoints according to your knx interfaces manual (via ETS or for older ones via web interface).

Only if you use GAs from a different line than the one HA is tunnelling to, and these addresses are not used in that line. So if your interface sits on main line and you want to use GAs that are only assigned to 1.1.x devices, then you’ll need a dummy device in ETS to have the line couplers filter tables forward the telegrams to the main line.
It’s mentioned somewhere in docs in the troubleshooting section afair, but this is not HA specific, but basic KNX topology.

The buttons should not reply here. No idea why they reply on a different GA. Are these GroupValueResponse or GroupValueWrite telegrams?

Yes, for a start. But I don’t know why the buttons are even assigned to that GA here. If it is to update their status they should have the “W” and “U” flag set … normally these defaults are fine, so not sure why it is that way on your installation.
Can you show a screenshot of one of these buttons group objects GA assignments?

pridi · November 9, 2022, 9:27am

Here we go:

The “W” flags are assigned to turn on/off the small led of the buttons (they are buttons from Vimar where you can see if the light is switch on/off by looking at the LED).

By looking at the single physical button you can see below its assignments.

The state 0/1/1 is there but I don’t know if its doing something. I’m very sorry for this, I’m absolutely not an expert of KNX and this project has been done 6 years ago by the guy who made the installation.

pridi · November 9, 2022, 9:55am

Another, probably, important point!
In order to work with HA, 3 weeks ago, I’ve bought an IP interface from enertex (enertex bayern gmbh :: knx ip secure interface :: catalog). Previously I had a quite old USB connection to KNX.
By looking at the log generated in HA by KNX, I’ve just seen that there’s the GA 15.15.2 that is making a GroupValueRead to that particular state. I did not configure the IP module from Enertex in ETS so it is not mapped (for sure with the wrong address!) inside my ETS project.

2022-11-09 09:02:59.749 DEBUG (MainThread) [xknx.telegram] <Telegram direction="Outgoing" source_address="15.15.2" destination_address="0/1/1" payload="<GroupValueRead />" />

Something to care of?

farmio · November 9, 2022, 12:35pm

What is holding you back? If you add it to the project you can/have to assign a proper address for the device, as also for the tunnelling endpoints. And you can also turn secure tunnelling on if you like.

Aren’t the objects 2, 5, 8, 11 of 1.0.21 used for that? They would have proper flags for that at least (W+U).

Do you use buttons to “toggle” your light, or do you have dedicated ON and OFF buttons? Such a configuration where the status GA is added to a button group object is used for ON/OFF - so if another device/GA set the light the button can know what to send next - on or off (since there is no direct toggle-payload in knx).
If you have dedicated ON/OFF buttons you don’t need to update anything because the button shall always sends the same payload anyway.

I would just remove every read-flag of push buttons. A push button doesn’t hold the state of anything - that is mostly always the actuator.
And set the update-flag (together with write-flag).

Maybe get a good book about KNX / ETS so you can learn about the inner workings of that all when you start to manage your project yourself I’m afraid, I can’t recommend an italian one

pridi · November 10, 2022, 5:25pm

Thank you very much farmio, I’m sorry for the late reply.
In the next day I’ll follow all your suggestions as you described!

pridi · November 15, 2022, 8:23pm

Hi farmio, sorry to bother you again. I’m waiting for my KNX book but in the meantime I would like to finish this (stupid!) task.
I’ve simplified the management of the states as per your suggestions. Now the actuator write the on/off to turn the light on/off and the states of the lights are managed only by the actuator (and no more the switches as before!).
The question is: what are the correct flags to give to the actuator to manage the states? I’ve search everywhere but nothing gives me an explanation about the correct flag (flags?) to set in order to have the state of the light consumed by someone else (HA in my case).
I’ve seen somone putting Read+Transmission and someone putting only Write (I’ve tried both as you can see in the picture…).

The state is only managed by the actuator

farmio · November 15, 2022, 9:00pm

A good default for states is R+T, for commands W (+U if you like).

Have a look at the link in KNX - States change after some time even if they are correctly set - #6 by farmio again to understand what these flags are doing.

If you set W on a state object it will not be readable and not send a new state to the bus. But change its internal value if something is received - which doesn’t control the actuator as it is only a state object .

pridi · November 16, 2022, 9:05am

Thank you as always farmio.
Nothing, I still have the same problems. Even if the states of the lights are now managed only by the actuator with R+T flags, after one hour the states changed in HA; I left the lights physically switched off, the states were correctly off but after one hour all the states of the lights in the HA dashboard were in ON states, without that anyone pressed the physical or HA switches.

When I try to read in the ETS Diagnostic the state, for example, of the light “luce 1 cucina” 0/1/1, this is the result:

The “Enertex IP Secure Interface” has been integrated in the principal line with the address 1.0.63 and it generates 8 Tunnels. The 1.0.72 is the “Tunnel 2” that you see in the diagnostics.

I had also the doubt that the KNX configuration in HA was wrong (even if the configuration of lights should be straightforward:

What (the hell!) am I missing?

farmio · November 16, 2022, 9:29am

The actuator now seems fine, but you have your buttons still set to respond to read requests.
So the read request is still answered by multiple devices, not just one.

pridi · November 17, 2022, 6:37am

I feel so stupid…one of the problem I had was the fact that I didn’t download the actuator modifications! In any case, it’s now working perfectly!! Thank you thank you!