KNX blocking lights from HA is being automatically reset

Hey everyone,
l could use your input with this HA/KNX setup.

I use HA with my KNX setup. All is working well with KNX… Whenever I try to block the detection to stop the light from going on and off, it works for exactly one hour and HA would reset it automatically to the state it had before.

Some screenshots from the ETS configuration as well.

Thank you

Here is the setup I have:
HA specs on VM:

  • Core 2024.4.3
  • Supervisor 2024.05.1
  • Operating System 12.2
  • Frontend 20240404.2


#Bewaesserung using switch
    - name: "Bewaesserung Rechts"
      address: "7/1/1"
      state_address: "7/1/31"
    - name: "Bewaesserung Links"
      address: "7/1/2"
      state_address: "7/1/32"
    - name: "Bewaesserung"
      address: "7/1/3"
      state_address: "7/1/33"

#Blocking lights
    - name: "Sperrung BM Garderobe"
      address: "6/0/0"
      state_address: "6/0/0"
    - name: "Präsenzmelder Garderobe"
      address: "6/0/6"


``type: custom:mushroom-chips-card

  • type: template
    entity: switch.sperrung_bm_garderobe
    icon: |-
    {% if is_state(‘switch.sperrung_bm_garderobe’, ‘off’) %}
    {% else %}
    {% endif %}
    content: SAS
    icon_color: |-
    {% if is_state(‘switch.sperrung_bm_garderobe’, ‘off’) %}
    {% else %}
    {% endif %}`

HA reads *_state_addresses every hour and reacts accordingly to the response.
Have a look at the GroupMonitor to see what device is answering with which payload. (Probably the 3rd in your screenshot - the one with the R-Flag).

Hey @farmio , thanks for the reply. I did some screenshots here from HA and from ETS. Is it possible that zennio is reversing the action?
19:47:56 I blocked
20:47:56 zennio sends the off value after the request from HA.

What is weird is that the sensor looks like unlocked and should turn on/off the light but it’s not doing it. It looks as if it is enabled on zennio but when I move in the room the light doesn’t go on…

At least it is sending that. The rest is a pure Knx issue. You can always reproduce that from ETS Groupmonitor by reading the address.

Looking at the action in ETS, looks like the integrator should pay me a visit :smiley:

HA sending ON value
Screenshot 2024-05-17 200350

HA sending the one status
Screenshot 2024-05-17 205557

Zennio jumping in to send the OFF value
Screenshot 2024-05-17 205608

Here is an attempt at the flags:

  1. Clear U from the 667 → problem still there
  2. Clear U & T from 667, then add W to 668 → it works because Z41 canno read the status anymore and cannot control the blockage. Not the solution I expected though.

I’d probably only clear T from 667 and add W to 668. But only if the Zennio device is the actual actuator / controller that’s managing locking. If there is a different device - like a motion detector or dimming actuator, it shouldn’t answer to Reads in the first place - the actuator should.

In this case, there is a movement sensor that turns on the light if there is movement. Here Zennio should block the sensor from turning on the light if there is movement… I guess the zennio switch is the controller in this case from what I see in ETS.