Next alarm sensor won't stick on the right time

Mobile Apps Home Assistant Companion for Android
,
16

True, I can confirm my old Samsung phone is not suffering from the same issue. Using an external alarm clock solves the problem on Xiaomi devices, simply upgrading the built-in application makes no difference.

17

Using the Google clock app, solved the problem :+1:

1 Like
18

I’m trying to get something similar from SleepAsAndroid on my Xiaomi Mi 9 (Cepheus) but still unable to get the right data. When you say “use an external alarm clock” could you please elaborate? Because even with SleepAsAndroid setting the time correctly, I’m currently having a nightmare of a time with it. At this point, I’m resorting to a LogCat filter in Tasker to try and get the correct time when the alarm is set or changed. But this is far from ideal and requires a lot of javascript to parse the logcat entry.

Ideally, I just want SleepAsAndroid to just expose the next alarm time via something easy to read. But at this point, I don’t know if that’s even a possibility outside of the Alarm API the HA client is already using on Android.

19

What issues are you having with getting the alarm from Sleep as Android? I use it myself and I get the state changes just fine.

20

Essentially exactly the same problem as the original post. The Alarm API the HA app uses always shows the com.xiaomi.calendar details, but never any of the others. Thus the whole reason I’m resorting to using LogCat in Tasker to try and get the time and send that via a webhook.

How are you doing it? What sort of device?

21

I do not make use of apps that abuse the alarm API and I also have a Pixel.

There is a new feature in version 2.5.0 that allows you to create an allow list so you can block out unwanted events. Go to App configuration > Manage sensors > next alarm > then at the bottom select the allow list and choose the packages you want to get events from.

Also documented here: https://companion.home-assistant.io/docs/core/sensors#next-alarm-sensor

2 Likes
22

Oooh, I had not noticed that change! You just saved me a whole lot of JS frustration! :smile: Thank you. I very much appreciate it!

1 Like
23

I am going through the post, I am making sure, bottom line there is no fix from samsung on the next alarm time issue correct? and I understood HA is obeying what is being sent from Samsung phone. So end of the day the issue still exist.

24

we provide whatever data is given to us by the android api, if a manufacturer decides to go against that not much we can do. Your better off finding an app that follows better standards like the Google Clock app or Sleep as Android. Samsung and others are known to do these odd things with the alarm api.

1 Like
25

Sure, so say I have installed that apps… how can i send that data to HA? is that what you are referring to as “packages” to select ?

26

Yup that will filter out the noise from the apps that you don’t need updates from

1 Like
27

I will try that … thank u !

28

I’m trying Google clock too. Do you know the name of the package to put in whitelist?

29

com.google.android.deskclock

2 Likes
30

Thank you very much.

OT: I just found that Google clock can start a Google Assistant routine when alarm rings! :smiley:
this is great…

31

@dshokouhi I have a Samsung s20 plus and when I set my alarm in the normal Samsung alarm app, on HA it shows the sensor.my_phone_next_alarm 5 mins ahead of the actual alarm. So e.g. it would show 07:35:00 but in reality the alarm is for 07:40:00.

Is that something normal or? Is there anyway round I can get the actual alarm that I have set in the stock Samsung alarm app?

Thanks.

32

Please see my previous answer in this thread

1 Like
33

So I created an allow list, and now, when I disable all my alarms, my next_alarm sensor remains stuck on the most recent datetime that was set, rather than changing to unavailable. Any suggestions?

It actually sounds like this is how the allow list works, from the next_alarm sensor description in the HA app:

“This will ignore alarm events for packages not selected and the state will not update until the next scheduled alarm matches one of the selected packages.”

I hope I’m interpreting this incorrectly, and that this doesn’t mean the sensor can’t update to unavailable because there is no next scheduled alarm matching one of the packages.

Btw, I’m only allowing the two packages below because other packages (e.g. Tasker) were causing erroneous times:

com.google.android.deskclock
com.amdroidalarmclock.amdroid
34

As soon as it updates to the next alarm it will work as you’d expect. You just need to have some patience or set an alarm for 1 minute from now so it updates to that then delete the alarm.

35

Thanks for the quick reply. But wouldn’t the process of updating to the next alarm also trigger my wake-up routine (which is not desired because I have turned my alarm off) because the sensor still has a stale datetime rather than unavailable? It seems like I might be missing something…

I tried to test that myself just now, but now I’m finding that the sensor is no longer getting stuck, and it’s correctly changing to unavailable when I disable the only scheduled alarm. I didn’t change anything, so I’m not sure why the behavior is different now. But as long as it stays this way, then I guess my problem is solved :slight_smile: