It all depends. The template will work as is for the foreseeable future mostly on it’s own. But as breaking changes happen to OH or the openhab-js library there will be changes required to either the rules tools library or the rule template itself, or both. But most of those get limited to major version changes so expect to need to upgrade when going from 3.4 to 4.0. But you likely won’t need to between 4.0 and 4.1.
Note that to upgrade the rule template requires uninstalling the currently installed template, reinstalling it, then removing the old rule and recreating it with the newly installed template. Hopefully upgrades will get better over time but for now that’s how it works. The rule template itself may end up depending on a newer version of the library but it will error out and tell you so when that happens. Only then would you need to upgrade the library (or if there is a bug fixed or new feature you need for something else in the new library).
My hope is that the combination of the descriptions of the parameters, the table in the post, and the examples in the first reply would make it clear what each parameter does and how they might work together.
But at a high level, all the rule does is when an Item meets a defined condition one rule gets called (optional). When it remains in that condition for a time, another rule gets called (optional). When the Item stops being in the defined condition, a third rule gets called (optional).
Everything else controls when/whether the rules get called.
That’s why I’ve been able to create a single template that handles all these use cases. All the template really does is implement a rule trigger based on an Item’s state over time.
I am of course open to any and all suggestions for rewording and reworking of the parameters and docs to make it more clear.
Note that most of the rule templates are not this complicated. They do one thing and do it well. For example, Debounce has just to parameters. Delay Start disables some rules at runlevel 40 and reenables them sometime after runlevel 100. It’s just the “do something when an Item has been in a given state for a given amount of time” use case is so common with only slightly different variations that makes Threshold Alert so complicated.
That’s weird, it shouldn’t be doing that. It would need some investigation to see what’s going on, whether the rule is indeed stuck or the UI simply didn’t refresh or receive the IDLE event. The rule usually only spends a few dozen milliseconds to run. The rule’s state does not change back to RUNNING when the code in the timer runs.
You can see when the rule starts and stops by changing the openhab.event.RuleStatusInfoEvent logger to INFO and events.log will start logging out when the rule starts and stops running. You can correlate that with what you see in the UI to see if the UI missed it going back to IDLE for some reason or is really stuck.
Sort of but no this is not the case. When the rule is triggered it will transition to RUNNING. As soon as all the script actions exit it will return to IDLE. It does not become RUNNING when the timers execute though, only when triggered. It really doesn’t have anything to do with the CPU, but it should not be constantly running in this case either.