HTTP API issue?

So here’s a strange thing that started tonight. Pretty sure it’s related to the HTTP API.

I have a set of Applescripts that I use on my Mac that trigger scenes in my home office (which I will share below if anyone wants to steal it). It calls the HTTP API “Activate Scene” endpoint using curl with my API key and the UUID of the scene. Using the Applescript menu, I can access all my scenes I’ve created scripts for in the menu bar, which is SUPER AWESOME. I can confirm this was working as recently as last night.

On the LIFX app itself, I can use the scenes just fine. Tap one, and everything is configured properly. However, when I use the API, I get no color - only white lights at different brightnesses, which isn’t what I want. My “work” scenes are all different colors, as I prefer that over whites (strangely, when it’s set to white, I have zero motivation to work, weird right?). I can confirm that I get the same results when using curl via the command line (just tested it).

My current scripts are as follows:

in ~/Library/Script Libraries/LIFX.scpt:

property apiKey : "{my API key goes here}"

to ChangeScene to uuid
  set a to "curl -X PUT \""
  set urlFirstPart to ""
  set urlSecondPart to "/activate"
  set b to "\" -H \"Authorization: Bearer "
  set c to "\""

  set fullString to a & urlFirstPart & uuid & urlSecondPart & b & apiKey & c
  do shell script fullString
end ChangeScene

in ~/Library/Scripts/LIFX - {my scene name}.scpt:

tell script "LIFX" to ChangeScene to "{UUID of scene here}"

The result of fullstring in the LIFX.scpt library returns

"curl -X PUT \"{UUID of scene here}/activate\" -H \"Authorization: Bearer {my API key goes here}\""

Which is then executed by do shell script. This output is the escaped version and is identical to typing into the command line:

curl -X PUT "{UUID of scene here}/activate" -H "Authorization: Bearer {my API key goes here}"

Which is identical to what is recommended for curl on this page:

If I use my API key on that page to test it out, the same thing occurs - only whites, no colors.

The response in any of these cases is a 207, which returns the following JSON:

  \"results\": [
      \"id\": \"{OMITTED}\",
      \"status\": \"ok\",
      \"label\": \"Studio Desk Lamp\"
      \"id\": \"{OMITTED}\",
      \"status\": \"ok\",
      \"label\": \"Studio Wall Lamp\"
      \"id\": \"{OMITTED}\",
      \"status\": \"ok\",
      \"label\": \"Studio Table Lamp\"
      \"id\": \"{OMITTED}\",
      \"status\": \"ok\",
      \"label\": \"Studio Light Strip\"

Anyone having the same issue? Or is this a bug in the HTTP API?

1 Like

Hi Thanks for this bug report. We are investigating now and implementing a workaround.

1 Like

The workaround is currently in place. This should be working as expected again.

Looks like it is working again! Thanks!

1 Like

@kevin, I don’t believe this issue is resolved. I am seeing the same behavior when calling PUT SetState. If it makes a difference, I am calling from powershell on Mac OS X.

EDIT: I just tried it from the test page and the app, those both work.

Can you provide more details about the requests you are sending? The level of detail the original poster gave allowed us to quickly figure out exactly what the issue was and fix it.

Using duration fails as well. We have an IFTTT action that runs a 15 minute dim on some lights. The last two nights have been immediate changes from 100% to 15%.

Hey @dougc84,

We have been trying to replicate this in the office but we can’t seem to. Are you able to share the IFTTT recipe with us?


I was trying to recreate it just now. It failed 5-10 times, then it began working again. So all I can say at this point, is that I am using PowerShell built for Mac OS X. Specifically the Invoke-WebRequest, and Invoke-RestMethod cmdlets. What I mean by failure by the way, is that the lights wouldn’t turn off but I would get a successful 207 response from the server.

I also tried adding a content-type of application/json to the headers of the request but seeing as that didn’t immediately solve the issue I am unsure that it is important or related. Maybe there is some weird caching going on? I have always sent the no-cache cache control header, though so I don’t know.

Sounds to me like one of our deployments fixed your issue. This morning we have deployed two changes:

10:46am - Made the Content-Type assume application/json if not specified.
11:12am - Added Content-Type to the Allowed CORS headers

Do these correspond to the requests you made?

Possibly, as I said it’s working for me now. It was very weird behavior, I was always getting a successful response (Status code 207, with my lights listed out), but the lights just never turned off. If I used the android app or the test page in the docs, everything seemed fine. I only had problems with the requests i made myself. I also just remembered that I updated the firmware last night so maybe that has something to do with it too?

We just caught this one. The magic piece of information we were missing was that it applied to scenes but not other types of recipes. The v1/scenes/scene_id::scene_uuid/activate endpoint was not properly processing the duration parameter. We’ve corrected this issue and have just rolled out a fix, you should see this working as expected from now on.

Thanks for reporting the issue to us.