As a recent refugee from SmartThings frustration-land I have gotten more and better automation set up in a couple hours with Hubitat than I ever did with ST. Major props to the Hubitat creators!
The only thing missing from the default device support from my point of view is Lifx. These lights are pretty popular and I have a bunch, are they planned to be supported devices in the future?
For now I've found the Lifx group of groups community driver but it is less than idea in that it only controls lifx groups instead of individual lights and uses the lifx cloud connection. If it isn't planned to be supported in the near future perhaps I will take a stab at a local lifx driver if I can find the time =)
You can add the bulbs to a group to get around this limitation. Far from ideal like you said, but it should work.
You will make a lot of people happy if you can accomplish this. I might even pull my Lifx bulbs out the the HA graveyard I just put them in this weekend, if you do.
LIFX is actually capable of local control, and the team has previously expressed a desire to get it going at some point. You can also voice your support over here: LIFX Local Control
Lifx is UDP on port 56700 and back in September, @patrick was willing to converse. Pre-Pre code, etc. In other words, development will be a "spiral towards completion."
Lifx a big thing to bite off and I'm certain that's why there's no 100% local implementation, BUT the hub can do it. Seems to be chicken and egg though. Someone has to build out some prototype code, and then work with Patrick to get it working. then build on that... rinse, repeat.
Usual disclamer.. I may not know what I'm talking about, given all my "facts" are statements from here in the forum.
I'm thinking Hubitat doesn't have a local implementation because it's low on the priority list of things to do currently. From a technical stand point it's absolutely possible for them to do this.
From a user developed app stand point if we can't even get libraries for an MQTT client I highly doubt we will be able to access the network stack to create a UDP receiver.
I have no doubt it's possible to SEND packets. It's the setup of a listener that I don't see ever happening from our end.
Without a listener I see little value in being able to send a packet to a device as there's no way to get the response for processing. I guess there could be a use in a fire-forget scenario like syslog... oh we don't have that either....
I think that means: An App on the hub must initiate the UDP exchange. The "reply" will be seen in the parse method of that App. That might mean Lifx can be implemented locally.
I heard that some test code has been created as proof-of-UDP. I heard that on/off of a Lifx bulb was successful. In other words, UDP as it exists in the Hub for several months at least, works for Lifx.
I'm making progress with mine, currently works with on/off, hoping to get hue, saturation, brightness and temperature working this week. I'm not 100% happy with the architecture yet, currently I have a virtual device that does the discovery, all the bulbs etc are currently children of the discovery device. However, I'm leaning towards having an app to improve the discovery process, since holding on to state seems to be a bit of a nightmare, an app would allow me to use atomicState, so I don't need to create the devices prematurely.
