I am building some more advanced rules in OH and need a more granular item persistence (had been using primarily everyChange in the past).
Working on this I observed that double entries get stored in the database e.g for
every30Minutes : "0 0/30 * * * ?"
I get two entries within 20 seconds:
Same thing happens if I run a cron DSL rule - it also gets executed very similarly twice. This makes me think it is something related to the scheduler, but cannot really get any reasonable clue.
Double checked the system time mapping as OH runs on docker and for presence of hidden files (.persist or .rules), pulled the latest image and rebuilt the container from scratch, but no luck.
Interestingly when running every minute (“0 * * * * ?”) strategy, this does not happen. Furthermore after restart of OH - the container in my case, first time the persistence seems correct (14:00 on the screenshot). Any subsequent run - item state stored two times: ~20sec earlier than the trigger, and afterwards at the correct time.
This kind of issue has been poked around before, without resolution -
Note that talk of “new rules engine” in OH2 environment is effectively same as OH3 engine.
There is a sort-of logic to the “twice” symptom, if the “job” is run prematurely it should reschedule itself for the next due time in just a few seconds.
Why does it fire prematurely is the question.
This would tie in with the suggestion that it is rescheduling calculation that messes up.
I agree with your logic the premature run and reschedule, though looking at the issue mentions here and there, it seems a difficult one to tackle.
Found this on GitHub with a fix merged in 3.1, but the docker milestone release is for any reason crashing with my config. I will later run a test with clean config container to see if this is still there.
Below a quick and dirty workaround to drop premature triggers for rules, if someone stumbles upon the issue.
rule "Energy by hour"
when
//Trigger at the 30th second of minute 0 of every hour.
Time cron "30 0 * ? * * *"
then
ruleFiredAt = now.toLocalDateTime()
// Below condition is used to avoid a bug with pre-mature triggers of the rule
var seconds_reminder = ruleFiredAt.getSecond() % 30 //there will be a reminder if rule triggered prematurely earlier than second 30 as set in cron
var minutes_reminder = ruleFiredAt.getMinute() % 10 //this is to avoid edge cases of premature triggering at e.g. xx:59:30
if( seconds_reminder == 0 && minutes_reminder == 0 ) {
logInfo("MY_RULE","Execution triggered at right moment. Time is " + ruleFiredAt.toString())
//rule actions go here
}
else {
logInfo("MY_RULE","This is wrong trigger. Time is " + ruleFiredAt.toString())
}
end
Though, this does not resolve the problem with the persistence triggers. In my case I moved the item update logic elsewhere (external python script triggering as needed) and use persist on change strategy.
