Scenes - OpenHab vs Home Assistant in 2022

Setup, Configuration and Use Scripts & Rules
21

I don’t think this is an accurate statement. I’ve helped many users without a basic understanding of the difference between Items and Things complain about the limitations of profiles.

But whether or not they are beginners is irrelevant. The expectation is there that that should do more and when they can’t the response is invariably “why do I have to use something as heavy weight as a rule to do that?”

It’s not dumb. It’s actually pretty cool. It has it’s own tab so you can see when your time based rules will run on a calendar. Unfortunately it can’t handle (yet?) a bunch of time based stuff like ephemeris, probably not the Time is <item> trigger, etc.

But, IIRC, it was always just a first step towards implementing a scheduler in OH. Something like the timeline picker widget only built in. Perhaps a place to see when timers are schedule, not just rules. In short, I think Schedule is intended to become a place to see the upcoming schedule of activities in OH, and that’s pretty darn useful.

I actually like having it separate. I would have chosen a different name though. The reason I like it separate is because these are kind of a personal library of functionality you can call. These really are kind of something different in that respect. But the name causes confusion. I’ve seen people try to figure out how to run their .sh script from there, actually code their .sh script from there, create rules here with triggers, write their code here because it didn’t occur to them that they could code their actions as part of the original rule, etc.

Were I king, I’d probably not eliminate the Scripts menu but move it under Developer Tools. In a lot of ways, it’s kind of like the Custom Widget builder and Blockly Library builder. I’ve long considered what I’d rename it to and not come up with anything satisfactory so I suppose “Scripts” would be the name I’d use.

But I’m not king and I can see good reasons to keep them there too.

But this really is moving away from the OP’s topic.

Two. Scripts are still a thing you can run from executeCommandLine and the Exec binding.

@florian-h05 and I are working on a complete rewrite of the rule docs. You can find the tracking issue here and our current work in progress here. I’d love any additional contributions, even if it’s just review. PRs can be submitted to my fork here.

Both of us are pressed for time so progress is slow. If you do want to pick a topic and write about it, just let the rest of us know in the comments so we don’t stomp on each other and duplicate work.

I did not think of adding the idea of rules as scenes to the docs so would definitely welcome any ideas on how and were we could fit that in. That can help address the OP’s concerns in the short term.

As a quick background, the overall approach is to add a rules page to the concepts section and then add a section like we have for UIs where we provide the reference guides for UI rules, Blockly, and Rules DSL. The driver is to make it clear that all rules follow the same overall structure and concepts. The primary differences are syntax. So let’s structure the docs that way.

2 Likes
22

I will definitely try to carve out some time to take a look.

23

Scenes have no triggers in other apps, neither do they have triggers in Home Assistant. This requirement I’d say is hypothetical.

Maybe but as Justin mentioned, scenes is a well established concept in home automation and have clear boundaries. Either way, I suspect that any new concept addition will cause some of these debates.

Rules are great but if everything ends up in rules, it’s going to be hard to manage for the common mortal. In terms of math - each scene in Hue can easily involve 10+ items and you can easily end up with 10+ scenes for each room. Multiply this by room - I don’t think stuffing this in rules is a clever idea even properly tagged.

24

Done - I created this feature request Add support for Scenes in OpenHab · Issue #3087 · openhab/openhab-core (github.com)

2 Likes
25

So you can’t say “at 7:00 run the evening light scene” or “when I leave run the away scene” or put a button on a UI to be click to enable a scene? Then what good are they? How are they caused to run off not by some of event?

If the answer is, “they’d be run from a rule” then my concern is no longer theoretical. The question becomes “why do I have to define both a scene and a rule? Why can’t I just add triggers to the scene?”

So stuffing it in some other menu called “scenes” somehow solves this problem? I don’t see how. If you have a hundred or more of something, it’s going to be hard to manage no matter where you put it. So there needs to be a more robust management than mere tags. Why can’t we find a better way to manage rules then instead of introducing new concepts?

