if you aren’t then it’s OK for a unix timestamp to have that long of a decimal as the fractional part of the seconds. that’s why it needs converted to an int to match on the seconds.
I don’t really consider that a solution. It’s a workaround for the thing that you couldn’t get working but it doesn’t answer why it didn’t work originally. Sometimes a work around is OK if there is no real answer. I’m just not certain that is the case in this situation.
But if your happy with it then that’s OK.
I’d still like to see your original full code for the binary sensor that wouldn’t work to figure out why it wouldn’t.
I always thought a timestamp had to be an integer. While I understand the concept of a fraction of a second, I didn’t think it was valid in a unix timestamp. I have been wrong before though.
@finity
I tested the original configuration with a twist, here is a bulletpoint;
Removed all alarms on Android
Created a one time alarm (then there is no new alarms after this)
Did a current time > alarm time it was false until current time passed alarm time then it became true
This concluded the rule worked.
So why didn’t it trigger when I used == ?
I guess the reason could be at a fraction of time, the alarm time got updated with the next alarm and possibly updated so fast that the binary_sensor didn’t update. Perhaps it changed from false to true so fast (and short time) that I could not see it even in the history of the sensor? Perhaps it would show in a log?
But I’m very happy with how it works for me now, this was actually closer to what I wanted and now I can actually easily control when and how long the binary sensor should be true.
Here are the old code you requested:
- platform: template
sensors:
stigh_next_alarm:
entity_id: sensor.time
value_template: >
{{ as_timestamp(now()) | int == as_timestamp(states('sensor.arielam30_arielam30_alarm_sensor')) | int }}
as I kind of suspected (which is why I asked for the code to be sure) I think here is the problem:
you were updating based on the change in the “sensor.time” entity. But that sensor only updates once every minute. You were trying to update your binary sensor on a second basis.
So the only time that the “trigger” (entity_id: to act on) and the “condition” (the value template) would coincide is if the “sensor.time” and the “now()” updated at exactly the same time which is highly unlikely.
To get it to work you would have to create a sensor that updated itself every second or use an automation that updates every second to be able to test for ==.
your workaround is another solution to that problem.
at least now you might know why it didn’t work as you originally expected.