Wrong next alarm

[noxhirsch]

Home Assistant Android version: 2.1.1-9-g8fef348-258-full

Android version: 10

Phone model: SM-G975F

Home Assistant version: 0.114.0

Last working Home Assistant release (if known):

Description of problem:
The next alarm sensor seems to report all kinds of events. In my case instead of the next alarm tomorrow morning, I get the time of the next Tasker profile which triggers a task, which renders this sensor useless.

Traceback (if applicable):

Screenshot of problem:

Additional information:

[dshokouhi]

So this sensor actually reports whatever is the next system scheduled alarm that pretty much any app can use. To combat this we have provided the package so you can skip over these unwanted updates. Tasker is known to make a lot of use of this android feature which is the same feature that all alarm apps use. Skipping tasker won't solve this issue as then we don't get any value for the next alarm, your better off using package as a condition in your automation.

[noxhirsch]

Okay, to bad. I didn't think this would be a problem, because with Tasker itself I get the true next alarm, which I use to show that time on my dashboards.
Filtering in Home Assistant would need e.g. an additional template sensor so that wouldn't be the cleaner and easier solution I hoped for. Also updating every few minutes because of changing values might not be the best for battery life especially on bad cell reception, so I better disable it then.

Should I close this issue or keep it open if someone has a solution for the problem?

[dshokouhi]

So this is the API we are using. Tasker is honestly its own animal and they probably can filter their own events easily that way. We don't really have control over what schedules the next alarm. You can see here the API only returns the next event and not a list of events.

https://developer.android.com/reference/android/app/AlarmManager#getNextAlarmClock()

We can leave this open for now in case someone has a good solution for it.

[dshokouhi]

So I've been looking into this. If we decide to filter out lets say for example just tasker. If a user sets a tasker alarm every 5 minutes then this means the sensor will be unavailable up until the next scheduled alarm that is not set by tasker which would also not be that great. This will not stop the app from receiving the update and sending them to HA as we would still be sending unavailable anytime the sensors are updated as long as tasker is the source. I wonder if this sensor should come with a warning for tasker users that make use of scheduled profiles?

It also seems like other things tend to highjack this as Samsung does some trickery around Google Calendar based on research. I think that providing the package should still be helpful for those not wanting to go the Tasker route. At least then you can filter it out in an automation by using the package attribute as a condition.

[noxhirsch]

I think a general warning about this sensor might be the best solution for now 👍
Maybe the sensor also should be turned off by default, so users can see the warning in the settings.

[fti7]

Same Issue here :-) (Also primarily Tasker, but there are also other Apps which uses System Alarm Clocks)
I ended up with an Automation and feed it into an input_datetime if there is an update only from Sleep as Android Package (My primary Morning Clock) - This works but is not very user friendly

@dshokouhi as far as i understand to filter out specific Packages like Tasker etc is more or less just an Caching issue?
Why would you like to send the "unavailable" event to HA?

You could completely ignore all Events. Except from Packages, selected by the User. (Or send all, if none is selected)

For HA Based Caching:

• You could also add an own attribute per recieved package name to the sensor. (Not sure if HA allows partially update only one attribute per Sensor)
• Own HA Sensor per Package Name
  Or keep an persistent cache in the App Itself with PackageName<=>NextAlarm

But actually i dont see the issue if you only update the current sensor on Recieved Events from one or more selected Packages.
Or is the because you want also to report if there will be no more NextAlarm for an package?
Then just use the cached Time(s), compare it with the current time and invalidate/send "unavailable" if it already reached that point

BTW: My current automation works for me. But i really want to minimize the Updates send to HA. Especially on 1minute Timers in Tasker + Bad Mobile Cell Coverage... its bad

[dshokouhi]

Well so here is the problem. We can only get the next scheduled event from whatever package that maybe. If you have 1 minute timers setup in Tasker then you may only get 1 notification if that from the actual alarm (it may even get missed in that case). We have to listen to those alarm event changes. We also need to handle when the alarms are off or bad data is received hence the unavailable. Currently the sensor logic is that anytime a broadcast receiver gets an update or the update interval of 15 minutes passes all sensors get an update. So while we can skip some packages we are still going to send a value for now.

