Strange behaviour with next_alarm entity provided by HA App

pete123 · November 2, 2020, 12:35pm

Hi,

since the next_alarm entity on Android HA app has been provided recently, I wanted to switch my alarm templates from using Hassalarm to this new method.

When testing this in the template editor I experienced some interesting behaviour.

Next Alarm Companion App:
current time    : {{now().strftime("%a %h %d %H:%M %Z %Y")}}
alarm time      : {{(((state_attr('sensor.pixel_4_xl_next_alarm', 'Time in Milliseconds') | int / 1000) - 0*60 ) | timestamp_custom('%a %h %d %H:%M %Z %Y')) }}
triggered:      : {{now().strftime("%a %h %d %H:%M %Z %Y") == (((state_attr('sensor.pixel_4_xl_next_alarm', 'Time in Milliseconds') | int / 1000) - 11*60 ) | timestamp_custom('%a %h %d %H:%M %Z %Y')) }}

The result looks this:

Next Alarm Companion App:
current time    : Mon Nov 02 13:19 CET 2020
alarm time      : Mon Nov 02 16:42 CET 2020
triggered:      : False

Sometimes when I set my smartphone alarm clock to a specific time like 16:43, the template shows 16:42. But sometimes it uses the correct time in minutes.

I can’t really see a pattern besides the fact, when it happens, the templates is set to 1 minute before the actual time which has been set up on the phone.

Does anyone has an idea, what could cause this?

Best

Hellis81 · November 2, 2020, 6:06pm

I have noticed the same thing.
It can be as much as three minutes incorrect.
I believe it has always been earlier than the alarm for me.

I just haven’t bothered since it’s never been enough to be an issue.

This morning the kids literally pushed me out of bed half an hour before my alarm was due.
1-3 minutes is ok for me.

I believe you should edit the post and place it in the companion app forum instead.

pete123 · November 3, 2020, 7:24am

Hey,

I moved it to the companion app forum.
However, when this issue occurs the time of the app sensor show the correct time. It seems to be the sensor entity on the server which receives the wrong time.

dshokouhi · November 3, 2020, 1:36pm

what alarm app are you guys using? Some alarm apps are known for sending incorrect time. All the app does is take whatever time Google sends to us and we send it back to HA. There is no data manipulation going on.

pete123 · November 3, 2020, 2:40pm

Hi dshokouhi,

I’m using the stock android clock. In the HA companion App under sensors the next alarm matches the android alarm but the alarm time being shown in HA has an offset.

e.g. I set the alarm on android to 21:45.
under sensors in the HA companion app 2020-11-03T20:45:00.000Z is shown. That’s probably CET.

in HA under developer tools, this code

{{(((state_attr('sensor.pixel_4_xl_next_alarm', 'Time in Milliseconds') | int / 1000) - 0*60 ) | timestamp_custom('%a %h %d %H:%M %Z %Y')) }}

shows:

Tue Nov 03 21:46 CET 2020

dshokouhi · November 3, 2020, 2:57pm

So the timestamp provided is that which your device reports as local time. That is what you see in time in milliseconds, that is pure raw data from the android API. If you are referring to what the Front end is displaying to you then that is entirely different from what the app provides. We only take the system provided time and convert the state to UTC format since that is what the front end expects and the attributes remain as local time to help the user with less conversions.

pete123 · November 3, 2020, 3:18pm

ok. But why is there an offset between the next alarm entity and the information the companion app provides? Is there maybe an error or rounding error in code mentioned above?

dshokouhi · November 3, 2020, 3:33pm

Here is all the logic for this sensor, as you can see we dont do any rounding

github.com

home-assistant/android/blob/a4f8ac53b5525bf32fb8482834c2a0c9b3fdb29d/app/src/main/java/io/homeassistant/companion/android/sensors/NextAlarmManager.kt#L67


val sensorDao = AppDatabase.getInstance(context).sensorDao()

val sensorSetting = sensorDao.getSettings(nextAlarm.id)

