Scene State

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.

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.

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…

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”

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

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.

https://github.com/akbooer/openLuup/blob/development/openLuup/scenes.lua (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 ?

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

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?

1 Like

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?

3 posts were merged into an existing topic: openLuup: ZWay plugin for ZWave.me hardware

A post was merged into an existing topic: openLuup: ZWay plugin for ZWave.me hardware

Best Home Automation shopping experience. Shop at getvera!

© 2020 Vera Control Ltd., All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules