If the suggestion here is that multiple jobs are being scheduled, rather than a single job getting mis-scheduled multiple times - is there some unique job key/reference that can be extracted for diagnostics?
That looks pretty much what I’m asking about, but don’t know enough about the mechanism.
Looks like the same cron rule trigger being scheduled, and producing a new “key” trigger reference.
But it’s not clear why that happened ten minutes apart, rules reloading? Haven’t got the background here.
Bumping this old issue because I have the exact same problem with my OH 3 installation. I‘m curious: @juelicher Did you ever find a solution? My cron based rule is set to trigger every Friday at noon:
0 0 12 ? * FRI *
The rule is being executed shortly before the time intended (couple of seconds) and again at the time intended. This has been going on through all milestone builds up until and including RC2. (Am now on the latest snapshot but could not test it yet.)
I had the same rule running on OH 2.5.x without issues.
Edit: Mine is a DSL rule, not Jython.
Edit 2: Just noticed a related issue on Github. If no one else does then I will try to come up with a scenario to reproduce and add it to the issue. Once a week is a bit… impractical.
No, at some time I gave up and modified my rules. Now they check the time since the last execution of the rule and just return when this was long enough ago.
@juelicher Sorry to bother you again. It’s been suggested that the issue might be an inaccurate system clock. Might I ask which hardware & OS you’re on? I’m on a mac Mini 2012 / macOS Catalina.
I had this on two different platforms, a 2012 Mac Mini latest macOS on this machine was Mojave. Than I migrated to an APU 3 from PC Engines with Debian. First Debian 9, now Debian 10.
The system clock on booth platforms was synced via ntp.
