DynamicGroupController and attributes

[gwp1]

Has anyone played with the LIFX API thru Reactor? https://api.developer.lifx.com/docs/introduction is their info. I see a lot of curl noted and, admittedly, my API-foo ignorance is only surpassed by my Expressions ignorance.

I know the API call requires authentication, just having a hard time formatting what goes where in the Reactor fields to facilitate this.

My reason for tapping their API is that instructions sent from Reactor to the actual bulbs are hit or miss as far as what the results show. Thought was that, perhaps, calling their API may improve this.

Solved here: https://smarthome.community/post/9919

[toggledbits]

@gwp1 said in Reactor and LIFX API:

My reason for tapping their API is that instructions sent from Reactor to the actual bulbs are hit or miss as far as what the results show.

Since Reactor would control LIFX bulbs through an existing integration with your hub, you're likely having the same problems with your hub, and the hub likely uses that same API. I would focus on troubleshooting the existing link.

But based on what I read in the API docs, you can generate an access token in your account settings for LIFX. That simplifies things a lot, as you don't have to go through full OAuth2 on the fly. So that would be your first step: create an access token in your account settings.

It then says that you can supply that token as either HTTP Basic authentication (harder) or an Authorization header (easy). To do that, all you need to do is add this in the Headers field of an HTTP Request action:

    Authorization: Bearer <auth-token-from-account>

I would try something trivial like toggling a light first. The docs say that the request URL for this would be https://api.lifx.com/v1/lights/nnnn/toggle, where nnnn is the selector for which bulb(s) to change. Put the Authorization header as shown above in this and every request action. This action requires you to use POST, not GET. Other than the header, there is no data to send; all of the data needed is in the URL.

The URL for this API is to a cloud target. You didn't describe at all how your existing integration is "hit or miss," but I assert that given that it's a cloud-based API and therefore has a ton of dependencies outside your control, doing this from Reactor directly is unlikely to improve average reliability over the long run, unless for some reason your hub's existing integration is terrible and nobody has bothered to notice or care to fix it.

[gwp1]

This is precisely what I was looking for, @toggledbits, thank you. I wanted to float this first so I could give it a kick before returning to the collective for alternate guidance. The issue at hand is that, whilst the lights will go on and off Reactor>Hubitat, they are ignoring the color-changing commands. I wanted to avoid cloud-based anything, obviously, but am looking to see if using the API nets me the same results. If NO, then on to troubleshooting which commands Reactor sends will accomplish the goal.

[toggledbits]

OK. While you're doing that, I'll retest Hubitat with the only color lamp I have, which isn't LIFX, but should still be using the same Hubitat commands/capabilities.

[gwp1]

@toggledbits Here's the options I see for LIFX in Reactor.

[toggledbits]

OK. Found a problem recent since 21270 that would affect RGB on Hubitat. Fixed in a build I'm working on now.

[gwp1]

Confirmed via testing that lights are responding to Reactor-issued commands again. Thanks for the quick turnaround, @toggledbits (and for saving my sanity.)