LIFX Local Control


#21

I'm still not sure why it sometimes takes two attempts to find some devices, there's very little consistency in what works and what doesn't, which is strange since actually controlling the devices seems to work more than 99.99% of the time.

Tile may take some time, definitely a complex device, but the latest version does let you turn it on and off :slight_smile:

I'm hoping the strip will work the same as the beam (which currently can only be turned on and off), so they should only need the LIFX Multizone DTH. I only got my Beam this week so that's the next on the list.


#22

This is great! thanks @rob!!

Quick question: I can see that the app is able to see the groups.. obviously we can always make a new group device in Hubitat.. but is there a possibility of a Group Device type for LIFX?


#23

Yes, there is, I just need to work out how to build it. It's been on my list for a while now, and possibly also one for locations.

Although there was a hint from one of the LIFX engineers that it may be possible at some point to allow a device to be in more than one group, which would be very handy. I guess it depends on how much memory is free in the devices themselves. I don't think there was any timeframe given for it though.


#24

Great - thanks for all your hard work on this.. Having LIFX local control has been on my wish list for years!!

another thing to add to your roadmap: it would be great to be able to set a transition period for all changes.. not just colour map.

Thanks again


#25

I'm also considering a proxy device, which would delegate to the real device. The idea being that you'd reference the proxy in your rules etc. and discovery wouldn't wipe out the proxies - this would also allow for IP address changes and substituting in a replacement bulb in case one broke.

This could be done with virtual devices I guess, but I'm not sure how that would work with e.g. Tile


#26

All my LIFX bulbs have a static address on my network and I'd recommend that people do that if they can because I've found it helps a lot with their stability


#27

It's been a bit of a slog, but it's working fairly well.

The default colour map transition time preference actually now applies to all transitions where a duration isn't specified. I should probably change the wording :slight_smile:


#28

Great!

How are you finding the speed of this? - for e.g. it seems a little sporadic currently. If I hit on/off the light will respond anywhere from instantaneously to 5 seconds, when using as part of a group they all turn on at different times.


#29

I find that for a single device it's virtually instantaneous 100% of the time so far, but you're right about multiple devices. Not sure if I can do much about that, there's a lot going on in the background.

It would be nice to have a high resolution timer available to work out how long it takes to build a packet. Then I could perhaps see if it's worth caching the packets for a given command and payload rather than rebuilding them every time.


#30

I'm sure there must be something undocumented that happens with the HTTP API to allow a group to be treated as one device.


#31

It's possible that UDP packets are occasionally being lost I suppose. I request an acknowledgement for each packet that modifies state, if another packet is sent (such as polling for the state of the device) before the ack is received then it will attempt to resend the previous packet just once. But I would expect that to take potentially up to a minute, rather than just 5 seconds.


#32

seems like a good idea for the roadmap!


#33

I'd recommend holding off until tomorrow at least - I've made some changes to the discovery process, it now discovers all my devices in the first pass, over 95% of the time. I need to make a few more tweaks, but it seems pretty solid - going to try it on my new spare hub tomorrow though (and make sure that it works when you have two hubs as well).


#34

Okay, the github repo is updated with better discovery, and a new LIFX White driver in addition to the LIFX White Mono driver.


Planning my move from smartthings
#35

And a quick fix for bad parsing of the colour map (including the colour temperature). Should only require an update of the LIFX Master app


#36

Rob, I'm in your debt. Thank you so much for creating and maintaining this control!


#37

I'm hoping to be able to get the multizone driver working this weekend, but no promises.


#38

Rob, do you know if it's possible to activate LIFX scenes using Hubitat?

Currently I'm using a Samsung SmartThings button to control 4 lights in my family room. Push sets the lights to 70% brightness and color temp 2000. Double-push sets them to 0% brightness (essentially turns them off). Holding the button sets the lights to 100% brightness and color temp 3500. The problem is that whenever I perform any of these actions, it cycles through each light first to set the brightness for each light and then again to set the color temp for each light. This results in a weird "musical chairs" effect. However, when I'm using Google Home I can simply tell it to activate a specific LIFX scene, which sets the brightness and color temps for all 4 lights all at once. <wishing, dreaming> :slightly_smiling_face:


#39

The same thing applies when using the LIFX Skill on the Amazon Echo.

You can use SetColor with [level:100, saturation:0, kelvin: 3500] - use a custom command in Rule Machine to do that. It will only apply to one bulb at a time, but will set all the parameters in one action.


#40

Thanks, Rob. This is my first time using custom commands, and I must be doing something wrong because I can't get setColor to work correctly. I'm assuming it should be that parameter 1 is type string and the value is "level:100, saturation:0, kelvin: 3500". Am I doing something wrong?

BTW, all other searches on the setColor command has been fruitless.