Next Alarm Inaccurate when Apps Excluded

Home Assistant Android version: beta-2646-84aa4454-full

Android version: 12

Phone model: Samsung s10

Home Assistant version: 2022.8.7

Last working Home Assistant release (if known):

Description of problem: For the Next Alarm sensor: if an excluded app sets the next alarm, then the Home Assistant Companion App does nothing and the Next Alarm sensor keeps its previous value. This is not accurate because the Home Assistant Companion App now has no idea when the next alarm will be for an allowed app. The sensor should become unavailable or unknown when the next alarm is an excluded app.

One situation where this actually presents as a bug: The next alarm is currently set from an allowed app, and there is another later alarm set in an excluded app. The Next Alarm sensor in the Home Assistant Companion App currently has the value from the allowed app. If the alarm in the allowed app is turned off, nothing happens to the Next Alarm sensor. The Next Alarm sensor keeps the same value even though the alarm was turned off because the next alarm is now from an excluded app. Any automation triggered by the Next Alarm time will all execute at the time the alarm was set for even though I turned off the alarm.

It’s probably fine if the Home Assistant Companion App assumes that the previously set alarm time is still valid as long as the alarm is AFTER the next alarm time from an excluded app, but the Home Assistant Companion App really needs to clear the Next Alarm sensor if the next alarm from an excluded app is after the current sensor value.

Traceback (if applicable, to get the logs you may refer to: https://companion.home-assistant.io/docs/troubleshooting/faqs/#android-crash-logs):

Screenshot of problem:

Additional information:

[dshokouhi]

Personally I think that if we change the behavior then it needs to be a setting that is not default as this sensor has been out for some time. The only time an issue happens here is when users do not understand how the API or their devices work. For pixel users we don’t have extra apps adding alarms in places unexpectedly by default. This issue really only impacts a small subset of manufacturers and apps that use the API in unexpected ways. In most cases where the API is not abused the sensor behaves as described in the docs and no stale state is kept. This will also be considered a breaking change for this sensor as the unavailable state will happen in different situations and more frequently.

IMHO I prefer not to manipulate the data and only send events when we care about them, just like we do for Last Notification and current sensor behavior. The app does not care about what the value is that was previously sent, it only sends values that we care for. We already print to the logs when we don’t send an update in an effort to help the user understand why the state is stale and not updating.

I honestly can’t see any valid use for the Allow List on the Next Alarm sensor.

You will want to read up on the next alarm sensor issues to better understand the history and how certain features came to be but when you have apps that trigger every 30 seconds (which indeed there are apps like that) you start to get a lot of events generated. So skipping events completely is valid but nobody is forced to use the allow list if they don’t want to. I think the use case described is more of an edge case and if the user really wants data to be presented in a certain way then its best for them to avoid the allow list and automate around the raw data as they see fit.

The best way to think of this API is in a very literal sense. It only contains data for the next scheduled alarm and thats it, it does not know about previous events or future events only the next event in line. For that reason is why there is an allow list and not all users need to use it. It depends on things from device to device and user to user so consuming unfiltered data might be best for some and not so good for others.

[jpelgrom]

Couldn’t you at least make the sensor value unavailable if the current value is BEFORE the next alarm? In that case you know 100% that the value is invalid.

That will result in issues when device and cell network are off by timing

I don’t quite follow how this could create issues if the device time is off?

If I understand the request correctly, rephrasing it to be a bit more technical: if nextAlarmClock returns a value but that isn’t for an app on the allowlist, could the sensor state be changed to unavailable?

This will allow you to know if the value is ‘updated’ or not, which with the current behaviour isn’t possible. (I know it’s documented but feel like it doesn’t match expectations about what a sensor is.)

scenario	current state behaviour	proposed state behaviour
next alarm is for an app on the allowlist / all are allowed	[time for next alarm]	[time for next alarm]
next alarm is for an app not on the allowlist	state doesn’t change!	unavailable
no next alarm	unavailable	unavailable