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?
because that log includes the attempt to join both the ST contact sensor and motion sensor, that little bit I posted was showing that the log contains the attempt to join the ST contact sensor.
Ok, I already saw this in the log. But please if you post part of a log, just tell me why so I’m not second guessing why you’re posting
Sorry, it made sense when I wrote it. I reverted back to 2.3.0.201802081624 and was able to get the motion & contact sensors added.
@chris: As I wrote via e-mail the latest addon still only worked with big latency (multiple minutes) when switching on/off lamps. Did you find out what’s causing this big latency in my network?
As I’ve said a few times in this thread and on email, there is a queue of traffic in large networks and I will likely need to add a transaction management layer to better handle this.
I have a number of things that I need to do with the binding at the moment, and this isn’t right at the top of the list (sorry). There are a few other things that I will try and add that will help, but please don’t expect this to be fixed immediately (again - sorry).
Hi,
I am faceing the same problem using 2 sensors from st (Motion Sensor and multipurpose sensor) can you please tell me how did you solve it ?
| zigbee_logicaltype | END_DEVICE |
|---|---|
| zigbee_powerlevel | FULL |
| modelId | motionv4 |
| zigbee_networkaddress | 53164 |
| zigbee_powersource | MAINS |
| zigbee_zclversion | 1 |
| zigbee_routes | [] |
| zigbee_lastupdate | 2018-03-12T09:56:56Z |
| vendor | SmartThings |
| zigbee_appversion | 27 |
| zigbee_powermode | RECEIVER_ON_IDLE |
| zigbee_permitjoining | true |
| zigbee_powersources | [MAINS] |
| zigbee_neighbors | [] |
| zigbee_devices | [] |
| zigbee_logicaltype | END_DEVICE |
|---|---|
| zigbee_powerlevel | FULL |
| modelId | multiv4 |
| zigbee_networkaddress | 39915 |
| zigbee_powersource | MAINS |
| zigbee_zclversion | 1 |
| zigbee_routes | [] |
| zigbee_lastupdate | 2018-03-12T09:55:47Z |
| vendor | SmartThings |
| zigbee_appversion | 27 |
| zigbee_permitjoining | true |
| zigbee_powermode | RECEIVER_ON_IDLE |
| zigbee_powersources | [MAINS] |
| zigbee_neighbors | [] |
| zigbee_devices | [] |
