Note that there is a breaking change that occurred after 3.2 M5 so even if you were to successfully install the rule template right now, if you are not on the SNAPSHOTS it won’t work. So that might be coming into play here too.
But there may be a problem in my fixes for that breaking change. I’m debugging that now.
It should work not, but remember that it will only work on SNAPSHOTS post 3.2 M5 and 3.2 release and later.
Thanks Rich, I have updated to latest snapshot and all is working well. Thank you for all your efforts and good work you put into the openhab community.
But note that this is merely one way the rule template can be used. If your DateTime Item is populated from the Android App or iCalendar binding or the like no UI is required. Personally, I just use this template to trigger a rule when I have an alarm set on my phone that will transition my Time of Day state to MORNING if it’s not already day.
My rule templates are created to be build blocks towards a full solution, not a turn-key “install it and use it”. Even so, I do not plan on writing such comprehensive tutorials for all of my rule templates.
@rlkoshak - of course you have already - truly a beautiful article, apologies I tried searching but not hard enough - might be worthy pinning this solution article to the time of day and the above at the top to help others find this awesome article.
I’ve not added it to the docs for this rule template because I don’t want people to think it’s limited for use in just this one example. All this template does is schedule a rule to run based on the state of a DateTime Item. Nothing more, nothing less. But even with that simple capability it is useful in its own right and useful in many different ways.
Bump up the logging on the rule. You can either edit the “debugs” to make them “info” level or adjust the logging level for “org.openhab.model.script.rules_tools.Alarm Clock” in the karaf console or log4j2.xml file.
One minor problem I uncovered is related to the Android app. I discovered that my phone and server were about five seconds apart. Usually that wouldn’t be a problem except Sleep as Android sets the alarm only a minute before it’s supposed to go off and then when it does go off it cancels the alarm. Since my phone was five seconds ahead, the cancel came before the alarm timer in OH could go off and it got cancelled.
I can’t tell if something like that is happening here without more logs.
The AlarmClockTime did not change in between (just with the push to next day at 12am)
EDIT:
I have removed your rule and set it up again.
Although it was working before and I did not change anything in your rule, I will check if it will start working again.
Add logging to the script that gets called by the alarm clock too, assuming there isn’t some there already.
I assume you are not restarting OH between the time the alarm is set and the alarm is to go off. The rule should handle that but it is an important piece of information even so.
And yes, I do not restart OH after 12 am.
From the logs a restart before 12 am correctly reconizes the new wakeup time.
So everything seems to work, but the trigger at 6:30 itself.
Anyway, after deleting the rule and creating it again, this morning it worked.
I will track that closely, because this was the case with the first try as well.
(it stopped working).
Thank you, Rich.
I will get back here, if it happens again.
Thanks. It’s really odd behavior. I’ve only ever had it not work for me the one time and it was what I described above and due to a quirk with the Sleep as Android app and my phone and computer being about five seconds apart.
The only thing I didn’t ask was to make sure you grabbed the latest version of the template by removing and then readding it and then recreating the rule. That will ensure we are both looking at the same code.
It looked to me like the rule triggering happened at the start of the timer, not just before the script ran.
I want it to check the condition just before it triggers the script.