KNX - HA turns switch unintended

Hi all,

i have a problem with my KNX integration.

There are two identical switches in the Bus. They are not physical, but controlling the movement sensor.

One of them is working fine, just as expected. But the other one turns exactly after 1 hour to state “on” if it is “off”.

There is no automation in HA, no automation in the KNX Bus. I checked the logs on the KNX and the “on” state update is send by HA to the Bus.

What could be the trick?

thanks, marco

What do you mean by identical? The same model/same knx group/same adress(i hope not).
How is the group setup in your configuration.yaml?

Gonna need alot more info to help

I mean identical configuration, and same model.

Here is my configuration:

- name: Diele Bewegungsmelder sperren
  address: "1/0/1"
  state_address: "1/0/1"
  
- name: Garage Bewegungsmelder sperren NEU
  address: "1/0/5"
  state_address: "1/0/5"

“Diele” ist working fine. “Garage” is the entity with the problem.

What does the history say for the entity within HA? Does it also show an on?

Every hour (exactly 1 hour after last telegram) by default the knx Integration reads the status of a state_address.
So it should send a GroupValueRead request to 1/0/5 (and 1/0/1). That’s the same as if you pressed “Read” Button (“Lesen”) in ETS Diagnose GroupMonitor. Try that from ETS for both addresses and post the results please.

Yes, in the History it shows “turned on”

At the moment i have no access to the ETS but i have the output from the HA Log when Read is starting.


2021-09-03 08:56:31 DEBUG (MainThread) [xknx.state_updater] StateUpdater reading 1/0/5 for Garage Bewegungsmelder sperren NEU - State
2021-09-03 08:56:31 DEBUG (MainThread) [xknx.telegram] <Telegram direction="Outgoing" source_address="0.0.0" destination_address="1/0/5" payload="<GroupValueRead />" />
2021-09-03 08:56:31 DEBUG (MainThread) [xknx.knx] Sending: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="TUNNELLING_REQUEST" Reserve="0" TotalLength="21" />
body="<TunnellingRequest communication_channel_id="16" sequence_counter="156" cemi="<CEMIFrame SourceAddress="IndividualAddress("1.1.200")" DestinationAddress="GroupAddress("1/0/5")" Flags="1011110011100000" payload="<GroupValueRead />" />" />" />
2021-09-03 08:56:31 DEBUG (MainThread) [xknx.knx] Received: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="TUNNELLING_ACK" Reserve="0" TotalLength="10" />
body="<TunnellingAck communication_channel_id="16" sequence_counter="156" status_code="ErrorCode.E_NO_ERROR" />" />
2021-09-03 08:56:31 DEBUG (MainThread) [xknx.knx] Received: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="TUNNELLING_REQUEST" Reserve="0" TotalLength="21" />
body="<TunnellingRequest communication_channel_id="16" sequence_counter="90" cemi="<CEMIFrame SourceAddress="IndividualAddress("1.1.200")" DestinationAddress="GroupAddress("1/0/5")" Flags="1011110011100000" payload="<GroupValueRead />" />" />" />
2021-09-03 08:56:31 DEBUG (MainThread) [xknx.knx] Sending: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="TUNNELLING_ACK" Reserve="0" TotalLength="10" />
body="<TunnellingAck communication_channel_id="16" sequence_counter="90" status_code="ErrorCode.E_NO_ERROR" />" />
2021-09-03 08:56:31 DEBUG (MainThread) [xknx.knx] Received: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="TUNNELLING_REQUEST" Reserve="0" TotalLength="21" />
body="<TunnellingRequest communication_channel_id="16" sequence_counter="91" cemi="<CEMIFrame SourceAddress="IndividualAddress("1.1.11")" DestinationAddress="GroupAddress("1/0/5")" Flags="1011110011100000" payload="<GroupValueResponse value="<DPTBinary value="1" />" />" />" />" />
2021-09-03 08:56:31 DEBUG (MainThread) [xknx.knx] Sending: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="TUNNELLING_ACK" Reserve="0" TotalLength="10" />
body="<TunnellingAck communication_channel_id="16" sequence_counter="91" status_code="ErrorCode.E_NO_ERROR" />" />
2021-09-03 08:56:31 DEBUG (MainThread) [xknx.telegram] <Telegram direction="Incoming" source_address="1.1.11" destination_address="1/0/5" payload="<GroupValueResponse value="<DPTBinary value="1" />" />" />

Well, there is your answer (only xknx.telegram logs are of interest here).
Device 1.1.11 responds with 1 (True or ON) so all Devices on the Bus (with active U-Flag (“Aktualisieren”) including HA) will accept that.

This was not sent from HA - but requested. Does the other GA respond differently ?

Ah ok now i understand.
I wondering where the “1” is coming from. The other Switch is exactly configured like the problem switch.

Here the log from the other switch. This one is answering with “0”

2021-09-30 17:36:25 DEBUG (MainThread) [xknx.knx] Sending: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="TUNNELLING_REQUEST" Reserve="0" TotalLength="21" />
body="<TunnellingRequest communication_channel_id="16" sequence_counter="64" cemi="<CEMIFrame SourceAddress="IndividualAddress("1.1.200")" DestinationAddress="GroupAddress("1/0/1")" Flags="1011110011100000" payload="<GroupValueRead />" />" />" />
2021-09-30 17:36:25 DEBUG (MainThread) [xknx.knx] Received: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="TUNNELLING_ACK" Reserve="0" TotalLength="10" />

There is no answer in the log you posted.

Do you mean it is configured the same in ETS?

yes the same as in ets

You will have to solve this from ETS. There is nothing you can do from HA when the device is reporting a wrong state (except not sending the read request but that’s not solving, but ignoring the problem).

ok thank you. I will check this next week on the ETS. I will post the solution then. Thank you.