LIFX Local Control

📢 Feedback Feature Requests
181

I'm having a problem with the https API for Lifx so looking forward to giving this a try via the MakerAPI. Has anyone been using this with Maker? What are the parameters?

I also have a TypeScript implementation as @Bobfrankston/lzlan but haven't exercised it much but feel free to borrow from it as I borrowed from others.

At the moment I am running a Class C network but with 200 IP addresses already in use, I may have to expand it.

182

I've never used the Maker API - but not sure why you'd want to use my driver that way.

183

#1 reason is static friction -- the shortest path to getting things working using my existing knowledge.

It makes it very easy to write my own apps that use Hubitat as a bridge. I wrote my own shim for Smartthings that allowed me to use http but their OAuth implementation was clunky.

Do you write apps on other machines to control the devices? Or do you just write apps on the Hubitat itself?

184

I try to keep everything on the hub

185

That's the key -- I have a far more distributed system.

186

Minor update here available from the usual place (see first post in this topic I think!)

  • Discovery scanning speed is improved.
  • Added a preference input for one or more IP subnets e.g. 192.168.0 for the cases when the LIFX bulbs are on a different subnet from the hub. I'm not 100% sure this works, since I only use a single subnet at home, but as long as UDP traffic can pass between subnets then there shouldn't be any issues. This field is relatively forgiving, you can specify 192.168.1 or 192.168.1. or even 192.168.1.1 - all these will be taken as 192.168.1.

Sorry, I haven't put version numbers in yet.

2 Likes
187

Hi @rob, appreciate all your hard work on this. I pulled the trigger on Hubitat a few days ago and it seems I am lucky to have jumped in at a point where LIFX local control is so far along, as I have several.

I have noticed that the 1 minute polling works well for when bulbs are changed state via other means such as the LIFX app, and this status gets updated on my dashboards. However, it doesn't seem that this polled status gets propagated to groups and scenes (when toggling lights via Hubitat, the status DOES propogate to groups/scenes, so I assume they should update). I also notice the sliders on groups don't reflect the same % value as the bulbs themselves.

Not a huge deal as my primary means of control is via Hubitat but thought it was worth mentioning.

188

Interesting, I'm not sure why that's the case - I'll check tomorrow to make sure that I'm sending the right events when polling,

189

I'm currently working on a HomeSeer -> Hubitat plugin that is working well with @rob LIFX app. However I have some questions as well.

What are the input parameters for setColor, setState as they are presented through Maker API as "commands". However through the HE web interface nor through Maker API can I get anything to work with them.

190

At the device handler level, for setColor it should be a map, for setState it should be a string that looks like a map e.g. "[brightness: 30]".

The full list of parameters for setState are:

  • hue (0-100)
  • saturation (0-100)
  • brightness (0-100)
  • level (0-100)
  • power (on/off)
  • kelvin (the literal kelvin value, depends on the bulb)
  • duration (number: transition time in seconds)
  • color
    1. 'random' - pick a random colour from the colour list
    2. a hex colour e.g. #224759
    3. a named colour from the colour list
  • colour (exactly the same as color, just because I'm British :slight_smile: )

Both of those work fine in the web interface, but as I said earlier I've never tried using the Maker API so I'm not sure how you'd pass them in.

I could possibly make them more flexible and allow JSON if that would help?

Note that both of these only apply to LIFX Color and LIFX Plus Colour devices - a white only version of setState could be possible I suppose in future.

191

From the HE interface working with the "Set Color" I've found.

  • [random] does not work
  • Using a named color/colour is not working me. Perhaps I need to update? Example [white] or [White] or [red], [green] etc does not work

In Set Color using the "Color Picker" that works fine.

The Maker API takes the input as part of the URL in a GET call which makes it simple to work with. Ideally it would be nice to use this for integration purposes.

  • setColor could accept either 'name' ie 'blue' or the hex value minus the '#' symbol
192

@jeubanks, the parameters listed are for setState. This is a Lifx api specific command that gives a bit more flexibility than the standard setColor.

Eg. Under setState you can use
[color:random]
[color:red]
[color:green]

I don't believe the Maker Api can use custom commands (which setState is) so it may not be possible to configure the bulbs with that method. I could be wrong as I have not been following the Maker api changes with each update.

1 Like
193

@stephack thanks for the clarification on the 'setState' parameters. That is working nicely in the Web UI.

Now to try and see if/how to get it working with Maker API

194

Let us know if you get it going.
If not, you should probably wait for a response here:

195

@stephack, it works. Mostly...

Going to color 'white' does not work. Other colors are switching and working. This is currently just through POSTMAN testing.

[EDIT]: All of the "white" or light colors I've tried have far too much red in the end result.

URL:
http://192.168.10.64/apps/api/254/devices/510/setState/[color:red]?access_token=

Simply passing the map as the subCommand to setState is working.

[EDIT]: Colors in the color map with a 'space' in the name even with it being HTML encoded is not working through Maker API but all other single word colors are working with exception of light/white colors (not really a color though right? :slight_smile:

1 Like
196

@rob

Here's some log info from using Maker API with setColor.

app:2542019-04-20 10:59:14.236 debugExecuting with secondary command: 

setColor [hue:31,saturation:100,level:100] on device: Desk Lamp
dev:5102019-04-20 10:59:14.233 errorgroovy.lang.MissingMethodException: No 
signature of method: user_driver_robheyes_LIFX_Color_651.setColor() is 
applicable for argument types: (java.lang.String) values: 
[[hue:31,saturation:100,level:100]]
Possible solutions: setColor(java.util.Map), iterator() (setColor)
197

In the Lifx Color driver I notice that the setState method does an active conversion of string to map where as the setColor method assumes an incoming map. I'm not a good enough coder to know the solution but something tells me that is where the problem lies.

198

Hmm, that's odd. The colours look fine here.

For the ones with space in the name, edit the LIFX Master app and change line 565 to be
myColor = (null == color) ? null : lookupColor(color.replace('_', ' '))
Then you can use an underscore where you need a space.

199

For now I'd suggest adding this method to the LIFX Master app

@SuppressWarnings("GrMethodMayBeStatic")
Map<String, List> deviceSetColor(com.hubitat.app.DeviceWrapper device, String colorMap, Boolean displayed, duration = 0) {
    def hsbkMap = getCurrentHSBK device
    hsbkMap << getScaledColorMap(stringtomap(colorMap))
    hsbkMap.duration = (colorMap.duration ?: duration)
    deviceSetHSBKAndPower(device, duration, hsbkMap, displayed)
}
200

I haven't tried this at all. Just trying to help @jeubanks out. My assumption is that the Maker Api is sending the secondary command value as a different value type than just entering it in from the HE device page. I have no plans to test any of this myself.