And this is all missing my main point. Every new concept that gets added to OH, especially a concept with overlap in capability of an existing concept, adds too the over all complexity of OH, increases the amount of stuff the end users have to learn about, and makes configuration more difficult.

Again I’m not arguing against the idea here, I’m just pushing everyone to think wholistally. What does the addition of a new Scenes concept mean to OH over all? How would they be used? How are they different from what already exists? How would they interact with what already exists? Can/should we reuse or whatever what already exists to better support them?

For example, I don’t see why completing the extension of the sematic model to rules (they already support semantic tags), adding new rules/scenes nodes to the semantic model tree, and slightly adjusting the UI to only present Item Actions when one selects to create a scene wouldn’t fit this requirement and then some. In the end, do we really need some brand new concept called “scenes” or do we just need a better UI to organizing and build rules that implement scenes?

26

Everything is possible theoretically - you could have triggers inside the scenes or have the triggers somewhere else but why would OpenHab need to reinvent the wheel? Every other app has the two separated - if these are not - isn’t this going to confuse the user even more? Hue=Scenes + Automation. HA=Scenes + Automation/Scripts. With Hue, changing scenes is even a special button on a switch.

Moving scenes outside rules would enable: 1) better dialogs to edit presets. i don’t see how a rule editor can be easily converted to a friendly editor with 20 lights. 2) there are so many ways to abstract scenes. Hue just puts a smart icon for each scene. Then you can see the details. This puts the details of the settings for each light 3 dialogs away. I can browse rooms, browse scenes without being overwhelmed.

Using rules everywhere could make it quite difficult to bring that abstraction in the UI - and ultimately, I don’t really care what the backend is - I’m sure rules is possible in a way with some metadata but what I really care is a good UX to navigate that. Group → Scene → Edit Scene with proper UI to see all important controls on a single screen. I put examples of that in the PR.

A common user should be able to use scenes without knowing what kind of backend system is used and without going into a rule editor.

27

Have you used the UI rule editor? What is a scene except for “command these Items to these states” right? So why not present a dialog to create a rule and only offer Item actions? There is already a precedent for presenting different UI dialogs in different circumstances. For example, a Script is a rule like any other but when you create one from the Scripts menu you get a dialog to choose the language and then all you can do is write the code. So present a dialog that doesn’t let you do anything but add Item Actions and call it a “Scene”.

I can’t get to my OH right now but create a new rule in the UI. Imagine removing the triggers section and the conditions section. Now add an Action and choose Item Action. Now imagine you didn’t have to choose and when you click on add action it automatically jumps to presenting the Item Action instead of give you a choice.

What more (or less) do you need to define a scene? You have a place to select your Items and define what they should be commanded to using everything that is already there to create a rule. The only difference, the only change required, is to modify MainUI to present a more limited and restricted dialog when the user indicates they want to define a scene.

28

Yes I am familiar with the rule editor. Whether scenes are using the rules or not, at the end of the day, it doesn’t matter to me but today, you would need to drill down in the action details and there would be a second or third click to get to the color editor. And repeat this for all the items in the scenes, that is a massive and unfriendly number of clicks.

For a practical flow - if I have 20 lights, the UX must have a flow to offer the color editor for each item in a single click and have all of them accessible on the same page.

29

I’ve never been arguing that we must only allow rules in the form they are today. My concern is this whole discussion seems to be wanting to work around the current rules editor by introducing something brand new. Why not take what we already have with rules and make that better instead?

3 Likes
30

That’s interesting. Then there’s some lack of clarity somewhere here, because taking “what we already have with rules and make that better” is exactly what I thought this proposal was.

As I see we have two givens:

  1. Users, especially new users expect a home automation platform to have something called scenes.
  2. In OH scene functionality is a subset of rule functionality so there has never been a push to incorporate the term “scene” into the core or UI.

Result: New users get confused/irritated with OH when they cannot set up a “scene”.

