Trigger automation based on time in a sensor that writes a string

Configuration
1

Hi all,
I’m trying to make an automation that will broadcast to my google speakers when the car is done charging in 10 minutes. (We always use public charging, so we need to move the car).

I have an entity “sensor.time_charge_complete” which will report the time when the car is done charging.
Now, if only time_charge_complete JUST reported the time, then I could use the following template to trigger 10 minutes before this time:

{{ states('sensor.time') == (state_attr('sensor.catmobile_time_charge_complete', 'timestamp') - 10*60)|timestamp_custom('%H:%M', false) }}

Above is taken from Post #5

However, sensor.time_charge_complete reports values such as this:

18 January 2023 at 21:16

Does anyone have an idea how I could make a trigger that triggers 10 minutes before the above timestamp?

Thank you very much in advance!

2

strptime(string, format) will convert your string to a datetime object.

See: https://www.home-assistant.io/docs/configuration/templating/#time or search the forum for examples.

1 Like
3 
trigger:
   - platform: template
     value_template: >
       {% set time = states('sensor.time_charge_complete') %}
       {{ now() >= strptime(time, "%d %B %Y at %H:%M", today_at()) | as_local
       - timedelta(minutes=10)}}
1 Like
4

Thank you for leading me to the documentation. I cannot find heads or tails in this, I am not really familiar with python. :confused: If it possible you could give me a finished example? It would be much appreciated!

5

Hi Drew,
I’ve tried this now, and it does not work entirely how it is meant to.

It will not trigger if there is less than 10 minutes, which is not a problem.
It does trigger at any time that is above 10 minutes however. So it triggers 10 minutes before, 20 minutes before, 30 minutes before etc.

It is supposed to only trigger at 10 minutes before. Do you have an idea what the issue could be? I tried changing >= to <= after now(), but that didn’t seem to work.

6

While the template will evaluate as true any time after ten minutes before the time given by the sensor, it should not lead to multiple triggers. Template triggers only fire when the template’s evaluation changes from false to true.

One change you might want to make is to the default argument I put in the strptime(). Using today_at with empty args will cause the template to default to ‘true’ if the time charge sensor is unavailable, unknown, or has an output that doesn’t match the format. To make the template default to false you should only need to set the today_at as late in the day as possible.

trigger:
   - platform: template
     value_template: >
       {% set time = states('sensor.time_charge_complete') %}
       {{ now() >= strptime(time, "%d %B %Y at %H:%M", today_at("23:59:59")) | as_local
       - timedelta(minutes=10)}}

… if it keeps repeatedly triggering after you’ve changed that, it means the template’s value is bouncing between true and false and there is likely an issue with the stability of the sensor.time_charge_complete.

When doing time comparisons for triggers I always use now() >= instead of now() == because there are edge cases where the template might not be rendered exactly at the right time and the trigger will be missed.

The now() <= ... construction that you have proposed can’t work as a trigger with the rest of the template as given because it would be changing from true to false when the “10 minutes before” mark is met.

1 Like
7

Hmm, okay. Thank you for taking the time at explaining it to me.
Let me clarify on the sensor.time_charge_complete entity. When the car is not connected to a charger, this entity will be “Unknown”.

Once the car connects to a charger, the sensor.time_charge_complete will update and give the specific time the car will be finished charging at. I.e. 18 January 2023 at 21:16.

When the car is unplugged it will go back to “Unknown”.

Right now the car is unplugged and the state is “Unknown”. I am testing my going to development page, and manually setting a state. However, it only takes 1 second before the entity goes back to “Unkown”. I manually set the state of the sensor with a value like so: 18 January 2023 at 18:40 and experiment with different times.

In this testing manner, I tried the new example you gave. Now, the automation does not trigger any more with a time that is further than 10 minutes in the future which is perfect.

Though it does now trigger at 10 minutes before, 9 minutes before, 8 minutes before and so on. It did not do this using the previous example.

