Using Scenes in the API

Continuing the discussion from A Penny for Your Thoughts:

Currently it is not possible to create/save or edit scenes using the HTTP API. We have started work to implement this but there are many unresolved issues we need to sort out before we make it publicly available. Watch this thread for future updates on this area.

2 Likes

I just added documentation for using the HTTP API to view and activate a users scenes. We haven’t yet got a way to create or edit scenes, but we would love to hear how you plan to use it, so that it can guide us as we build it.

/cc @rasputin303, @LightDJPro and @jorgerdz

1 Like

That’s cool. The reason I asked originally was for a specific use-case, which I’ll try and explain here:

In phoniclynx’s Kodi/XBMC add-on NateKodilifx (https://github.com/phoniclynx/NateKodilifx), when you start watching a movie in Kodi, it uses the HTTP API to read the current state of each of your bulbs, then set them all to a dim blue colour (like cinema lighting). When you pause or stop the movie, it then restores them all to their original colours.

The problem is, the restoration happens one bulb at a time, because the code has to send a message to the first bulb and wait for the Lifx Cloud to respond before sending a message to the next bulb, etc. So instead of getting a smooth fade-in of all your bulbs, it happens patchily.

If instead of reading the initial state of each bulb, you could simply save the initial state of all the bulbs as a scene, and then activate the scene when the movie stops, you’d get the desired behaviour because all the bulbs would change at the same time.

(Of course, another way of doing it is to use the LAN protocol instead, where the latency is so low that you don’t notice that the messages are being sent sequentially to each bulb… I keep meaning to write a version of the add-on that does this…)

tl;dr - there are situations where you might want to be able to set multiple bulbs to different colours at the same time, and this is one reason why the ability to (temporarily) create/save and activate scenes in the HTTP API might be useful.

I see, in that case, Scenes isn’t the best way to achieve what you’d want. You want the ability to send a set of lights and the states you’d like them to be set to in a single request, right?

I can add an endpoint that’ll let you do that, but it might be a couple of weeks until I have time to work on that. Also, we cannot guarantee that all the lights will execute the actions at the exact same time. How does that sound?

Yes, that sounds like a good option - although please don’t invest time in this for my sake. In the time since I posted that original query, I’ve learnt how to use the LAN protocol - and I personally, I think I’ll be using the LAN protocol for everything I work on in future (mainly because it’s making me learn a lot more about how to programme properly!)

But maybe there are other people out there who would find this useful? Or maybe people would prefer full support for scenes in the HTTP API as a higher priority? Hopefully some of the other members of this community will contribute to this discussion.

+1 for full support for creating/editing scenes via HTTP API.

We want to know how you would use scene creation and editing. This feature isn’t one that is too hard to build, but because the scenes are synced to the mobile applications it may interfere with the usability for them. Knowing how you want to use them will help us figure out how to design the interfaces.

I’ve had a bit of a think about this over night and (bearing in mind that I’m not an API designer) these are my thoughts.

To create a new scene:

  • A Post request should be made to https://api.lifx.com/v1beta1/scenes/create
  • The body of the request should contain JSON data with the following attributes:
  • name
  • devices
    • id
    • brightness
    • power
    • color
      • kelvin
      • saturation
      • hue

Any devices not included in the request should not be included in the scene. If no devices are included in the request, then the current state of all devices should be stored in the scene.

To edit an existing scene:

Any devices not included in the request should not be updated. Any attributes not included in the request should not be updated.

Does anyone else have any thoughts on this?

PS, in the List Scenes endpoint, the device serial_number is currently being returned. Should this be updated to id to match to the current convention in the List Lights endpoint?

@kubalicious I meant what applications would you build and how would you use scenes in your own applications if we enabled creation or deletion. Though your API design looks pretty sane and RESTful to me. :smile:

Also regarding serial_number and id we are aware of the inconsistency (I made a note of it on at the bottom of the List Scenes documentation). We will be fixing it in a future version, but we wanted to release this to our developers sooner rather than later.

If I can make a suggestion, what about a push pop functionality, I would rather manage scenes from the mobile device however when it comes to the functionality described above in the API I would like to be able to use a simple command to push the current settings into a temporary scene and then later pop the lights back to their previous settings.
In this way for Kodi at the start of a movie I just push the current settings, call my movie scene and then when the movie ends or is paused pop it back to original settings. Nice and simple and it all happens at once.

1 Like

Hi Daniel,
Just a small note, the documentation for listing scenes return JSON is different to what you actually get and the returned result is far better than what is in the documentation.

@boxhead I’m getting the response that is documented, just not in the documented order - are you receiving additional fields?

I’m also seeing the same result as documented. It can occasionally be in a different order as ordering in JSON data is unspecified for dictionaries. We also list things in the order they are processed in the cloud applications, so the ordering could be different every time.

If you happen to have specifics please feel free to post them here or email us at developers@lifx.co.

It is the order that is different. The sample has the scene name at the end, whilst the test value it is at the start so obviously there is no problem. I just didn’t realise it could change order.

For something to do I took Nate’s add-on and forked it, I have added support for a TV and Movie scene using the new scenes in the HTTP API

Now if I could temporarily store the current settings as a scene that can be called later and automatically deleted it would be brilliant. I am not having issues with the add-on like I was before and it works fast enough really.

Daniel how about the ability to set a fade in time for the scene ? It would be nice to fade to the scene rather than just switch over.

Well, turns out that was already implemented and I just missed it when documenting it. To use it simply send a duration parameter, that same way you do for the power controls.

In the meantime I’ll go and correct the documentation… oops :confused:

I’ve now documented this. You can now use the examples on the Activate Scene page.

Brilliant thanks for that. Seems to be working well, mind you I am working from the office testing with lights at home.

@rasputin303 @kubalicious @boxhead I’ve added an API endpoint that lets you set multiple states on multiple selectors in the one request. Check out HTTP API Changes - v1beta1 - 2015-08-28 for more information. There is no documentation just yet as we’ll gather feedback and make changes if necessary before documenting the new endpoints. Please put any feedback in that thread rather than this one!

1 Like