So it will be true only for a fraction of time?
My goal was for a minute (not using seconds). That is where I started messing with those strings (and as I stated, I assumed I needed this as integer).
Again, unfortunately time & date are still my nightmare…
Divide each number by 60 and convert to integer (I think)
It probably helps to know that these numbers are just seconds. Another way would be ti subtract them and see if the result is less than 30.
Like this ?
{{ as_timestamp(now()) / 60 | int ==
as_timestamp(states('sensor.arielam30_arielam30_alarm_sensor')) /60 | int }}
May I ask why you need it to be on for 1 minute?
Sure you can ask 
No particular reason, but it should be more than a 1/100 second, as I want to trigger automations and scripts based on this binary_sensor. Probably a second is more than enough - never done any testing if there are any delays from a binary_sensor switches between true/false to trigger an automation.
I make a lot of stuff regarding templates, sensors and stuff - though as stated - I hate time & date.
{{ as_timestamp(now()) / 60 | int ==
as_timestamp(states('sensor.arielam30_arielam30_alarm_sensor')) /60 | int }}
did not make it flip between false & true…
As far as I know, timestamp is just the number of seconds passed since 1. January 1970. So the binary_sensor should be on for one second, I think this should be enough to trigger automations.
here is some additional information…
Have you checked that “as_timestamp” for your sensor actually returns a valid unix timestamp in the template editor?
I think it should but since you having troubles it is easy enough to check.
{{ as_timestamp(now()) | int }}
returns 1583534241
At the moment,
{{ as_timestamp(states('sensor.arielam30_arielam30_alarm_sensor')) | int }}
returns 1583741100
So yes, they do… but the sensor never changes from false to true.
value_template: >
{{ as_timestamp(now()) | int == as_timestamp(states('sensor.arielam30_arielam30_alarm_sensor')) | int }}
I’m not sure if i’m losing something but those aren’t “equal” from what you posted.
try using a < or > just to make sure you are on the right track. one or the other must be true unless they are truly equal for 1 second.
the other thing to remember is that the template editor won’t update in real time. you have to modify the contents of that page before it will update the results. So you would literally have to make a change to the text every second to see it switch from false to true to false again.
Don’t know if it’ll help you but I have a sensor that returns true a couple of minutes before the set time
{{ ((as_timestamp(calendar_tvattid) - as_timestamp(now())) / 86400) }}
right now returns calendar laundry time event in 2.5 days
<= 0.004 makes the sensor true a couple minutes before the calendar event
tvatta_countdown_timer_trigger:
entity_id: sensor.time
value_template: >-
{% set calendar_tvattid = state_attr('calendar.tvatta', 'start_time') %}
{% if ((as_timestamp(calendar_tvattid) - as_timestamp(now())) / 86400) <= 0.004 %}
true
{% else %}
false
{% endif %}
then I automate an input boolean to show a timer
Hi @finity
Actually, I think I’ve found the reason for not getting the == (or why it is incredible short state).
As I have programmed alarms for every day in the morning, as soon as the ((now)) == alarm-sensor, the alarm-sensor updates to the next alarm time, and ((now)) is again < sensor-alarm.
I did turn off all alarms, created a one-time alarm on the android device, using this:
{{ as_timestamp(now()) | int > as_timestamp(states('sensor.arielam30_arielam30_alarm_sensor')) | int }}
Guess what, as soon as the alarm started, it changed from False to True, meaning the rule works but I assume as the alarm-sensor as soon it is triggered by the ==, it resets to next alarm. Perhaps HA doesn’t even get tu update the binary_sensor?
So, for what Mattias wrote in his sensor, it would be smart to actually trigger the binary_sensor a bit before they actually are ==. See my point?
Maybe it would be helpful for you to post the entire code for your binary_sensor instead of the just the template. You might be doing something else in that code that is preventing the sensor from updating…
I just did a test to turn on an input boolean based on now being equal to an input datetime making the seconds required to be equal and it worked for me.
@Mattias_Persson !!! You’re the man!
Here is the working solution, it turn on the binary_sensor 3 minutes before it actually should trigger. One of the issues earlier was exactly the part that as there is a new alarm coming up, somehow the sensor did never flip from ‘false’ to ‘true’.
I can edit the time before by changing the <= 0.002 % which I changed to 0.002 % = approx 3 minutes. Now I can trigger my morning routine where I actually do all the stuff that doesn’t work with Google Home in countries outside US; wish me good morning, turn on lights, open bliders, give me the weather report and turn on the radio on the Google Home.
entity_id: sensor.time
value_template: >-
{% set trigger_alarm = state_attr('sensor.arielam30_arielam30_alarm_sensor', 'state') %}
{% if ((as_timestamp(trigger_alarm) - as_timestamp(now())) / 86400) <= 0.002 %}
true
{% else %}
false
{% endif %}
Thank you everybody helping me resolve this 
In mine it gives a figure with 5 or 6 decimal places eg 1583547700.674958
I’m not sure if you are agreeing with me or not…
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.
if you are agreeing with me then 
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;
current time > alarm time it was false until current time passed alarm time then it became trueThis 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.