Solution: Let the UI bridge the gap and have a “scene” link that takes the user to a rule page where the rule wizard is slightly modified to most closely match that subset of functionality users are comfortable calling scenes. That sounds very much like:

unless I’m missing something.

4 Likes
31

I’m sure it is possible, but I’d be surprised that in the long term, this is not a more complicated solution rather than having that separated.

  1. It won’t take much for a rule to not be able to be opened in a scene editor - a scene editor would need to assume that a rule only has a series of actions to items with constant values - and limited to one action per item. The minute a rule has anything different, it’s going to be a more complicated story.
  2. transitions are going to be complicated to support - yes I’m sure more rules could be built but keeping these rules coherent seems like a complex undertaking.
  3. Triggers - a scene editor would need to make assumption on the trigger
  4. adding context to all existing rule dialogs so that they don’t list 100+ scenes also seems like a major rework
  5. I would think that building UX on a well defined declarative model rather than code parsing and generation would be more flexible
  6. I personally like the rule editor as is. I don’t know why it would need to go under a major rework to support scenes.

And to add to the discussion, I don’t see why - as interim solution - your existing widgets couldn’t be integrated in the solution.

32

yes!

33

The minute it has anything different is it still a scene? And if scenes are implemented using rules, you could “convert” the scene to a rule at the touch of a button (or some other simple setting) and you wouldn’t lose anything.

What sorts of transitions do you have in mind? How do you envision these being defined and handled differently/better as a scene?

I guess we need to decide on this point. Previously you argued that a scene doesn’t have triggers. If a scene does have triggers, why would defining them be any different from how rule triggers are defined? Even if scenes were a completely and wholly independent thing in OH, why wouldn’t you make defining the triggers the same?

Seems like adding rules and scenes to the semantic model would solve that. There is already indication that rules are intended to be added to the semantic model given you can apply semantic tags to them separately for “regular” tags. Search is also very helpful as is the developer sidebar.

Again, why invent new when we can make what we already have better?

The UI rules I’m proposing using are defined declaratively. That’s why they seem to be a natural fit for the implementation. That means that all is needed is UI work without backend work.

I’m not suggestion we replace the existing rule editor to define generic rules. I’m proposing a new “scene” editor, similar to the Script editor, which is tailored for the definition of scenes. When you create a scene, you get a dialog that just lets you add Item command actions (maybe triggers?) and is customized to make doing that as efficient as possible.

Given that the widgets also depend on rules, I’m not sure it’s as easy as just submitting them as is to the repo. The rules at a minimum would need to be rewritten from scratch as ? (binding?, feature in core?)

34

Hey, sorry for the late reply - I was mentioned during my holidays so I lurked and meant to reply when I could lay my hands on an actual keyboard 10 days later… and obviously that didn’t happen.

I would tend to agree.
In fact if you look closely all entries under the “Automation” group in the settings menu are just specialized UIs to configure a common artifact - rules. Scenes could just be that, rules with a special “Scene” tag attached to them, which would have their dedicated UI. Home Assistant’s scenes editor is mainly useful because 1) it only asks for devices and their target state, and 2) (crucially) when adding a device, the target state is set to the current state, so all you have to do is set your devices/entities to the desired state by other means, and create a scene, and lo you can now recall these states later at will. So it certainly could be achieved with a UI that can just handle rules with no triggers, no conditions, and only the ability to add “command” modules in a simplified fashion, very much like Scripts.

Actually I already had this concept in mind years ago when I made the rules UI - you’ll notice that you have a semantic tags picker for rules, which seems out of place and largely unused. This was initially meant for scenes. The idea was to add buttons in the semantic cards on the Home page to launch these “semantic” scenes. For example you could assign scenes to a specific location (“LivingRoom”), or class of equipment (“HVAC”) or property (“Light”) and it would display buttons accordingly somewhere in the relevant card - if the rule has both the “Scene” tag and the semantic tag. You could also perhaps customize the buttons’ order or appearance (color…) using additional tags, or other means.
Obviously this was never implemented but I still like the idea.

