This is a simple concept for scene management. I really like it for its simplicity.
The following is needed:
1 item
1 rule
plenty of scripts: one per scene (openHAB flavor, no shell scripts)
1 sitemap
The main concept is simple. Each script defines a special scene. With a specialized mapping in the sitemap you can call the script you like.
Prior to that concept, i had several SwitchITems which each triggered a special rule. This bunch of SwitchItems could be removed.
The item:
String callScriptItem ""
The rule:
val String logger = "callScript"
rule "call script"
when
Item callScriptItem received command
then
logInfo(logger, "command: " + callScriptItem.state +".script")
callScript(callScriptItem.state +".script")
end
one example script “SwitchOn_LightsStairs025.script” (The other used scripts are similar, just the dimmer value is changed) :
Every now and again you see something so simple and so clever you think “Why didn’t I think of that.” Yes indeed, this is an excellent use for scripts. Thanks for posting!
One thing I particularly like about this is not only the many many lines of code it will save in the .rules file but that it makes it easier to reuse the same scenes across multiple Rules.
Great idea for pre-defined scene setpoints (for which using tons of rules is cumbersome) - I wonder if you could somehow make the setpoint values configurable (maybe use XSLT transforms for storing/recalling xml strings with values for each light/dimmer item?). There’s nothing like being able to fine-tune a scene down to the smallest detail, and then just turn on the “Store” switch to remember each setting for future use (instead of having to create another scene or go back into the code every time you want a change)…I have it set up that way using method 3.5 (@rlkoshak 's generic rule) here and ended up using it a lot - I just have a few scenes set up for different times of day/events, and adjust the items in the scene (lamp brightness, colors, effects) at my (or my wife’s) whim…
Well, yes, it is possible. But not via xslt or some other fancy stuff. Just add an unbound item for each value you want to fine-tune on the fly. (That’s the bad part, many items.)
I use this “settings concept” for plenty of stuff, the doorbell sound, the alarm clock, the dimmer level used by the motion sensors to switch on the light, etc, etc.
Important: use a persistence (i use mapdb) with theses unbound items, otherwise you might cry at a restart.
Put those values on a settings sitemap/page and change them on the fly. I keep the above script example.
This is one of the uses for Design Pattern: Human Readable Names in Messages though I would choose either a MAP or a JASON file over XML and XSLT. If you must use XML, at least use XPATH. XSLT is really hard to use for something like this.
Another alternative is one can load a .properties file (it’s basically an .ini file) that you can load into your Rules into a Map<String, String> with a couple of lines of code. But it wouldn’t work with Scripts because you can’t pass the Map to the Script as an argument meaning you would have to load it each time the Script runs. If you have to do that you may as well save a line of code and use the transform Action.
Of course, unbound Items are also an option like job recommends.
