However, if you want to create an installable rule template, you’ll need to write this as a UI rule. At least for now, only managed rules support templates.
OH doesn’t have support for avoiding that yet. But there is a PR to add a crypto-store which is the first step.
Some comments on the rule:
Overall this looks a lot like a Nashorn rule that has been lightly adjusted to JS Scripting. There are a number of simplifications that could be added if the full openhab-js library were used.
This is only needed if one has changed the default setting of the JS Scripting addon to “Do not use built in variables”.
Because for managed rules any one rule could have multiple actions and conditions, requiring an import for every one is a larg burden.
All of this is (and should be) accessed through the openhab-js library. See JavaScript Scripting - Automation | openHAB
When/if you make a template these would become properties the user fills out while instantiating the rule from the template.
Note in a managed Script Action/Condition, because the context is reused from one run to the next, you cannot use const and let in the root context of the Script. You can use them inside of functions though.
When/if this becomes a template, most of these should become debug.
In JS Scripting the state is already a String. It’s redundant to call toString() here.
Also, in OH 3.4 + you can use the shorter options:
let alarmState = items.Alarm_State.state;
let alarmState = items["Alarm_State],state;
openhab-js has a time.toZDT() function which is a factory for ZonedDateTime Objects. If you pass it no arguments it will return now.
Using the js-joda classes it’s better to use Duration. At least you don’t need to mess with ChronoUnit.
let stateChangeTime = detectorItem.lastUpdate;
let elapsedTime = time.Duration.between(stateChangeTime, now).abs();
return elapsedTime.compareTo(time.Duration.ofSeconds(5)) >= 0;
There are other ways to do this too.
So for now it’s only possible to have one rule per rule template. However, looking at the triggers here it’s definitely possible to combine this all into one rule and have different paths through the rule depending on what triggered the rule. For an example of this sort of thing look at my 4.0+ rule templates (e.g. MQTT Event Bus).
For a managed rule, use the shared cache for “global” variables. Use the private cache for variables that are only used by one rule but which need to persist from one rule to the next.
If you want to prevent rules from running until runlevel 100, see Delay Start [4.0.0.0;4.9.9.9].
Debounce [4.0.0.0;4.9.9.9] could be used for this part. That might simplify this rule significantly. Essentially, with a debounce on the door Items, this rule won’t even trigger until the door has been open for five seconds, saving you from even needing to check for that with timers and such.
Threshold Alert and Open Reminder [4.0.0.0;4.9.9.9] might also be used here but that would require a whole new approach for this capability. But again, the rule wouldn’t even be called until the door has been open for longer than five seconds. The advantage here though is there is a do not disturb period which could be useful and or enhanced to take into account the armed/disarmed status.