I got a bit lost when going from method 2 to method 3 and 3.5, where do you set the values of the items, eg brightness, color etc?
Methods 3 & 3.5 use “storage” items for each item you want to set with a scene. Those storage items hold the “preset” value, and that value gets copied into the actual item when the scene rule fires (e.g. “Lighting Scene Evening” example in post 1 above). The storage items are prefixed with an appropriate “Scene_xxx_” prefix to differentiate them from the actual channel-linked items and from other scene storage items.
If you want to change the presets, you can change the actual items to make up the scene you want, and when you fire the “Lighting Scene Evening Config Store” rule, those current states of the actual items will be copied into the storage items.
Obviously, those storage items need to be persisted, if you don’t want to lose your scene settings between every system restart.
Nice post!
I would like to add two suggestions: first one, concerning method 1, is the possibility to add a custom action to a routine. So instead of accessing the openhab items via ‘adjust lights, plugs, and more…’, you can use ‘Add action’ to add an action just like you would tell the Google assistant. This way it’s possible to set brightness or color via the routine interface.
Second suggestion, albeit slightly off topic, is to use the integrated assistant routines in the standard Android clock app. Since the app’s last update it’s possible to start a routine after you stop your alarm. Either using method 1 or method 2 it’s possible to automatically activate a scene after waking up 
Thanks for the suggestions! For method 1, the video is a bit outdated at this point, as Google has done some major updates to the Routines menu (and in fact, the entire Google Assistant/Home app layout has changed) - great to know there’s another option to use dynamic configuration settings!
I’ve been using method 3.5 exclusively for the past year, with great results - I don’t have my scenes scheduled on timers or anything, though the use of something like Timeline Picker sounds like a great use case for my scene method above (i.e. schedule different scenes to turn on at different time throughout the day). I’ll play with something like this in the near future. That said, your Android clock routine calls are another great option
Thank’s for the great tutorial.
I always wanted to cleanup all the rules doing different light configurations.
So I’ve implemented it today according your method 3.5.
That’s great! Make sure to add your settings items to a persistence service (I was lazy at first, and ended up losing all my settings the first time I restarted OH)
Then, check out the Home Automation Switch Plate for a neat way to control scenes from a wall switch panel…
1 Like
Thanks for video! I’ve been using method 3 successfully, but with one little issue. When I haven’t used one of my scenes for a while (around a day or two), the scene will take around 10 seconds to execute. After that, the scene is almost instant and everything works perfectly. Any ideas?
Have you modified/saved the file that contains your rule? The first time a rule trigers after saving a rules DSL .rules file, there is a delay.
Yeah I have and it works perfectly right now. Then there will be a 10 second delay when I trigger it for the first time tomorrow.
Would there be a delay after I make any changes to rule files? Not just the affected rule?
After saving a rules DSL .rules file, the first time each rule in the file triggers, there is a delay. Rules in other files would not be affected. If a rule is delayed after the first time it triggers, then there’s something else going on.
Yeah it’s something else then… Only thing I can think of is that I have 2 to dimmer switches that are kind of strange. There is just one dimmer channel for the switch but it needs to receive an ON command to first turn it on (So I can’t just send a command of 70) to turn it on). To get around this, I created a switch item to turn it on or off, and a dimmer item to control the dimmer. I made config items that match both in my routine. Do you think the extra time comes from the 2 different type items controling the one thing channel?
Hello! Great tutorial. I realized that a quite easy way to get the store-rule generic as well was to activate storing when the Scene switch changes to OFF. Then you you can use the same design pattern or whatever you call it. So i changed the code a bit and now i load a scene by turning the switch to ON and store values to the same scene when I change the same switch to OFF. So if you can live with that it’s and easy solution to have just two rules for thousand of scenes. 
@Erik_Bergstrom - that’s very interesting! I would definitely like to see how you handle that, and I’m sure other readers would too - can you post your modified rule? I’ll add it to the main post as another potential solution…
It’s basically the same code as activating a scene but easier. It’s triggered by the same Item but OFF-command instead of ON. The for loop goes through all items controlled by the scene, stores the storeItem name, then sends the i.state to the storeItem.
Hope that is understandable. You can probably write it cleaner than this, I’m a programming noob just copying, cutting and pasting different stuff that I find.
The only problem is that I would like to have the Scene activating item exposed to Google Home enabling activating scenes by voice. But if I for example say ,“Hey google, turn everything off.”, the scene switches would also turn off and erase all previous values stored. But that’s an other issue. For now i just never say, “Turn everything off”.
rule "Lighting Scene Store Generic"
when
Member of LightingScenes received command OFF //Use this line if you're on OpenHAB 2.3 or later
then
// Get the Group of Items that are controlled during this scene
val items = Scene_Items.members.findFirst[ grp | grp.name == triggeringItem.name+"_Items" ] as GroupItem
// Loop through all the Items controlled by this scene
items.members.forEach[ GenericItem i |
// Store scene Item name
val storeItem = triggeringItem.name+"_"+i.name
// sendCommand the Scene state
if(i.state !== null)
{storeItem.sendCommand(i.state.toString)}
]
end
Merry Christmas!
2 Likes
I’ve yet to try this… but after any scene item is turned on, doesn’t the generic “Restore Settings” rule turn that scene item “OFF” (but obviously leaves controlled items in that scene’s state. So Wouldn’t this trigger at the end of every invocation of ever “scene on”?
Instead shouldn’t there be a new group “LightingSceneStores”, and make every “Scene_<some_scene>Store" item a member of that group? And then your “when” would change to “Member of LightingSceneStores” received command ON and at the end of your generic store rule you’d change the "Scene<some_scene>_Store” item back off?
Yes that’s true. I just removed the OFF-thing at the end of the “activate scene” -rule. Its not a problem for me that the scene switch is left ON. But I use the expire binding to switch it to undefined after a couple of seconds. Looks better in the UI.
Hi all =) I’ve read the above tutorial, and wanted to add a scene via item/rule definition. I only have one problem I can’t solve. I use paperui and the mobile-app of android for controlling my items…but these only show linked items. Is there a way to get around making extra sitemap and control everything with paperui?
The answer is short. No.
PaperUI is and was only ever intended to be an administration tool, not the main interface for controlling your devices.
To control a proxy Item like this you have to use a sitemap or HABPanel or HABot.
Ok I found a dirty hack…You can install the network binding, add the ip adress of the pi, and bind all scene items to the online-status channel…then they get displayed but do nothing…really dirty but does it’s job…