From testing I found that the Android App in OH3 will change AlarmClock Item when the Alarm expires and then immediately ‘cancel’ or r’eschedule’ the timer before it expires.
A workaround to this problem is to antecipate the timer ‘timerAlarm’ by a few seconds.
Then the sample rule in the OH3 documentation for the Android App works with a minor modification.
Replace the line:
‘timerAlarm = createTimer(newState.toLocaleZone.zonedDateTime, [|’
with
’ timerAlarm = createTimer(newState.toLocaleZone.zonedDateTime.minusSeconds(5), [|’
If exact timing of the allarm is essential above solution may not apply. But, postponing the action for 'cancel 'and ‘reschedule’ of the ‘timerAlarm’ should also work. It would require a bit more coding as additional validation checks must be performed.
I came back to say that the issue is still happening to me.
I also think that Android 10 and 11 (I was on 10 having the problem, and now in 11 its the same)-
are having issues with OH app. I don’t know what is causing the problem, I took the precaution of disabling all kinds of “optimizations” and “battery optimizations” in my samsung note 10 but it still doesn’t work, from a day to the other it stops working. If I program it close to the current time, it works. I have no clue what is happening.
This issue doesn’t seem to happen on my older samsung Note 4.
If it helps, the phone has been recently wiped various times, so no custom apps interfering and the phone is using local time and language (Spanish - Latin America time).
hi there, getting worse. Even on my old Note 4 I miss the alarms. Sometimes it works, sometimes it doesn’t. This happened a couple of times. The phone is always connected to power and is online (I use it as a remote control).
I missed the alarm today. Late for work.
aaaaand again… another missed alarm today. Late again. Even on my older phone running older android. Can this be a problem on the HAB server side? I mean something with openhab 3? it was working perfectly on OH 2
@elcosomalo Do you see any Alarm sent by ... lines in the Android log?
Honestly, don’t rely on a single system if it’s important. I’m using openHAB as alarm clock for several years for now, but also an additional battery-driven alarm clock as backup.
bump— Just to add some more information: I flashed my old note 4 (OH app working) with an AOSP android 9 ROM and it doesn’t work with the alarms anymore so there is definetly some issue between OH app and android 9 onwards.
EDIT: 27/06/2021
The android 9 ROM was giving more problems than solutions (I really don’t understand the people on XDA forum since everyone just worships the ROMs, but not a single one is working properly) so I flashed stock android 6 ROM again.
Tested with note 10 (android 11) and it didn’t work. The alarm is being sent to the server but for some reason, it doesn’t fire when it has to.
Something odd here… the alarm gets cancelled at 8:00 for absolutely no reason.
Why is it cancelling the alarm? (PD: the phone alarm sound worked normaly at 10:00 as scheduled)
Well, you might read your rule to find out how it could get to that message.
To trigger the rule, Item AlarmClock must have changed. What it changed from and to is probably of interest. There’ll be a record of that in your events.log.
To get to the “cancel” code, the new state must not be of DateTimeType. Maybe that’s true sometimes, but you shouldn’t cancel in every circumstance.
But as yet, we don’t know the circumstance.
Checked the events.log and this shows up:
(this events take place after a successful alarm, it was set to local time (real time) 7:30 AM and it shows up as 10:30 in the logs)
OH is configured with my timezone UTC -3.
2021-06-28 07:30:01.023 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'AlarmClock' changed from 2021-06-28T10:30:00.000+0000 to UNDEF
Then… after a minute:
2021-06-28 07:31:01.041 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'AlarmClock' changed from UNDEF to 2021-06-29T10:30:00.000+0000
Its difficult to know what is causing it to not fire, since the “working” log is almost the same as the “non working” log. The only difference I could notice is that in the openhab.log the alarm gets cancelled in time instead of firing.
Well, the Item state changes so the rule is triggered.
The new state UNDEF is not a DateTime, so the rule does as it was told to do, and issues a cancel.
There is no surprise here.
The question is why your Item gets an update UNDEF.
This will be coming from the binding, most likely your android has sent something that cannot be interpreted as datetime.
But I think this is the issue @Roland_Ebener told you how to avoid by setting your OH alarm a few seconds earlier than the UNDEF happens.
I think that’s exactly the issue: The alarm goes off at 7:30 and sends the next alarm time to the server (next day at 7:30). If the times of the server and smartphone aren’t exactly synced, the app may cancel the alarm before it goes off.
Not quite; this gives the appearance that when the alarm goes off at the android end, it sends some non-datetime value. Maybe “alarm” or “null”, who cares.
This triggers the rule, which processes as though it were a cancel.
This only a problem for when android time is ahead of OH time.
(After that comes the “next” new datetime message, and everything gets put right for next day, cancelled or not.)
I guess when you really want to cancel, some non-datetime is also sent?
Can we at OH end distinguish between “alarm now” and genuine “cancel” events?
If not, then perhaps the rule can be made smarter so as not to cancel if we are within a few minutes of alarm time. This would take care of clocks creeping out of sync.
You might also need to make the rule smarter about what to if, when a ‘cancel’ has been avoided because it is too close in time, a “next day” new/reschedule then comes in close to target time.
I think you are getting close there… it makes sense. Just to add info, I checked the NUC (WIN10) where my OH server is running and the date/time is OK (meaning it is not minutes ahead of the phone). Maybe its a matter of seconds?
The app itself cannot distinguish between “next alarm is set, because previous one went off” and “next alarm is set, because previous one was cancelled”
That’s exactly what I think as well. The smart rule might be added to the docs as well.
