Alarm in the same hour is in UTC format and not in GMT+1

[JoachimVeulemans]

I'm having an issue with the time format. I think there is an error with formatting it to UTC. I have updated to the latest version of the app. The issue was already there with the previous version.

Time of testing: 01:20 local time or 00:20+1 (GMT+1)

Alarm in phone: --- Value in HA: 01:50 / 00:50+1 --- 01:50+1 <-- Incorrect 02:50 / 01:50+1 --- 01:50+1 03:50 / 02:50+1 --- 02:50+1 04:50 / 03:50+1 --- 03:50+1

If the alarm is within the same hour (max 60 minutes from now), the format is not in GMT+1 but GMT+0 or UTC. This shouldn't be the case. The screenshot is when the alarm is set to 01:50 local time so HA needs to output Wed Dec 23 00:50:00 GMT+01:00 2020

[Johboh]

@JoachimVeulemans hey! Make sure you are running the latest version of Home Assistant (see second to last entry here https://github.com/Johboh/hassalarm/issues/21) and that you are using the input_datetime mode.

[JoachimVeulemans]

I'm using 2020.12.1. This is my configuration in the app.

[Johboh]

@JoachimVeulemans Is this something new you are experiencing? HA stores the value for the input_datetime in UTC. E.g. the timestamp you see in home assistant when checking the datetime, it shows the UTC timestamp. Here is an example where I at 14:10 set the next alarm to 14:25 and publish it:

And looking in home assistant:

Notice that the timestamp is 1608729900, corresponding to 13:25:00 UTC, but the time is 14:25, as HA is in GMT+1.

[Johboh]

The first screen is from the log console in "test connection" in Hassalarm, whereas the second one is from state view in HA.

[JoachimVeulemans]

I've always had problems with this issue. The next screenshot is what I get when I set my alarm to 14:39 or 15:39. I have no way of knowing which hour it actually is. So it's UTC the first time and GMT+1 the second time.

[Johboh]

@JoachimVeulemans But this is not an input_datetime, it's a sensor. Can you look at the input_datetime.next_alarm, the one shown in the screenshot you posted for Hassalarm?

[Johboh]

@JoachimVeulemans Can you show me the output of the "Test connection" log in Hassalarm? You can right-click and do "Copy anonymous log" to not include private keys and such.

[JoachimVeulemans]

I don't see this sensor?

[Johboh]

It will look something like this:

Using long lived token
Entity ID is of type input_datetime
Request: POST <host>/api/services/input_datetime/set_datetime

Request headers: Authorization: Bearer <token>

Request body: {"entity_id":"input_datetime.debug","timestamp":1608729900}

[JoachimVeulemans]

Using long lived token Entity ID is of type input_datetime Request: POST /api/services/input_datetime/set_datetime

Request headers: Authorization: Bearer

Request body: {"entity_id":"input_datetime.next_alarm","timestamp":1608731580}

[Johboh]

@JoachimVeulemans And do you have input_datetime.next_alarm declared in your configuration.yaml file, as specified here? https://github.com/Johboh/hassalarm#home-assistant-setup

[JoachimVeulemans]

I get the same timestamp in the log for different hours (15:53 and 16:53) 17:53 gives this:

Using long lived token Entity ID is of type input_datetime Request: POST /api/services/input_datetime/set_datetime

Request headers: Authorization: Bearer

Request body: {"entity_id":"input_datetime.next_alarm","timestamp":1608738780}

[Johboh]

@JoachimVeulemans The sensor in https://github.com/Johboh/hassalarm/issues/22#issuecomment-750302440 is not from Hassalarm, but from somewhere else (unless you are using the legacy sensor). Are you using the next alarm function in the Home Assistant Android app?

For Hassalarm, make sure you have the input_datetime sensor added https://github.com/Johboh/hassalarm#home-assistant-setup and then make sure it shows up when checking the state for it in Home Assistant.

[Johboh]

@JoachimVeulemans The value reported is the raw value reported by the Android OS. the next alarm will be the one reported by the alarm clock app. If you get the same timestamp for two different times, make sure you actually removed the first one, and that you gave it some time to update (by the alarm clock app).

[JoachimVeulemans]

It was not in my configuration, it is now but the same problem remains

[JoachimVeulemans]

I'm using the next alarm function. The entity (input_datetime.next_alarm) is showing up. Legace sensor is disabled. When I set a new alarm, I change the minutes so I know when it's updated. The minutes update but the hour doesn't because it's the same for an alarm in 60 minutes or the next hour.

Is it possible there is a conversion error to UTC when the alarm is less than 60 minutes away?

[Johboh]

@JoachimVeulemans When you say "next alarm function", do you mean the next alarm function in the Home Assistant Android app (i.e. not the Hassalarm)?

[JoachimVeulemans]

It's both set up I think, but both having the same problem. But now I'm trying to debug the problem with the Hassalarm app.

[Johboh]

@JoachimVeulemans Can you set an alarm within 60 minutes and show me the log from "Test connection", and then also a screenshot from the input_datetime.next_alarm state in Home Assistant.

[JoachimVeulemans]

Using long lived token
Entity ID is of type input_datetime
Request: POST <host>/api/services/input_datetime/set_datetime

Request headers: Authorization: Bearer <token>

Request body: {"entity_id":"input_datetime.next_alarm","timestamp":1608733860}

[Johboh]

@JoachimVeulemans So that looks correct, right?

[JoachimVeulemans]

When I select an alarm between 60 minutes and 120 minutes from now, the hour is the same. Thus the timestamp is also the same but should not.

[Johboh]

@JoachimVeulemans Make sure you don't have any alarm set. Verify that by opening Hassalarm and see that it says "no next alarm set". Run the Test Connection and verify that the input_datetime.next_alarm in Home Assistant is set to timestamp: 1 and year 1970 Then set an alarm between 60 and 120 minutes from now. Paste the log from "Test connection", and then also a screenshot from the input_datetime.next_alarm state in Home Assistant.

Also note what alarm time you did set.

[JoachimVeulemans]

Using long lived token
Entity ID is of type input_datetime
Request: POST <host>/api/services/input_datetime/set_datetime

Request headers: Authorization: Bearer <token>

Request body: {"entity_id":"input_datetime.next_alarm","timestamp":1}

Using long lived token
Entity ID is of type input_datetime
Request: POST <host>/api/services/input_datetime/set_datetime

Request headers: Authorization: Bearer <token>

Request body: {"entity_id":"input_datetime.next_alarm","timestamp":1608735480}

[Johboh]

@JoachimVeulemans Given the same scenario, what does Android OS report as next alarm? E.g. the one you see in the top of the notification area when you pull it down:

What alarm app are you using? And what does Hassalarm report as next alarm on the main screen?

[JoachimVeulemans]

It's a build in Xiami alarm app. Circled in blue is correct, Circled in Orange is incorrect.

[Johboh]

@JoachimVeulemans Can you just try a different alarm clock app, to rule out that the alarm clock is faulty? This one: https://play.google.com/store/apps/details?id=com.google.android.deskclock

[Johboh]

Looks like this is an issue with the Xiaomi Alarm clock app: https://community.openhab.org/t/xiaomi-miui-alarm-clock-sending-wrong-epoch-value/90734 https://c.mi.com/thread-2585135-1-0.html

[JoachimVeulemans]

Yeah, I installed the Google one and that works perfect. The issue is on Xiaomi's side. Sorry to bother you. Issue can be closed now! Thanks for your help!

[Johboh]

Great!

[thedevleon]

Maybe you could add this to the troubleshooting part? I was pulling my hair out why everything was one hour behind, and it is indeed the xiomi alarm clock. Everything works correctly with the google clock app.

[Johboh]

That is a great idea @thedevleon, I will do that.