A couple of further observations:

  • Conceptually, does a scene have a state? I for one have still a Scene_General item and a set of rules that date back to my first day with OH 1.8. I also have rules with conditions so that they only trigger e.g. on the “Night” scene (which use presence sensors to make a dim light pathway automatically from the bedroom to the bathroom, if you must know). Also, while stateless scenes (that is, just rules with the “Scene” tag) can be triggered manually from many places in main UI pages using the “Run rule” action, you can’t do the same in sitemaps.
  • Invariably there will be cases where the simplified UI will not be enough and there would perhaps be a need to have a button converting the scene to a regular rule - this also applies to scripts! It’s just a matter of removing the “Scene” or “Script” tag.
4 Likes
35

This is what I was trying to suggest, but more fleshed out. I view scenes as a good way to help new users quickly “succeed” with openHAB by leveraging concepts that are familiar to them.

I agree that it’s not actually hard to make rules that turn things on/off, but we’re fighting perception more than reality. So I’m thinking of scenes as “rules with training wheels”.

I also have an item that functions like Scene_General, but I call it System_Mode.

I would vote for scenes to be stateless, so that they really are just simple rules and nothing more. Otherwise, people will become dependent on them and ask for more functionality, when we really want them to realize that “scenes are just rules”.

As well, there are going to be people who want only one scene to be active at a time (a new scene cancels the current one) and others who want to have multiple scenes at the same time (for different areas of their home). I don’t think we want to get into that.

It’s also worth noting that while we want to take advantage of common terminology, we also want to avoid confusion with the scenes available in Google Assistant (and, I assume, Amazon Alexa). GA is still going to require an item that has the scene metadata.

36

I disagree - editing scenes and capturing scenes is simply not possible today (except capture - which is somehow possible through the ux scene widgets). It is not a perception issue that creating custom scenes would be time consuming otherwise.

I’ve been playing with Home Assistant lately and their scene implementation is a prime feature. HA did load all my hue scenes and integrated them in the HA dashboards and makes internal/external scenes completely seamless to the user. They all show up for each Area in the dashboards without any additional effort.

37

I’m not so sure scenes should be stateless. Or put anther way, there should be something somewhere to tell us which scene(s) are currently active.

But I think what you and @ysc are describing are events that trigger a scene to execute which is a little different. In that case, I think that what sorts of events that can trigger a scene should be left open and not predefined. If one wants to trigger a scene based on an Item event, time, Channel trigger event, manually, or anything else that can trigger a rule we shouldn’t arbitrarily limit that.

But there are two sides to this scene state: what scene’s are active and what events trigger them. I’m thinking that these are not the same. And we might need something "clever"to keep track of which scenes are active. But I would save that to be an addition after scenes themselves get implemented. I can actually think of some ways to implement this in a rule template in the mean time.

+1

38

That’s an interesting thought - and I haven’t seen any system that has proper tracking for scene states. Both HA and Hue do not have an “active” scene. In these systems, a scene is just sends a series of settings with a transition. If the active scene could be synchronized from bindings, this would be a really nice feature.

39

That’s going to be up to the binding authors to decide whether/how to support that, assuming that there isn’t a technical or policy reason why a binding cannot create rules.

40

Scenes should be stateless. Otherwise you’ll run into issues as two scenes contain the same items. ´

  • scene1: light1 50%, light2 50%, light3 100%
  • scene2: light4 100%, light5 100%
  • scene3: light3 0%, light4 100%

Now consider the following situations:

  1. scene1, later scene2
  2. scene1, later scene3
  3. scene2, later scene3

Which ones are active at the end?

  1. I would say both, they are independent.
  2. I would say only scene3, because a part of scene1 is overwritten by a new setting
  3. I don’t know. scene3 overwrites a part of scene2, but on the other hand it is the same value.

It’s nearly impossible to track that for more difficult setups (which is the reason why hue or deconz consider scenes to be stateless).