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.
I’m currently working with 2022.2.3. Spent a lot of time, but the dimming did not work properly. The best solution, is the folling one. Works also correct even if you change the lights over the hue app, but you need this 3 steps:
- Create a light group that contains the hue lights
light:
- platform: group
name: EG Wohnzimmer Ambient Lichtgruppe
unique_id: eg_wohnzimmer_ambient_lichtgruppe
entities:
- light.hue_eg_wohnz_bodenlampe
- light.hue_eg_wohnz_tischlampe
- Expose this light group entity to KNX feedback address. This is needed that the led indication and the state of the knx button are correct.
knx:
expose:
- type: 'binary'
entity_id: 'light.eg_wohnzimmer_ambient_lichtgruppe'
address: "2/0/38"
- use the modified blueprint with this configuration
The modified blueprint sens a fix dimmed value at a long press of the knx button. Not that bad, you dont have to have the right timming 
DIM DOWN = dimmed value
DIM UP = initial value
blueprint:
name: KNX - relative dimming for lights
description: Controll Home Assistant Light entities from KNX switching and relative dimming (DPT 3.007) telegrams.
domain: automation
input:
target_lights:
name: Light
description: The lights that shall be controled.
selector:
target:
entity:
domain: light
switch_address:
name: Switch group address
description: >
Group address for switching the lights on and off. DPT 1
Example: '1/2/3'
dimm_address:
name: Relative dimming address
description: >
Group address for dimming the lights. DPT 3.007
Example: '1/2/4'
initial_value:
name: Initial value
description: Initial value for light on, from 20% to 100%.
selector:
number:
min: 20
max: 100
step: 10
unit_of_measurement: '%'
mode: slider
default: 100
dimm_value:
name: Dimmed value
description: Dimmed value for light dim, from 5% to 90%.
selector:
number:
min: 5
max: 90
step: 5
unit_of_measurement: '%'
mode: slider
default: 50
# no matched condition stops repeat sequence to stop dimming (dimm 0)
mode: restart
max_exceeded: silent
variables:
_initial_value: !input initial_value
_dimm_value: !input dimm_value
trigger:
- platform: homeassistant
event: start
id: "initialize"
- platform: event
event_type: automation_reloaded
id: "initialize"
# when KNX integration was reloaded
- platform: event
event_type: service_registered
event_data:
domain: knx
service: event_register
id: "initialize"
- platform: event
event_type: knx_event
event_data:
destination: !input switch_address
telegramtype: GroupValueWrite
id: "switch"
- platform: event
event_type: knx_event
event_data:
destination: !input dimm_address
telegramtype: GroupValueWrite
id: "dimm"
action:
- choose:
# TURN ON by KNX
- conditions:
condition: and
conditions:
- condition: trigger
id: "switch"
- "{{ trigger.event.data.data == 1 }}"
sequence:
- service: light.turn_on
target: !input target_lights
data:
brightness_pct: '{{ _initial_value }}'
# TURN OFF by KNX
- conditions:
condition: and
conditions:
- condition: trigger
id: "switch"
- "{{ trigger.event.data.data == 0 }}"
sequence:
- service: light.turn_off
target: !input target_lights
# DIMM UP by KNX
- conditions:
condition: and
conditions:
- condition: trigger
id: "dimm"
- "{{ 9 <= trigger.event.data.data <= 15 }}"
sequence:
- service: light.turn_on
target: !input target_lights
data:
brightness_pct: '{{ _initial_value }}'
# DIMM DOWN by KNX
- conditions:
condition: and
conditions:
- condition: trigger
id: "dimm"
- "{{ 1 <= trigger.event.data.data <= 7 }}"
sequence:
- service: light.turn_on
target: !input target_lights
data:
brightness_pct: '{{ _dimm_value }}'
# 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
@hansQ Nice that you found a workaround that does the job for you, but did you also file an issue so that the underlying problem has a chance to get fixed at some point?
I would love to name the issue…
I my point of view the hue api documentation is necessary to fix it. Do you have a good link?
I was curious if it is a timing issued because I’m running HA on a virtual machine on proxmox. So I mirrored the port where the hue bridge is and used wireshark to record the traffic. Just to the have the timing… there are two hue lights controlled out of my HA and I used time = 3s and dim steps = 10, so I expected telegrams with a delay of 300ms. The record shows something in this direction. Some telegrams within 20…30ms and then a repetition within 300…400ms. To go further I need a documentation.
ip addresse .21 is HA, .11 is the hue bridge
Cool, this will surely be very appreciated, but here is the wrong place to discuss HUE specific details (and I’m the wrong person to do so).
May I point you to https://github.com/home-assistant/core/issues to open an issue against the HUE integration so the experts on that domain can have a look.
The issue should be reproducible with a simple automation with a repeat-sequence and delay so no blueprint or KNX needed whatsoever.
Afaik this did work with Hue lights previously (at least I have never heard of any specific issue) so I guess it’s fixable.
Hi framio, the issue is reproduceable with a test automation and reported in: https://github.com/home-assistant/core/issues/66551
1 Like
PS: For the blueprint, I would limit the input. At the moment the worst case scenarios are 100 steps in 1s or 2 steps in 20s. My proposal is to have a DIM time between 2…5s and a fix step time of 200ms. The number of steps are calculated. I think these input options are sufficiant.
Hi Matthias, I finally came back to my project again to puzzle this issue out. Config used for the blueprint:
light:
name: "kitchen"
address: '1/1/0'
state_address: '1/1/1'
brightness_address: '1/1/10'
brightness_state_address: '1/1/11'
Results from bus monitor when using actuator on my wall (turned light on and repeated dim-up three times):
Not an expert in KNX, but seems like DPT 3.007 is used for dimming.
Later, I tried to repeat the same using Home Assistant (Source Name: Tunnel 1):
Light went ON for less than a second and OFF again immediately. Then automation keeps sending OFF telegram to the bus forever unless automation is terminated.
not sure what exactly you want to do with this blueprint here, but it seems you mix up absolut (DPT 5) and relative (DPT 3) dimming. Former sends an absolute percentage the light shall dimm to, latter sends a start (up/down) and then a stop signal. These have to use different GAs.
Per above, the config I am testing is very basic. One light, different GAs for switching & dimming. Just want to be able to turn on/off and dim the light. I decided to focus on this blueprint (DPT 3) since my previous efforts on HA were unsuccessful. If I understand correctly my KNX installation is using both: DPT 3 for relative dimming and DPT 5 for dim state in %.
Initially I’ve tried standard HA light integration. Using HA I was able to turn on and off the light and read dimming level set by actuator on the wall. But going the opposite direction and setting dim level from HA does not work. HA sends values to the KNX GA (I can see via ETS bus monitor), but those values are somewhat incorrect and lights just do not dim. No errors in the xknx.log.
that’s fine, but not on the same GA. You would need 2 different group addresses - one for DPT 3 and one for DPT 5. The KNX light entity only works with 5.
This blueprint is built to controll non-KNX light entities from KNX switches, not to control KNX light actuators from HA.
That answers the blueprint related question. Thank you!
I will ask KNX integrator to add additional group address and specifically configure it for DPT 5 dimming.
Hi Matthias, I have a strange problem, my dimming not working on HA, but it working with Physical buttons. I am trying to monitor it on ETS, see the below image.
as you can see, the top two records which are using HA light brightness bar to trigger. it looks exactly the same as remain 3 records(I triggered by Physical buttons). But the strange thing is that only Physical buttons will be working.
The very strange thing is brightness status will sync between KNX brightness bar and HA brightness bar. It means brightness status always correct.
light:
- name: dinner_room_light
address: 0/0/7
state_address: 0/0/7
brightness_address: 0/1/9
brightness_state_address: 0/1/9
the config is very simple, I am trying to change state_address to 0/1/9, but it still won’t work.
any idea for this case? thank
Probably a problem with your topology. Search for how “filter tables” in line couplers / routers and ETS dummy’s work if you are using routing.
But I don’t know what this problem has to do with the blueprint this topic is about.
Thanks, Matthias. my problem is I cannot access routers. so I have to use knx-ip to bridge between knx system and HA system. I think you are right, it is the only way to access knx router.
In addition to the switch, please add the function of brightness and color temperature.
HOW TO ADD KNX - absolute dimming for zigbee lights
Brightness is supported - it’s the whole point of this blueprint.
For color temp, feel free to extend it to your needs. It should work by just copy&paste the brightness stuff.
Use a knx_event as trigger for an automation if you need Knx absolute dimming.
How to add the absolute dimming group address to your blueprint.