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?
The best way to switch would be to wait for Chris to merge the changes into master 
Otherwise, try a restart after the uninstall, and make sure the zigbee binding isn’t listed in your addons.cfg. But if you see two bindings again, just uninstall the one you don’t want.
Agreed - I hope to get this all merged today so I can start a major refactoring to split the bundles…
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…
2018-02-25 05:39:01.467 [DEBUG] [ystems.zigbee.internal.ZigBeeNodeServiceDiscoverer] - 7CE524000011F4D1: Node SVC Discovery already scheduled or running
2018-02-25 05:41:38.285 [DEBUG] [ystems.zigbee.internal.ZigBeeNodeServiceDiscoverer] - 7CE524000011F4D1: Node SVC Discovery running
2018-02-25 05:41:48.287 [DEBUG] [ystems.zigbee.internal.ZigBeeNodeServiceDiscoverer] - 7CE524000011F4D1: Node SVC Discovery ManagementLqiRequest response CommandResult [TIMEOUT]
2018-02-25 05:41:48.288 [DEBUG] [ystems.zigbee.internal.ZigBeeNodeServiceDiscoverer] - 7CE524000011F4D1: Node SVC Discovery request NEIGHBORS failed. Retry 328, wait 668100ms before retry.
… like maybe it hung during discovery. After restarting the binding, the bulb became responsive again. I doubt there’s anything worthwhile in it, but would you like the log?
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…
Hi @chris,
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.
Yes - I agree with this approach. At the time we discussed this I did try and find a conversion from CT to/from HSB but it seems it’s not so easy to do it consistently.
I think there does need to be a discussion about CT control so hopefully your other post kicks this off.
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’m going to grab the logs and create a ticket
Yes, but the build has been broken for the past few days and so it’s only been rebuilt a few hours ago. If the problem occurred last night then it would not have been with a new binding.
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.
Ok, but if you had the problems with the old version, then it’s probably not related to the new version - or am I missing something?
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: 2.3.0.201802261341
There’s no sign I can see of the device joining the network…
This is the contact sensor join from that log
2018-02-26 12:10:37.984 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - RX EZSP: EzspTrustCenterJoinHandler [newNodeId=58931, newNodeEui64=000D6F000B10DC62, status=EMBER_STANDARD_SECURITY_UNSECURED_JOIN, policyDecision=EMBER_USE_PRECONFIGURED_KEY, parentOfNewNodeId=38420]
2018-02-26 12:10:37.991 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX: EzspTrustCenterJoinHandler [newNodeId=58931, newNodeEui64=000D6F000B10DC62, status=EMBER_STANDARD_SECURITY_UNSECURED_JOIN, policyDecision=EMBER_USE_PRECONFIGURED_KEY, parentOfNewNodeId=38420]
2018-02-26 12:10:37.998 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - 000D6F000B10DC62: nodeStatusUpdate - node status is UNSECURED_JOIN, network address is 58931.
2018-02-26 12:10:38.004 [DEBUG] [e.ember.internal.ash.AshFrameHandler] - --> TX ASH frame: AshFrameAck [ackNum=2, notRdy=false]
2018-02-26 12:10:38.005 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - 000D6F000B10DC62: Node 58931 added to the network
2018-02-26 12:10:38.016 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - 000D6F000B10DC62: Discovery notification
2018-02-26 12:10:38.026 [DEBUG] [nal.ZigBeeNetworkStateSerializerImpl] - Saving ZigBee network state: Start.
2018-02-26 12:10:38.035 [INFO ] [bee.discovery.ZigBeeDiscoveryService] - 000D6F000B10DC62: Starting ZigBee device discovery
2018-02-26 12:10:38.049 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - 000D6F000B10DC62: Creating ZigBee device zigbee:device with bridge zigbee:coordinator_ember:8d67166e
What’s your point though? I thought the problem was with the power outlet?
I stated my problem above and in the ticket:
Ticket:
Subject :Zigbe Logs - cannot include ST Motion or Contact
Ok, but I wasn’t sure why you posted that little bit of the log. What point were you trying to make with that?