Light group modifies brightness of dimming lights

Jaspack · December 12, 2022, 2:32pm

I have a home automation setup with KNX and I am running home assistants besides KNX which integrates with the system. In this setup I configured a couple of dimming lights, which I could operate through home assistant without any issues (seeing status, brightness, on off etc).

A week ago, I did add configuration for a light group which tells me if any of the lights are on in the house. As soon as I added this group, I did notice some strange behaviour with the brightness of these lights. From time to time, without any interaction with home assistant or even with the physical switches, the brightness of these dimming lights changes (i.e. the go to full brightness without any reason).

I don’t have any automation running on it, also don’t see anything suspicious in the logs. Did anyone experience something similar or could have an idea on whats going wrong here?

This is my group config:

light:
  - platform: group
    name: "Alle verlichting"
    entities:
      - light.buiten_buitengevel_verlichting_SW
      - light.kamer_1_dimming
      - light.kamer_10_verlichting_SW
      - light.kamer_11_toilet_verlichting_sfeer_SW
      - light.kamer_2_verlichting_spiegel_SW
      - light.kamer_2_verlichting_SW
      - light.kamer_3_gang_verlichting_sfeer_SW
      - light.kamer_3_verlichting_SW
      - light.kamer_5_dimming
      - light.kamer_6_dimming
      - light.kamer_7_dampkap_verlichting_SW
      - light.kamer_7_verlichting_SW
      - light.kamer_8_verlichting_SW
      - light.kamer_9_verlichting_SW

my knx config:

knx:        
  light:
    - name: "Kamer 6 - dimming"
      address: "1/1/6"
      brightness_address: "1/2/6"
      brightness_state_address: "1/3/13"

farmio · December 12, 2022, 4:32pm

The KNX integration sends Read-requests after 1 hour of not receiving a telegram on any *_state_address by default. If something in ETS is not configured properly this could lead to strange behaviour.
But I’d not have any clue what the HA group has to do with that

Maybe run a ETS group monitor and see if any telegram correlates with your unexpected bahaviour.

Jaspack · December 13, 2022, 7:28am

Thanks for the response!

I could indeed be looking in the wrong direction. I remember fixing the state_address of the dimming lights, while also adding the light group.

This is my current configuration of the feedback group address, which should give me the on/off state of the dimming light.

I did already try out different configurations in ETS, by only allowing Read for the feedback object. From that moment on, the feedback state doesn’t seem to get updated anymore however. Seems like it needs the Write flag to push the state from the device to the object.

farmio · December 13, 2022, 7:47am

A dedicated feedback (state) object normally only needs Read and Transmit flags, and Communication, of course.
On most actuators it doesn’t matter if it receives a new value - as there is a second dedicated object for setting a new state - implementations for KNX devices vary though…
See here for details about flags https://support.knx.org/hc/en-us/articles/115003188089-Flags

Jaspack · December 14, 2022, 11:01am

Thanks for the feedback. This changing of the brightness doesn’t happen often, so always takes a bit of time to see if it is working. I did update the flags for these objects in the feedback group addresses, but unfortunately, yesterday evening I again had the same happening.

Luckily i could pinpoint the logs right when this happened:

