The EPIC Time Conversion and Manipulation Thread!

Have you checked the docs recently? it’s in better state than it used to be in terms of Time section.

Thank you :slightly_smiling_face:

I wouldn’t even know where to start on trying to get it to be part of the docs.

submit a pr on the documentation on github… super easy.

I’ve done a couple of doc PR’s already and that isn’t too bad.

It’s the “organizing” part that has me hesitant about laying it all out in a way that fits with the format of everything else.

2 Likes

I can’t get timestamp_custom to work with the following, what am I doing wrong?

{%- set t1 = states.sensor.vast_brunnsgatan_tram2.state %}
{%- set t2 = now().strftime("%H:%M") %}

{{ t1 }} - {{ t2 }} = X minutes

{{ strptime(t1, "%H:%M") - strptime(t2, "%H:%M") | timestamp_custom("%M") }}

Gives me xx:xx:xx instead of just x for minutes.

Because when you subtract a datetime from a datetime, you get a timedelta object. Not a datetime. Strftime and timestamp_custom do not work because it does not have the strftime method.

You can get the seconds out and divide it by 60.

{{ (strptime(t1, "%H:%M") - strptime(t2, "%H:%M")).seconds / 60 }}

but you’ll end up with minutes and a remainder.

so you can round it

{{ ((strptime(t1, "%H:%M") - strptime(t2, "%H:%M")).seconds /60) | round() }}

or truncate it

{{ ((strptime(t1, "%H:%M") - strptime(t2, "%H:%M")).seconds /60) | int }}

If you want to get technical, truncating is the route to go

1 Like

I think in your case the assumption is both now() and states.sensor.vast_brunnsgatan_tram2.state represent time within the same day (as you’re only using hours and minutes).

In this case there is no need to heavily use datetime as t2.time already has hour and minute field and all we need to do is extract hour and minute from t1 and do some basic maths:

{% set t1 = states('sensor.vast_brunnsgatan_tram2') %}
{% set t2 = now().time() %}
{{ (t2.hour - t1[0:2]|int)*60 + t2.minute - t1[-2:]|int }} minutes

Thanks both @AhmadK and @petro!

AhmadK, your solution looks neat but gave a negative value…

Well, that’s only possible if t1 > t2 (which is impossible :wink: ) or (most likely) t1 holds time not from today.
Does petro’s solution produce a different result?

t1 is in the future (next tram) so it could be the case…
Yes Petros gave a positive/correct value.

1 Like

well, if I don’t know that, how is it possible to give you the right solution?
I thought you’re working with time in the past… :frowning:
This code works for both past and future times

{% set t1 = states('sensor.vast_brunnsgatan_tram2') %}
{% set t2 = now().time() %}
{{ ((t2.hour - t1[0:2]|int)*60 + t2.minute - t1[-2:]|int)|abs }} minutes

Hi
is the following possible?

can I convert to a readable format the following calendar sensor

Next calendar event on {{ state_attr('calendar.makis', 'start_time') }} 

i get this

Next calendar event on 2020-05-11 11:30:00

but google home reads something like: two, zero, two, zero, five, etc
and I would like something
Monday 11 May at eleven thirty in the morning
is it doable?

I don’t use Google Home so I’m not sure how you would need to tell GH that the number is a date instead of just a string of digits to read out.

That’s really outside the scope of this thread.

EDIT: Sorry if that came across badly. I should have said “Sorry but I don’t use Google Home…”

1 Like

I got deep into a topic that I expected to be quite easy. All I want to do is to display how long ago switch was pressed that executes a automation.

First problem, the last_changed state resets when home assistant reboots.

So I tried with a sensor template:
value_template: '{{ ( as_timestamp(now()) - as_timestamp(state_attr("automation.muffin_essen_start", "last_triggered")) ) | timestamp_custom("%H:%M") }}'
I grab the last triggered state from the automation as this seems the only thing that is preserved after a reboot. I would need more time conversation for this, as the “timestamp_custom” does not work in this case. First, the hour starts always with 1, second it shows a maximum of 24 hours. While trying to fix that I run into a lot of trouble :slight_smile:

While searching I though I found another solution with “relative_time”, that is easier to do, the downside is that is only shows the biggest value (e.g. no minutes when it’s more than 1 hour).
value_template: '{{ (relative_time(state_attr("automation.muffin_essen_start", "last_triggered"))) }}'
that would be good enough. it does only update when the automation is triggered, so I had to add a sensor.time as entity (I think that way it updates every minute). And with that there is another downside, after pressing it still shows the old value up to a minute. But the best I could do so far :slight_smile:

- platform: template 
    sensors:
      muffin_time_passed:
        entity_id: sensor.time
        friendly_name: "Last trigger"
        value_template: '{{ (relative_time(state_attr("automation.muffin_essen_start", "last_triggered")))  }}'
        icon_template: mdi:timer

If you’re using just an entities card, it’s much easier.

sensor:
- platform: template
  sensors:
    muffin_time_passed:
      friendly_name: "Last trigger"
      device_class: timestamp
      value_template: '{{ state_attr("automation.muffin_essen_start", "last_triggered") }}'

device_class: timestamp will auto update the UI to reflect the last triggered time. It will be a friendly verbiage as well. Like x minutes ago.

You can also just do this without a template by placing the automation in an entities card, but it will appear in the secondary info spot instead of the state spot for the row.

type: entities
entities:
- entity: automation.muffin_essen_start
  secondary_info: last-triggered

yes, that a nice tool isn’t it :wink:

too bad the same last-triggered for scripts is still not surviving restarts.
Don’t now why, but the bug report got buried probably.

1 Like

You could always set an input_datetime to the time the switch was triggered. Those survive reboots and you could set up another sensor using it if needed to give you “how long has the switch been on?”.

He’s using an automation so it’s a moot point because those survive.

1 Like

I really need to start reading more closely…

fwiw, here’s the link to the issue for last_triggered not being restored as it should be: