Since I’m still seeing my bulbs become unresponsive on the default 2.3 binding installed via PaperUI/Habmin, what would be the best way to switch to the Test 2.2 binding and avoid having 2 bindings running?
I had previously uninstalled 2.3, Stopped OH2 and then added the Test 2.2 to my Addons Folder. Is that the correct approach?
I’ve just noticed a bulb that was not responding, although the others in the room were still working. I don’t have a debug log from when it started, but have one now while trying to turn it ON/OFF. The only thing I see in the log, other than the ON/OFF commands, are some discovery messages…
Feel free to send it over. It’s probably not useful, but I’d just like to have a look at some of the other management frames that might be kicking around to see if there’s anything else that I could use to trigger off…
Last year, there was a discussion on Github whether it was appropriate to keep the “color mode” channel of certain lamps. It was decided for consistency’s sake, to leave it out.
Back then, I argued that it would be needed to know what the lamp’s actual state is. Because I now wanted to make a rule that acts upon a certain lamp’s state, I had to take another approach that works without the color mode channel. To avoid ambiguity, I decided to avoid operating lamps in color temperature mode, and convert all such commands into HSB commands. This way, the color channel would always provide an accurate state. I no longer need color mode, since I exclusively use a single mode.
I the following thread, I make the case for leaving the lamps in HSB mode, and converting all CT commands into HSB commands. It has some code how I currently convert it.
Wouldn’t it make sense for the binding to do this in stead? It could still expose a CT channel (for any color lamp), but only send out HSB/RGB commands to the lamps. Then, we would always have an accurate state in the color channel.
Of course, you will never be able to reflect a color state in a CT channel, so the CT channel should not be used for rule input in case of color lamps. So we only have to keep the HSB value accurate.
As an alternative way of keeping an accurate state, the binding could use the native CT channel, but additionally update the HSB state with an approximate value for the color temperature. So basically, do it the other way around. I found with the philips lamps that hue 45 and saturation 0-60% does the trick.
That way, the lamp shows the color temperature the way it’s maker intended, and people could still build rules that react to HSB updates exclusively. Even if in that case the HSB state wouldn’t exactly be true to what the lamp shows, for rules it would still be good enough. You could even “reserve” a certain hue, e.g. 45, to indicate that it is actually in color temperature mode. If anything commands 45 by HSB, send out a 44.
I’m not completely sure this is the “way its maker intended”. The protocol clearly has color (in different configurations) and CT (in kelvin). I think not having a CT channel isn’t really an option - I think it’s complex to define CT as HSB so for people who want warm light in the morning and cold at night, progressively changing during the day, CT is much easier and more understandable.
Often these bulbs have both color and when LEDs since an RGB bulb can not accurately represent white/CT. In ZWave, each LED is often controlled independantly where in ZigBee they are controlled through color and CT commands…
Personally I would keep both channels, but try and synchronise them so that if someone sets CT, then HSB is also updated (if possible) and vice-versa. It allows people then to use whatever they like.
Anyway, I don’t think this is really a discussion specific to ZigBee which is of course why you started a different thread
I meant, the binding operates the lamps as it currently does, using both modes as requested. But additionally, it would keep the state of HSB updated internally when in CT operation, even if the lamp itself doesn’t report HSB when in CT mode.
Vice-versa updates is not possible, you can’t reflect a saturated green in the CT channel. So one way from CT to HSB would be the way to go. Only thing that can be updated vice-versa would be plain white. One might also try to reflect saturation in the CT channel, to aid automation. But I am not sure whether that might be confusing in the UI.
The relevance to this binding is that it would be helpful if the binding allowed to get a reliable state info. After the “color mode” channel disappeared from the zigbee binding, this was no longer possible for lamps that use different color modes.
Chris, were these changes merged into master? I noticed last night that all of my devices went offline with a status of “node not found on network”. I grabbed the latest off of cloudbees this morning and am trying to rebuild but I seem to only be able to include the ST Outlets; my ST contact & motion sensors include but never finish initialization.
I grabbed the build a couple of hours ago. The problem that happened last night was with a build that was a couple of weeks old. Its been running stably until last night when it wasn’t. I thought I would update to the latest build but It looks like my ember stick & ST Motion/Contact sensors are now disagreeing.
I had a problem with the old version so I grabbed the new version. I removed and re-added the ST power outlets and that works well. I then tried adding ST Motion & Contact sensors but they won’t complete discovery
I’ve submitted a ticket with logs.
the binding version I started using today is: 220.127.116.11802261341