Trigger based on DateTime item not firing after restart server

Hi everyone. I’m running an server on Ubuntu that was migrated from windows a couple of months ago. My old server was unstable and I had a (kind of legacy) rule to restart it every 3 days at 4:00 am.

I have a rule for Hue light that must start at different times depending on a wake up alarm. I used to use the rule in the market to fire events based on DateTime items, but now that we have that trigger natively integrated I’m using that.

But I found that my time based rules are not firing the days that the server restarts until I run them by hand at least once, then, they work ok until the next restart.

Does anybody knows if this is a bug or could be an error by my side? Thanks in advance.

Please provide a full rule that shows this issue.

The rule script shall not be relevant as it is autogenerated. I have a log than inform when the script starts, but it does not show on frontail until I run the rule by hand.

Another bit of info that may be relevant is that I got the rule to bring datetime items to today every day, but it does not seems to affect once my rules are working after the next server restart.

configuration: {}
  - id: "2"
      itemName: huedawntime
      timeOnly: true
    type: timer.DateTimeTrigger
conditions: []
  - inputs: {}
    id: "1"
      type: application/vnd.openhab.dsl.rule
      script: (Here goes the long script that is called)

This is how the rule looks:

This is on a non restart day (The fade switch is set to ON)

This is a restart day (the rule does not trigger):

Is there anything in the logs regarding this rule when the system starts?

No, nothing that I can identify in the main log. Maybe changing the logging level…

How often does the DateTime Item that triggers this rule update?

Does the rule run if the Item is updated to some time in the near future instead of running it manually?

I have 3 that behaves the same: They get updated daily by the toToday rule from the market (I used that with the deprecated alarm clock rule). I think that rule updates the items at 00:00 and when system restart gets 100%, in my case, at 4:05 every 3 days (so, two updates that day). The items time can be changed with an input card, which sets the date back in time (can’t remember to what year). Just to keep track on when those must trigger I’m still using the ToToday rule to update the date without changing the time. Note that I usually don’t change the time, only when I have to change my daily routine, that wasn’t the case today that the rules failed to run.

I have no manual way to update the date, only the time, but this will set the date to the past not the future…

This is how two of the datetime items looks. Hue Dawn didn’t run so I’m not expecting that Hue sleep triggers although the datetime is already on the future.

The input cards are nothing special. I copied the config from somewhere in the forums.

You don’t really need that anymore either. In the rule trigger you can tell it to just use the time part and ignore the date. Then it will fire at that time every day (depending on any conditions applied to the rule).

That rule template is also written in Nashorn JS and there is potentially a problem there. Add some logging to verify that To Today is running at system start. If not, it’s not updating the date part so the rule doesn’t trigger.

It does look like it’s running but I’d still like to see confirmation. Also, go ahead and change the rule trigger to just use the hour. There’s no need to use To Today for this. It’s all built in now.

FTR: Fix DateTimeTrigger not triggering on restored state by J-N-K · Pull Request #3277 · openhab/openhab-core · GitHub

Thank you. I mark this as solved as we need to wait if the changes are enough.

Thank you. I understand that we don’t need the ToToday rule and my rules are set to ignore date, only time, but I really hate to see those dates in the past on the items. The ToToday rule is running as I got the day correctly every day (although I’m not using it). According to J-N-K I think I may have found a bug. Let’s how the future changes work.