Add a scene editor to Main UI

[J-N-K]

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

Signed-off-by: Jan N. Klug [email protected]

[relativeci[bot]]

Job #636: Bundle Size — 15.97MiB (+0.05%).

97901b0(current) vs eb0b49d main#635(baseline)

Metrics (3 changes)

	Current Job #636	Baseline Job #635
Initial JS	1.72MiB(-0.24%)	1.72MiB
Initial CSS	608.33KiB	608.33KiB
Cache Invalidation	84.66%	83.71%
Chunks	218	218
Assets	688	688
Modules	2013(+0.2%)	2009
Duplicate Modules	110	110
Duplicate Code	1.82%	1.82%
Packages	133	133
Duplicate Packages	15	15

Total size by type (2 changes)

	Current Job #636	Baseline Job #635
CSS	856.37KiB	856.37KiB
Fonts	1.08MiB	1.08MiB
HTML	1.21KiB	1.21KiB
IMG	140.74KiB	140.74KiB
JS	9.04MiB (+0.08%)	9.03MiB
Media	295.6KiB	295.6KiB
Other	4.59MiB (~+0.01%)	4.59MiB

---

View job #636 report View main branch activity

[ghys]

Thanks for submitting the PR, I tested it right away as I had the IDE/dev server running; I also happen to have rules with the "Scene" tag and only ItemCommandAction modules and they work nicely already. I'll make some experiments later to try to improve the editing experience and make it less "generic" i.e. provide appropriate controls to edit the state and if possible avoid the popup.

All things considered maybe the triggers/conditions sections could be retained, for instance:

• item command triggers to have a proxy item (so the scene can have a state after all, and be called from sitemaps)
• run the scene e.g. at 7AM on weekdays excluding holidays - without the help of another rule. Note that such scenes could even appear in the schedule if they have both the "Scene" and the "Schedule" tags!

[J-N-K]

This state/trigger-issue was discussed in the forum thread and my impression was that we agreed on scenes being stateless and having no triggers, so only storing a set of states that are "restored" when the scene is called. It's super easy to add a rule that has an "run rule" action and that can handle conditions, triggers or whatever is needed, but it keeps the scenes as simple as possible.

Another thing is that the item-list should be filtered, it makes no sense to have Contact or Image in the list because there is no command that can be send to these item types.

[ghys]

This state/trigger-issue was discussed in the forum thread and my impression was that we agreed on scenes being stateless and having no triggers, so only storing a set of states that are "restored" when the scene is called. It's super easy to add a rule that has an "run rule" action and that can handle conditions, triggers or whatever is needed, but it keeps the scenes as simple as possible.

I know, but I changed my perspective when seeing my existing scenes (which have triggers) in the scene editor with the trigger not accessible (except in code view). If I have 5 scenes and want to add a dropdown in a sitemap to launch them, I would need a proxy and 5 additional rules to launch the appropriate scene when the item receives a different command (or a single rule with some scripted logic). It'd be way easier to have at least a simplified optional item picker+state in the scene editor, managing a single ItemCommand trigger (again, making it clear that it's optional) to avoid the hassle. That was my original idea and then I figured, why restrict the triggers/conditions when you can also have the morning scene on sunrise etc. But for these I agree making a rule isn't too hard.

[florian-h05]

What is the current status of this PR? Is there any chance to get it into the next release?

Regarding the trigger discussion: I‘ve partly followed the discussion in the forum, personally I agree with Yannick that scenes should provide a simple Item+State trigger. Otherwise you‘d need an extra helper rule to use scenes from BasicUI and so on.

[J-N-K]

As I said in the forum thread: If we start to introduce an item trigger here, the next request will be to have time-based triggers. Then someone will ask, why conditions are available for rules but not for scenes. In the end the editor will become as complex as the rule editor and we‘ll lose what we introduced scenes for: simplicity.

The idea behind scenes should be that they are simple state aggregations that can be called by rules.

[florian-h05]

I get your point, but IMO the ItemCommandTrigger is required for calling a scene from Sitemaps (unless you don’t want to create a helper rule) and a „basic“ trigger, and all other triggers like Time of Day are more advanced. If one asks why we don’t have the other triggers and conditions, we can answer: the ItemCommandTrigger is there to allow calling a scene from Sitemaps. To keep the scene editor as simple as possible, we don’t support other triggers and don’t support conditions.

Let’s have a look at HomeKit to have an example how other smart home platforms handle this: You can create a scene and call it from the UI (in openHAB, we need an ItemTrigger to call a scene from Sitemaps, for MainUI we can introduce an action or something like that), but to run a scene at a given time of day or when someone arrives at home, you need to create an automation in HomeKit.

[rkoshak]

for MainUI we can introduce an action or something like that)

