It looks like it might be a timing issue. The rule is being triggered twice for each update and it looks like the code it running with just the right timing that it is creating two timers but losing the reference to the first timer when it creates the second one. Probably the easiest way around this would be to wrap the rule in an reentrant lock so only one instance of the rule can run at a time. This will prevent this sort of timing problem.
// other imports
import java.util.concurrent.locks.ReentrantLock
// other globals
val ReentrantLock lock = new ReentrantLock
// other rules
rule "gPresent changed"
when
Item gPresent received update
then
try {
lock.lock
// your code goes here
}
catch(Throwable t){
logError("Presence", "Error processing BTPresence update: " + t)
}
finally {
lock.unlock
}
end
That worked! It never accured to me that it was creating two timers! It should have been obvious with the double log especially since I was seeing the timer being canceled. Thanks for the help, I’m new to openhab but so far this is a great community! Now I know how to create locks too!
Since were on the subject any idea why it would be running twice in the first place, wondering if there’s something wrong with the code itself cause it to loop?
It is a side effect of how the state of a Group Item gets calculated. The short of it is that your rule will triggered n times per item update where n is the number of items they are a member of the group.
You are not doing anything wrong. I should have had the lock there in the first place.
I have updated the above code that I payed above which you can find here:
My understanding is adding a type to the group should be sufficient to get update events on the Group but since I use gPresent’s state elsewhere I’ve always had a function.
That is correct. The ReentrantLock is no longer needed. I’ve been running this code for many months now and I honestly don’t remember why there ReentrantLock lock was in there in the first place.
@rlkoshak Thanks i will try but i have seen another issue
The Sensor_lastUpdate is update at each reboot or restart service
Rule:
rule "ZWaveNode2_DoorWindowSensor"
when
Item ZWaveNode2_DoorWindowSensor changed
then
ZWaveNode2_DoorWindowSensor_LastUpdate.postUpdate(new DateTimeType())
end
log at the boot
018-06-06 10:06:42.821 [vent.ItemStateChangedEvent] - ZWaveNode2_DoorWindowSensor_LastUpdate changed from NULL to 2018-06-06T09:41:32.001+0300
i have tried to check if the value is not NULL in my rule (boot time) but it do not work
rule "ZWaveNode2_DoorWindowSensor"
when
Item ZWaveNode2_DoorWindowSensor changed
then
if (ZWaveNode2_DoorWindowSensor.previousState().state.toString!==NULL){
ZWaveNode2_DoorWindowSensor_LastUpdate.postUpdate(new DateTimeType())
}
end
rule "ZWaveNode2_DoorWindowSensor"
when
Item ZWaveNode2_DoorWindowSensor changed
then
if (previousState === null) return; # Don't run the rule if the previous state is null
ZWaveNode2_DoorWindowSensor_LastUpdate.postUpdate(new DateTimeType())
end
.previousState will give you the most recent value in the database. So what is probably happening is the changed state (i.e. the change that triggered the Rule) is already saved in the DB before the Rule executes giving you the current state of the Item when you call previousState. This is why the implicit variable previousState exists.
Also, only use !== or === when on of the operands is null which is not the same thing as NULL.
Am I right in saying a Transform map could somehow conver this rather unusable string to something more like minutes or seconds that the door has been open for use in an TTS Alexa rule?
No. That item is a DateTime so it records an instant in time, not a duration.
You need a Number Item and a Rule to periodically increment the value while the door is open. Then you need a JS transform to convert the number, let’s say minutes, to hh:mm
