Hi,
although your decription sounds very clear to me, by using your lock-code I get following error:
12:55:19.632 [ERROR] [.script.engine.ScriptExecutionThread] - Rule ‘CheckAnwesenheitJuergen’: An error occured during the script execution: The name ‘.islocked’ cannot be resolved to an item or type.
var ReentrantLock lock = new java.util.concurrent.locks.ReentrantLock()
rule “Check”
when
Item MyItem changed to ON
then
logInfo(“CheckStart”,“MyItem = {}”, MyItem)
if (!lock.islocked) {
lock.lock
try {
logInfo(“Check”,“MyItem = {}”, MyItem)
…
}
finally{
lock.unlock
}
}
end
2017-02-16 19:24:05.303 [ERROR] [o.o.c.s.ScriptExecutionThread ] - Error during the execution of rule 'Alarm Triggered': The name '<XFeatureCallImplCustom>.isLocked' cannot be resolved to an item or type.
I have the case right on lock.isLocked…
import org.openhab.core.library.types.*
import java.util.concurrent.locks.ReentrantLock
var Lock lock = new ReentrantLock()
rule "Alarm Triggered"
when
Item Alarms received update
then
if(!lock.isLocked) {
lock.lock()
try {
logInfo("Testing", "Alarms received update")
val alarm = Alarms.members.filter[s|s.lastUpdate("mapdb") != null].sortBy[lastUpdate("mapdb")].last
if (alarm.state == OPEN) {
logInfo("Testing", "Test: " + alarm)
}
}
finally {
lock.unlock()
}
}
end
If the second trigger arrives after the rule is completed, it will run twice. The lock only stops reentrancy, i.e. two copies of the rule running at the same time.
Alarms is a group and multiple updates are the norm, as you know
Having got a lock now, you can work around the multiple update ‘feature’ by having your rule sleep while it has a hold of the lock. Further updates will be bounced until the lock is released.
In this case, we want to take a different action if we enter the rule and the lock is locked, rather than just queue for it, hence the if-test. Or do you mean you can put the .lock method in the test?
If (!mylock.lock) { … does that work? Would save tme
Looks like you will either have to write code that doesn’t matter if it runs twice, for find a trigger condition other than update-of-group. I cannot think of any locking or debouncing technique quicker than what you have tried.
What is the Openhab host, out of interest? I developed a set of rules on an ancient Windows XP laptop, worked lovely. When transferred to a dual core desktop, it showed up all sorts of reentrant hiccups and needed lots of rework.
The .tryLock method allows for acquiring and testing the lock all in one go. It will grab the lock and return TRUE, or it will fail to get the lock and return FALSE. Then you can make a decision, in Nathan’s case to abort the rule altogether, and are not forced into a queue as with the simple .lock method.
By putting a sleep in the got-lock code, you can reject subsequent triggers for a period while it has possession of the lock. An effective (if complicated) debounce method.
Hi, have several rules and i need to prevent it from firing for 3 seconds.
My switches receive state ON in 3 sec after power on.
Do i have to use lock1, lock2, lock3 for every my switch or ReentrantLock use only one instance?
Reentrant lock may not be what you want at all here. Depends what you mean by " prevent firing" - do not perform any action, like discarding that trigger? Or to wait, queue up to perform the action?
How many locks or other tests you might depends on the wanted behaviour too.
Guessing we are dealing with some kind of output switch? OpenHAB turns the switch on, 3 seconds later some Item gets a ready response?
Are you trying to get one switch sequence “in progress” to discard or delay action on other switches? Sounds a bit like a Group job.
