I can report that I am also experiencing the same issue with my Samsung S9+ so it might be that the Samsung implementation is screwing things up for us. Please let me know if you come across any solution or workaround.
I can report the same issue with my Samsug A70. Did anyone find a solution (for example a different alarm app than the default samsung one)?
I just dowloaded the default google clock from the play store and set the Home Assistant app to use that package (com.google.android.deskclock). But still when I turn off the set alarm on my phone, the next_alarm value in the home assistant app remains the same.
Also when I snooze my alarm (which sets an alarl 10 minutes into the future) and then dismiss the snooze, the sensor in the home assistant app remains 10 minutes from now.
Do I have to deduct that also google’s own clock app implements the API incorrectly?
Can anyone point me to an alarm app that uses the API correctly?
Im using “sleep as android” and it seems to work on my galaxy A70 (or A50? not sure).
However, i could use some help using the time stamp in node-red. Does anyone have an example that uses the android set alarm to do something in node red?
I’ll try to remember to share my node red automation tomorrow.
You confirm that with sleep as Android, if you remove an alarm, the next alarm sensor will also get updated accordingly (for example emptied if there is no next alarm anymore)?
Here’s the code which I mostly copied from someone else that starts the alarm sequence.
Caveats:
- it works for my wife but not for me as I have yet to find an android app that uses the API properly and thus works with the next alarm sensor (would welcome your confirmation about sleep as android).
- having this sequence for 2 mobile phones makes it go crazy, even at the level of the home assistant companion app. The next alarm sensor will start giving wrong times for both phones (both in home assistant and in the app configuration windows in the app itself). No clue why this is happening.
[{"id":"664bcf1c.d25e8","type":"delay","z":"7a3ae4e9.be665c","name":"wait until time","pauseType":"delayv","timeout":"5","timeoutUnits":"seconds","rate":"1","nbRateUnits":"1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"x":520,"y":220,"wires":[["dbe04d14.7bbab","2fea0326.b6ab7c","6ff082bf.fe0cdc"]]},{"id":"ffa8ad2e.133d4","type":"change","z":"7a3ae4e9.be665c","name":"reset","rules":[{"t":"set","p":"reset","pt":"msg","to":"true","tot":"bool"}],"action":"","property":"","from":"","to":"","reg":false,"x":330,"y":220,"wires":[["664bcf1c.d25e8"]]},{"id":"17ff4332.e9872d","type":"function","z":"7a3ae4e9.be665c","name":"time difference","func":"const now = Date.now();\nconst alarm = new Date(msg.payload);\n\nconst timeDifference = alarm - now;\n\nmsg.delay = timeDifference;\n\n// Reset the delay node before setting the new delay\nreturn [[{reset: true},msg]];","outputs":1,"noerr":0,"initialize":"","finalize":"","x":340,"y":180,"wires":[["664bcf1c.d25e8","96909069.97977","7510cf3b.04c65"]]},{"id":"2f50c59a.2439ea","type":"api-current-state","z":"7a3ae4e9.be665c","name":"get next alarm","server":"5c29d263.09d2ac","version":1,"outputs":2,"halt_if":"unavailable","halt_if_type":"str","halt_if_compare":"is_not","override_topic":false,"entity_id":"sensor.mobile_florence_next_alarm","state_type":"str","state_location":"payload","override_payload":"msg","entity_location":"data","override_data":"msg","blockInputOverrides":false,"x":160,"y":140,"wires":[["17ff4332.e9872d"],[]]},{"id":"71576a68.4c7494","type":"server-state-changed","z":"7a3ae4e9.be665c","name":"Next Alarm Flo","server":"5c29d263.09d2ac","version":1,"exposeToHomeAssistant":false,"haConfig":[{"property":"name","value":""},{"property":"icon","value":""}],"entityidfilter":"sensor.mobile_florence_next_alarm","entityidfiltertype":"exact","outputinitially":false,"state_type":"str","haltifstate":"unavailable","halt_if_type":"str","halt_if_compare":"is_not","outputs":2,"output_only_on_state_change":true,"for":"","forType":"num","forUnits":"minutes","ignorePrevStateNull":false,"ignorePrevStateUnknown":false,"ignorePrevStateUnavailable":false,"ignoreCurrentStateUnknown":false,"ignoreCurrentStateUnavailable":false,"x":120,"y":200,"wires":[["17ff4332.e9872d","96909069.97977"],["ffa8ad2e.133d4"]]},{"id":"8e4828e2.840ed8","type":"inject","z":"7a3ae4e9.be665c","name":"reboot or deploy","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":true,"onceDelay":"5","topic":"","payload":"","payloadType":"date","x":110,"y":100,"wires":[["2f50c59a.2439ea"]]},{"id":"5c29d263.09d2ac","type":"server","name":"Home Assistant","legacy":false,"addon":true,"rejectUnauthorizedCerts":true,"ha_boolean":"y|yes|true|on|home|open","connectionDelay":false,"cacheJson":true}]
I just disabled my alarms in Sleep as Android, and then I get this in HA:
Excellent, looks like you have found an android app that works, thank you! I will be testing this soon as well.
I’m still puzzled how it is possible that google’s own alarm app doesn’t work …
Hmm. some bad news for you perhaps, I just tried with android’s built-in clock, and that also seems to work for me.
Yes that might indeed be bad news for me.
TLDR: with the default google clock and the sleep as android app, removing the alarm does not set the next_alarm sensor to unavailable, and it won’t pick up an alarm set more than a couple of hours into the future.
I tested the sleep as android app (in the allow list I had to add com.urbandroid.sleep)) and had the following result:
I have bolded the problematic results.
- I set an alarm 1 hour in the future and the next_alarm sensor picks that up.
- I change that alarm to 3h29 minutes in the futute and the next_alarm sensor picks that up
- I change that alarm to 3h 31 minutes in the future and the next_alarm sensor does not pick that up and keeps the previously set alarm value.
- The alarm goes off and i click the snooze button which adds 10 minutes. The next_alarm sensor picks that up.
- The alarm goes off and I click the dismiss button, the next_alarm sensor keeps the original alarm time (which is now in the past) instead of being replaced with unavailable (if no next alarm is set) or an alarm more than 3h30min into the future (if I’ve set one). If i’ve set an alarm to less than 3h30min in the future, the next_alarm will correctly be replaced with that.
- I remove all the set alarms and the next_alarm sensor does not pick that up and keeps the previously set alarm time.
I also tested again the default google clock app (in the allow list I had to add com.google.android.deskclock) and there I experience similar behaviour of the next_alarm not becoming unavailable when removing the set alarms, and any alarm more than roughly 02h50min
(so not 3h30 min here) not being picked up.
Other strange things I’ve noticed, but which do not seem to affect the functionality of the next_alarm sensor:
One of the attributes of the next_alarm sensor is “Time in Millisends”, for me that is set to values such as 1610293320000 or 1610286360000, which I believe is 51 years into the future.
In the Allow List if you set for example com.google.android.deskclock (the google clock app), and then remove the google clok app, com.google.android.deskclock remains in the list and there is no way to remove it.
@dshokouhi, does any of this make any sense to you, or is it just my phone that is ready for the mental hospital?
I think you are not fully understanding how the Next Alarm API works in Android. If you do not see the sensor going to unavailable or changing to the next alarm that you set in the app then that is purely caused by another app making use of the Next Alarm API. The API is very literal in the sense that it only returns the next scheduled alarm. So if you have Tasker setting an alarm every 30 seconds I am sure you can imagine why it would be next to impossible for the state to update as Tasker will always be the next schedule alarm unless you set one thats just before that Tasker alarm but there is no way to really know.
The allow list does not let us magically get the alarm set by the apps you chose, we still have to wait for that app to be considered the next schedule alarm. All the allow list does is skip the update until it has one. unavailable will only show up if your device does not have an alarm scheduled, at all. In your case something is still abusing this API and the only way to stop it is to stop using that app or feature.
For your use case maybe ditch this sensor altogether and make use of Sleep as Androids new webhook feature so you dont even need to go by a date/time object. You go by the events that get pushed to the webhook. The app now also offers MQTT for the same thing. Just check the sleep as android app.
2 Likes
Thank you, Indeed I did not understand these nuances.
I realy like the next_alarm sensor, which works fine for my wife’s phone. But as I don’t know how to find our what is abusing the API, I will follow your advice to use sleep as android and the new webhook feature. Thanks a lot for the explanations and the tip.
Thanks @Hellis81 for pointing out my ignorance 
I assumed Time in Milliseconds was comparing the current time with the time of the alarm. 1610286360000/1000/60/60/24/365,25 is approximately 51 years 
Timestamps usually count from 1970-01-01 00:00:00.
So if you got 51 years (+10 days I assume) then that sounds correct.
Excel uses a timestamp format from 1900, and there is one other timestamp format that I have seen. But it’s very rare to see something else but UNIX timestamp when it’s in programming.
1 Like
Remove all apps from the allow list and use your alarm as normal to see what apps use the API
1 Like
Ah yes I understand.
It’s com.android.providers.calendar
I uninstalled business calendar pro now to understand whether that’s the culprit.
I would not expect it to be the Samsung calendar app as it does not have access to my calendar and when I click deny on the access request the Samsung app just closes again. Can’t uninstall that app.
Then I got net.dinglisch.android.taskerm so I’ve disabled tasker (I wanted to stop using tasker anyways).
Then I figured out that the Samsung clock app also behaves in a strange way (an alarm for 09:00 resulted in the next_alarm sensor reporting 08:55) so I stopped using that (can’t uninstall)
Now I still get com.android.providers.calendar and I’m not sure where it could be coming from now.
But I now understand the problem with the allow list better and have a suggestion for improvement.
When I remove an alarm which I had originally set 1 hour from now, the next alarm in the API will be for example 2 hours from now and come from com.android.providers.calendar. however as that is not in the allow list, the companion app will ignore it and stick to the now deprecated time 1 hour from now.
I’m not sure that is a logical behaviour for the companion app.
Would it not be more logical that when the API indicates the next alarm is no longer 1 hour from now and from the clock package but 2 hours from now and coming from com.android.providers.calendar (which is not in the allow list) that it changes the next alarm sensor to (temporarily) unavailable or unknown? After all,while we don’t know what the next alarm is from the clock package we know for sure that the alarm time 1 hour from now is no longer correct.
The allow list setting and the package attribute were designed to help make the situation easier on users. Adding more logic and complexity to an API that is already prone to abuse will not lead to a better experience. The unavailable state is reserved for when the system no longer reports any alarms so I suggest if you want it to work as expected you solve the issue with the app(s) misbehaving. Or you can just trust that things will update when they need to because eventually the alarm will be the next alarm to go off
I think I need to explain the proposed improvement better:
- Currently, if I have the allow list set to only allow com.google.android.deskclock and set an alarm at 09:00, the API will set 15:00 as next alarm time (coming from com.android.providers.calendar). Because 4ive set the companion app to ignore that package, it will keep the next_alarm sensor at 09:00, which in all cases is an incorrect value. I cannot imagine a single circumstance in which this is the desired value.
- Something similar happens when I set an alarm and it goes off and then end the alarm.
What I will now do is have the next_alarm sensor accept all packages, and then do the filtering in an automation, because that way the next_alarm sensor does get changed when I disable an alarm (and then make sure my lights & speakers do not turn on if the new next_alarm time is coming from another package than com.google.android.deskclock). However to me it would seem like a clear improvement in all circumstances to set the next_alarm sensor to ‘not yet known’ or something like that if the next alarm is not coming from the allowed package (and therefore it is for the moment impossible to determine what the next alarm is going to be).
For me it doesn’t matter that much anymore as thanks to all your helpful explanations I now understand better how it works and can automate my way around it, but I would expect it would also help others (this guy perhaps ) without causing any undesired behavior for anyone else.
1 Like
But this is a problem you have. Many others do not have this problem.
So fixing the problem for you may cause it to break for others.
If everyone else has to add allowed packages then that is an undesired behavior to me at least.
There is a saying that goes, Don’t fix what is not broken.
The thing that is broken here is how Samsung does things. The correct thing to do is to report it to Samsung and have them fix it.
Second thing to do is to stop buying Samsung stuff.
As I have this behaviour with the google clock app, my understanding was that this is universal.
But perhaps I still don’t fully understand the issue and it is indeed specific to Samsung devices, then nevermind my suggestion (which was intended to be helpful and not to solve my issues).