Yes, no yaml needed.
I must have misunderstood that sentence.
Yes, no yaml needed.
I must have misunderstood that sentence.
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!
The KNX dim up / dim down commands are to fast for Philips Hue. Thatâs why a long button push setâs a fix value.
If you want another value than 50% you can configure it in the automation.
With this approach you are using knx push buttons as input to control hue lights over an automation.
All good, nothing bad happens
PS: I woudnât plan my whole house with this approch neighter, but it is very usefull to integrate some decorative lights.
I wanted to setup dimming via my Gira switches but found that this automation does not what I expected.
I configured my switches to keep sending the relative dimming telegrams while I press the switch button.
This automation did not take this into account and just dimmed by a fixed value over time.
I therefore created a fork that handles the individual dimming messages for 12.5, 25 and 50% and adjusts the percentage of the brightness directly.
Hope this helps others: KNX - relative dimming for lights blueprint · GitHub