Sensor next_alarm not triggering on LG G8S phone

[Morphy99]

Home Assistant Android version: 2021.2.2-full

Android version: 10

Phone model: LG G8S ThinQ - LM-G810EAW

Home Assistant version: 2021.2.3

Last working Home Assistant release (if known): Possibly 2020.12 or 2021.1 but could be related to app version

Description of problem:

Next alarm sensor doesn't trigger for a LG G8 sensor but does for a Samsung S20. No errors visible in the log.

Example simple automation:

- alias: zzztest
  trigger:
  - platform: time
    at: sensor.lm_g810_next_alarm
  action:
  - service: light.turn_on
    entity_id: light.test_lights

State is reported as: 2021-03-01T11:46:00.000Z

State attributes:

Local Time: 'Mon Mar 01 11:46:00 GMT 2021'
Package: Unknown
Time in Milliseconds: 1614599160000
friendly_name: G8S Next Alarm
icon: 'mdi:alarm'
device_class: timestamp

The S20 has the same state timestamp format but the state attributes "Package" is not unknown so maybe this is the issue?:

Local Time: 'Sun Feb 28 12:21:00 GMT 2021'
Package: com.sec.android.app.clockpackage
Time in Milliseconds: 1614514860000
friendly_name: S20 Next Alarm
icon: 'mdi:alarm'
device_class: timestamp

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]

The next alarm sensor offers an allow list to get around this exact issue, an app setting an invalid time. You will need to set an allow list for this to work properly. Also some apps do not respect the Android API properly and will report invalid times. Samsung in particular is known for this behavior. Your option is to use an like the google clock app or sleep as android that make good use of the API.

Also duplicate of #1301 #1211 #1190

If the issue is regarding an automation not firing then that is not an app issue but an HA core issue, you will want to open a bug there if that is actually the case.

[Morphy99]

Thanks for the prompt reply! The time appears to be reported correctly by both though? It's the package attribute that is missing on the LG entity but I'm not sure if that would cause the automation not to fire. It's strange why the automation with the S20 works ok but with the LG not.

[dshokouhi]

if the automation is not firing then that is a HA core issue....all the app does is send over the date/time as a timestamp and HA core takes care of the rest.

[Morphy99]

Ok well I guess I need to do some more troubleshooting then as that was the only difference I saw. Thanks for the input.

[Morphy99]

I think what is happening is something similar to this where the sensor is changing to the new date/time a split second before HA triggers. I'm wondering if there can be some sort of delay in the app factored in so this doesn't occur?

It would also explain why this guy couldn't get his working but you could.

I tried creating a sensor from the mobile app sensor to trigger two minutes before and this worked fine:

- platform: template
  sensors:
    minutes_next_alarm:
      friendly_name: "Minutes until Next Alarm"
      unit_of_measurement: "m"
      value_template: >-
        {% set dummy = states("sensor.time") %}
        {{((states('sensor.lm_g810_next_alarm')|as_timestamp|int - now()|as_timestamp|int)/60)|int}}
      availability_template: "{{ not is_state('sensor.lm_g810_next_alarm','unavailable') }}"
      attribute_templates:
        time: "{{ state_attr('sensor.lm_g810_next_alarm','Local Time') }}"

[dshokouhi]

I think what is happening is something similar to this where the sensor is changing to the new date/time a split second before HA triggers. I'm wondering if there can be some sort of delay in the app factored in so this doesn't occur?

The allow list is what you are after here. All android apps are allowed to use the alarm manager API. We provide an allow list so you can filter out the noise and only get the updates from your alarm app of choice. Just keep in mind some apps do not make good use of this API and you may need to find a better app that will not abuse the API with false data.

[Morphy99]

What false data? The data provided is correct? The issue is the phone time is either slightly ahead of HA or the alarm app is changing the data a millisecond before which would be odd.

So I tried changing the allow list to just the LG clock which is com.lge.clock but now the alarm doesn't update. Probably because the mobile companion app doesn't read the package name for some reason. (hence package: unknown).

I downloaded Google Clock as recommended and set this to the allow list. I also brought up my system time and I can see this a few seconds behind. But the crucial difference is the sensor does not change immediately to the next alarm date/time. I've no idea when the google app changes this but even turning the alarm on then off and a pop up in the app saying alarm set for two days time, doesn't change the next alarm date in HA or the companion app.

IMHO, this behaviour isn't correct either as the next alarm should reflect immediately and there is nothing wrong with what the LG clock app is doing. It also means I have to have another app on my phone with the same name which is confusing. But at least I just noticed my Android Wear watch alarm now goes off as well with the google clock app (Not sure if that's a good thing yet!)

[dshokouhi]

What false data? The data provided is correct? The issue is the phone time is either slightly ahead of HA or the alarm app is changing the data a millisecond before which would be odd.

False data is any data that is not the same as you set in the alarm app, so if your alarm app is changing data beforehand then that would be false data. We report whatever data the API gives us the moment it sends us the data. Nothing more.

So I tried changing the allow list to just the LG clock which is com.lge.clock but now the alarm doesn't update. Probably because the mobile companion app doesn't read the package name for some reason. (hence package: unknown).

Sounds like either a manufacturer issue or app specific issue. We read and send back whatever data the API gives us.

I downloaded Google Clock as recommended and set this to the allow list. I also brought up my system time and I can see this a few seconds behind. But the crucial difference is the sensor does not change immediately to the next alarm date/time. I've no idea when the google app changes this but even turning the alarm on then off and a pop up in the app saying alarm set for two days time, doesn't change the next alarm date in HA or the companion app.

