Next Alarm is not set after an alarm is triggered, or deleted before the trigger despite a next candidate being available later

[wsw70]

Home Assistant Android app version(s):

2025.11.2-full (18888)

Android version(s):

16

Device model(s):

Samsung Galaxy S25+

Home Assistant version:

2025.11.2

Last working Home Assistant release (if known):

N/A

Description of problem, include YAML if issue is related to notifications:

I use AMDroid as my alarm clock and whitelisted it in the sources for that sensor in the app.

I have an alarm set for 19:10 today. I set the refresh or sensors for every minute

• I add a new alarm at 14:55 for 14:58 → ✅ OK, this new alarm is immediately picked by HA, I see it on HA's web app when monitoring the state of the entity (I do not need to wait one minute)
• I let the alarm trigger (the phone rings at 14:58) and I dismiss it → ❌ this alarm stays, the next one (=19:10) is not set (status after waiting a minute just in case)

This means that an alarm that is triggered is not cleared in the app to give the spot to the next one. Only creating a new alarm will do that.

This is the same problem with an alarm deleted before they are triggered

Companion App Logs:

(filtered on [Aa]larm)

11-17 14:55:45.146 27742 12003 D NextAlarmManager: Next alarm is scheduled by com.android.providers.calendar with trigger time 1763392500000
11-17 14:55:45.146 27742 12003 D NextAlarmManager: Skipping update from com.android.providers.calendar as it is not in the allow list
11-17 14:56:02.936 27742 12003 D NextAlarmManager: Next alarm is scheduled by com.amdroidalarmclock.amdroid with trigger time 1763387880000
11-17 14:58:00.154 27742  7595 D NextAlarmManager: Next alarm is scheduled by com.android.providers.calendar with trigger time 1763392500000
11-17 14:58:00.154 27742  7595 D NextAlarmManager: Skipping update from com.android.providers.calendar as it is not in the allow list
11-17 15:00:14.282 27742  7593 D NextAlarmManager: Next alarm is scheduled by com.android.providers.calendar with trigger time 1763392500000
11-17 15:00:14.282 27742  7593 D NextAlarmManager: Skipping update from com.android.providers.calendar as it is not in the allow list

Screenshot or video of problem:

Additional information:

[jpelgrom]

Your log excerpt suggests that the issue is that the next alarm that is available, is not from your alarm clock app, which is why the state doesn't change. This is by design: Android doesn't expose any information other than the next alarm system-wide, so the Home Assistant app doesn't know that there is an alarm at 19:10 (yet).

[wsw70]

yet

Thank you. So, when does the "yet" happen (when would it know that there is an alarm)? When there is no other (system-wide) alarm between now and the alarm from my app?

EDIT: ha! I now had a look at the next alarm and it is correct! (I have no idea why). The next alarm in my app is a week away, with tons of "intermediate" ones in between (from other apps)

[jpelgrom]

When there is no other (system-wide) alarm between now and the alarm from my app?

Correct.

The sensor is very literally the next alarm on your device, it can be from any app and even for alarms that are not visible to you as the end user if apps misuse the system.

[wsw70]

The sensor is very literally the next alarm on your device, it can be from any app and even for alarms that are not visible to you as the end user if apps misuse the system.

Thank you, this makes sense. When my whitelisted alarm goes off, it stays as it is because another one is setting the next alarm sensor (one that is not whitelisted). So the change of the value is denied. Only when a whitelisted one is next the value will chnage.

This is not very useful to know when the next alarm is, but it will work fine for automations (I just won't know when the automation will run).

---

This is not very reliable, though.

Somehow my next alarm is now set to next week, despite having many intermediate ones from non-whitelisted apps (from the calendar for instance)

As a test, I set it for a few hours from now. No changes in the value in HA after a minute. I will leave it for the night to see how it goes (my concern is the lack of reproducibility, sometimes it works, sometimes not, sometimes too well (like with the next alarm in a week)

[dshokouhi]

The reliability of the sensor really depends on the apps on your device and if they are using the same API. The best way to make it more reliable is not to use the allow list and instead look for the package attribute for alarms you dont care for and then remove them from the offending app. That way you can keep the next alarm list clear and it can behave better. Samsung calendar app for example sets alarm for each entry. Every app will be different.

[wsw70]

The problem is that I actually have three alarms (per the Android definition):

• Google Calendar, with alerts on upcoming meetings
• My Therapy, with a morning alert reminding me to take my pills
• Amdroid, an alarm clock

So I have to have several sources of alarms.

My last experiment showed that, with the whitelist, the alarm is not updated either, and now stubbornly shows next week (despite having set an alarm for tomorrow morning). This is the unreliability I had in mind.

I will however check tomorrow (it is the night here) if completely removing the whitelist as you suggest, and checking in the automation for the package name from the attributes of Next Alarm would not solve the problem. I would need to test my unreliable case by inserting alarms from various sources but it will not be difficult. I hope this will be the ultimate solution.
The displayed Next Alarm would not be useful but ok, I can live with that.

[jpelgrom]

@wsw70 Did you check with removing the allowlist?

What you describe is a bit confusing, but sounds right to me. Until the next alarm changes to one in the allowlist, the sensor state won't change. If for some reason the alarm a week away is the next one, it will change to that, but won't update to an earlier time until that earlier time is from the allowlist. The information given by the system is quite limiting, unfortuanately...

Unless your allowlist testing discovers an issue, I'm tempted to close this as there is no bug.