Of course, if the lights are already automated switching to a random pattern can itself be a signal that no one is home. Be careful of that.
An alternative approach I like to promote is to use persistence. Just playback what the light was doing seven days ago (or the time of your choice). That way it will be completely indistinguishable from you being present. In fact, that’s a easy one I can post to the marketplace for another example.
As for the marketplace, it currently only works with managed rules (i.e. those defined in the UI or through the REST API). That doesn’t mean that jRuby isn’t supported (though when I asked about that the jRuby developers didn’t see interested in ensuring that it does work in UI rules). I’d hope that UI rules with jRuby are possible.
The marketplace supports rule templates. You can create properties for the user to enter (which Item(s), Thing uids, thresholds, etc.) when they instantiate a rule from the template. So it is possible to make the rule flexible and give the user the ability to adjust those things that need to be adjusted via a simple form. Furthermore, once instantiated, the user can go in and modify the actual source code too. So it’s reasonably flexible on that front.
In your rule’s case I’d create a Group to hold the lights. The name of that Group would be a configuration property. The SunElevation Item could be an optional property, Alarm_Armed the same. The rand seed, time of day, and all that can be properties, some required and others optional that the user can set when instantiating the rule from the template.
It’s pretty manual at the moment. You need to create a rule through the UI. Then save the YAML from the code tab to a .yaml file. Alternatively, you can create the rule through the UI and pull the JSON from the REST API and save that to a .json file.
Then you need to replace the stuff before the “triggers” element with rule template information. For example, here’s the rule template stuff from my Alarm Clock template which is YAML.
uid: rules_tools:alarm_clock
label: Schedules a timer to run a script
description: This will trigger on an update to a DateTime Item and schedule a timer to call another script at the DateTime's state.
configDescriptions:
- name: alarmTime
type: TEXT
context: item
filterCriteria:
- name: type
value: DateTime
label: Alarm Time Item
required: true
description: Item that holds the date and time to run the script.
- name: script
type: TEXT
context: rule
label: Script to Call
required: true
description: The Script or Rule to call at the alarm time.
triggers: ...
Here it is in JSON for one of my MQTT EventBus rule tempaltes.
{
"uid":"rules_tools:mqtt_eb_online",
"label":"ONLINE Status Publisher",
"description":"Publishes ONLINE as a retained message to the LWT topic.",
"configDescriptions":[
{
"name":"broker",
"type":"TEXT",
"context":"thing",
"label":"MQTT Broker Thing",
"description":"Select the MQTT Broker Thing used for the MQTT Event Bus",
"required":true
},
{
"name":"topicRoot",
"type":"TEXT",
"label":"openHAB Instance Name",
"description":"Name of this openHAB instance, used as the root of the topic structure.",
"required":true
}
],
"triggers": [...
The uid needs to be unique. Yannick and Kai use their names for the first part of the UID. I use “rules_tools” since I’ve already established that as a repo for my rules and will host my templates there. Everything else is pretty self explanatory.
The configDescriptions work the same as properties in custom UI widgets. So if you need an Item name for a field, you can specify that and the user will get the list of Items to select from.
You can post the yaml of json inline in your forum post or host it elsewhere (e.g. github) and provide a link to it.
Unfortunately, the only way to test it though is to publish it to the forum and set the “published” tag. The marketplace is currently the only way to install a rule template. But it’s just an initial testing release so we can’t expect it to be complete.
Another limitation is it currently only supports one template per post. So in cases like this with three rules there needs to be three postings (or figure out how to make one rule do all three jobs). I’ve already filed an issue on that because I suspect it’ll be rare that capabilities we post will be limited to one rule. In fact Yannick has an idea where maybe someday we can post whole comprehensive modules with a binding, rules libraries, rule templates, and UI widgets in one bundle on the marketplace. That’d be really powerful.
We sure can use some more rule template examples. I’m happy to help make this or anything else into a rule template.
I thought about playing a youtube playlist on a google home speaker to make some noise.
