Deconz: Change on Thing-Configuration "Transitiontime" has no effect on Colorlight when switching ON / OFF


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.

Well I can send ON/OFF to it, right but I cannot read ON/OFF from it as it has a HSB value…

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.

If you link the channel to a Switch item you should get the correct value. If this does not work, it’s a bug.

Nice! This works! I was not aware that this is possible. This makes a lot of things easier for me. Thank you!

But by using this switch the transitiontime configured in the item is still ignored…

Are you sure that you can see 1/10s?

Are you sure that you can see 1/10s?

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?

As @ebauuw explained in that issue: ignoring transitiontime for on/off is inherent to zigbee, so nothing openHAB (or deconz) can do.

You can of sent brightness=0% or brightness=100%. In that case the transitiontime should be used.

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.

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.

Please set the binding to TRACE logging and check what is actually send. If you see a bri=0 with a transitiontime=1 it should be used.

It appears to me that transtiontime is not set correctly, see codeblocks below. Going to fireup tcpdump too, to see the actuall HTTP request.

UID: deconz:extendedcolorlight:0f57d295db:001788010246779f0b
label: Medienzimmer - Decke I
thingTypeUID: deconz:extendedcolorlight
  transitiontime: 1
  id: "8"
bridgeUID: deconz:deconz:0f57d295db
13:18:30.388 [TRACE] [nz.internal.handler.LightThingHandler] - deconz:extendedcolorlight:0f57d295db:001788010246779f0b received LightMessage{hascolor=null, ctmax=null, ctmin=null, type=null, state=LightState{reachable=true, on=false, bri=254, alert='null', colormode='xy', effect='none', effectSpeed=null, hue=41190, sat=87, ct=153, xy=[0.3042, 0.3255], transitiontime=null}, e='changed', r='LIGHTS', t='event', id='8', manufacturername='', modelid='', name='', swversion='', ep='', uniqueid='00:17:88:01:02:46:77:9f-0b'}

That’s a telegram that was received from the deconz REST API. It’s expected that transitiontime is null, it’s only a command option, not a status.

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.

What does that mean, you sent theopenHAB Item an OFF command?

I mean:

  1. Linking the Color-Channel of the Thing to a Dimmer Item
  2. Using this Dimmer-Item and dragging the Dimmer knob to 0.

See image below. This is what I used based on the previous suggestion, that I should set the brightness to 0 as in:


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.

I’m not sure how we should change that.

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?

Yes, that’s a bug.