A simple scene management: finally a good use of scripts

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) :

FEDL_DIMM.sendCommand(25)
FEDL_TOGGLE.sendCommand(ON)
F1DL_DIMM.sendCommand(25)
F1DL_TOGGLE.sendCommand(ON)
F2WL_DIMM.sendCommand(25)
F2WL_TOGGLE.sendCommand(ON)

The sitemap:

sitemap scenes label="scenes" 
{
   Frame label="Scenes" 
   { 
      Switch item=callScriptItem label="Lights Stairs" mappings=["SwitchOff_LightsStairs"="Off", "SwitchOn_LightsStairs025"="25", "SwitchOn_LightsStairs050"="50", "SwitchOn_LightsStairs075"="75", "SwitchOn_LightsStairs100"="100"]
   }
}

The result:
image

15 Likes

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.

2 Likes

I like the approach and I’ll borrow your idea for sure!

Thanks for sharing

I just thought of using a mapping as well…

scene1=scene1.script
scenegoodnight=scene2.script
...
callScript(transform("MAP", "scenescript.map", callScriptItem.state.toString))

That way you can describe your scene by context and refer to the same script if needed.

1 Like

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. :wink:

Put those values on a settings sitemap/page and change them on the fly. I keep the above script example.

FEDL_DIMM.sendCommand(StairsDim25Preset.value)
FEDL_TOGGLE.sendCommand(ON)
F1DL_DIMM.sendCommand(StairsDim25Preset.value)
F1DL_TOGGLE.sendCommand(ON)
F2WL_DIMM.sendCommand(StairsDim25Preset.value)
F2WL_TOGGLE.sendCommand(ON)
1 Like

Excellent! I’m going to have to give this a try! I do have all my setting items persisted (learned that the hard way, like I assume most of us did :wink:

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.

I added the designpattern tag to this as I think it qualifies and it will make it easier to find.

1 Like

Thanks for this post!
I found another way without using mappings that are specific to one UI, command options.

I just created the string item and added command options metadata with the script names as keys and the descriptions as values and it works fine!

EDIT: Just found out that this will NOT work with the Android app, only works in the Web paper UI and main UI. I think it is a bug in the android app