Like I said, I test this by manually setting the state of the entity. I set the time 10 minutes in the future. (And the entity then goes back to Unknown right after. If I then update the time to 9 minutes in the future, the automation triggers again.

In a real world scenario, the sensor.time_charge_complete will not go back to Unknown until after the car is completely done charging.

So, is it just my testing that gives false positives, whereas real world scenario where the sensor.time_charge_complete entity doesn’t bounce back and to “Unknown”, it would in fact not trigger at 10,9,8,7… ?

EDIT A quick and dirty fix is I could set a boolean as a condition, so that the automation would only trigger once a day.

EDIT Checking the entity, I also see it has assumed state true. Maybe this is the culprit?

assumed_state: true
attribution: Data provided by Tesla
device_class: timestamp
icon: mdi:timer-plus
friendly_name: Catmobile Time charge complete
8

Yes, your testing method/environment is causing triggers that should not happen in the real world. In the real world, the template’s value will stay true from ten minutes before the time until the sensor either changes to a new time or ‘unknown’/‘unavailable’. Staying ‘true’ does not re-trigger an automation.

Adding a boolean would just add unnecessary complication.

1 Like
9

Ohh, that makes perfect sense. Thank you very much! You just made our life that much easier! :smiley:

10

Hi Drew,
Something strange happened. The sensor had “Unknown” state all evening and night yesterday. Yet, the automation triggered at exactely 23:50:00. Does this has something to do with today_at("23:59:59")? For now, I’ll make a condition so that the automation won’t run at 23:50, but even better solution is if you were willing to take one more look over the template trigger?

Here is the entity:

Screenshot 2023-01-19 at 08.41.58
Screenshot 2023-01-19 at 08.41.58995×221 20.3 KB

And here the execution:
Screenshot 2023-01-19 at 08.45.05

And this is the trigger: (note, I know I’ve been referring to the entity as: “sensor.time_charge_complete”, but the name is actually: “sensor.catmobile_time_charge_complete”. So please don’t let this confuse you in the following template. I just want to show you exactly what I have in my config.)

id: '1674046851272'
alias: Bilen er opladt om 10min
description: ''
trigger:
  - platform: template
    value_template: >
      {% set time = states('sensor.catmobile_time_charge_complete') %} {{ now()
      >= strptime(time, "%d %B %Y at %H:%M", today_at("23:59:59")) | as_local -
      timedelta(minutes=10)}}
condition:
  - condition: or
    conditions:
      - condition: state
        entity_id: person.mikkel
        state: home
      - condition: state
        entity_id: person.barbora
        state: home
action:
  - service: tts.cloud_say
    data:
      message: Bilen er opladt om 10 minutter
      cache: true
      entity_id: media_player.hjemmegruppe
mode: single
11

Well, that’s annoying… one option would be to use a more explicitly falsifying default.

{% set time = states('sensor.catmobile_time_charge_complete') %}
{{ now() >= strptime(time, "%d %B %Y at %H:%M", now()+timedelta(hours=1))
| as_local - timedelta(minutes=10) }}

Another option would be to use a if clause to skim off all the “Unknown”-type states instead of trying to design the default.

{% set time = states('sensor.catmobile_time_charge_complete') %}
{% if time | lower not in ['unknown', 'unavailable', 'none'] %}
{{ now >= strptime(time, "%d %B %Y at %H:%M", today_at())
| as_local - timedelta(minutes=10)}}
{% else %} false {% endif %}
1 Like
12

Thank you!
I really like the solution with the if statement, I’ll try that off. Tomorrow we’ll charge the car, so I can give it a proper test. I will post the results here tomorrow.

Anyone using the tesla custom integration could really benefit off of this. I’ve linked this thread on the github page, along with a request that actually provides a sensor just supplying remaining time in minutes.

In the meanwhile, I’m really glad there are people like you willing to help strangers make their custom automations!

13

@Didgeridrew seems to be working! Thank you Drew, just bought you a coffee :slight_smile:

1 Like