I'll be submitting this for the next build.. Auto driver detection will be a bit harder, I'll have to figure out which device models require the legacy driver vs the normal..
@bcopeland Great! I've found one issue with this driver from a bit of testing - the "set Color Temperature" Command does not appear to work
@bcopeland actually let me clarify that statement - the set color temperature command does work in the sense that it will change the color temperature to whatever you set it to - however the "level" parameter of this command does not work. So if the lights are at level 0 (i.e. off) and you set color temperature to 3500, level 30, transition time 1 second... it wont come on
Ahh.. I know what that is .. Fix coming
1 Like
@bcopeland sorry, let me clarify this further. If the lifx bulb is off and the set color temperature command is fired - even if as part of this command the level is set... the light will not turn on. However if the light is already on and at a level greater than 0 then the command works including the level parameter. Hope that this makes sense!
I just updated it.. try the new version
That definitely helped. Thanks! Let us know if you are able to figure the type of bulb out automatically.
From a cursory review of this driver, compared with debug logs from the existing Color driver... Is the only difference the use of SetPower instead of SetLightPower (which allows a duration param)?
I noticed the flashOn and flashOff functions still use the latter (haven't tested to see if those work)...
1 Like
Yes
Oops.. That would be in error.. Good catch, I’ll fix that..
2 Likes
Fixed
1 Like
Ok, switched my problem bulbs to the "Legacy" driver, and they now physically respond with only one on/off command. However, one bulb doesn't always show the correct switch state on the device details.
Debug logs, turning on:
dev:13682021-12-04 08:26:28.446 pm debugLightState(hue: 19456, saturation: 65535, brightness: 65535, kelvin: 3500, power: 65535, label: Front Windows)
dev:13682021-12-04 08:26:28.439 pm debugparse:lifx device: D073D5255A020000, command: 107, payload: 004CFFFFFFFFAC0D0000FFFF46726F6E742057696E646F7773000000000000000000000000000000000000000000000000000000, isBroadcast: false
dev:13682021-12-04 08:26:27.442 pm infoFront Windows switch is off
dev:13682021-12-04 08:26:27.434 pm debugStatePower(level: 0)
dev:13682021-12-04 08:26:27.429 pm debugparse:lifx device: D073D5255A020000, command: 22, payload: 0000, isBroadcast: false
dev:13682021-12-04 08:26:27.385 pm debugon()
As noted "may occur" in the LAN protocol documentation from LIFX, the response packet (StatePower) shows the previous state, not the new one. The follow-up privateRefresh gets the correct power level in the response, but there is no handling of this attribute in the lifxEvent() function for LightState, so it is not updated.
1 Like
Updated again..
Here's a possible bug. At minimum odd behavior, but workaround/fix was easy.
Simplified reproduction steps (Lifx Z strip - model 32, didnt bother testing with a model31):
- Set the parent strip device to some color. (i originally discovered this with scenes with the child zones)
- Create a button device with an actions of:
set color temperature 4500, 100% on the parent device, 0 delay (whole strip)
cancel delayed actions
- Push the button for the button device
What happens:
Light stays the color (if using zones it briefly goes white before going back to a color). The whole strip goes to the color of the first zone i believe.
The culprit appears to be the cancel delayed actions call
The work around:
Change the button device to do the cancel delayed actions first then set color temperature
Are LIFX Tiles currently supported? If so, could someone advise how I make it 'morph' or any of the other ways to generate multiple colors simultaneously on a Tile?
I added a couple Tile initially with the LIFX Color driver but switched one to the LIFX Strip because the Tile seems more analogous to the strip vs. an A19 or Mini C. However, I don't see where a component child has been created so the Tile is all or nothing. Though I will note that the LIFX Strip driver's speed and color accuracy on the Tile is much better than the LIFX Color driver delivers for the Tile (based on extremely limited playing around).
There is no specific built-in driver implemented (yet) for the Tile, or other matrix-style devices (like the candle color bulb). Even for the strip, the firmware-based effects are not implemented in the driver.
That said, since all of the LIFX packets have been implemented as classes, creating such a driver should be pretty straightforward, if someone had the inclination to do so.
2 Likes
Is there a way to get the "comms state"? Currently, none of the device data seems to change when it goes offline. I want to setup an automation to cycle the power to the LIFX strip when Hubitat doesn't hear from it for 20 minutes. I've checked the values of Status, Link quality, and signal strength. But they just take whatever the last value was when it was connected.
I also want to add that renaming the device doesn't rename the zones (for the strips).
Just updated to 2.3.0.118 and I'm wondering if I should switch my Lifx devices to use the Lifx Legacy driver. I have Lifx Color 1000 bulbs. They seem to be working okay. What's different about the legacy driver?
Some of us were having trouble with older bulbs turning on/off with a single command... So Brian made this change. That said, I never had this trouble with Rob's lifxcode drivers/app, which I double-checked - it used the same SetLightPower packet...
I have an inquiry in to LIFX support about any restrictions or limitations of this packet... Will post here once they have completed their investigation
2 Likes
Mainly for on/off issues with older bulbs.. If you aren’t having any issues, then no need to switch..
1 Like