MainUI already has a widget action that lets it call a rule directly which should work for this. It's only sitemaps/HABPanel that would need an Item.

[florian-h05]

MainUI already has a widget action that lets it call a rule directly which should work for this. It's only sitemaps/HABPanel that would need an Item.

Thanks for pointing this out.

As already said, I‘d prefer to have the Item trigger for Sitemaps/HABPanel; but to be clear, I am also fine without it. My major point is to get the scenes, as this is some large improvement for our users.

[ghys]

As already said, I‘d prefer to have the Item trigger for Sitemaps/HABPanel

I'm still on the fence but I think I would agree with that. As said above, having multiple scenes driven by commands received by a single item (and the appropriate sitemap dropdown) is an all-too-common scenario which we wouldn't not try to at least facilitate. Having 6 scenes and then 6 rules to react to commands to an item to launch these scenes seem really overkill when the scenes really are rules so they could at least support a "run this scene when this item receives this command" option (which wouldn't be as elaborate as a regular rule's UI).

This is more controversial, but I could also see a simplified UI for scheduling a scene where you could choose when to run them, with an UX completely different than the generic "triggers and conditions" but something more elaborate which would ask the days of the week (or weekdays/weekend), whether holidays should be excluded (with Ephemeris), and the time of the day when they should run. The triggers and conditions required would be completely managed by the UI (but you would still have a Code view). Once implemented this "schedule" interface would also be useful for rules with the "Schedule" tag.

[J-N-K]

We could also merge it without and see where it goes. It's much easier to add a feature on heavy request than to remove a mostly unused feature.

[MyRaceData]

I agree, thank you Jan, let's just give the users scenes, and in the future, if users like it and use it, triggers can be added right? Lets roll it out, scenes in openHAB is a great enhancement from a user point of view

[rkoshak]

Having 6 scenes and then 6 rules to react to commands to an item to launch these scenes seem really overkill when the scenes really are rules so they could at least support a "run this scene when this item receives this command" option (which wouldn't be as elaborate as a regular rule's UI).

Maybe I'm misunderstanding things, but I don't think anyone is talking about a one-to-one limit where a single rule can only trigger one scene. So you could have the one rule triggered by the one Item that launches all six scenes. Though it would be in sequence which might be undesirable for some perhaps. If you want them in parallel you'd have to do the six rules.

We could also merge it without and see where it goes. It's much easier to add a feature on heavy request than to remove a mostly unused feature.

Agreed. And the sneaky among us will know it's just a rule and can add triggers through the REST API if we are really determined. 😈

[kaikreuzer]

So you could have the one rule triggered by the one Item that launches all six scenes.

This is actually what I have in place since 10 years in my setup already (scenes being "scripts" in the DSL world). Since we are only talking about a trigger for sitemaps, we are probably talking about tech-savvy users that wouldn't have a big problem in adding a single rule for the triggering. Since the Main UI can directly trigger the scenes from a widget, I'd think this is good enough, so I'd also vote for keeping scenes simple and merge like it is.

The PR just needs to be rebased as it seems, @J-N-K.

[florian-h05]

@ghys Any chance to get this into 3.4.0?

[ghys]

No. This is a significant feature, and we're in a feature freeze. It also needs improvement. We'll plan it for the next release.

[jlaur]

@ghys, I'm reading through this PR and corresponding forum thread for the first time, so forgive me if I missed something. But since we are now moving ahead with 4.0 and there seem to be some consensus to merge this PR "as is" and see where it goes, what is missing to get this PR merged?

[ghys]

I wanted to open a PR against this PR with a number of UX improvements first, rest assured you'll get it way before the final 4.0 release. I don't see any need to rush it. Right now the scene editor is functional but not user-friendly enough to justify adding the feature early as it's not much more than rules.

In a nutshell:

• the YAML view shouldn't have been removed, even if the serialization isn't the complete rule, I insist it should exist as they are useful for instance to duplicate stuff easily
• ability to add multiple items at once
• appropriate controls to set the desired state - color pickers, sliders, lists when state/command options are available etc. The "raw" input box could still exist
• 2 way sync buttons for one or several items between the actual current state and the desired state for the scene - this would allow the user to design the scene interactively, setting the items and the action modules back and forth to their desired state until the scene is complete
• minor: the placeholder when there's no scenes is still the one for rules
• could be another PR: rename the "run rule" action to "run rule, script or scene" and group the rules in the rule picker into 3 groups (Rules, Scripts, Scenes)

and there seem to be some consensus to merge this PR "as is" and see where it goes

I know I won't make any new friends by saying this, but here goes, "the consensus" didn't write most of this UI and is yet not still maintaining it ;)

[J-N-K]

Didn't know UI was a one-man-show.