I have a sensor that reports the last time a device_tracker’s location changed and I’m trying to calculate the time that has passed since then (eg: now - last_changed), but I’m not a Jinja Ninja.
Ah, formatting after-the-fact (outside of this template) hadn’t even crossed my mind.
However (which I failed to clarify in the OP ), I’m planning to combine this template with other (non-timestamp) templates as attributes in a template_sensor. If I’m understanding correctly this would not work with your solution would it, Mariusthvdb?
My initial goal was to incorporate states and attributes from several components into a single template_sensor, but after some fiddling I decided that was too limiting for my use-case – which is to display the data in a more-info popup on a google static map (generic camera on a picture_element card) that shows the locations of our family members. So instead I installed thomasloven/ lovelace-popup-card and I’m creating individual template_sensors to populate it.
Good info, I wasn’t too clear on how that functioned. Wouldn’t the device_class option convert the output to a timestamp though?
I’m not familiar with the relative_time function and didn’t find any documentation after a cursory search.
After a little more playing I think I’ve made some more progress using utcnow to isolate days / hours / minutes:
I can now perform the calculations separately then reassemble the outputs within the template to display as though they were a single string. This also allows me to omit useless info (zeros) and properly syntax labels (1 hour, X hours, etc.). So this is an example of what I have so far:
I’m not sure I’ve covered all necessary calculations yet – it’s a WIP.
I’m also experiencing some really unusual behavior: Templates that calculate correctly in the Template Editor will sometimes calculate incorrectly when copy/pasted into the template_sensor. Have you encountered anything like that before?
Ah, I think I just realized what was causing the strange behavior: I did not have an entity_id referenced to trigger updating the template_sensor. Per the docs.
I’ve now added: entity_id: device_tracker.zy225dsn4h_2
That’s only required if the sensor can’t determine an entity to update from.
I’m pretty sure if that is the case then there will be a warning printed in the log. At least that used to be true. If there is no warning then I don’t think that is a problem. But it also can’t hurt to put it in either.
since your calculating proximities, you might have a look at integration Proximity makes for easier templates/automations using these as entities in your config.
You should use params there. If your states change during the execution of the template, you’ll get odd results. The chances of this are low, but it can happen the way you are doing it.
Lat and Lon are floats inside attributes, no need to convert.
Rounding in the if statement to zero will remove the decimal place, this means you’ll only get results that fall on the whole number. Meaning anything less than 0.5 miles will be zero, everything between 0.5 and 1.0 will be 1. Which leads to the next point. You should round to 1st decimal place instead.
Your elif == 1 was never being hit because the if statement before it if <= 1 will get hit first.
You can combine == 1 and > 1 into 1 statement and programatically add the plural letter s.
- platform: template
sensors:
wifes_distance_from_home:
value_template: >
{% set dist = distance(state_attr('device_tracker.zy225dsn4h_2','latitude'), state_attr('device_tracker.zy225dsn4h_2','longitude'), XX.XXXXX, XX.XXXXX) | round(1) %}
{% if dist < 1 -%}
Less than 1 mile
{% else -%}
About {{ dist | round(0) }} mile{{ '' if dist | round(0) == 1 else 's' }}
{% endif %}
icon_template: >
{% set dist = distance(state_attr('device_tracker.zy225dsn4h_2','latitude'), state_attr('device_tracker.zy225dsn4h_2','longitude'), XX.XXXXX, XX.XXXXX) | round(1) %}
{% if is_state('sensor.wife_s_moto_x4', 'home') %}
mdi:home
{% elif dist >= 1 %}
mdi:steering
{% else %}
mdi:steering-off
{% endif %}
friendly_name: Distance from Home
@finity: Adding entity_id seems to have fixed the updating problem so far. I guess the sensor couldn’t detect any entities because they’re all defined within templates that it can’t decipher…? I have some other sensors in this set (time_at_location, battery_charge, etc.) where I used entity_id: sensor.time to update every minute.
@ Mariusthvdb: Yes, excellent recommendation! I had forgotten about Proximity but it’s now added to my todo list. Thank you.
Lat and Lon are floats inside attributes, no need to convert.
I don’t know why I didn’t notice that; Lat & Lon must be the most obvious examples of floats one would encounter!
…anything less than 0.5 miles will be zero, everything between 0.5 and 1.0 will be 1…You should round to 1st decimal place instead.
Hmm. I rounded to zero because I don’t care to have the smaller units displayed, but could that somehow throw off my calculations? It doesn’t seem like it would (in this context) since the rounding is performed after calculating, but maybe it would be a better practice for future usage (such as Proximity)…?
Your elif == 1 was never being hit because the if statement before it if <= 1 will get hit first.
I meant variables. Using {% set xxxx = .... %} means you’ll only access the state machine in that line essentially. This forces you to get the answer 1 time instead of multiple times. As the code executes, it doesn’t get a new number each time the function is called. It just gets the number once. Like I said before, it would be extremely rare that you run into differing numbers, but it could happen. So why not avoid it?
Good catch, @Bartem. I ran out of room on the card and stopped using that particular sensor shortly after this was posted, so I can’t confirm or dispute which works best. I seem to recall encountering inaccuracies with one of them due to the nature of GPS tracker reporting but my memory is vague.
Thanks for sharing your work… I ended using most of your sensors, and used the formatted address one as the basis for something kind of different but you saved me a ton of work and helped lead me in the right direction!
offer some advice?
), I’m planning to combine this template with other (non-timestamp) templates as attributes in a template_sensor. If I’m understanding correctly this would not work with your solution would it, 
makes for easier templates/automations using these as entities in your config.
).
