Add support for Scenes in OpenHab

[ErikApption]

Following up on the debate on this thread

Scenes

Definition

A scene is a preset that will change all items that are effected, so if you set a scene in a room, all lights in that room will be changed to the settings of that scene.

Scenes in Hue

Scenes is the main user flow in the Hue interface. Other features such as triggers, buttons and other integrations are secondary in the user interface.

Scenes in Home Assistant

Since version 0.15, Home Assistant has a support for scenes. See this link for more details. A scene in HA has a name, icon and a series of entities. Each entity in each scene has any number parameter values.

HA also supports transitions for scenes to gradually transition the values when possible. HA enables to create snapshots of multiple entities into a scene using their scene service.

To clarify some of the debate in the thread above, the HA concept and features don't seem to be debated by users in their github.

Implementation

Rules

A series of addon Widgets provide multiple features to support scenes. See this

Pros:

• No change to the core OH are required.
• Each scene is captured in this model in a separate rule.

Cons:

• Not sure editing scenes is supported.
• Also going to assume that if the rules are manually edited, it could easily break any built-in editor.
• The number of scenes would generate a large number of rules which would need to be managed somehow (tags? new UI sections?)

Core OH Addition

If OH did follow the HA model - scenes can be added in the core model.
Scenes could be applied at the group level and provide a way for a group to switch between multiple scenes.
livingRoomLights.SetScene("Morning")

Pros:

• Adding scenes to the core could support better UX for adding and editing scenes
• The scene data would have a separate conceptual space and not clog the rule section
• Applying scenes to group would make it easy to integrate them with rules

Cons:

• Changes in core
• Need for new UI for capture and editing of scenes

Other considerations

One additional consideration for implementing rules would be to integrate with existing scene systems. Almost every light system already have their own built-in scene support, it would be nice if the API could leverage them transparently: livingRoomLights.SetScene("Morning") would call scene "Morning" inside my Hue lights

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/scenes-openhab-vs-home-assistant-in-2022/138782/24

[rkoshak]

I argue that no changes to openHAB core are required here and that this issue should be transferred to openhab-webuis. From the core's perspective, there is nothing distinctive about a scene compared to a UI rule consisting of just Item Actions. A scene is just a list of Items and what they should be commanded to when activated. We already have a way to do that. The only thing missing is the UI to make defining them easier.

[ErikApption]

1. Without core support - how would you handle transitions?
2. How will a UI extract the state of multiple items if the rules have more than one update/command for each item or other actions
3. Without core support, scenes could get mangled with triggers. Other systems clearly separate both concepts. Still concerned here that a scene editor could be fragile if it needs to extract state from rules.
4. Scenes could easily add 100+ rules - how would OH make sure that these are clearly separated in the UI from key rules / automation

[ErikApption]

To add to the suggestion - here is an idea how it could be seen from a user perspective

[J-N-K]

I have read the forum thread and the discussion here. And I have some questions:

• It is already possible to add semantic tags (like "Living Room") to a rule. Displaying that rule in the model is only an UI issue.
• Why should a scene be limited to a room? In my system there is a scene called "Night", it turns off all lights in the house, closes all roller shutters and sets a Switch item called "night" to ON, so motion detectors only turn on lights at 10%. This is clearly "scene" in your definition (a defined set of states is applied to a defined set of devices), but it covers the whole building.
• I don't understand why a "Scene" section in the UI would be any better than the rules display. If you have 10 rooms with 10 scenes each and 100 rules to trigger them, you have either 100 rules and 100 scenes. And to be honest, I doubt it makes a difference if there are two-times 100 or one-time 200 rules in the list. You don't want to scroll through an unfiltered list in any case. If you use the search box at the top of the rules list, it's super easy to show only some of the rules, e.g. those relating to your living room.
• It's already possible to define rules without a trigger. They can be called from other rules or manually from the UI. What is the (technical) difference between a rule without trigger that consists only of item actions and the "scene"? If there is no difference, then it's only an UI issue to better edit or create them (e.g. by selecting items and storing their current value).

Regarding transitions: It's nearly impossible to do that as a generalized concept. There are so many corner cases where the behavior is unexpected or unintuitive. I have tried that when developing DMX binding and I still think it's not ideal - and that is only one technical solution. There has been some discussion in the past which are related to that. IIRC @cdjackson proposed extending Command with some sort of metadata to attach transition times and similar information. This would allow the most fine-grained control on item level, but should be discussed in a separate issue. Having transitions attached directly to scenes instead of commands would surely raise the question why it is not possible to turn on some of the light immediately while slowly fading out others. Since newer commands override older commands this would also solve the question how to handle a new command hen an old transition is still in progress.

