I didn’t say that there’s a perception issue with scenes. I said there’s a perception issue with rules.
That’s what I was thinking–it gets complex in a hurry. Different users will have different preferences for how scenes behave, so I think it’s simpler if they’re “fire and forget” sequences, same as rules.
This also avoids any confusion around turning scenes ON or OFF. If scenes have states, then it would be logical to assume that you can turn one off to turn off the associated items. But that wouldn’t work for dimmers and other items that aren’t binary.
If scenes are stateless, then it’ll be more obvious that you need to have a scene specifically to turn items off.
I wasn’t really thinking about state in that way. I was thinking about it more like how Tasker does Profiles. But those are more driven by state so it may not make sense in OH.
But what happens is the state happens and while that state persists the profile is active. If a second profile activates and changes something from the first people, both profiles are still active.
From that perspective, the scene has it’s own state independent of the Items that are part of that scene
The challenge, and what would make it probably not work is how to know when the scene is no longer active, unless there were a way to define an event too “turn off the scene”.
As long as a scene is active, are all items that are set by this scene blocked for commands? If not, then what is the value of the information „scene is active“ if not all members have the state that was initially set?
If the scene is deactivated, what happens then? Are all items set to some default value? Are they returning tobte state they had before the scene was activated? Do they move to the states they would have if the (blocked) command would have been executed?
Imho scenes are one of these things that sound great at first glance but become useless or more of a burden real soon. @J-N-K made some nice examples and valid points why.
In HABApp we have the MultiModeItem which significantly helps modeling the desired output and is an attempt to address these problems.
But it is still necessary to make the decision on an item basis and not on a scene basis.
Because maybe you have two lights and scene 1 overrides light 1 and scene 2 overrides light 1 and light 2 and scene 1. Or for light 2 the priority is scene 2, scene 1 and then the default.
And then you can mix the turn on of the scenes:
First scene 1, then scene 2, scene 1 gets deactivated, scene 1 gets activated again, etc. etc. .
So basically there is no “scene” but multiple values for each item which can be dynamically selected.
Each value corresponds to a mode and each mode can be enabled/disabled and when enabled set to a value.
Activating a “scene” is then activating the corresponding modes for the desired items. The value of the item however is set by the modes that are active for the individual items.
There is value in knowing that it’s night, or the Movie scene is active, or it’s afternoon and all are away. Perhaps other rules want to do something different when a scene is active than when it’s not, such as pausing the video and backing up 30 seconds when the bathroom light goes on or the like. We don’t want to do that all the time, only when the Movie scene is active.
Like I said, it’s not really feasible in OH today and may never be so I’m pushing for it. It’s just a thought.
I do not think Items an commands to Items should be blocked when a scene is active.
Then it’s no longer shown as running with what ever tracks the state of which scenes are active. I don’t think there needs to be anything one to keep track of the states of the Items or enforce them throughout the life of the scene.
I think there is some confusion about what a scene is.
I wouldn’t call your night a scene. It’s more a “flag” that can be used in a rule to send a dim-command to a light when it is turned on, turn down room temperature or don’t ring the doorbell. I have something similar for my heating system: summer and winter.
For me a scene is a defined set of states for items. If the scene is “activated” then all items are set to the stored states. This is also consistent with what other systems call a scene and I believe we should not create a new meaning of that.
I completely second Jan‘s opinion and would like to ad my two cents.
If a somewhat called scene (e.g. movies) is activated, some items will be set to predefined states. If for whatever reason one of the included items changes, the scene is no longer valid and should be deactivated.
So while „running“ a scene, all members need to be monitored for changes. This would cause to create a large number of additional rules just for monitoring item state changes to deactivate active scenes.
This also applies to scenes overriding state of items in other scenes. This would have to be checked and other scenes have to be deactivated and items reset to earlier state.
I agree that stateless scenes make the most sense.
This is a very valuable function, but I think it’s easy enough to leave this up to the user.
If the user needs to know the status of a scene then the state of a proxy item can be included in the scene definition. The circumstances that result in the deactivating or changing of that item then have to be determined by some other rule or scene. This prevents OH from having to make arbitrary assumptions about scene status, gives the user the most flexibility about what constitutes the “end” of a scene, and even allows for the possibility of a more complex scene status item such as a string item to hold multi-state options (e.g., “starting”, “in progress”, “paused”, “ending”, and “ended”).
If you try to add a state to the scene itself, this proposal gets away from the elegant simplicity of letting the UI “simulate” OH having scenes and moves towards including a whole new item type in the core. We’d be talking about a “Scene item” that is much more akin to a Group than to rules. Scene items would broadcast all the appropriate commands to their member items and based on different possible aggregation functions, the states of each of the member item may impact the state of the Scene item. That’s more heavy lifting than it’s worth, I would think.
Note, I didn’t read 99% of this topic. I just want to point out that back in 2016 @jonnydev13 already created a general scene rule in Javascript which I later translated to python for openHAB 2.x.
Configuration of the scenes is done by means of a JSON object which defines the target states of the items in the scenes. When selecting a certain scene then all items are set to the configured state for that scene. The reverse is also true, so if all items match a certain scene then that scene is activated (without triggering any item update since they already have the correct state).
These two linked topics may provide some inspiration.
The the command field always a text entry? If so is there any way to put the text field on next to the Item instead of needing to click through to edit it?
Saving that extra click through could save a whole lot of user interaction. In those rarer cases where one wants to change the Item, I think deleting and adding a new one could fit that bill. I suspect changing out Items is a much rarer activity than wanting to adjust what the Items are commanded to.
Those are just my thoughts and not necessarily well thought out really. I’m just imagining wanting to adjust an already created scene and becoming annoyed at the extra clickthrough.
The command field should be similar to what you see in the rule editor when configuring an action module with an ItemCommandAction. Unfortunately the editor based on the item-type (e.g. color-picker) is not displayed at the moment and I couldn’t figure out why. This also doesn’t always work on my system for the rule editor, so I believe there is some general issue with that and probably @ghys might know why and how to fix it.
There’s 2 different UIs in the rules editor, a “wizard” of sorts when you add a new module (which can only add certain well-known module types, organizes them into 4 categories and has a tailored UI for some of them) and the generic module editor when you edit an existing one (which is a simple config sheet):
If you press “Show all” on the first screen of the “wizard” then you’re back to the regular module editor to configure the new module.
There’s no easy way to have the wizard UI for existing modules without some refactoring.
The scenes UI looks great, you could do the type check (or group’s base type) yourself and offer another input based on that - there are many options: https://v5.framework7.io/vue/inputs#examples
Regarding the “trigger or no trigger” discussion, as I mentioned in Add a scene editor to Main UI by J-N-K · Pull Request #1520 · openhab/openhab-webui · GitHub
I’d still like to see at least an option to link the scene to an item+command (don’t call it a trigger if you’re not comfortable with that, call it “Run the scene automatically upon receiving a command” or something like that).
It’s been a best practice since OH1.8 and asking users to have 6 “regular” rules to run the 6 scenes when the proxy item changes is simply not reasonable.
That’s why I proposed to find a compromise and have the scene editor support a single optional “Item received a command” trigger.
For other more complex cases, like running the morning scene at 7PM or at sunrise excluding weekends & holidays, then it’s acceptable to require a regular rule in addition to the scene.
