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')) }}
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.
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?
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…
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.
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?
State: {{ states('sensor.steves_phone_next_alarm') }}
Attribute: {{ state_attr('sensor.steves_phone_next_alarm', 'Time in Milliseconds') / 1000 }}
State as Timestamp: {{ (as_timestamp(states('sensor.steves_phone_next_alarm'))) }}
returning
State: 2020-11-04T15:25:00.000Z
Attribute: 1604503470.0
State as Timestamp: 1604503500.0
Looking at the code, I wonder if it is because the next alarm time returned by the AlarmManager is a Long but the SensorManager is treating the “Time in Milliseconds” attribute as a float (Long and Float are both subclasses of Number):
This could be resulting in floating point conversion issues.
I’ve confirmed that the floating point conversion is likely to be the cause of the issue by running this code in an online Kotlin compiler:
fun main() {
val originalTimeStamp: Long = 1234567890;
val timeStampString = originalTimeStamp.toString();
val timeStampFloat = timeStampString.toFloat();
val timeStampLong = timeStampString.toLong();
System.out.format("Original %d\n", originalTimeStamp);
System.out.format("String %s\n", timeStampString);
System.out.format("Float %f\n", timeStampFloat);
System.out.format("Long %d\n", timeStampLong);
}
and getting this response
Original 1234567890
String 1234567890
Float 1234567936.000000
Long 1234567890
So, the alarm timestamp is being converted from a Long into a string (to store it in the app database) and then back into a Float which is causing the value to change. If it is converted from the string into a Long, the same issue doesn’t occur.
