I recently picked up a zigbee controller for LED strips. It worked immediately with OpenHAB however it runs afoul of this UI bug and is essentially unusable because of it: https://github.com/openhab/openhab-webui/issues/1268.
Are there any alternative similar controllers that anyone here would recommend? I’m looking for one that supports R/B/G channels, I don’t need temperature or other channels. Nor do I have any particular voltage input or wattage requirements but something similar to my existing device would be great.
If you are willing to go z-wave, have the Zooz Zen31 controller which was very easy to install and they’ve got great support. The Zooz thing does support R/G/B channels. Because of the UI widget bug you mentioned, I tried using these channels instead and that works just fine. A list of channels is below.
BTW, I suspect that because this same UI bug was recently fixed in the dimmer widget, it is likely to be fixed in an update soon.
I came across that one (which simply looks like a better product than the one I linked) however it is the same product linked in the thread in the github issue where the original problem was reported. I’ve had the issue come and go so I’m not sure. And to be clear - it would only occur if you’re using a rgb picker/slider widget and have the widget on-screen somewhere.
That issue was fixed by comparing values the server sends to the UI and, if they match exactly, not sending an update back to the server. This new issue is different - the server sends intermittent states or inbetween values as the device smoothly transitions from one value to the next.
That fix assumes that the server only sends updates to the UI that exactly match the end value, but that assumption is not true per this problem. It seems to me a design with that assumption built in is going to need serious changes for a fix to be possible.
Check out the opensource project called WLED you can make your own or there is a store selling ready to use boards with screw terminals if you can’t solder and prefer to do it that way. Very active project and works great.
Ummm - looking at this bug, the problem is with the colour-picker in the UI, so it will impact not only ZigBee devices, but others as well. It therefore seems the best option would be to get the UI fixed and avoid buying more devices impacted in the same way…
I’m not so sure about that. The specific aspect of my current device that aggravates this bug is the fading process; I described this in the original post. A device without this behavior should work correctly.
Well, the bug is raised on the UI, so I’m assuming it’s therefore relevant to other similar devices.
I’m not sure if you mean the first post above, or another thread, but you don’t describe the issue here - you just reference to the UI bug.
The UI bug does seem to be related to the fading, so possibly you can change this behaviour in the device you have already purchased? The zigbee binding allows you to configure the fade rate so possibly it can be adjusted to avoid the problem?
If I remember correctly, the command sent to the device also sets the speed at which the change happens, so this is a binding setting.
Have you checked to see if you have this setting on the colour channel? I’m pretty sure it will be there - it’s called “Default Transition Time” and it should be available for all colour channels and doesn’t depend on the device.
I haven’t looked at this but I’ve reached out to the manufacturer, they were quite sure it can’t be adjusted. They responded in literally 7 minutes while I was still troubleshooting, which was nice lol. I can also see the commands sent to the device in OpenHAB’s debug log and they contain only 3 numbers, which are the HSL or HSV values:
I don’t own any zigbee devices with on-device tunable settings, but I own a couple z-wave devices with such. There aren’t any adjustable options surfaced in OpenHAB’s UI where I would expect them to be for this device, if it had any.
Strange as the speed/duration at which a transition occurs is part of the command - it is not an adjustment that is made in the device itself, but is commanded over Zigbee every time the colour etc is changed.
But here you are not looking at the right information at all. This is just the HSV color command. What is sent to the device is not this. You would need to enable zigbee debug logging to see this, but it will contain the Transition Time. This is a configuration on the channel itself and you can therefore only adjust it in the configuration UI (ie MainUI).
They will be there in the channel configuration - it’s not part of the device configuration.
Of course, the device firmware may completely ignore the information sent by the binding, so it may still not work, but it is worth trying since the binding allows you to change this.
Ah that’s good to know, this will definitely help in future debugging.
I see, thanks for pointing that out. I found the channel config screen for the device’s color channel and it does have a “Default Transition Time” option, though it is at 0 currently.
Edit: on second thought, it does seem to do something. I set it to 10,000 (without reading that the unit is 100ms intervals ) and it definitely made the transition very slow. I’ll play with it.
) and it definitely made the transition very slow. I’ll play with it.