2022-12-13 22:19:44.727 DEBUG (MainThread) [xknx.state_updater] StateUpdater reading 1/3/22 for Kamer 5 - dimming - State
2022-12-13 22:19:44.729 DEBUG (MainThread) [xknx.telegram] <Telegram direction="Outgoing" source_address="1.1.254" destination_address="1/3/22" payload="<GroupValueRead />" />
2022-12-13 22:19:44.735 DEBUG (KNX Interface) [xknx.knx] Sending to 192.168.0.121:3671/tcp at 1670966384.7359138:
<KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="TUNNELLING_REQUEST" Reserve="0" TotalLength="21" />
body="<TunnellingRequest communication_channel_id="16" sequence_counter="30" cemi="<CEMIFrame code="L_DATA_REQ" src_addr="IndividualAddress("1.1.254")" dst_addr="GroupAddress("1/3/22")" flags="1011110011100000" tpci="TDataGroup()" payload="<GroupValueRead />" />" />" />
2022-12-13 22:19:44.758 DEBUG (KNX Interface) [xknx.raw_socket] Received via tcp: 061004200015041000002e00bce011fe0b16010000
2022-12-13 22:19:44.759 DEBUG (KNX Interface) [xknx.knx] Received from 192.168.0.121:3671/tcp at 1670966384.759421:
<KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="TUNNELLING_REQUEST" Reserve="0" TotalLength="21" />
body="<TunnellingRequest communication_channel_id="16" sequence_counter="0" cemi="<CEMIFrame code="L_DATA_CON" src_addr="IndividualAddress("1.1.254")" dst_addr="GroupAddress("1/3/22")" flags="1011110011100000" tpci="TDataGroup()" payload="<GroupValueRead />" />" />" />
2022-12-13 22:19:44.796 DEBUG (KNX Interface) [xknx.raw_socket] Received via tcp: 061004200015041000002900bce010040907010041
2022-12-13 22:19:44.797 DEBUG (KNX Interface) [xknx.knx] Received from 192.168.0.121:3671/tcp at 1670966384.797131:
<KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="TUNNELLING_REQUEST" Reserve="0" TotalLength="21" />
body="<TunnellingRequest communication_channel_id="16" sequence_counter="0" cemi="<CEMIFrame code="L_DATA_IND" src_addr="IndividualAddress("1.0.4")" dst_addr="GroupAddress("1/1/7")" flags="1011110011100000" tpci="TDataGroup()" payload="<GroupValueResponse value="<DPTBinary value="1" />" />" />" />" />
2022-12-13 22:19:44.800 DEBUG (MainThread) [xknx.telegram] <Telegram direction="Incoming" source_address="1.0.4" destination_address="1/1/7" payload="<GroupValueResponse value="<DPTBinary value="1" />" />" />
2022-12-13 22:19:45.337 DEBUG (KNX Interface) [xknx.raw_socket] Received via tcp: 061004200016041000002900bce010040b0c020080ff
2022-12-13 22:19:45.338 DEBUG (KNX Interface) [xknx.knx] Received from 192.168.0.121:3671/tcp at 1670966385.3388:
<KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="TUNNELLING_REQUEST" Reserve="0" TotalLength="22" />
body="<TunnellingRequest communication_channel_id="16" sequence_counter="0" cemi="<CEMIFrame code="L_DATA_IND" src_addr="IndividualAddress("1.0.4")" dst_addr="GroupAddress("1/3/12")" flags="1011110011100000" tpci="TDataGroup()" payload="<GroupValueWrite value="<DPTArray value="[0xff]" />" />" />" />" />
2022-12-13 22:19:45.342 DEBUG (MainThread) [xknx.telegram] <Telegram direction="Incoming" source_address="1.0.4" destination_address="1/3/12" payload="<GroupValueWrite value="<DPTArray value="[0xff]" />" />" />
2022-12-13 22:19:46.729 WARNING (MainThread) [xknx.log] Error: KNX bus did not respond in time (2.0 secs) to GroupValueRead request for: 1/3/22
2022-12-13 22:19:46.733 WARNING (MainThread) [xknx.log] Could not sync group address '1/3/22' (Kamer 5 - dimming - State)

Where:
1/3/22 => Kamer 5 - Verlichting ST (feedback in on/off)
1/3/12 => Kamer 5 - Dim value (feedback in %)
1/1/7 => Kamer 5 - Verlichting SW (switching on/off)
1/2/5 => Kamer 5 - Verlichting Dim value (setting dim value)

And config:

knx:        
  light:
    - name: "Kamer 5 - dimming"
      address: "1/1/7"
      state_address: "1/3/22"
      brightness_address: "1/2/5"
      brightness_state_address: "1/3/12"

Finally I also tested addresses 1/3/22 and 1/3/12 with a manual write operation in ETS, neither one of them influenced the actual brightness of the light. So from what I see this behaviour should come from communication through 1/1/7 or 1/2/5 (it also jumped to full brightness so i suspect it coming through 1/1/7). I’ll set up logging for this channel.

Dujith · December 14, 2022, 2:13pm

In KNX most dimmers have a default action for the on switch (1bit object) which you can set in ETS
Could it be thats set to 100% ?
Still weird that something would send an on to 1/1/7

Jaspack · December 14, 2022, 8:38pm

I configured my dimmers to switch back on with the previous brightness they had last time they were on.

What I do see in my ETS config is the following:

Could the fact I added the Feedback On/Off to the 1/1/7 group (to switch the on/off) have something to do with this? I find it kinda strange that Feedback On/Off is marked as “Sending”. Could it be that receiving a new feedback triggers this group?