That would do it. 
Iām glad you figured it out.
One more snippet for the crowd:
sensor:
- platform: uptime
name: "Uptime"
id: uptime_sec
- platform: template
name: "Uptime Days"
lambda: |-
return (id(uptime_sec).state/60)/60/24;
icon: mdi:clock-start
unit_of_measurement: days
I wanted to have the uptime still in seconds and have another one breaking it down in days
4 Likes
Andā¦here is another version to show a more human readable uptime in days, hours, minutes, seconds:
sensor:
- platform: uptime
id: uptime_sec
text_sensor:
- platform: template
name: ${upper_devicename} Uptime
lambda: |-
int seconds = (id(uptime_sec).state);
int days = seconds / (24 * 3600);
seconds = seconds % (24 * 3600);
int hours = seconds / 3600;
seconds = seconds % 3600;
int minutes = seconds / 60;
seconds = seconds % 60;
return { (String(days) +"d " + String(hours) +"h " + String(minutes) +"m "+ String(seconds) +"s").c_str() };
icon: mdi:clock-start
update_interval: 113s
Result:
10 Likes
Great stuff guys! Hereās a version I did that only shows variables if they are positive. (i.e. doesnāt state ādaysā until it has been up for at least 1 day.)
sensor:
- platform: uptime
id: uptime_seconds
text_sensor:
- platform: template
name: ${friendly_name} - Uptime
update_interval: 42s
icon: mdi:clock-start
lambda: |-
int seconds = (id(uptime_seconds).state);
int days = seconds / (24 * 3600);
seconds = seconds % (24 * 3600);
int hours = seconds / 3600;
seconds = seconds % 3600;
int minutes = seconds / 60;
seconds = seconds % 60;
if ( days ) {
return { (String(days) +"d " + String(hours) +"h " + String(minutes) +"m "+ String(seconds) +"s").c_str() };
} else if ( hours ) {
return { (String(hours) +"h " + String(minutes) +"m "+ String(seconds) +"s").c_str() };
} else if ( minutes ) {
return { (String(minutes) +"m "+ String(seconds) +"s").c_str() };
} else {
return { (String(seconds) +"s").c_str() };
}
-J
5 Likes
This works like a charm, thanks!
Guys, Iām really liking the human readable uptime strings but have you noticed that just after you program the thing it gives a value that is MASSIVE? For example:
Thanks for sharing this @JayElDubya, I used it and added the āStarting upā to take care of the huge negative number right after flashing.
lambda: |-
int seconds = (id(${node_name}_uptime_raw).state);
int days = seconds / (24 * 3600);
seconds = seconds % (24 * 3600);
int hours = seconds / 3600;
seconds = seconds % 3600;
int minutes = seconds / 60;
seconds = seconds % 60;
if ( days > 3650 ) {
return { "Starting up" };
} else if ( days ) {
return { (String(days) +"d " + String(hours) +"h " + String(minutes) +"m "+ String(seconds) +"s").c_str() };
} else if ( hours ) {
return { (String(hours) +"h " + String(minutes) +"m "+ String(seconds) +"s").c_str() };
} else if ( minutes ) {
return { (String(minutes) +"m "+ String(seconds) +"s").c_str() };
} else {
return { (String(seconds) +"s").c_str() };
}
icon: mdi:clock-start
I also determined that the huge negative number was causing a boot loop on the ESP32 so now I have used this code to reflash all my ESPHome devices so they come up with more readable and accurate values. 
6 Likes
nice find. Will update my nodes.I have had random reboots on several devices that eventually sort themselves out. I wonder if thereās some variation as to what order things are initialized upon boot. Hopefully this stops the overflow. For what itās worth, Iāve noticed high values on HA sensor values as well before it actually connects to HA and refreshes the value. Is there a way, maybe with a clever filter, to have an initial value (like 0) for a sensor to have before the data comes in?
-Josh
Iām not super found of limits (although I highly doubt my nodes will reach close to 10 years uptime).
This works even better:
text_sensor:
- platform: template
name: ${friendly_name} Uptime
id: ${node_name}_uptime
icon: mdi:clock-start
sensor:
- platform: uptime
name: "${friendly_name} Uptime Sensor"
id: ${node_name}_uptime_raw
update_interval: 60s
on_raw_value:
then:
- logger.log:
format: "Raw Value of Uptime sensor: %f"
args: ['id(${node_name}_uptime_raw).raw_state']
level: INFO
- text_sensor.template.publish:
id: ${node_name}_uptime
state: !lambda |-
int seconds = round(id(${node_name}_uptime_raw).raw_state);
int days = seconds / (24 * 3600);
seconds = seconds % (24 * 3600);
int hours = seconds / 3600;
seconds = seconds % 3600;
int minutes = seconds / 60;
seconds = seconds % 60;
if ( days ) {
return { (String(days) +"d " + String(hours) +"h " + String(minutes) +"m "+ String(seconds) +"s").c_str() };
} else if ( hours ) {
return { (String(hours) +"h " + String(minutes) +"m "+ String(seconds) +"s").c_str() };
} else if ( minutes ) {
return { (String(minutes) +"m "+ String(seconds) +"s").c_str() };
} else {
return { (String(seconds) +"s").c_str() };
}
Edit: Iāve added this as an example to the esphome doc: https://esphome.io/components/sensor/uptime.html#human-readable-sensor
3 Likes
Is this good according to the new template style too? Working fine on my end, but still want to check.
Hm, that was 3 years ago, and I have completely changed my approach. That code is probably still going to work fine - I havenāt heard about deprecating the old template format.
What I am doing nowadays is to have a time entity on the ESP device, then have a text_sensor that exposes that value, and then set the device class to timestamp inside Home Assistant. The major advantage of this approach is that the entity only updates once (as opposed to every 60 seconds) and thus reduces the load on the database, and it uses the built-in way to display a human-readable uptime like ā2 days agoā or āLast monthā.
text_sensor:
- platform: template
name: "${display_devicename} Last Restart Time"
id: last_restart_time
icon: mdi:clock
entity_category: diagnostic
# device_class: timestamp
time:
- platform: homeassistant
id: homeassistant_time
on_time_sync:
then:
# Update last restart time, but only once.
- if:
condition:
lambda: 'return id(last_restart_time).state == "";'
then:
- text_sensor.template.publish:
id: last_restart_time
state: !lambda 'return id(homeassistant_time).utcnow().strftime("%Y-%m-%dT%H:%M:%S.000000+00:00");'
2 Likes
Iām using this code (original code from Frenck):
time:
- platform: homeassistant
id: current_time
on_time_sync:
- component.update: uptime_timestamp
sensor:
- platform: uptime
id: uptime_sec
- platform: template
id: uptime_timestamp
name: "$devicename Uptime"
device_class: timestamp
entity_category: diagnostic
accuracy_decimals: 0
update_interval: never
lambda: |-
static float timestamp = (
id(current_time).utcnow().timestamp - id(uptime_sec).state
);
return timestamp;
3 Likes
I use the same, but Iāve set the first sensor to internal only, so it wonāt end up in HA.
1 Like
Itās internal by default if it has no name:
ah, didnāt know that, thanks 
modified it to comply with new guidelines
template:
- sensor:
- name: "Huawei Modem uptime"
state: >
{% set uptime = states.sensor.huawei_igd_uptime.state | int %}
{% set days = (uptime / 86400) | int %}
{%- if days > 0 -%}
{{ days }} days, {{ (uptime - (days * 86400)) | int | timestamp_custom('%H:%M:%S', false) }}
{%- else -%}
{{ uptime | int | timestamp_custom('%H:%M:%S', false) }}
{%- endif -%}
Edit: removed unit, bcz it is self explanatory.
1 Like
device_class: duration
can be used but what difference it makes is still not known in uptime.
Great! it works.
It gives warning in compilation but it works. thank!
1 Like
Hi guys,
why not using copy integration as suggested for wifi signal component to show rssi data in percentage?
Seems to be the new guideline, am I wrong?
This code ends up sending the device_last_restart to HA every 60 seconds, even if update_internval = 6h or a filter for delta 0.01 is addedā¦ it keeps sending the same last restart data every minute.
??