You have come to a solution so I don’t have much to offer except there recently was a post of a tutorial showing how to enter DateTimes in a more reasonable manner than the Alarm Clock approaches that require a separate Item for each part of the time which might be useful SchreibWas II - Using HTML5 Input-Type in OpenHAB Basic-UI - good or not.
I’m not sure what brings you to this conclusion. Timers are very reliable in my relatively extensive experience. In fact, I’ve replaced cron triggers with Timers for my latest implementation of time of day in Jython. You may not know this, but I believe Timers and cron triggered rules are actually managed by the same code. The only gotcha is you are responsible for some of the book keeping to:
- make sure timers are cancelled when the script is unloaded; in Jython define a scriptUnloaded function and cancel the timers there; in Rules DSL you just have to live with the errors
- make sure to recreate the timers when the script is loaded; use a System started trigger on the same rule that triggers on a change to your datetime Items.
You can see an additional example at https://github.com/rkoshak/openhab-rules-tools/tree/main/ephem_tod.
The timers in that code have been running for up to 24 hours every day for many months. I’ve never missed an event yet.
Just to make it clear, when you schedule a timer you give it an exact date and time to trigger. That’s why in all the alarm clock examples you have to reschedule the timers around midnight for the upcoming day. Timers are not relative so you don’t have to figure out how much time is left. You just need to recalculate the exact date and time the timer should run just like you do when the alarm Items change.
If you were in a situation where you would need to figure out how much time is left, your best bet is to create an Item that gets persisted and restored on startup. Keep that Item up to date with how much time is remaining, or set a timestamp for when the activity started or the like. Since the Item is persisted when OH comes back online check that Item and you can calculate how much time has passed.
This can be particularly use in cases like handling the edge case where you are irrigating some plants, OH goes offline and comes back online and wants to take into account the time that OH was offline when calculating when it’s time to turn off the irrigation. But for a case like this, you don’t care how much time has passed because you are calculating an exact time date time and not a relative date time. Therefore it will come up with the same date time even if it recalculates it on a reload as long as the source data (i.e. alarm clock Items) haven’t changed.
If you reload your .rules file while a Timer is scheduled, that Timer becomes orphaned and generates an error in the logs. Otherwise the lambda inside the Timer is throwing an exception and moving that logic to a cron triggered rule is not going to make the error go away. In short, the behavior you are seeing isn’t caused by the timers, it’s caused by something else. Timers are very reliable.