Yes, sure. I was thinking of adding this too.
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.
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. 
wasnāt even aware there was a knx.register_exposure, thatās even better and save the hassle with the ugly trigger.
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.
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 }}'
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.
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.
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
Hi 
!
What values did you set for the dimming speed and step when configuring the blueprint?
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.
This would be my expectation too.
You can try to debug it with HAs automation debugging tool. 
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 
Maybe your light reacts with their own dimm-time for new brightness values which is reset on every call š¤·
Hey,
thx for ur hints so far.
Will send an update after some debugging fun 
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 
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 
ā¬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
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.
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
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.
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
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: singleI 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