I know its not ideal now but all sensors currently send updates even if there were no changes detected. I noticed this as well when I was trying to get the battery percentage to update faster but it resulted in updates even when the screen turns on/off so I avoided that approach in that PR.

I like the idea of adding a description to each sensor so we can be mindful of situations like these and notify the user. I also like the ability to set certain sensors disabled from the start. Currently the only sensors that are disabled when we start are the sensors that require explicit permissions like phone and location.

To handle the logic of when to send sensor data if the value has indeed changed is a bit out of my realm but lets keep the ideas coming. I hear you that in bad coverage areas this is problematic.

[poofyteddy]

Hello,
I encounter this and also hopped for a way to filter (which look like it' won't be :( )
basically tasker use what it call 'Reliable alarm' (google it up, having the right word help) in order to save battery while keeping stuff in sync.
If you don't have task that are based on precise time but only on event, you can disable this in tasker.

1. Triple dots
2. Preferences
3. Monitor
4. Use Reliable Alarms -> Never

Sadly this wasn't enough for me with a Samsung phone because other app, (calendar but not only) created some alam ...
I will be looking for something else, maybe not use my phone as an alarm ... i don't know.

Hope this help

[aaamoeder]

Just wanted to chime in to report this as being "not use-able"
Is there a possibility to filter by alarm tag/name ?
This way we could set an alarm called "homeassistant" or whatever and have that be tracked by HA, filtering out all the rest, making it reliable.

[dshokouhi]

They do not offer the tag/name of the alarm in the next alarm API, only the package that set it. Use the package attribute as a condition in your automation to filter out the packages you don't care for.

[aaamoeder]

That's where I'm having issues.. alarm gets set every few minutes by tasker for some random reason I don't quite understand. These all get detected by the sensor fine and report the package "net.dinglisch.android.taskerm"
But when I set the actual alarm (tried both the stock oneplus app and the clock app by google from the play store)
it doesn't get detected by the sensor at all. It seems like it is getting flooded out by the tasker process or something.

[dshokouhi]

Tasker makes use of AlarmManager for scheduled and timed tasks/profiles. Unfortunately any app or manufacturer can make use of this API so we can't do anything when an app decides to abuse it. Your best bet is to adjust your tasker tasks to not make use of scheduled time based events.

[aaamoeder]

I did as poofyteddy suggested and it appears to be working..
I'll have to wait and see what effect it has on my tasker automations..

[fti7]

We need an option to filter specific Packages on HA Companion Level.... its just to much Changes which drains Battery/Traffic.
Also the Sensors should only sent Updates when there is an actual Change, not just pedriodically.

I would also like to have an Option to enable Queuing of Sensor Data if the HA Instance is not available.
e.g. for the GPS/Location Sensor when there is no Cell Coverage. - For next Alarm, it doesnt make really sense obvisly

[dshokouhi]

We need an option to filter specific Packages on HA Companion Level.... its just to much Changes which drains Battery/Traffic.

This will probably be an allow-list so users can just specify what apps they want the events from. There's just too many apps out there, now and in the future, that can make use of this API. So its better to let the user dictate what to allow as opposed to what should be blocked. It is an alarm sensor so I would imagine if you downloaded a new alarm app you would want to add it to the list, as opposed to downloading something like Tasker and discovering it uses the API when you didn't expect it to.

Also the Sensors should only sent Updates when there is an actual Change, not just pedriodically.

This was actually already completed in the last release, we only send an update if we have something new to send.

I would also like to have an Option to enable Queuing of Sensor Data if the HA Instance is not available.

There is no way to send back old data into HA, core will need to be updated to achieve that but I don't think it will happen. The app itself is aware of when it doesnt send data over and we use that for our state change detection to make sure we send the next update once your server is back online.