Changes in HTTP End Points?

Hi,

I’m the developer of this extension: https://chrome.google.com/webstore/detail/lifx-web-control/ohedkkoibkekbipjoeehpofmjbmmkhin?hl=en

Since yesterday I got a bunch of emails from people saying that the Extension stopped working. I didn’t change anything on my side. Upon further inspection I identified that after generating a token and making a request against “https://api.lifx.com/v1/lights/all” I get a 404 error.

Again, I didn’t change anything on my side, so there must be an issue or update on your side. What could be the issue?

Thanks in advance.

1 Like

Did you test using the documentation examples ?
It is working fine now so may have just been some down time with the server.
Your extension is working just fine at the moment.

They changed the API and it broke my program too.

The colour temperature for Set State and Set States no longer work which makes the API pretty useless for controlling anything other than colour bulbs.

Also the Set State API now requires a content type of JSON in the HTTP headers.

This is so embarrassing for us developers that rely on these API’s to be stable and well tested.

Same here. I maintain some custom drivers (device handlers) for SmartThings. I have been able to adjust my code to get it to work. Here is what I changed to fix it…

1 - I had to remove my sloppy trailing “,” at the end of my group lists.

group:Kitchen,group:Foyer,

group:Kitchen,group:Foyer

2 - When setting colors I had to put a space between the hue and saturation settings instead of a “+”

["color" : "${color.toLowerCase()}+brightness:${brightness}", "from_color" : "${from_color.toLowerCase()}+brightness:${brightness}", "cycles" : "${cycles}" ,"period" : "${period}"])

["color" : "${color.toLowerCase()} brightness:${brightness}", "from_color" : "${from_color.toLowerCase()} brightness:${brightness}", "cycles" : "${cycles}" ,"period" : "${period}"])

That said, neither the “,” or “+” were part of the documented api, they just worked.

1 Like

Ok. I finally figured out my issue…

My extension does an initial GET request to get all the available lights.

The URL I was using for this request was: https://api.lifx.com/v1/lights/all/ … (With a trailing slash). Someone at LIFX felt “inspired” and thought it was an “awesome” idea to force HTTP URIs to not work with a trailing slash.

IMHO, that’s a stupid architecture decision. It makes your API super fragile and hard to debug. Any good API should handle these cases and do the proper URI rewrites or redirects if needed. Also trailing slash is the recommended Base URI format, so I really don’t see the point in creating such a strict architecture.

I think this change should be reverted.

@pacomac maybe this is your issue. Do you have requests with trailing slashes?

Thanks @boxhead and @whoismoses. It was a change on their side but I found the issue and fixed it on my side.

I wish they would spend their time fixing the lights dripping off the network I read of f’ing with this API crap.

They don’t ever drop off for me. I have no problem with them at all.

Nice work, clean and simple and works well whilst looking good.

They are perfectly stable for me too. I’d look at your router if I were you.

Do any of you guys support colour temperature specifying values in kelvin? This is now the only thing that I’m having issues with, but this for me is a major issue as most people will but the more affordable CT bulbs.

I get back an HTTP 207 but the temperature doesn’t change. I’m also sending a saturation of 0.0 and brightness along with the kelvin values. I’ve tried Set States and Set State API calls and I seem to be getting back for Set State (not for Set States):-

“unknown params” = {
“kelvin” : "5000"
“saturation” : “0”
}

With the Set States it is only accepting the brightness and throwing away kelvin and saturation but this time no unknown params reported.

Colour bulbs work just fine. It’s as though the support for colour temperature has been completely dropped from the HTTP API.

Color temperature works for me. Have you tried it without sending saturation? Just tested this on gen2 color bulb.

If I set duration to 0, the light now doesn’t turn on instantly. It turns on with the old color at around 10% brightness and then changes to the new color and brightness set in a split second. Looks weird.

It’s not my router. I have 46 bulbs with a Ubiquiti setup. All bulbs work fine except for the LIFX Z strips. Plus, have you looked around this forum? There are a ton of connection issues. I get your bulbs work fine, but that doesn’t mean they don’t have an issue.

For anyone still having this issue, I noticed in my implementation, not all headers were set up. Make sure you add Content-Type: application/json and Accept: application/json besides the Authorization header. In my case, I missed the Content-Type header. After adding it, everything is back to normal.
Good luck!

1 Like

Hi, during the recent change we inadvertently removed this undocumented feature. Please specify kelvin and saturation as part of the top level color property

 {"color": "kelvin:2500 saturation:0"} 

This would be the way to set kelvin and saturation on a bulb. The best source for documentation on how to construct a color string would be the http api documentations color page

Listen @kevin : there’s a reason API’s are versioned - so stuff like this nonsense doesn’t occur. And not only this issue, but the multiple other issues on the forum. V1 should be stable, complete with a working test suite, without any changes. Want to make changes to how things work? Again, that’s why APIs are versioned. Roll out a v1.1. It’s about time we got some updates to the HTTP API anyway.

1 Like

The behaviour @kevin referred to is the only documented way to do it. Please stick to documented behaviour if you wish to maintain stability.

This is still an issue. Unless it’s intended.

Edit: ok. Tested this some more it seems you are intending a fade on of 1sec. If I don’t send any duration, the fade looks smoother and takes a bit longer. Still what you miss is, that this doesn’t work, if the bulb was set to a different color before. It will fade from that color to the new one. This can and will look weird depending how far away from each other the colors are on the color table. You’ll have to set the new color first before you start the fade process.

1 Like

Hey @dymas , Would you be able to add some detail to this? such as the initial settings and what you are fading to so we can generate a test case for this in office.

power: “on”, brightness: 1, color: kelvin:(anything)

Set this, then try it again with another color.