LIFX Local Control

jeubanks · April 20, 2019, 3:55am

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.

rob · April 20, 2019, 9:13am

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 )

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.

jeubanks · April 20, 2019, 2:18pm

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

stephack · April 20, 2019, 2:37pm

@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.

jeubanks · April 20, 2019, 2:42pm

@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

stephack · April 20, 2019, 2:43pm

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

jeubanks · April 20, 2019, 2:45pm

@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?

jeubanks · April 20, 2019, 3:01pm

@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)

stephack · April 20, 2019, 4:55pm

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.

rob · April 20, 2019, 5:18pm

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.

rob · April 20, 2019, 5:21pm

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)
}

stephack · April 20, 2019, 5:25pm

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.

rob · April 20, 2019, 5:28pm

I was just responding to the context, I probably should have responded to @jeubanks' message directly.

jeubanks · April 20, 2019, 8:38pm

@rob thanks for the info on updating the code. I can make the changes on my install, however I'm working on a HomeSeer plugin to integrate Hubitat. Will this be updated in mainline or should I fork this to keep the change?

rob · April 20, 2019, 9:44pm

Once you've told me it works I'll update it on Github

I'll probably refactor it a bit so that the String version calls the Map version

jeubanks · April 20, 2019, 11:56pm

@rob,

The @SuppressWarnings annotation already exists. I made the other modification from the previous post and I will test.

[EDIT]: So far the replacement is working. I can use the '_' instead of space through Maker API and on the first few test colors it works. BTW the names are interesting but the Aloeswood Brown is more like a older Soft Incandescent

rob · April 21, 2019, 12:08am

Sounds like you pasted the code in the wrong place, or maybe the annotation applies to all versions of the same method?

Yeah, you're not wrong about Aloeswood Brown, it's way too bright - I should probably go through all the colours and make sure they work properly - that'll be fun! As the comment in the code says, the colours come from Named Color Codes / Reference Chart, not 100% sure why that one doesn't work properly - greys really don't I think.

jeubanks · April 21, 2019, 12:12am

Actually I didn't copy/paste anything. I looked at the code and compared. The annotation was already there, unless I was looking at the wrong block (possible). Either way I have not tested/verified the suppression as it's not effecting anything that i can tell but just something I noticed. Now I'm gonna have to go back through the code as the "did I miss that" is bugging me

Yeah not blaming you for the colors from the chart. I've found that a lot of the "charts" are somewhat "off" and possible I'm a bit color blind or so my wife thinks so

rob · April 21, 2019, 12:21am

Ah, did you replace the existing method? You need to have both methods for it to work with the normal means.

The @SuppressWarnings is really only for my benefit in the IDE I use, it doesn't do anything as far as Hubitat is concerned. I just like to ensure that the code is as clean as possible.

jeubanks · April 21, 2019, 12:24am

See I did not... and yeah I don't care much for the web page ide. Let me go back and look at your post and see where to add in the new section...