It changed in the most recent version, 2020.12.0, and is described in the Breaking Changes section of its release notes.
Hereās an excerpt:
to adhere to Home Assistant architectural design rules, the sensor is now changed to a timestamp.
As a side effect of this change, the unit_of_measurement option of this integration is now deprecated and can be removed from your configuration if you used that.
It means the sensor no longer reports the elapsed time since startup. It reports the time of startup.
If you want to know the elapsed time, you will need to calculate it (subtract the Uptime Sensorās value from the current time). Let me know if you need help creating the template.
sensor:
- platform: template
sensors:
s_ha_uptime:
friendly_name: HA Current Uptime
value_template: >
{% set secs = as_timestamp(states.sensor.time.last_updated) - as_timestamp(states('sensor.uptime')) %}
{% set days = (secs / (24 * 60 * 60)) | int %}
{% set plural = ' days ' if days > 1 else ' day ' %}
{% set hrmn = secs | timestamp_custom('%H:%M', false) %}
{{ days ~ plural ~ hrmn if days > 0 else hrmn }}
Yes, I added the colons. What do you mean by the whole template? What should I try in the template section of dev tools exactly?
I have all my sensors there. Also, I have āsensorsā under āplatform: templateā inside sensors.yaml and they are working just fine. I think you have to have it because it complains w/o it.
Again, to reiterate, this is the (only) template section of my sensors.yaml
- platform: template
sensors:
master_bedroom_temp:
friendly_name: "Temperature"
unit_of_measurement: 'Ā°F'
value_template: "{{ states('sensor.master_bedroom_temperature') | round(1) }}"
device_class: "temperature"
uptime_parsed:
friendly_name: Uptime
value_template: >
{% set secs = as_timestamp(states.sensor.time.last_updated) - as_timestamp(states('sensor.ha_uptime')) %}
{% set days = (secs / (24 * 60 * 60)) | int %}
{% set plural = ' days ' if days > 1 else ' day ' %}
{% set hrmn = secs | timestamp_custom('%H:%M', false) %}
{{ days ~ plural ~ hrmn if days > 0 else hrmn }}
Should NOT have the middle āsensors:ā line (Iām amazed it didnāt complain loudly at that). By definition āsensors.yamlā only contains sensors so this would be a repeat and is under - platform: template, which is a type of sensor. Nope thatās fine
Re: changes to offered code: When cutting and pasting stuff, get it working first, then customise it to your preferences then, so you know āwhatever you last didā was what broke it. Iāve learned most of my templating from backing out of mistakes
Itās considered very bad form to mark your own post as the solution
Every post on the forum would be solved by the original poster
Read the forum sticky (by Tinkerer) at the top of the forum (then read it again its a very good document)
Usually itās the person who contributed most to your solution.
Sometimes thatās the person who gives you the solution, but mostly itās the person who points you at a part of the documentation or corrects your syntax, or even just gives you an unrelated clue that turns out to be the solution.
Thanks for your guidance on this. I thought about it the wrong way. I did not intend in any way to take credit for the solution, simply to make it easier for whoever in the future with a similar problem to find a complete working code. But I see the point now.
{% set secs = as_timestamp(states.sensor.time.last_updated) - as_timestamp(states('sensor.ha_uptime')) %}
{% set days = (secs / (24 * 60 * 60)) | int %}
{% set plural = ' days ' if days > 1 else ' day ' %}
{% set hrmn = secs | timestamp_custom('%H:%M', false) %}
{{ days ~ plural ~ hrmn if days > 0 else hrmn }}
[/quote]
This is āthe whole templateā
Your version : -
[quote=ābackslashv, post:7, topic:260497ā]
- platform: template
sensors:
uptime_parsed:
[/quote]
Should NOT have the middle āsensors:ā line (Iām amazed it didnāt complain loudly at that).
By definition āsensors.yamlā only contains sensors so this would be a repeat and is under - platform: template, which is a type of sensor.
When cutting and pasting stuff, get it working first, then customise it to your preferences then, so you know āwhatever you last didā was what broke it. Iāve learned most of my templating from backing out of mistakes
Does this relate to my code as well?
- platform: template
sensors:
uptime_parsed:
friendly_name: Uptime
value_template: >
{% set secs = as_timestamp(states.sensor.time.last_updated) - as_timestamp(states('sensor.ha_uptime')) %}
{% set days = (secs / (24 * 60 * 60)) | int %}
{% set plural = ' days ' if days > 1 else ' day ' %}
{% set hrmn = secs | timestamp_custom('%H:%M', false) %}
{{ days ~ plural ~ hrmn if days > 0 else hrmn }}
It seems to be working, and the other āvariantsā I have tried ācomplains loudly at thatā.
If anyone is interested, hereās a one-line Template Sensor to report āup timeā.
- platform: template
sensors:
up_time:
friendly_name: Up Time
value_template: >
{{ ((now() - strptime(states('sensor.uptime'), '%Y-%m-%dT%H:%M:%S.%f%z')) | string)[:-10] }}
If the up time is less than a day, it is reported in this format (HH:MM)
20:46
When it exceeds a day, itās in this format (N days, HH:MM):
2 days, 20:46
The template produces a Timedelta object so thatās what governs the outputās format. The templateās [:-10] simply slices off the Timedeltaās seconds and microseconds.
