Scene State

[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?