Scenes - OpenHab vs Home Assistant in 2022

I don’t want to stir any debate but I realized that in some of the more recent HomeAssistant versions, they have a native support for scenes. Been waiting to see something like this for a long time to unify different equipment around the house.
In OH3, I noticed that there is a set of widget/rule/etc. to manage scenes in OH but this doesn’t look as easy to configure as the scenes in HomeAssistant. OH3 is fantastic, but haven’t seen any major new features in the last couple releases. Is there any recent opinion on OH3.4 vs current HomeAssistant? Any specific feature I’d lose if I switched over HomeAssistant?

I can’t speak to Home assistant, I haven’t tried it in years. But, I can say that OH has a very simple, native system for “scenes”, it just doesn’t use that word.

If we consider a “scene” as any situation where a single action results in multiple devices being changed to some preset value, then in OH, that is just a rule and can be entirely configured in OH3 UI using the rule wizard. With the item trigger and item action parts of the rule wizard you can create a scene with as many items included as you would like. What is it that home assistant provides beyond this capability?

1 Like

You are right - the rules are amazing and the rule editor in OH3 is excellent. I simply already have a ton of rules, and really wouldn’t mind having all the scene related stuff in a separate place. The only main difference from what I’ve seen is about the ease of editing and creating scenes and integration with other rules. However, it looks like your widget goes a long way in that direction but given how long the scene concept has been debated here, I have little hopes that it will ever make to the core.

This is a perfect use for the tags in the rules. Just give each of your rules that is really just a scene a Scene tag. then when you go to the rules page type Scene in the search bar at the top and the page will filter out all the other rules and only show you only your “Scenes”.

Again, I’m not pushing an agenda here, I’m trying to gather information. I haven’t used HA in forever, so I don’t know what this flow looks like from that perspective. Can you give an example. Just from a theoretical perspective, it’s hard to imagine that it’s really that much more efficient than using the rule wizard because that really does strip it down to a minimal number of clicks:

Create a scene:
  Settings -> Rules -> (+)
    Add trigger -> Item event -> [Find and select item] -> Trigger type -> Trigger value (optional) -> Done
    Add action -> Item action -> [Find and select item] -> Item command value -> Done
    (Repeat add action as required)

Short of allowing multiple item additions from the same dialog window (i.e., removing the requirement to press Add action and Item action each time), it is difficult to see where this process could be streamlined and still collect all the relevant information.

As for interaction with other rules, an OH rule can already interact with other rules as well via Add action and Other rules. Then your “Scene” can activate some other rule as part of the scene or be activated by some other rule.

Note I’m not even advocating for the use of the widget as the simplest path here. The widget has some advantages (e.g., can be configured by non-admin users) and some disadvantages (e.g., cannot interact with other rules; can be configured by non-admin users - depending on your opinion and the critical status of the scene) relative to the use of rule-based scenes (and I, in fact, use both methods depending on use case and the various pros and cons).

I don’t think that there’s really any opposition from the core devs or the UI devs. My guess is that it’s just that no one has really demonstrated that what already exists is sufficiently inadequate to warrant them putting time into this. That’s one reason why I’m hoping you can elaborate a little bit on what it is that makes the HA system appear easier. If it really is just a nomenclature issue then that can be addressed in the docs without taking time away form the other things the devs are working on.

1 Like

