He filed it in the right location. That will have to be implemented by the automation engine which is located in the core.
For something like this written a reusable library that people can use called debounce. You can create a proxy Item and add some metadata and it will hold onto a command/change to an Item until a certain amount of time has passed before passing it to the configured proxy. Ive a Jython and YAML (OH 3) version available at GitHub - rkoshak/openhab-rules-tools: Library functions, classes, and examples to reuse in the development of new Rules..
I think there is now a debounce Profile as well, but of course that only works with Items linked to a Channel.
I use this all over the place. My presence detection rule has been completely replaced by this.
I can’t say if this would be useful but I want to bring it up as the sorts of rules capabilities you will be able to just download and use going forward instead of needing to copy from the forum and adapt.
For the lights timers I’ve create an implementation of the Gatekeeper DP which would be perfect for that. In your rule you can just have something like:
from community.gatekeeper import Gatekeeper
gk = new Gatekeeper(logger)
# Inside a rule, add a command to the queue and prevent another command until
# a second after this command runs.
gk.add_command(".5s", lambda: events.sendCommand("Light1", OFF))
gk.add_command(".5s", lambda: events.sendCommand("Light2", OFF))
gk.add_command(".5s", lambda: events.sendCommand("Light3", OFF))
gk.add_command(".5s", lambda: events.sendCommand("Light4", OFF))
# putting the above into a loop is an exercise for the student
NOTE: I’ve not yet implemented a JSONDB OH 3 version but it’s high on my list.
Notice the use of “.5s” to denote the time for when you want the timer to go off. I’ve implemented a timer_mgr class that greatly simplifies the creation and management of Timers. And I’ve created a time_utils library that lets you convert all sorts of stuff to a ZonedDateTime needed by createTimer so I can schedule a timer like:
timer_mgr.check("ItemName", "2m5s", func=runme) # if it doesn't already exist, create a Timer with "ItemName" as the key to go off in two minutes five seconds and execute runme, cancel the timer if it exists
timer_mgr.check("ItemName", 1000, reschedule=True, func=runme) # if it doesn't exist, create a Timer with "ItemName" as the key to go off in 1000 msec and execute runme. If it does exist reschedule it.
timer_mgr.check("ItemName", items["MyDateTimeItem"], flapping=runme2) # if it doesn't exist, create a Timer with "ItemName" as the key to go off at the instant defined by the state of MyDateTimeItem. If check is called again while the Timer still exists, call runme2
timer_mgr.check("ItemName", items["MyNumberItem", func=runme) # same as first example only the number of milliseconds is defined by the state of a Number Item
Anway, what the above rule does is send a command to Light1 and then it will wait for half a second before the command is stent to Light2 and so on. The time passed is how much time must pass after that command runs before the next one is allowed to run.
This is a great way to set up cascading timers too as you can just send all the commands all at once to the Gatekeeper and it will do the timing stuff for you.
It’s this sort of stuff that has me excited about rules in OH 3. I’ve done all the work and all you have to do is download and use them.
As of this writing I’ve only ported ephem_timeofday, timer_mgr, time_utils, and debounce to OH 3 JSONDB rules or libraries. I’ve implemented but not yet posted rate_limit (it’s like gatekeeper but instead of queueing up the commands and sending them all but a certain amount of time apart, it drops any additional commands sent to it, useful for doing things like preventing a given alert from being sent to you more than once a day).
For an example of how these can simplify your rules, here is a rule I have that sends me an alert when the humidity gets too low in one of the rooms where I track humidity. I use rate_limit to prevent the alert from being sent more than once a day even if the humidity bounces around the threshold.
var logger = Java.type("org.slf4j.LoggerFactory").getLogger("org.openhab.model.script.Rules.Humilert");
this.OPENHAB_CONF = (this.OPENHAB_CONF === undefined) ? java.lang.System.getenv("OPENHAB_CONF") : this.OPENHAB_CONF;
load(OPENHAB_CONF + "/automation/lib/javascript/community/rateLimit.js");
load(OPENHAB_CONF + "/automation/lib/javascript/personal/utils.js")
this.rateLimit = (this.rateLimit === undefined) ? new RateLimit() : this.rateLimit;
var sendAlertGenerator = function(msg) {
return function() {
sendAlert(msg);
}
}
var name = getName(event.itemName);
this.rateLimit(sendAlertGenerator("Remember to fill the humidifier in " + name + ", current humidity is " + event.itemState + "."), "1d");
I don’t even have to think about the timers. It’s amazing how freeing that is. Note getName is defined in my utils.js and it returns the value of a name medata on the Item. Similarly sendAlert is a function that sends an OH notification during the day but an email at night.
