After successfully pairing the LED controller with my zigbee-network I got 2 Channels offered in the UI
one for the color temperature (displayed as a dimmer control)
one for the color itself (should be displayed as a color control)
The dimmer for the color temperature works (except, the value 0 is warm white and 100 is cold white and not the other way round as it is stated in the description).
If I change the control type to “Dimmer”, I am able to dim the (white) light and so turn in on and off.
But I am not able to control an color.
I already searched this forum a lot, but dind’t find any hint what the problem could be or what I am doing wrong.
What I already tested :
I multiple times added and removed the controller to the zigbee network.
I completely removed all zigbee deviced (including the coordinator and the complete binding)
I stopped openhab, cleaned caches and rebooted the raspberry
nothing relly helps.
I have the same problem with a Tint color bulb. There I also get offered 2 Channels (Color Temperature and Color). And the problems seem the same.
I have tested the Tint bulb a long time ago and it worked ok, but maybe something changed. That said, I’m pretty sure that colour control is working or a lot more people would probably be commenting
I’m not an expert on openhab. could you please tell me exacly which logs you mean and what entries I should look for ?
In the openhab.log there is nothing to see when I change the control from Dimmer to Color (or the other way round).
In the events log there is only one line stating that the item was updated.
By the way I already had the Tint bulb working in openhab 2,5,and 3.0 (where I used a self flashed TI cc2531 coordinator. But I cannot get it to work in OH 3.1 at all any more.
Please take a look at the zigbee binding docs - at the bottom of the page is a description of what you need to enable to get logging running. If you’ve not read the docs, I would suggest to start with this
Well, I don’t think there has been any change in the binding between OH3.0 and OH3.1 that would influence color control, so if it worked in OH3, then probably it should still work.
I enabled the zigbee logs as described in the documentation
Just for explanation what you will find in the logs :
I added the Tint Color Bulb to my network.
As I wrote above I have the same problem with it, that the Color control does not work or better display the three sliders.
So this was the case here too. so I changed the control-type to Dimmer and then was able to dim the light. Color Temp was working fine.
I set the color temperature and (after changing Color control to Dimmer) dimmed the light.
I already opend the log in the online logviewer, but I still have no idea what my problem could be.
Here is the logfile. openhab.log (813.0 KB)
I think your problem is somewhere in the UI. I’m not really sure exactly what you’re doing, but there are no colour settng commands in this log. From the binding perspective, from a quick look, it looks fine. The configuration seems to go fine - including for the colour channel, and the colour is read back from the device ok.
Colour temperature looks to be working fine, and the colour channel commands that are received (which is just the dimmer and on.off) also seem ok, but as there are no colour commands, the colour does not get set.
So that you know what to look for, see the following bit of the log -:
This shows PercentType commands for the colour channel - so this is just a dimmer. If you send a color command, then it should do something different. You can see though that this all looks fine, but I can’t see any colour commands in the log (I might have missed one somewhere of course, but everything I saw was either a Dimmer or OnOff).
Thanks for your analysis. And it seems you are right. There is a color “sent” command missing and the so the color control stas uninitialized.
I simulated that and initialized the both color controls with a “sendCommand”.
After that I got the color controls displayed correctly and I am now able to set the colors using the UI.
So as a result I created a rule that will run after startup of openhab to initialize all my zigbee color controls to workaround the problem.
Strange that I seem to be the only one to have such a problem
Again thanks for the hint in the right direction.
One strange thing I have now (but only with Tint Color Bulb) is, that after I once set the color temperature of the bulb, the color control again get uninitialized and I am not able to set a color again.
State UNDEF is likely set by the binding when it fails to process some value, or communications failure etc. (Items are otherwise born as NULL, so something did it, and there isn’t much else apart from a deliberate rule action.)
So there appears to be some problem with your devices reporting status to openHAB. I’ll guess color encoding mode?
I don’t understand what this is doing or what it is initialising. As we saw from the log, the item is definately being initialised (well, I should say that the channel is being updated - the binding doesn’t directly know anything about items).
Below you can see this being initialised from the log you provided above -:
Without seeing a log I’m afraid I can’t really help.
Can you advise where this is handled please? I don’t think the binding will do this at all if that’s what you mean?
Can you please provide a reference to the log that shows this as I can’t see this myself - I’m not always looking at the same place, or looking for specific stuff, so I can miss things I’d like to understand what the encoding issue is though as the logs I’ve seen looks ok
So the binding DOES understand the value - it is updating the state, and it is processing commands. Something else in the system seems to prevent the colour commands from being sent to the binding. I want to understand the issue @rossko57 mentions above with the invalid colour mode though and will take a look at those logs to check this.
He’s just giving his Color Items some initial non-NULL, non-UNDEF state so as to overcome a UI limitation that the color picker widget doesn’t work without a valid start state.
That then allows him to send commands.
The underlying issue is that no valid state is supplied from the device.
Nope, I know nothing about the workings of this binding. Other bindings can elect to update channels with UNDEF state, if for example they have some incalculable or out-of-bounds value to deal with.
Attempting a non-sensible state update like ‘Elephant’ for a Switch or ‘0,0,101’ for a Color just gets ignored and logs a WARN, does not result in UNDEF
Apart from a rule explicitly postUpdating UNDEF, there are few (none?) other ways to get an UNDEF state into a non-Group Item. Hence my guess where it comes from.
And lo, there it is in the log at 11.48.21.720
It seems to follow some on-off rx message
But this does appear to be during initialisation, so could be a normal-ish event during startup or discovery…
The real thing that’s missing is a color update in normal use.
Ok, thanks, so I guess that this is a bug in the UI? Surely even if the state is unknown, the UI should allow the state to be controlled - otherwise how does a device get controlled. The binding is not required to set the state on startup, and it may or may not happen (depending on the binding, and the device).
I don’t think so. Firstly, as far as I can see, the binding is definitely setting the state - this is clear from the logs. Secondly, even if the state was undefined, the UI should still allow it to be set. So I don’t really agree that the underlying issue is the state isn’t set - more that the UI doesn’t seem to allow the state to be changed if the state isn’t set (and why it’s not set is another mystery as the binding is definitely doing that).
Ok, maybe I misunderstood - sorry.
Well spotted. I will take a look. At a first glance it looks like the “alive timer” is timing out during initialisation.
What do you mean? The colour will be updated if the device sends a colour update. It will also be updated after a poll, but this is much much slower.
Sorry to repeat, but in my mind, the major issue here is that the UI should allow a command to be sent even if the device is in UNDEF state. It seems to allow this for switch and dimmer types - just not colour types (@ysc what do you think?).
Pedantry - the UI (well this color picker widget) doesn’t allow commands to be sent etc.
Maybe I’ve misunderstood that no further color updates come from the device after the initial state has been trampled by that UNDEF. I’d assumed Autoupdate could be masking that, but if they’re there, that’s fine.
We shouldn’t lose sight of this bit though -
but maybe that is the correct response when ‘real’ colour is applied, a kind of either-or mode.
I’m not sure - where did you read this or are you making this assumption? For me, I’ve not seen this anywhere and there is absolutely nothing to prevent the binding setting the state if it receives an update. Please provide a log showing that states are not being correctly passed through if this is the case so I can chase this issue.
This is noraml. If the device reports that color mode is “colour” then colour temperature will be set to UNDEF. It’s not related to the command, but the state of the device.
Ok, so this is correct. The device reported that at this time it is in colour temperature mode, so the colour is set to undefined.
The only issue I think is that the UI does not allow the colour to be set when the colour state is currently undefined. To me, this seems wrong in the UI.
.