[ErikApption]

• I don't understand why a "Scene" section in the UI would be any better than the rules display. If you have 10 rooms with 10 scenes each and 100 rules to trigger them, you have either 100 rules and 100 scenes. And to be honest, I doubt it makes a difference if there are two-times 100 or one-time 200 rules in the list. You don't want to scroll through an unfiltered list in any case. If you use the search box at the top of the rules list, it's super easy to show only some of the rules, e.g. those relating to your living room.

Again it's not about the list - it's about the editor. One page that has controls to edit all the items part of a scene and that is the value that the other systems I included have. I don't see how a rule editor would be retrofit to do this specific use case. Otherwise, you can always code scenes manually in any language and enter manually RGB values for your theme.

• Why should a scene be limited to a room? In my system there is a scene called "Night", it turns off all lights in the house, closes all roller shutters and sets a Switch item called "night" to ON, so motion detectors only turn on lights at 10%. This is clearly "scene" in your definition (a defined set of states is applied to a defined set of devices), but it covers the whole building.

That was an example on how rules would be applied to locations - but I was thinking the group would be the most intuitive target.

I want to add that @rkoshak had a very important point in the thread about educating the users. I'd be concerned that doing everything in rules will complicate the whole UX for new users. Most users will know scenes from other systems.

[rkoshak]

Again it's not about the list - it's about the editor. One page that has controls to edit all the items part of a scene and that is the value that the other systems I included have. I don't see how a rule editor would be retrofit to do this specific use case. Otherwise, you can always code scenes manually in any language and enter manually RGB values for your theme.

I think you are making a false assumption. No one is arguing to retrofit or modify the existing rule editor at all. What I at am saying is to create a new dialog to create scenes. In the core, it creates a rule like any other but the dialog itself is optimized in all the ways you describe, just like the dialog/editor to created a rule from the Scripts page is different and optimized for that case. And the only things required here are additions to MainUI. No changes to core are required.

Why should a scene be limited to a room? In my system there is a scene called "Night", it turns off all lights in the house, closes all roller shutters and sets a Switch item called "night" to ON, so motion detectors only turn on lights at 10%. This is clearly "scene" in your definition (a defined set of states is applied to a defined set of devices), but it covers the whole building.

I think that's a general limitation of the semantic model in general. But in this particular case, I'd put that scene in the top level of your house since it applies to the whole house. I do something similar for things like the outside temperature, home/away status, etc.

But this also raises another interesting idea. What if these scenes were made available from and perhaps even could be scheduled from the Schedule page. That would be pretty cool.

But, given that the same over all problem exists for Items, any alternative solution to this cross cutting problem would best be solved in adjusting the semantic model itself so both can benefit.

To summarize what I propose:

• modify the Semantic Model to show and manipulate rules with semantic tags
• add a new special "Scenes" tag (similar to the "Script" and "Schedule" tags)
• consider adding a new "Scene" menu to the top level, though I can see arguments for that not being needed if they are in the Semantic Model
• when choosing to create a new scene or edit an existing scene, create a new dialog that optimizes the selection of Items to include in the scene and setting the commands to be sent to those Items. I think it's an open question whether or not triggers should be defined here.

That seems to address all the issues except transitions (which are not feasible for the reasons @J-N-K describe). And everything above is 100% implemented in the UI. No changes to core are required so I still maintain this issue is in the wrong repo.

I want to add that @rkoshak had a very important point in the thread about educating the users. I'd be concerned that doing everything in rules will complicate the whole UX for new users. Most users will know scenes from other systems.

You assume the current UI. You assume we do not introduce the word nor the concept of "Scene" to OH. Neither of which are being argued for. Yes, we should have something called a "Scene" and yes we should have a custom screen to define them to limit the clicking and complexity.

But I am vigorously arguing that "Scenes" are not something new and completely different from rules. A "Scene" should be documented, presented, and described as a special case of rules. And no changes to core are required to support them, just as there are not changes to core required to support Scripts or Schedule.

And while some users have exposure to the concept of scenes from other systems, exactly what a "scene" means and what it can do is different between almost all of them.

[J-N-K]

@kaikreuzer This also need to be transferred to ui, can you do that? Thanks.