Fixed Daytime Triggers of UI delayed by system downtime

  • Platform information:
    • Hardware: Raspberry Pi 4 / 8 GB
    • OS: OpenHABian
    • openHAB version: 4.0
  • Issue of the topic:

Today I made a full-image backup of the SD card with OpenHABian. I did this by shutting down, removing the card, putting it back in afterwards and boot up.

Including other delays (kids and the like :-D), this took 1:14 hours.

I was barely surprised that afterwards, all my rules I created in the UI using the “at a fixed time of the day” trigger were started with exactly 1:14h delay.

Cron rules were not affected by this.

Is this a known issue? Where does it come from and will it work correctly at least at the next day?

Thanks in advance!

This is not a known issue and the downtime should not have affected the rule triggers in this way.

It will be interesting to know if it does work correctly tomorrow or not. Whether a restart of the machine changes the behavior if not. Is the clock on the machine correct (date on the command line will tell you what time the OS thinks it is).

Thanks for the quick reply!

It is indeed. I tested creating a new rule with the fixed daytime trigger which would trigger in 5 minutes from the time of its creation - target time just “wrist watch + 5”, no computations or the like. And - it did. Without any cross-effects, so it was not affected by the delay, nor did it fix the delay of the rules created before the downtime.

The same happens if I change the trigger time of one of the existing rules (plus / minus one minute or so). It will trigger exactly as intended while the unchanged rules remain delayed.

So any saving / update of such a rule seems to fix the delay for that one rule.

I will update you what happens tomorrow!

Well, now as promised some interesting news!

  • It seems that the issue is somewhat cleared at midnight. I have many rules (20+) starting in the evening between 5 and 9pm and one cleanup rule running at 2:30am. After the downtime (yesterday late morning), all the evening rules were delayed as described.
    The 2:30am rule then came exactly on time. And right now I am observing the evening rules also triggering on time again.

  • Obviously there also is an effect when manually triggering a rule in the delay state. At least I triggered some of them manually some minutes after they should have done automatically, but way before they would have done with the delay. In this case, they did not trigger (once again) with the delay.

The whole picture of the effect made me think how the functionality is actually implemented.
At least it looks like there is some kind of timer or counter started at midnight which expires at the set time. The timer / counter is reset if a rule is changed or newly created, executed, or at midnight at the start of a new day.
If there is a downtime, the timer stops counting, but somehow at least stores the last value and continues counting when the system is up again.

Of course this is just a guess, but two major issues arise from it:

  • it seems like every downtime, reboot or maintenance, sums up on a daily basis and delays rule triggers up until next midnight.

  • As the last timer value before the downtime is not lost even at shutdown, it must be stored permanently somewhere. And the rule triggers have minute resolution, so there may be the possibility of every rule running a counter updated every minute. If this is done in a way like ZRAM and only written to SD card on regular shutdown, no sweat.
    But if this is actually written on the card on every increment, it might write the card to death within months…
    Would be relieving to know for sure! :slight_smile:

If it writes anything to the sd card it’s going to be somewhere in userdata, most likely jsondb. You can see if there is a file that updates once a minute.

I’m pretty sure that’s not how it’s working though.

Merry Christmas y’all! :slight_smile:

My first suggestion would also have been the jsondb, therefore I already checked that. I found nothing there coming even close to a once-per-minute rate; most change dates there were weeks ago, and the more recent ones related to my edits.

So far, for reliability reasons but also for greater flexibility I changed these rules to cron trigger meanwhile,with the only actual drawback being a slightly reduced comfort in the GUI.

While this is something which causes me no headache at all, I would be quite curious what the root cause for the issue is and if it will be solved some day…