val allowPackageList = sensorSetting.firstOrNull { it.name == ALLOW_LIST }?.value ?: ""



try {

    val alarmManager: AlarmManager =

        context.getSystemService(Context.ALARM_SERVICE) as AlarmManager



    val alarmClockInfo = alarmManager.nextAlarmClock



    if (alarmClockInfo != null) {

        pendingIntent = alarmClockInfo.showIntent?.creatorPackage ?: "Unknown"



        if (allowPackageList != "") {

            val allowPackageListing = allowPackageList.split(", ")

            if (pendingIntent !in allowPackageListing)

                return

        } else {

            sensorDao.add(Setting(nextAlarm.id, ALLOW_LIST, allowPackageList, "list-apps"))

        }

        triggerTime = alarmClockInfo.triggerTime

Hellis81 · November 3, 2020, 4:14pm

I have very similar issues as pete does.
I also have a sensor that formats the time that is based on the same principle.

Yesterday it was correct. (I have the same alarm time every day)

Look at Andreas alarm here:

dshokouhi · November 3, 2020, 4:25pm

I see you guys are using templates, if you don’t use templates does the state change at all or is it as expected?

You can see if templates from this thread help: How to use next alarm sensor

Hellis81 · November 3, 2020, 4:39pm

This is the template I’m using

It doesn’t do anything more than change the format.
The strange thing is that some days it’s +1 min and sometimes -3 mins and anything in between.

I believe it’s a problem with jinja/HA not the app, to be clear.

Hellis81 · November 3, 2020, 4:46pm

If I use this:

And input this: 1604463400000

I get 5:16

dshokouhi · November 3, 2020, 4:46pm

More than likely its a jinja issue. One thing we added recently to the beta version of the app is sleep as android integration…The sleep as android app has some neat events that may do away with some of this templating. For example you can tell when an alarm was triggered, snoozed or even dismissed. No need for templating or looking at the time etc…

Hellis81 · November 3, 2020, 5:01pm

Here is the problem…
There is 100 seconds difference on the as_timestamp and the timestamp in milliseconds.

Whatever is creating the attribute is doing it wrong… or differently than as_timestamp at least.

dshokouhi · November 3, 2020, 5:08pm

This is raw data from google as I mentioned up above. We don’t change it and only convert to date/time in UTC format as you can see in the code linked up above.

Hellis81 · November 3, 2020, 5:16pm

Yes I see that too.
But something makes a change in the timestamp.

But as I said before, it’s not enough to cause an issue and definitely not enough to do more debugging in my opinion.

pete123 · November 3, 2020, 5:27pm

in my case there is an offset of exactly 60 seconds.

{{ (state_attr('sensor.pixel_4_xl_next_alarm', 'Time in Milliseconds')) / 1000 }}
{{ (as_timestamp(states('sensor.pixel_4_xl_next_alarm'))) }}

1604436360.0
1604436300.0

So, that means the timestamp is being shown incorrectly while the template to trigger the condition should be accurate in case we leave out the timestamp function, right?

Hellis81 · November 3, 2020, 6:13pm

I believe we can use as_timestamp of the state instead of state_attr of time in milliseconds and it will be correct.

pete123 · November 3, 2020, 8:41pm

Right, that seems to work.

current time      : {{((as_timestamp(now())|int ) | timestamp_custom('%a %h %d %H:%M %Z %Y')) }}
alarm time        : {{((as_timestamp(states('sensor.pixel_4_xl_next_alarm'))|int ) | timestamp_custom('%a %h %d %H:%M %Z %Y')) }}
current time sec  : {{(as_timestamp(now())|int ) }}
alarm time sec    : {{((as_timestamp(states('sensor.pixel_4_xl_next_alarm'))|int - 0*60 )) }}
trigger condition : {{((as_timestamp(now())|int )) == (((as_timestamp(states('sensor.pixel_4_xl_next_alarm')) | int) - 0*60 ))}}

Best

Hellis81 · November 3, 2020, 8:44pm

I changed my template and it’s correct today at least.
We’ll see what happens.