Scene State

When the device’s state matches a scene’s criteria then the “active” variable in the “sdata” returns “1” otherwise it will return “0” or when using “status” request is will return “true” when the scene is active of “false” when is not:

controller_ip:3480/data_request?id=sdata

{“active”:0,“name”:“Good Night”,“id”:19,“room”:0}

controller_ip:3480/data_request?id=status&output_format=json

{“id”:19,“Jobs”:[],“tooltip”:{“display”:0},“status”:-1,“active”:true}

Would it be possible to implement scene’s state?

Yes, it’s been on the list, but I never found a need for it. I can do it. I think the state hangs around for a while after completing? What are you using it for?

I believe this may also fix the fact that the scene last run time does not properly update on the AltUI scene page, although it is correct in user_data.

It is used to display the proper state of scene controller that get triggered when a scene is active . It al used in homewave to display the correct state of a scene button and and realize if certain scene buttons are active or not . It is also used as conditional statement, if this scene in third party developements (kodi) is active then show a message or do this or that. And many more… :slight_smile:

Yes, understood. It still does not tell me what it really means or how to implement it.

For example, I have two scenes, with no timers or triggers, which turn on and off an LED lamp:

Quiescent state:

{
    "name": "RGBW All OFF",
    "id": ​4,
    "room": ​0,
    "active": ​0,
    "state": ​-1,
    "comment": ""
},
{
    "name": "RGBW Full ON",
    "id": ​3,
    "room": ​0,
    "active": ​0,
    "state": ​-1,
    "comment": ""
},

Turn on then off:

{
    "name": "RGBW All OFF",
    "id": ​4,
    "room": ​0,
    "active": ​1,
    "state": ​4,
    "comment": "RGBW Master: SUCCESS! Transmit was OK"
},
{
    "name": "RGBW Full ON",
    "id": ​3,
    "room": ​0,
    "active": ​1,
    "state": ​4,
    "comment": "RGBW White: SUCCESS! Transmit was OK"
}

…both active!

This is actually a timing thing. As I mentioned, they are ‘active’ for at least some period of time after running.

@ronluna

I’ve updated two files in the GitHub development branch: requests.lua and scenes.lua, to reflect my current understanding of the status/state and active flags for scenes in the status and sdata HTTP requests.

The flags are cleared 30 seconds after the last delayed action of the scene, unless it has been re-run in the meantime.

Grateful for any test reports.

Excellent @akbooer I will start running some test today. I do have to merge some changes I’ve made inside requests.lua for adding https and auth header to request_image function.

I’ll report back as soon as I finish the merge. :slight_smile:

Is that something which needs updating in the GitHub code? l[tt]uup.inet.wget()[/tt] supports HTTPS and username and passwords, but I thought that request_image actually used only HTTP.

request_image is generally used to retrieve an image from cameras. Some cameras are authenticated different than other, some required https or header to be pass on to the camera in order to gain access to it. While I was reading the camera thread I’ve noticed you could not really test it due to not having any cameras in your system so I decided to take on this quest.

I can post what I have which works for me but maybe is not the best approach as requires to add 3 addtional variable to the device (username,password,protocol) even thinking in trying to add rtsp support in the future…

I’m not keen on putting anything into the luup.xxx() functions which are not there in Vera.

While merging some file with the development branch request.lua makes references of update.lua which does not exists in in the development repo. Should We be worry about it?

local server        = require "openLuup.server"
local json          = require "openLuup.json"
local xml           = require "openLuup.xml"
local scheduler     = require "openLuup.scheduler"
local devutil       = require "openLuup.devices"      -- for dataversion
local logs          = require "openLuup.logs"
local rooms         = require "openLuup.rooms"
local scenes        = require "openLuup.scenes"
local timers        = require "openLuup.timers"
local userdata      = require "openLuup.userdata"
local update        = require "openLuup.update"
local plugins       = require "openLuup.plugins"
local loader        = require "openLuup.loader"

No.

I have finally test the scene state and is partially working. As akbooer predicted. It only shows the current state of the scene “true” momentarily and then it becomes false again even though the devices continues to be aligned to match the scene’s “true” state.

Is there any way to keep variable active = “true” while the devices in a scene are appropriately aligned to scene’s specifications?

Similar to Vera
s behavior?

I have no idea what you mean by “appropriately aligned” Which devices? Which specification?

Hi Guys,

Does active indicate the scene trigger condition is true? This could be the case for a long time (some variable of some device has value x) or just briefly (it is 10:00:00). I know for the first the Vera can (re)run a scene at reboot. But I cannot see it documented in the wiki so it looks like a guessing game.

Cheers Rene

Yes, thanks for the idea, I wondered about that too. But for openLuup it is a moot point, since it does not implement the UPnP-style triggers of Vera. A scene has absolutely no way of knowing what triggered it to run, except the difference between a timer schedule and a manual or HTTP run request, as reported in the log.

Hi. I know that this is a rather old thread but its the only one on point. I was wondering if this issue was resolved. You see I use Homewave and i run into it not displaying the correct state of a scene button. I wouldn’t mind putting LUA code to manually change the scene state if possible.

I haven’t done any more on this, since my understanding of what defines a scene’s ‘state’ is still lacking. Perhaps if you can elaborate on the symptoms with a concrete example, then I can try to grasp what is needed.

Hi Akbooer:

I’d be more than happy to explain. I use an App called Homewave on my iPhone. One if its abilities is to change the icon color to reflect the scene status. If a scene is active, the circle changes to white. I’ve attached a screenshot of the two scenes. In this example we?re comparing scene “GR Lamps On” and scene “Accent Lights On”. Both scenes are active but only “GR Lamps On” is indicating in Homewave that it is.

Using Ronluna’s formula, I went to the (controller_ip:3480/data_request?id=sdata) location in Vera to determine my Scene ID by searching for the name. Then I went to the (controller_ip:3480/data_request?id=status&output_format=json) location and searched for my Scene ID the results of which are below:

First I’ll show you “GR Lamps On” data which is the scene that IS displaying correctly in Homewave:

I go to (controller_ip:3480/data_request?id=sdata) and search for ?GR Lamps On?

The result is: { “name”: “GR Lamps On”, “id”: 85, “room”: 1, “state”: -1, “comment”: “”, “active”: 1 }

Then I go to (controller_ip:3480/data_request?id=status&output_format=json) and search for my Scene ID number, in this case its: ID:85

{ “id”: 85, “Jobs”: [ ], “tooltip”: { “display”: 0 }, “status”: -1, “active”: true },

Note how the last part of the string says “active”: true.

Now when I follow the same steps for scene “Accent Lights On”, the scene that is NOT displaying correctly in Homewave I get this:

{ “active”: 0, “name”: “Accent Lights On”, “id”: 87, “room”: 1, “state”: -1, “comment”: “” }
{ “id”: 87, “Jobs”: [ ], “tooltip”: { “display”: 0 }, “status”: -1, “active”: false }

Note how the last part of the string says “active”: false.

This is what I need help with. I would like to have LUA code that can force the proper scene status or alternatively find the reason why its not working.

Thanks again for looking into this.

  • Fred

Thanks for the detailed explanation. I’m a keen advocate of HomeWave myself, but not a big user of scenes, so have never paid attention to their status there. I well understand the mechanics of sdata and status responses too, so that bit is OK. What I completely miss is any understanding of the actual meaning of a scene being ‘active’, and searching the forum shows that this has been an issue for some people seeking enlightenment since day one (or at least 2009.)

I guess I will have to do some experimentation, but the whole concept seems pretty bizarre to me. A scene runs, does something, finishes. If you’re wise, it doesn’t take too long to do that. I know I am missing a key concept, but try as I might, I don’t yet ‘get it.’

Scene’s use to have a description that said if the devices were in the state as set by the scene … then scene was considered active.

But the active/inactive stuff never worked really worked.

i.e. You set a dimmer to ON  via SetTarget
      It goes to 100%
      You dim it  so LoadLevelTarget changes ... Is it still active ?

I would just say active state is not defined … as opposed to try to reverse engineer something in Vera that never worked well.