Uptime sensor in hours or days?

ESPHome
24

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:
uptime

9 Likes
25

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
26

This works like a charm, thanks!

27

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:
image

28

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. :slight_smile:

4 Likes
29

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

30

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
31

Is this good according to the new template style too? Working fine on my end, but still want to check.

32

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
33

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;
2 Likes
34

I use the same, but I’ve set the first sensor to internal only, so it won’t end up in HA.

35

It’s internal by default if it has no name:

36

ah, didn’t know that, thanks :slight_smile:

37

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.
image
image

1 Like
38 
device_class: duration

can be used but what difference it makes is still not known in uptime.

39

Great! it works.
It gives warning in compilation but it works. thank!

40

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?

41

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.

??

42

That should actually work. I am currently on ESPHome version 2023.3.2 and can confirm that setting a longer update interval for the template text sensor works.

The other thing to remember is (at least that’s my understanding) that even if the last restart time is sent every minute, because the value has not changed this should not be registered as an update in HA and thus not write an entry into the database.
Compare that with an actual uptime sensor that changes its value every single time, this would result in a state change and a new entry in the database.

43

Is it possible to make such a change so that there is no error when compiling?