The Hue app has IMO the concept of scenes nailed perfectly, there is no need to reinvent the wheel. Create, add, edit scene for each room (room would be a group in OH3). Build automation with scenes (I don’t need to refer to each item separately. I want a trigger and then group1.SetScene(“morning”) or group1.SetScene(“brightday”) when it is bright outside - I have a sensor to check that. If I have 10 lights or so, in my automation I can refer to scenes, I don’t have to bring every single item. Plus I want ot be able to bring new items to the group and just edit my scenes - not my rules. I know rules, triggers, etc. are powerful but it is not a practical solution to bring more than 10+ items in a rule.

All I want is something like this with an easy editor and API to control it from rules

OK, in the interest of refining where OH might go, let me continue to play devil’s advocate here :smiling_imp::

This looks pretty much identical to what you’ve got:

And now, with the scene (rule) defined, I can control it from (other) rules:

Agree - I think your solution is super close. All it might need is some better organization inside the rules, like auto tag the scenes, put them somewhere else in the UI. Also I haven’t tested your widget yet, my only concern would be that the editor for a scene could be a bit fragile if you manually edit the rule that corresponds to a scene - vs having a native structure to store the presets.

I think this may be the right direction. There are already precedents for exactly this sort of thing. The “Schedule” setting page is just a slightly different organized view of only rules with the Schedule tag and the (+) button on that page just opens a rule wizard with the Schedule tag auto set. It doesn’t seem like a big task to replicate this functionality with a similarly derived page named Scenes. Similarly, the Scripts settings page is also just a list of specialized rules. In this case they are rules that by definition do not have a trigger and so can only be run when activated directly or called by some other rule (which sounds a lot like what you are envisioning for scenes).

You’re absolutely right that there is an appearance that OH doesn’t handle “scenes”. This question comes up too often to ignore that reality. Perhaps if you put a proposal such as this up on the UI github page it has the right balance of effort/improved user experience that would get a dev’s attention.


There are about 50 suggestions in the github already around support for scenes since OH1…

Yeah, I’m sure. However, I think that because this one is not just a request, but rather a specific, thought-out suggestion that matches an already in use design choice, it might just a much better chance than all those previous ones.

I agree with Justin. It is the responsibility of the requestor to explain in detail why their request is an improvement over existing functionality, thus making the effort valuable and worth prioritizing over other requests. A lot of feature requests (not just for openHAB) don’t go that far, because requestors often assume that what they want is obvious to everyone else.

I’m not laying any blame for this…assuming that other people understand us is actually just a bad habit of humans in general. :wink:

Based on this discussion, you can make a case for adding scene functionality that’s very specific and–perhaps more importantly–serves the expectations of users coming from other systems (HUE, HA, etc.). Rather than having to explain that rules encompass scenes, we can ease them in with a concept that they already understand, and then present rules as advanced functionality.

If it’s simply a bespoke “Scene” interface that generates an auto-tagged rule, then there’s a good chance that the benefits for new users outweight the amount of work required.

1 Like

Maybe for scenes duplicate the script part and also automatically add an switch item that will activate the scene, to make it easier for users to include the scene into widgets or Alexa/Google home or other integrations :thinking:

In addition some additional thoughts (where I don’t have an answer to):
does any other home automation solution have an option to deactivate a scene again (e.g. undo what ever a scene will do) or to detect that a scene is active (e.g. if you randomly turn on some lights, these settings might match what a scene is doing and therefore the scene is considered as active)?

These are not hard to achieve,especially with the addition of the Item.

  • Restore to previous state: there are already a storeStates and restoreStates pair of actions. The rule the wizard could add the Items that are a part of the scene to storeStates when the scene is activated and restoreStates when it’s deactivated.
    However, in practice this can cause a ton of weird behaviors and side effects based on my experience with Tasker. This is especially true when you have the same Item that’s a part of more than one scene that can be active at the same time.

  • To detect when the scene is active, just look at that Switch Item you created. That can be used to both trigger the scene and to keep trac of when the scene is active.

But I’d play a different kind of devil’s advocate here. A good deal of confusion and complexity comes into play the more different ways you have to do something. We already have a huge number of issues with the overlap between rules and profiles and users get mad when they can’t do X in a profile because they don’t wanna create a rule. People are constantly confused about what “Scripts” are in MainUI, so much so that I added a section discussing that in the Getting Started Docs and the rewrite of the rules docs (in progress). I don’t think many are using the schedule that much but that’s another place for confusion.

The problem is people assume that since they are in a separate menu they must be different when in the end they are all just rules. Adding yet another way to create rules is not going to help the matter any. And, as with profiles, people will get mad when they want to do something just a little more complicated than these Scenes can handle and they have to write a rule (even though that’s what they are doing in the first place.

I’m not arguing against anything here. I just want to point out that there is a cost when adding features, particularly when those features overlap with existing features.

1 Like

This is often true, to be sure, but I don’t think it always has to be true. I would argue that the issue with profiles is not their overlap with other parallel functions but that they are one of the most abstract of the OH ideas requiring a fairly advanced understanding of the flow of information.

The fact of the matter is that this “Scene” nomenclature exists in the home automation world and it doesn’t really exist in OH and this causes no end of confusion. How often do questions pop up like “I was looking at the online OH demo and one of the buttons activates a scene but it is not connected to any scene it just runs a rule. How do I set up scene?”.

This is certainly true, but there’s more to it. Most users just don’t care that it makes sense from a backend perspective that scenes and rules are handled the same way, from a user perspective there is a distinct difference. While I’ve been using OH for so long it is not something I wrestle with, I would say that for many users “Rule” = decision tree, but “Scene” = static set of device settings. These are in fact fundamentally different in many important ways. I would say that this dichotomy is actually already subtly included in MainUI in the difference between the rules and scripts pages. If scripts are “just” rules without defined triggers then the options for script actions should be the same as the options for rule actions, but, of course, they are not.

Available Rule Actions:

Available Script Actions:

Scripts are restricted to the “decision tree” subsection of rules without triggers. So, where is the “static item state” subsection of rules without triggers? Well that’s really what most users want to call scenes…

What I like about where this discussion ended up (a place that many of the previous discussions about Scenes never did get to) is that I think this is one of the places where adding something actually alleviates more confusion than it creates. This proposal balances out that missing theoretical piece of “rules without triggers” and simultaneously incorporates a heretofore missing common home automation term that new users are very much expecting to find.

As is often the case, Russ said it much more succinctly than I managed to:

Beginning users can happily get on with their home automation without ever having to wrap their heads around the fact that “scenes” are just “rules”. It strikes me that it is much less total confusion to let OH match beginner home automation users expectations and then provide intermediate users with a revelatory glimpse under the hood, than to throw those beginner expectations into conflict with reality right away or expect the home automation world to adapt its terminology to OH.


I have to agree with Justin here. I know adding another redundant way of creating a ‘rule’ seems wasteful and may cause some confusion but to me ‘scenes’ really does seem to be a common use case and a popular concept. Most new users intuitively seem to get the idea with no explanation.
I also agree with Russ

1 Like

But are they without triggers? If we make them without triggers I guarantee the first thing that will be asked for is to add triggers to them.

Again, I’m not arguing against adding a scenes menu or category or any of that. I’m just raising the issue that we need to not think that doing so will be “free” when it comesto complexity and such.

Were I more active on Github I would have fought against the introduction of Profiles in the first place (I would have lost but that wouldn’t be the first time). I’ve since come around a little bit but I still am constantly fielding posts along the lines “what I want to do is so simple, why can’t I use a profile?”.

In philosophy I completely agree. However, we’ve failed again and again at this because as soon as the simple doesn’t quite meet their needs we get “but what I want to do is so simple [it’s not really], why can’t I just do it with a scene?” It sets the impression that rules are this big complicated concept that only the really advanced OH users should ever have to dirty their hands with. When in fact, there is absolutely nothing wrong with super simple rules.

Rules are not and should not be considered a last resort. They are not and should not be beyond even the least technical of OH users. The idea that “hey, I need to create a rule for this” should be no more outside the norm than “hey, I need to create an Item for this.” But I keep seeing the more rule alternatives we add (even if they are just a special case of rules) the more we get "but I shouldn’t have to create a rule for that.?

Rules get set up as this super heavy weight concept that should only be needed as a last resort when you have something really complicated to accomplish. When you have something as simple as “turn on the light when sunset occurs” it feels wrong to need to create something as heavy weight as a rule to handle that. And that’s the problem. Rules are not just to handle really complicated stuff, they are also for simple stuff like this. But the more stuff we add that do what rules do, or are rules just of a different name, the more the mere thought that I have to create a rule becomes too much.

I saw it start with the addition of profiles. I saw it grow with the introdustion of Scripts and the Schedule in MainUI, and I see it becoming worse if we are not careful in how we introduce the concept of scenes.

Once again, I’m not arguing against the addition of such a concept. I’m just cautious because I’ve seen what happens when these are added, and it’s not all good.

1 Like

I agree rich, people do seem to have some aversion to rules, which I’ve never understood. I remember Rossko telling people ‘they are free’ no biggie, just write another rule, no big deal, it doesn’t cost you an extra dime.

Well… if they know what a profile is, and how to use it, then this is not a beginner

yeah, this is really confusing, I agree, I know what a schedule is but still, why does it have it’s own tab? Schedule is just dumb fluff
Anyhow… @ysc are you paying attention to this discussion?
Can you weigh in on how you feel about maybe including this type of thing into Main UI?
Should we consider offering a a PR with this concept or crawl back under our rock?

1 Like

Screenshot from 2022-09-11 21-47-33
Rules… automate with triggers and actions
Scripts… rules dedicated to running code
Schedules… view upcoming time-based rules
So what is a script???
clicky clicky
Screenshot from 2022-09-11 21-51-16
Scripts are a ‘special kind of rule’ with no triggers
How about, you write a rule, but you don’t create a trigger
You go to save your ‘Script’ (an ordinary rule but with no trigger) and it pops up a dialog box that says ‘you’ve created a rule with no trigger, it will only run if you call it from another rule’
Do you want to add a trigger? No, I just want some code to run from another rule or, whoa, ok, I’ll add a trigger
Scripts eliminated from UI, it is a redundant term in openHAB anyhow
Schedules… Add a check box (marked optional) to add a schedule tag to a rule (my understanding is this is all a schedule is right)
Schedules eliminated
Much confusion removed, new users not confronted with needless options, Create a rule, no trigger? Advanced user knows he can call from another rule, noob is reminded his rule has no trigger. Schedule… well just dumb, throw it away
Andy is king for a day, Scripts only have one meaning now, schedules are thrown in garbage ans Justin’s interface becomes part of main UI

sigh …Can’t argue with you there. Wish I could, but…

Never thought you were. Just always appreciate it when you add your experience and insight to the depth of a discussion.

I’ve been teaching in some form or another since the last century. There’s just no solution to this problem. It’s universal, pervasive, and, on occasion, soul-crushing. I never let it stop me from trying make it easier for people to learn things though (I just go through more glasses of port on some nights than others).

I can’t agree strongly enough with the second half of this. The eternal optimist in me, however, will always believe that somehow we can eliminate that mistaken, lead-in impression. I’m not saying that a proposal such as this one is definitely the right answer, but there’s certainly a chance that, for some users, working with “scenes” and then learning that scenes really are just rules actually removes the fear of rules.

It’s still possible that all of this could be handled solely within the docs with a couple of pages demonstrating the congruence between scenes and rules. I’m not sure which is the better solution. Docs would certainly provide more clarity whereas an actual UI page would reach more users…