I’ve been using this for months, and it’s done very well for me
time_to_leave_for_work:
value_template: >
{% set t = strptime(states.sensor.time.state,'%H:%M') %}
{{ ( t.hour + t.minute / 60 ) > ( 8.25 - states.sensor.time_to_work.state | int / 60) }}
friendly_name: 'Time to Leave for work'
entity_id: sensor.time
Basically, this sensor " states.sensor.time_to_work.state" is the value of a waze travel sensor, which a numerical value representing how many minutes it will be to get to work. 8.25 is equal to 8:15am, so basically it changes to True, when I need to leave my house to get to work by 8:15am. I then use this as a trigger for other automations.
We’ll I’m getting to a point where sometimes I need to be in earlier (and rarely later), would be nice to have a simple input Date time to replace the static value “8.25”, but I dont know how to use input datetimes in math like this. Any tips?
In input_datetime (with only “time”) has a timestamp attribute which is the number of seconds the time is from midnight, as well as hour, minute & second attributes. So you could do:
time_to_leave_for_work:
value_template: >
{% set t = strptime(states('sensor.time'), '%H:%M') %}
{{ t.hour + t.minute/60 >
state_attr('input_datetime.XXX', 'timestamp')/3600 -
states('sensor.time_to_work')|int/60 }}
friendly_name: 'Time to Leave for work'
Note that you do not want entity_id: sensor.time, because first, sensor.time will be found automatically, and second, it would prevent the template from updating when sensor.time_to_work or input_datetime changes. Of course, since sensor.time updates every minute it’s not that much of an issue, but it’s really “more correct” without it.
EDIT: I should also say, in this case, you do not want the input_datetime to include date, because then the timestamp wouldn’t work for this.
Awesome, thanks. I had someone on here a while back saying that you should always use " entity_id: sensor.time" for all sensors to avoid timing issues. I was not really having timing issues, haha, but he seemed so convincing, I went ahead and added it to all my sensors. Are you saying I dont need it in this case because I’m already dealing with time, or maybe the other person may have given bad advice.
Either way, thanks for the knowledge, this will work perfectly
I think you’re referring to when now() is used in a template sensor. In that case the template will not be updated as time changes, because now() is not an entity, and hence, does not cause state_changed events. In that case you can “force” the template to update every minute by using entity_id and including sensor.time.
But, you have to be careful – if you use entity_id, then that prevents the usual automatic entity identification that is done for the sensor to figure out which entities is should watch for state changes. If you use entity_id (e.g., to add sensor.time), then you have to manually add all the entities the template uses, otherwise it won’t update sometimes when it should.
Great info, thanks. I might have to go back and double check some of my sensors.
So, last question. If I want this to turn true 15 minutes earlier without having to set my work time to 15 minutes earlier, I could just set it up like this right? I added .25 -
time_to_leave_for_work:
value_template: >
{% set t = strptime(states('sensor.time'), '%H:%M') %}
{{ t.hour + t.minute/60 > .25 -
state_attr('input_datetime.XXX', 'timestamp')/3600 -
states('sensor.time_to_work')|int/60 }}
friendly_name: 'Time to Leave for work'
Adding the .25 caused the template to fail. I’ve tried various ways of trying to basically make this true 15 minutes early. I’ve used parenthesis, single quotes, double quotes, but have been unable to figure it out.
EDIT: I could always just make my time to get to work 15 minutes ear;y, but would love to figure this out
