LIFX Built-in drivers - questions and discussion

I had that happen once, I let the app update the firmware then I factory reset the bulb. Then if you don't have the original apple home kit code (which does make setting up easier) just wait about 20 mins and the bulb will show up as it's own AP. Then use the lifx app to reset the bulb back up (note the serial number). Once it's set back up let the hubitat integration search for it again.

How can I manually add the bulb instead of waiting on the discovery process?

I meant to the lifx app. When you wait the 20 mins it will show as an AP, during the lifx app pairing process it can use that to bring it back in then once that's done use HE to rescan for it

Spent the weekend swapping out my kitchen lighting with the LIFX strips after being tempted by
all the rave reviews here. With a few strips now, including one that is 5 strips longs, I'm seeing crazy activity in the logs with all the child devices. I set them up on my dedicated LAN Hub. Is there any concern with all the child devices reporting state changes?

Nope... Every zone (up to 16 on one string) is reporting. You can turn off debug reporting if it's on but overall that's very normal.

1 Like

BTW driver for this is in the next release.

1 Like

@bcopeland - finally retired so I can now revert to being just busy. I will install everything in the new house that has 20 4-gang switches and 90 downlights and give it a try. Current cloud-based control is a bit annoying.

1 Like

Nice., Let me know if you have any issues.. It should work as is,. But you never know if there are little differences in the versions..

I added a 4-key switch and a number of downlights. The bulbs seem Ok, but I am confused by the switch behaviour. I set the switch names as Bed2Study0 through BedsStudy3, turned on logging and toggled the first (Bed2Study0) button on and off. The log seems to indicate that the state of all 4 buttons is set, and they are set to the same values when I select the key twice. I am toggling the first key using the mobile App, pressing the physical key does not generate log events.
Hope this makes sense!

@bcopeland - Learning HE starting with LIFX is not the easiest thing to do! I have a better feel for logging and debugging now but I think I am still missing something.
I have a 4 key switch with the first button called "Bed2_rear0, a bulb called "B1" and two basic rules that are "When Bed2_rear0 turns on, turn on B1" and "When Bed2_rear0 turns off, turn off B1". I enabled logging for the switch and the rules. My results are a little mixed and perhaps you could comment on the following.

  1. First, using the mobile app I can turn a key on and off and the action is logged. Using the physical switch button does not result in logging.
  2. If the key is configured to use a directly connected bulb (rather than an Internet driven bulb) then toggling the key via the mobile app fires the rules and B1 turns on and off. If the key is configured for Internet operation then the rules are not triggered using the app or the physical key.
  3. When I do move off the the Internet then I will just rely on rules - that is of course if toggling keys does give me events that can drive the rules.

So the current issue is how to configure the switches so that their state change is seen by the rules?

In this respect, LIFX switches are not the best for local automation Toggling the switch physically does not send anything to the hub, as the two are not paired - it does not broadcast the change. You could enable polling to update the hub with the current state, but this will incur delays in your automations (up to the length of the polling interval, if you "just missed it") waiting for the trigger.

The same can be said for the bulbs, but manual control of bulbs is less common. LIFX works great when the origin of control is Hubitat - but there are downsides when controlling from outside the hub. Zwave/ZigBee switches are better suited for manual control due to their direct pairing allowing for immediate state updates.

2 Likes

I would have assumed if you used the switch as a button controller vs directly pairing it, that would have hubitat poll the status of the device regardless of the protocol.

@dkilgore90 yes, that all makes sense. I understood that the default cloud mode of operation would introduce some latency issues but I thought I could live with that. A bigger issue is the possible loss of access to the servers either thru net outages or corporate issues. LIFX's parent (Buddy) has gone into Chapter 11 and while LIFX seems OK for now, that does worry me. The best solution is to implement some form of local control and I have been considering a few approaches.

  1. I looked at using Brilliant switches but I have read that there may still be a cloud dependency and in any case they don't seem to work with the 240VAC power we use in Australia.
  2. I have considered using a Wi-Fi to ZigBee bridge so that I can feed state changes straight to Hubitat. This seems a bit convoluted but it does overcome the polling issue. This link provides a starting point and for now I can live with the 32 channel limit.
    Setting up a Zigbee WiFi bridge using Tasmota and Sonoff hardware - Stuff Blog
  3. I could replace my LIFX switches with 4 gang ZigBee ones. A bit expensive and I would also need to add 10-15 Tasmota-ized Sonoff Minis to handle the dumb bulbs that are currently handled by the direct LIFX switch outputs. I am not sure that this is as straightforward as it sounds but I could start with one switch and find out!
  4. I could use some custom code and Home Assistant but that would most likely end up being a maintenance nightmare.
  5. Some other solution?

Thanks for your input, as you pointed out ,polling isn't practical as you would end up with unacceptable latency. Also, the LIFX switch doesn't support dimming and timed functions so it's not the best starting point. It will be fun finding the 'right' solution!!

@rlithgow1 I am pretty new to Hubitat so I don't have a good feel for how much load polling 20 4-gang switches would require. Perhaps dedicating a C7 to this might be ok? I had considered using a RPi to do this so that I could handle dimming and other functions and pass events across to the C7's.

Not sure if you resolved this - but I will add some more details on bptworld reply.

To resolve this, I created a group with all Child Devices of an LED which I use as a dimmer.

It works to dim the LED, though you can see it's heavy on Hubitat the network

Yes, I understand the issue now. In order to update from one of the child devices I need to poll and doing that at a rate that provides an acceptable latency will overload the C7. I might be ok for a few devices but I have 20 switches and hence 80 keys to poll.
This weeks 3.60 firmware update appears to add some additional LAN functionality so I am going to look into that.

1 Like

@bcopeland -- resuming development on expanded LIFX drivers, first focus is on MultiZone.

I have

cmds.add(new hubitat.lifx.commands.SetMultiZoneEffect(instanceId: 4824828, type: effectType, speed: 5, duration: duration))

-- no matter what value I specify for duration (have tried -1, Long.MAX_VALUE, and 5000, I get this error:

java.lang.UnsupportedOperationException: Cannot use rightShift() on this number type: java.math.BigInteger with value: 18374686479671623680 on line 381 (method setEffect)

Am I providing the duration input incorrectly? Appreciate any insight, variable types are not my strong suit.

@argyrou @j.koss2 Not to toot my own horn (at least not too loud), would suggest you check out the new "Enhanced" driver for multizone that I just published: [BETA] LIFX Enhanced Drivers

This utilizes the current state of each zone and the SetExtendedColorZones packet to adjust the level of each zone without changing the other values for hue, saturation, or kelvin.

2 Likes

Looks great. Having resolved the first issue, the popcorn effect on Strips is something that annoys me a bit every time, so I will give it a try next time I have a LIFX Strips day! :slight_smile:

Thank you! I've added your driver (and configured), but after some initial tests, it appears to still change the color each time, even after manual polling. After reviewing your code, I don't believe it is that, but I intend to go through the logs and find out why. I'll follow up here if I find anything.