I experience difficulties in certain situations when using the otherwise great Deconz addon.
I have a good number of Philipps Hue E27 Color bulbs that I have plugged in via deconz. If I switch the lamp on or off, for example via the sitemap in the app (with ^ v), this takes about a second in which the lamp dims up or down.
This is not the desired behavior from my point of view. Therefore, I would expect that if I set the transitiontime in the thing to 1 (1/10 sec), this time of dimming is minimized.
But this is not the case.
The transitiontime parameter seems to have no influence.
If you call the API of deconz directly it is quite possible to switch the lamp directly on or off without dimming.
So I wonder why I can’t get this to work with the DECONZ binding.
Speaking of it: Why do colorlight not have an onoff channel if there is the on:true/false value in the deconz-api?
Doesn’t need one. You can send ON/OFF commands to an openHAB Color type Item.
What the binding does with those commands, and if treats them differently from say brightness command 0, is up to the binding.
What commands are you actually sending from UI ? Look in your events.log if unsure.
Something easy as this wont work, i need an extra script parsing the HSB value. This wont be needed if it had an on/off channel. But never mind, I found another solution, utilzing deconz lightgroups which have “any on” / “all on” read only states, which even works better for me, using scenes even clears my transition issue as the transition time is then defined at deconz and not via the imho broken binding.
So “works for me” but I’m willing to elaborate and disscuss the issue I see with the transition time, as think this is a general probelm. Are the binings maintained by the project or by individuals? I’d like to chat with the authors of the deconz binding.
I’m sorry if I was missleading:
Let me clarify: The current transitiontime is for sure way grater then 1/10 sec, like a second or such, I can see that.
I want it down to 0/10sec or 1/10sec, using the parameter indicated above, but it does not work.
I’m pretty sure this has to do with this.
The deconz api does not use transitiontime parameter, when the on parameter is given whitout the bri one. But when switching on an lamp the openHAB deconz-Binding does only send on and transitiontime which doesnt work. Is this possible or am I barking up the wrong tree?
Okay I get it now. A bit unintuitve, but relateable. Thanks for the Input!
Its just a bit frusttrating seeing that transitiontime parameter in OH having no effect without explaination.
Edit:
As linking a Dimmer-Channel and setting the brightness still does not use the transition time for me, the only workaround I can recommend to users having the same issue, is to use lightgroups in deconz, define the ON and OFF scenes and set the scenes transition time to 0. Then activate them by using the Recall Scene Channel.
Ok, then I am to stupid to set the logging to show raw HTTP traffic. Nevermind, sorry on that:
However, I fired up tcpdump and sniffed on my wire.
My observations:
Turning on using dimmer item: The transitiontime value is “10” on the wire dispite my item setting.
Turning off using dimmer item: The transitiontime is not even set, instead on=false is transmitted, resulting in default transitiontime.
I’m not allowed to upload .pcap-files. Therefore here are screenshots.
After looking in the code I remember that this was changed on request in the past. The problem is, that 0% is equal to OFF in openhab and everything above 0% is ON.
This is not the case in deconz (and zigbee). ON/OFF and brightness are independent. That’s generally a good idea, because you can switch a light with brightness 50% OFF and the device remembers that value for the next ON.
What is modelled in openHAB is
OnOffType → on = true/false
PercentType → bri = (value), then on = bri > 0
The on in the second part is necessary, because otherwise a “50 %” command would not turn the device on again. If I remember correctly setting a bri=0 does not turn of the lamp but only sets it to the lowest possible brightness, which is 5% for some devices, so sending on=false is necessary to really turn it off. The result would be that you can’t turn the device off with a slider, which seems counter-intuitive, too.
What you describe makes sense.
Is there some reason openHAB ON OFF commands can’t be treated differently though? You can send a direct ‘off’ to deconz without simulating a 0%brightness instruction, and deconz would action without ramping?
The problem is not the ON/OFF command, it’s the PercentType command.
If you link a Dimmer item to the channel (let’s make it a bit easier and assume it’s a brightness channel, the problem is the same), you can’t turn the device off, because if you drag the slider to the left, you send a 0 % command. You would need to add a second item (or at least a second UI widget) to the same channel. If the light is off, dragging the slider to 50% would not turn it on, you would need to send that via the second control.
Ramping is only possible for brightness commands, not for on/off commands, so to get it right, it would be necessary to first send bri=0, transitiontime=x, wait until we receive a state report with that value and then send on=false.
It’s more difficult in the other direction: if the state stored in the light (in deconz) is OFF/80% and you drag the slider to 50%, you expect the light to ramp from 0 to 50%. As long as the light is off, sending bri commands is not allowed, so you have to either set the value to 50% and send on along with that (what we do now, bri=50, on=true, transitiontime=x which probably will ignore the transitiontime) or you send on=true first, then bri=50, transitiontime=x. But the on=true will turn the device to 80%, so the ramp would be 80% to 50%, which is not a good choice either.
For switching lights off i really get why there is the need to use the on=false way of doing so. Yet, the transition time is wrong in my wireshark screenshots, on the wire I see transitiontime=10 while I have the thing configured to 1. Any ideas on that?
