Companion app next alarm sensor useless? - not resetting

Tags: #<Tag:0x00007f327058d370>

Used to roll with the Hassalarm app, but saw that the official companion app now has a Next Alarm sensor. However, on further testing, I noticed that disabling all alarms does not set the nextAlarm sensor to something like 1970-01-01 00:00:00. Basically, once an alarm has been set, it can only be postponed or preponed (if that’s a word lol) - not disabled.
Also, that allow list of thousands of packages really needs a search function lol.

How does anyone go about this issue?

I’m quite sure that is an issue with your phone.

Its in the App companion’s configuration - not actually within HA.

Also, just read here that its supposed to return nothing when no alarm is set, but nodered and HA still reports an alarm.


Again… That is an issue with your phone.
Both my alarm app, HA companion app and HA state show unavailable.

If your phone says there is an alarm then that is what HA will believe.

Hmmm - So how does one solve that? (Samsung s10e)

You could try a different alarm app or report it to Samsung as a bug.
But I doubt they will care.

rip - thanks anyways! (although hassalarm can get my alarm from the samsung app without any issues so it should be fixable in the companion app?)

The app takes what is in the phones API.
Perhaps there is a enabled/disabled flag that hassalarm also looks at but I assume the “standard” way of using the API is to clear the value from the next alarm.
I know there has been problems with other manufacturers and it has been discussed in the companion app forum.

1 Like

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 ( 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.

  • 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 =;\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.

  1. I set an alarm 1 hour in the future and the next_alarm sensor picks that up.
  2. I change that alarm to 3h29 minutes in the futute and the next_alarm sensor picks that up
  3. 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.
  4. The alarm goes off and i click the snooze button which adds 10 minutes. The next_alarm sensor picks that up.
  5. 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.
  6. 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 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 (the google clock app), and then remove the google clok app, 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.

1 Like