Scene State

[ronluna]

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"

[akbooer]

@ronluna

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?

No.

[ronluna]

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?

[akbooer]

@ronluna

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

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

[reneboer]

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

[akbooer]

@reneboer

Does active indicate the scene trigger condition is true?

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.

[hotopic]

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.

[akbooer]

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.

[hotopic]

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

[akbooer]

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.’

[RichardTSchaefer]

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.

[hotopic]

Hi Richard. I know what you are saying about the devices were in the state as set by the scene … then scene was considered active. The options are still in Vera but as you say it never worked really well. To answer your question, this particular scene uses LoadLevelTarget 100%. If you change the dimmer to go below 100% the scene is marked inactive. What i mean is that the “On Scene” will turn off in Homewave but the “Off Scene” isn’t enabled either which technically is how it should be. Its very odd I agree. Sometimes if I reboot Vera all these scenes display properly. Other times they don’t. Mores the pity.

[hotopic]

akbooer - what i use is for is mostly when I’m accessing the system remotely away from home. Its nice for me to see a visual indicator that a light has turned or off and that the scene completed.

[akbooer]

@RichardTSchaefer

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

Richard, spot on, I would say. I’ve trawled the boards and found an amazing array of opinions and discrepancies, over the last 7 years, some from people whose opinion on all things Vera I mightily respect…

@nullx8

strangely if all the device status as listed in the advanced tab do come true on some other means (like they beeing activated/deactivated manually over time) it seems this does act like a trigger and the scene is beeing executed by the controller.

@nullx8

2 things:

1. can someone confirm that the “consider as active” in advanced tab of the scenes do act as a trigger too ?
2. how can i control the execution if so

@garrettwp

The status is being reported by Vera. Scenes are considered active when the devices of that scene are correctly set e.g. under the Advanced settings of the scene you’ll see “Scene is Active - when all devices in the scene are properly set”. For example, say I have a scene to turn on my living room lights at sunset. The scene is configured to have the living room lights on. If I turn on the lights say during the day, Vera will mark the scene active as the living lights are on and that matches the settings of the scene minus the time. Vera will only check the device settings to mark the scene active or not and will ignore times, triggers, etc.

@futzle

Scenes are not “active” or “inactive”. They are instant events that affect the state of your devices, and then they are finished.

If you want to know if the states that your devices are in matches what the scene set them to, you’ll have to query each device individually, and apply whatever logic you need to the results.

Full disclosure: Vera (UI5 particularly, I haven’t seen this in UI7) has some logic that attempts to do the above for simple scenes, but I never found that it worked well, and it’s definitely not exposed through Luup, so you’re back to doing it yourself manually.

@LibraSun

Hmmm… is this another one of Vera’s “Ha ha, you misunderstood how it’s supposed to behave” features?

Not worth spending the time on, if one is to maintain any degree of sanity. I’d echo @futzle’s advice:

“If you want to know if the states that your devices are in matches what the scene set them to, you’ll have to query each device individually”

[hotopic]

Hmmmm well it was worth a shot. Thanks for looking into it for me. ;D

[ronluna]

Hello @akbooer , Thanks for the changes on http client sockets (Currently being tested on request_image and working great) sharing it once stable to get your opinion.

On another note. We are wondering what can be reliably use to create scene_watcher request? The previous advice was to use

luup.scenes[n] :user_table()

But apparently it was removed on the development branch’s latest changes.

openLuup/scenes.lua at development · akbooer/openLuup · GitHub (Line 66)

We are just wondering what would be the proper approach to prevent from breaking in the future. would it be safe enough to use

scene[SCENE_NO].definition

any thoughts/idea ?

[akbooer]

I told you previously that the scene internals were about to undergo significant refactoring!

I was very unhappy with the scene implementation holding some of its context in a function closure, so now they’re in a fully-fledged object. The openLuup implementation of devices had always been object-oriented, and now scenes are too. I notice this matches the trend for the new Ezlo API, although I have no interest in maintaining compaibility with that, at this time.

I certainly don’t guarantee the longevity of the openLuup API internals, but I have always strived to use open standards wherever possible – the WSAPI CGI interface, Graphite Whisper files, DOMs for XML, HTTP, and SVG, indeed the Luup API iteself. I may also document the device and scene objects in due course, with the caveat that new versions may not be backward compatible.

So, for the time being, scene[SCENE_NO].definition should be stable to use. I would just ask that you don’t create and use any new entities in there – this is, after all, the data structure that shows in the user_Data, and which AltUI uses to define scenes.

On a slightly separate issue, I would point out the tremendous success that some people are now getting with the Z-WAVE>ME hardware (Razberry PI / UZB stick) and the ZWay plugin. It provides a very stable and fast system. Something you may want to take a look at?

[ronluna]

So, for the time being, scene[SCENE_NO].definition should be stable to use. I would just ask that you don’t create and use any new entities in there – this is, after all, the data structure that shows in the user_Data, and which AltUI uses to define scenes.

We will stick to scene[SCENE_NO].definition for sure without and follow your requirements of not creating new definitions.

On a slightly separate issue, I would point out the tremendous success that some people are now getting with the Z-WAVE>ME hardware (Razberry PI / UZB stick) and the ZWay plugin. It provides a very stable and fast system. Something you may want to take a look at?

I’ve started testing it again last night. seems to be great for basic devices such as sensors, switches and dimmers. although Thermostats or Combo devices seems to be a challenge. Trying to understand how to merge the children into one device for things to be more vera-like by using zway_cgi.lua?