Somehow I miss the part how to define the relative dimming address in the configuration.yaml. The entity KNX light supports only DPT5 not 3. Could you provide an example?
This is a blueprint for controlling non-knx HA light entities from Knx buttons.
No Knx light entities should be involved.
Thatās what Iām trying to do, but thereās this relative dimming address that Iām assigning to a KNX button and that should be used in the template. So I donāt need to declare this address in the configuration file? Just use it in the automation?
Yes, no yaml needed.
I must have misunderstood that sentence.
1 Like
Hi, I really like your blueprint and it is working great with my ikea tradfri light.
I use the MDT Glastaster 2 for controlling the light and would like to control the color too. The switch offers a way to change the color, but it uses HSV and the DPT 3.007 dimming step. Do you know a way to integrate this into your blueprint?
Thanks a lot
Hi 
!
I think your best bet is to copy / fork the blueprint and extend it. I do not plan to add more features to it right now.
It was originally meant to be a showcase how the knx integrations services can be used 
For me this blueprint wont work. It only dims one or 2 percent and then aborts the dimming process like the others described. Im using MDT Tas55 and GT2. I think the problem is the feedback. If we can read out the brightness before dimming and count it up or down by ourself without waiting for the return state of the lights entity it should work, like the owner of the Hue integration suggested. I will try it but Yaml is totaly new to me. I think thats also the way how some other vendors implemented relative dimming.
Not sure what you mean by that. This blueprint doesnāt wait for any return.
Iām successfully using it with Hue, but not with the default step count - Hue seems to have problems processing too many service calls per second. (I use 5 sec 5 steps currently).
Where did marcelveldt say that? Do you have a link?
Dont know if i understand it correct but it seems that sending absolut percentage should be better or am i mistaken? But to do this, the start brightness should be read out first and after that al dimming steps (initial_brightness - step_pct) should be calculated with the initial value.
Youāll need to test that.
I could imagine that the sent value drifts away from the actual value then. Eg. You start at 100% and dimm down. Each step -5%. If the light doesnāt dimm as fast as you send new values (eg. because it adds system dimm time) when you release the button after 15 steps, but the actual brightness is just 50%, it will still dimm all the way down to 25% - because that was the last received value.
Hi, am a fan of this blueprint and use it in a couple of places already. I would like to surpress that the dimming (up or down) powers on or powers off the light. In other words, when the lights are off, a long press of the button should not power on the light from. And, vice versa when the light is already on and dimmed all the way down, it should not power off the light. Which is what happens at the moment and makes the KNX / ZigBee combination behave different than the rest of the lights in my home.
Is there a chance for a flag that ignores dimming when light is otherwise off and when itās about to be powered off? I hope I made myself clearā¦
Thanks in advance!
Hi !
I donāt plan to add any features to this blueprint. Feel free to fork it and add things you need.
Maybe also have a look at one of the more recent forks here: Advanced control of any light entity from KNX (state,brightness,dim,color + states feedback)
I updated my code with an option to prevent the light to switch off when reaching the minimum dimming level. I am not at home at the moment so I was not able to test it, let me know in the dedicated subject if you face problems.
Hi there,
just one, maybe stupid, question:
I want to integrate my existing knx dim lights ( more accurate lights attached to mdt knx dim actuator) in home assitant.
All the lights have been setup using relative dimming.
Can I use this blueprint or better not?
Any Knx dimming actuator I have seen supports not only relative, but also absolute dimming objects. You should use those.
This blueprint does not send Knx relative dimming commands. It only receives and acts on them.
Hello farmio,
thank you for your explanation,
I will have a look into my knx programming and will have a Test whether I like the absolut dimming or not. Right now the relative dimming works quite smooth and I like that.
From what Iāve gathered the knx ultimate for node red should be able to handle relative dimming both for knx and Hue lights.
You can always use both. Relative dimming is for holding push buttons on wall switches. Not for setting specific dim values.
Hey @farmio , I am using a modified version of your blueprint from another webpage here:
I have mdt switches and am addressing hue lights. Switching on works. Switching off works. Pressing the off button long will set the light to approximately 50%ā¦ do you by chance have any idea why this is happening?
Thanks 
This is not a modified version of my blueprint.
It instructs to create a Knx light entity for a non-Knx light. I would never recommend that.
Noted.
I ceased using that, too Did not work, and I found Massimoās integration with Nodered. Thanks for the clarification!