Next Alarm API is very literal, if another app is sending over data that makes their app the next scheduled alarm then with the allow list we skip that update. You won't see an update until its actually the next scheduled alarm on the device. Again this is how the android API works.

IMHO, this behaviour isn't correct either as the next alarm should reflect immediately and there is nothing wrong with what the LG clock app is doing. It also means I have to have another app on my phone with the same name which is confusing. But at least I just noticed my Android Wear watch alarm now goes off as well with the google clock app (Not sure if that's a good thing yet!)

Please understand the technical limitations of the API as I stated up above. If the LG app is changing the alarm on its own then that is indeed something wrong with the app based on the way the API functions. It may not be an issue for the LG app but for the purpose of how the API works it is not correct.

[Morphy99]

False data is any data that is not the same as you set in the alarm app, so if your alarm app is changing data beforehand then that would be false data. We report whatever data the API gives us the moment it sends us the data. Nothing more.

It's not changing the data beforehand, there is a time difference and behaviour difference, I already stated this. I'm not sure the behaviour is incorrect either....

Sounds like either a manufacturer issue or app specific issue. We read and send back whatever data the API gives us.

Yes I checked the package name in Tasker and it's correct. The app must not be passing the name with the Next Alarm API maybe?

You won't see an update until its actually the next scheduled alarm on the device. Again this is how the android API works.

Let me get this straight, the sensor won't update when the next alarm is due, until it's due? That can't be correct. Both the Samsung Clock App and the LG change the next alarm sensor as soon as the current one is dismissed, which is how it should work IMO. Actually I think that's not true for the LG one, it changes as soon as that time is reached. Which is why I'm having a problem. In theory if you dismissed the Samsung one as soon as it sounded and the HA time hadn't reached that then that would have the same effect.

The google one seems to be very illogical to me, maybe even a bug. If it's a recurring alarm it won't update to the next alarm after it's dismissed. It will stay in the past. If you go into the app and change the time to the future, it updates the HA sensor. If you have another alarm in it set in the future it will update to that. So that to me sounds like a bug in the google app not updating the API?

[Morphy99]

In any case, the seconds time difference is causing an issue with my HA here so I need to address that. I have a RTC on a RPi so it maybe that.

If you think that the LG behaviour is incorrect then I will have to resort to using the template sensor as I don't want to use another clock app and I don't want the sensor to reflect a next alarm time in the past.

Maybe something needs to be added in the Wiki for this or you will be getting more people encountering the same issue.

[dshokouhi]

You misunderstand. Lets say you have 2 apps that make use of this API. One app abuses the API and sets an alarm every 30 seconds. The app you care for sets an alarm 5 minutes from now. You set the allow list to the app you care for. Because the other app is abusing the API. The app you care for does not become the next scheduled alarm until 4 minutes and 30 seconds give or take a few seconds. The Android API that we use to get data from is very LITERAL in this sense. There is not anything any app does different asides from setting an alarm with the API. The API sends out an update to all android apps, we read the data. We send it back based on the allow list and the data we get. To truly fix the issue you have to stop using any app that abuses the API. If your device does not send back the package then yes in your use case it will be difficult to track down.

I have a google pixel and I use both the Google Clock app and Sleep as Android. No other app I have uses this API. As a result the data is as expected.

You have to understand that ANY app installed on your device can set an alarm that will interfere with this data, regardless of the allow list. We provide the tools you need to get around things. The allow list is designed to prevent apps that wildly abuse the API from sending data you don't care for. Tasker for example can potentially set an alarm every second. Now imagine how bad the data output there is. We are at the mercy of the apps you have installed and how they use the API. This is going to be different for every user.

https://github.com/home-assistant/android/blob/master/app/src/main/java/io/homeassistant/companion/android/sensors/NextAlarmManager.kt#L77

[Morphy99]

Ah OK I see. So even though the allow list is set to the Google app the LG one is still interfering. You're right, I disabled the alarm in the LG app and now once Google alarm has fired and dismissed it sets to the next time as expected.

I noticed the sensor data goes to unavailable whilst the alarm is sounding. This means if the time is even a second behind in HA the trigger will also miss. I still think this is an issue when we're dealing with seconds and different behaviours between apps.

[Morphy99]

Thanks for all your time and input by the way, it's very appreciated!

[dshokouhi]

Unavailable state shows up when the API does not report an alarm. So if you turn off all alarms for example you will see unavailable as the state.

[Morphy99]

It shows as unavailable when the alarm is triggered and sounding on my phone. This is with Google Clock app.

[dshokouhi]

That would make sense if it is no longer considered the next alarm, and there is no scheduled alarm set after it.

[Morphy99]

Well technically there is a scheduled alarm after it as it's a reoccurring alarm. But either scenario presents an issue if there is a time delay of seconds between devices. Is there no way you can look at changing the sensor to delay reporting changes, even if it's ten seconds, it would make the difference between the automation triggering and not.

[dshokouhi]

I just tested the scenario on my end and I do not see any issues with the alarm being recurring, the state changed to the next scheduled alarm in the Google Clock app. Have you checked that your HA system time is correct and that your cell phone time is up to date?

We will not be adding any delays to a sensor reporting interval I'm sorry. This sensor updates as soon as it gets a state change.

[Morphy99]

So the sensor doesn't change to unavailable when the alarm is sounding? The time is correct but it's behind a few seconds compared to my phone for some reason.

[dshokouhi]

no it changed to the next scheduled alarm, it went off at 12pm and the next alarm is 6 hours after

[Morphy99]

I've just looked at the time differences and for some reason my phone was +5s ahead. After a reboot it's corrected itself and also testing the alarm, it no longer goes to unavailable when sounding. Strange. I think I will stay with the minutes before sensor just in case it reoccurs. Thanks again for your help.