Strange behavior alarm block

64 views
Skip to first unread message

P. Andreas Schmidt, IVE

unread,
Jan 13, 2023, 12:34:06 PM1/13/23
to Automate
Hi Henrik en community,

I recently noticed (not sure if this happened before, I'm afraid, and I recently also reset and re-installed my LG Velvet 5G Android 12), that the alarm block (to trigger when an alarm goes off), doesn't always behave as expected (by me at least).
It has happened (but more as an exception), that I started the flow, and afterwards changed my next alarm to a different time, but AM would trigger at the old time, and ignore the new alarm... Which means that at times it would trigger before the actual alarm. I don't use the workaround. And as far as I know there are no other apps using silent alarms, and it would seem strange that they trigger at precisely the old time of the alarm... 
Is this how it works? That instead of waiting for an actual alarm, that the block just fetches the next alarm time and waits for that, and ignores any changes or alarms in the meantime? Or is that not how it works, and for some strange reason that happens (only) on my phone? 
Should I try using the workaround?
Or could it be something left over in the system that triggers the alarm at the old time, whilst the Clock app awaits the new one? Or some other app that I'm not aware of doing something...?
Like I said, I don't remember this happening before the reset - and I've granted all system and some ADB permissions, excluded from battery saving ... 
Any ideas?

Many thanks in advance

Henrik "The Developer" Lindqvist

unread,
Jan 14, 2023, 9:27:40 AM1/14/23
to Automate
When you say "I don't use the workaround" i assume you mean the "Alarm clock" option for "Timer accuracy workaround" in settings, as that will interfere with alarms, since itself use those.

When using proceed "When triggered", when the block is executed it will query the system for the next scheduled alarm then "wait" until that time, while at the same time listening for change of the next scheduled alarm.

The block doesn't store the next alarm time, so the only way it could trigger on an old time would be if
  • the system still report the old time when queried;
  • doesn't report changes to scheduled alarms or Automate doesn't received them; or
  • maybe the block reacting to an old "timer" trigger intent somehow.
As a test try using the Broadcast receive block with Action= "android.app.action.NEXT_ALARM_CLOCK_CHANGED" to see if Automate still gets those.

Android version?


P. Andreas Schmidt, IVE

unread,
Jan 16, 2023, 5:21:54 AM1/16/23
to Automate
HI there Henrik, thank you for getting back

You assumed correctly about my "workaround"

I don't understand your explanation of how the block works, it seems kind of contradictory to me, I'm afraid: first you say it querys the time and "waits" until that time, but then you say it doesn't store the next alarm time...?! 

As to your test: i made a flow with a fork and both the alarm block set to "when changed", and the broadcast (in the other fiber). When I changed the next alarm, both fired. So my guess is it does work... perhaps those few times it didn't for some reason or another AM didn't receive that broadcast, some glitch... What do you think?

Android 12.

Henrik "The Developer" Lindqvist

unread,
Jan 16, 2023, 8:29:27 AM1/16/23
to Automate
It doesn't store the time, so if Automate restarts it will query for the upcoming alarm again, unlike how the Delay and Time await blocks work which do store their next times.

Figuring out the cause is not easy, especially if it only occur sporadically.
I'll do some test on Android 12, and maybe include some debug logging for the next release.

P. Andreas Schmidt, IVE

unread,
Jan 16, 2023, 9:56:04 AM1/16/23
to automa...@googlegroups.com
That's great, thanks. If I notice/find anything else, I'll let you know

Pater Andreas Schmidt, IVE
Kapelaan Federatie Edith Stein
Parochies Borgharen - Bunde - Geulle - Itteren - Moorveld - Ulestraten
---
Pastoor van Eijsstraat 3
6235 EK Ulestraten
THE NETHERLANDS



--
You received this message because you are subscribed to a topic in the Google Groups "Automate" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/automate-user/LFHxXW8Gbvg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to automate-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/automate-user/4634bd0f-5504-4088-bf41-8b182c9ef03fn%40googlegroups.com.

P. Andreas Schmidt, IVE

unread,
Feb 9, 2023, 4:42:02 PM2/9/23
to Automate
Hi Henrik,

today (perhaps) it happened again, at least something similar. So, I've got a fixed returning weekday alarm, that I prefer not to change if I need to be woken up at a different time, so I use an "extra" alarm. Today then, I first set that extra alarm to a different time. Then I cancelled the current returning alarm. And then I still changed the extra alarm to some 10 minutes ahead. The flow triggered at the first time that was set, not 10 minutes later.  I just tried something analogous, and it happened again. So it seems that with cancelling one alarm after setting a new one, and then changing that one to a later time, the flow keeps the first time... 
To double-check, I started the flow with an alarm to later, then cancelled it (before setting a new time), added a new alarm to over a minute, and then changed that alarm to a few minutes ahead. Funnily enough the flow didn't trigger ... neither at earlier time nor when the alarm actually went off...
I also noticed (not really part of the issue but kind of related, perhaps): if I have a fork with a delay, and I stop that fiber, then the alarm will remain, eventhough that delay is cancelled. So, I have a flow with a timer that uses delays to vibrate every so often. If I pause it, it stops the fibre with the delays. There's another flow catching alarms, that gets triggered by those delays, also after the fibre was stopped. So it's not like a real bug, but perhaps helps in this issue, or at least worth considering to add some "cleanup" into the delay block, if it get's stopped to cancel the alarm...?

Hope this helps, let me know if I should do some more tests apart from what I mentioned, or if I wasn't clear.


Message has been deleted

Henrik "The Developer" Lindqvist

unread,
Feb 10, 2023, 12:37:22 PM2/10/23
to Automate
As a test, make a flow which always execute the Alarm block in a new fiber, that would prevent any prior alarm triggers from interfering.
Reply all
Reply to author
Forward
0 new messages