Ummm… No…
How did you get to that date?
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).