Compare the example I posted here for finding the last item in a list, using python’s [-1
], versus the previous post in the same thread that employs Jinja2’s length
filter. Basically, “pythonic” means doing it the ‘python way’ and taking advantage of its strengths.
Quick question - if I have several sensors I want to format in a particular way, do I have to create the same template sensor each time with a different entity, or is there a way to create a “template” template sensor which can be reused by just passing the entity each time? Kinda like the way we can template Lovelace cards, but for the sensor itself, if you see what I mean?
Thanks to @finity for this thread, and also to @pedro who also added some very useful info on this Date formatting thread, both have been very helpful and enlightening, so thank you both!
No hay problema
You can reduce some of the duplication by using YAML anchors and aliases. I provided an example here:
Aaah! Interesting (I’d heard of the yaml anchors, but never looked into them further so didnt realise I could use them in the sensors (rather than in the lovelace side of things). Thank you @123, that should help somewhat
Thanks for that.
I never use those so I never remember to think about them.
Just wanted to thank you again for this thread @finity.
Every time I get stuck on something time/date related the answer is always right here! I bet you if you were to organize it all formal like and submit it, it could become part of the official docs.
Have you checked the docs recently? it’s in better state than it used to be in terms of Time section.
Thank you
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.
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
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
Well, that’s only possible if t1 > t2 (which is impossible ) 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.
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…
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