KNX - relative dimming for lights

Blueprints Exchange
, ,
22

Not sure what the best way is to contribute, but as it is not much I’ll just post it here:
Input Section

    switch_status_address:
      name: Switch status group address
      description: 'Group address for switching status of the lights. DPT 1 Example:
        ''1/2/3''

        '
      default: []

trigger & trigger_variable

trigger_variables:
  light_entity: !input 'target_lights'
trigger:
#...
- platform: template
  id: "light_changed"
  value_template: >-
     {{ is_state(light_entity.entity_id,'on') }}
- platform: template
  id: "light_changed"
  value_template: >-
     {{ is_state(light_entity.entity_id,'off') }}

action

#...
#new condition
  - conditions:
      - condition: trigger
        id: light_changed
    sequence:
      - service: knx.send
        data:
          address: '{{ switch_status_address }}'
          payload: '{% if is_state(target_lights.entity_id,"on")%}1{% else %}0{% endif %}'

This will return the on/off state to the bus and saves adding an knx expose for each switch.

23

We can use knx.exposure_register to dynamically create an expose.

The problem I see with that solution is when using multiple entities, let alone areas. :thinking:

24

wasn’t even aware there was a knx.register_exposure, that’s even better and save the hassle with the ugly trigger.

25

I guess the cleanest solution would be a second blueprint setting up exposures for one single entity wich is used as reference entity then - but thats quite the same as setting up the 2 exposures in configuration.yaml

Or to do an additional blueprint accepting only one entity as target - this could be a light_group then.
It would probably even be possible to implement a selection for linear/quadratic dimm curve since the current brightness could be used to calculate it.
But the Blueprint of this topic can’t be updated to that because it would break backwards compatibility / be a breaking change.

26

For me one of the goals is to have everything in one place to keep it manageable.
I’m not sure it is necessary to return the brightness back to the Bus but certainly the on/off state is useful for Status LED’s on switches.
Maybe introduce an entity selector to select a status entity and then register this for exposure.
I believe it is possible to set default values for inputs so older automation would not break with a new version of this BP.
I’ll play a bit with this today.

Also as I’m new to HA, there is no auto update for BP’s, right?

This seems to work fairly well for me:
input

    switch_status_address:
      name: Switch status group address
      description: >
        Group address for switching status of the lights. DPT 1 Example:
        Example: '1/2/3'
      default: ''
    switch_status_entity:
      name: Entity to get on/off status from for KNX Bus
      default: ''
      selector:
         entity:
            domain: light

*variables’

  switch_status_address: !input 'switch_status_address'
  switch_status_entity: !input 'switch_status_entity'

actions

    # INITIALIZE
    - conditions:
        condition: trigger
        id: "initialize"
      sequence:
        - service: knx.event_register
          data:
            address: !input switch_address
        - service: knx.event_register
          data:
            address: !input dimm_address
        - choose:
          - conditions: "{%- if switch_status_address != '' and switch_status_entity != '' %}true{% else %}false{% endif -%}"
            sequence:
#              - service: system_log.write
#                data:
#                  message: 'address:.{{ switch_status_address }}.entity:{{ switch_status_entity|pprint }}.'
              - service: knx.exposure_register
                data:
                  address: '{{ switch_status_address }}'
                  type: binary
                  entity_id: '{{ switch_status_entity }}'
27

Im not sure thb. See About Blueprints

Having a % exposure added then isn’t a big deal. It can just use the same entity as switch. If no GA is given it can be ignored.

28

I think we would be fine. They mention its OK to add new inputs with a default value (which I did).
Also the way i read it currently there is no update functionality in HA, it is something to be added in the future.

29

Hey,

thanks for this awesome blueprint.

I’m using KNX Switch Jung TSM 3092 with Dimming funktion and a Philips Hue Color and White Ambiance Gradient Stripe.

With this blueprint, both switching on and off as well as dimming works.

But i have the strange behavior, that dimming takes a very loooong time. While holding the button, you can see, that the stripe is dimming, but only a very little bit and there is a long time (2-4s) between each dimming step.

Any Help is welcome.

sincerely

Zandi

30

Hi :wave:!
What values did you set for the dimming speed and step when configuring the blueprint?

31

Hey,

I use the default values, 4 seconds for the full dimming and 20 steps.

My expectation was, that holding the button for about 4 seconds does the dimming from e.g 100% to 0%.

Actually, the tsm3092 is configured to up(on) and down(off), so short presses are invoking switch events on a different group adress and holds (longer than 400ms) are sending incremental up/down events with 4byte KNX dimming data type like mentioned in ur starting post.

32

This would be my expectation too.
You can try to debug it with HAs automation debugging tool. Open your Home Assistant instance and show your automations.
It should call light.turn_on with a new brightness value every 0.2 seconds until you release the switch.
Or watch HAs events when dimming from Open your Home Assistant instance and show your event developer tools.

Maybe your light reacts with their own dimm-time for new brightness values which is reset on every call 🤷

33

Hey,

thx for ur hints so far.

Will send an update after some debugging fun :slight_smile:

34

Hey,

one single button down hold for 4 seconds is starting the sequence ( 20 steps, each after 200ms, 4 seconds long) correctly.

The dimming value for each step is -13.

Don’t know, wether this is correct or not.

€dit:

ok, 13 is only the ceil rounded value.

I think, i had to try to understand ur script a way more :wink:

35

Hey,

one question. How the knx switch should behave to run the automation properly?

should it repeate its event while holding the botton down and if so, after which delay?

I had tried with repeating event (every 200ms) and without… but the first described behaviour keeps going…

after all, short long presses are stopping the sequence before step 20 correctly

dont know, whats going wrong :frowning:

€dit:

additional Info: full dimming Takes between 17 to 20s
I had monitored the device, while holding the button it takes 20 steps, as expected, but the wait time is nearly a seconds

36

I think it doesn’t really matter if the telegram is repeated or not.

Are you trying to dimm a group? See https://github.com/home-assistant/core/issues/65119 and many other issues currently open.

37

hey farmio,

actually, the light stripe is not part of a light group or group.

new insights:

  • without repeating telegrams and a dimm time of about 4 seconds, in HA only 5 dimm steps were executed, for dimming the full range, i had to press and hold the button up to 4-5 times o_0
  • with repeating telegram each 200ms, all 20 steps were executed at one single button press/hold, but with a wait time of nearly a secomd between each step
  • reducing max dimm time to the minimun of 1 second does not change the behaviour at all
  • reducing steps is working as expected

i have no idea what else to try…

possibly it is a similar case of an internal event delay

sincerely

zandi

ps: thx for ur help so far

38

I guess this is still related to the group issue. The blueprint does more or less the same as a light group - even if only one entity is selected.

39

Hi, I have exactly the same behavior as Zandrael. Couldn’t find the cause. The KNX sends a command to start DIM and to stop DIM, between these commands the blueprint repeat loop is active. → all good.
Maybe hue is not made for commands within some 100ms… I did not debug the hue interface.
As a workaround I used a seccond button on the KNX push-button to switch on the light with 40% on a value change. So left button ON/OFF with the blueprint, right button 40% ON. Here’s the automation for the 40% ON. The KNX push-button causes a value change.
of course all in one blueprint is better, still room for improvement :slight_smile:

alias: Auto Licht OG Zimmer Nord Szene
description: Zimmer Nord gedimmtes Deckenlicht
trigger:
  - platform: state
    entity_id: light.og_zimmer_nord_szene
    from: 'on'
    to: 'off'
  - platform: state
    entity_id: light.og_zimmer_nord_szene
    from: 'off'
    to: 'on'
condition: []
action:
  - service: light.turn_on
    target:
      entity_id:
        - light.hue_og_zimmer_nord_decke_1
        - light.hue_og_zimmer_nord_decke_2
    data:
      brightness_pct: 40
mode: single
40

I wouldn’t invest too much energy in workarounds as long as the mentioned issue wasn’t resolved.
You could check if this was related by trying to use the blueprint with 2021.12. The issue just came up with 2022.2

41

It seems 2022.2.6 has fixed the group problem. If your HUE lights continue to not work with this blueprint (or any other automation doing about the same) you should open an issue at GitHub for that.
I personally don’t own Hue hardware (or any light this bp is applicable to) so I can’t really test that.