Uptime in days hours and minutes

[andrei-lazarov]

Yes, but isn’t it a template sensor? I feel that code follows the legacy sensor configuration format

[Mariusthvdb (Marius)]

no, where did you get the idea this is a template sensor? some of the others above are, but this is a core integration

[andrei-lazarov]

I see, thank you.

[AllHailJ (J Gent)]

Here is how I would do it:

{{ states('sensor.ha_uptime') }}
{% set total_seconds = as_timestamp(utcnow())-as_timestamp(states('sensor.ha_uptime')) %}
{{ total_seconds }}
{% set days = (total_seconds / 86400) | int %}
{{ days }}
{% set hours = ((total_seconds % 86400) / 3600 ) | int %}
{{ hours }}
{% set minutes = ((total_seconds % 3600) / 60 ) | int %}
{{ minutes }}
{% set seconds = (total_seconds % 60) | int %}
{{ seconds }}
{{ [days, hours, minutes, seconds]|join(':') }}

You can cut & paste this in to developer templates and you should get something like this:

[Mariusthvdb (Marius)]

if you want a nicer state than the uptime sensor, why not use the template sensor posted above somewhere:

template:

  - sensor:

      - unique_id: ha_uptime_phrase
        name: Ha uptime phrase
        icon: mdi:history
        state: >-
          {%- set up = now().timestamp()-as_timestamp(states('sensor.uptime')) %}

          {%- macro phrase(name,divisor,mod=None) %}
            {%- set value = ((up//divisor) % (mod if mod else divisor))|int %}
            {%- set end = 's' if value > 1 else '' %}
            {{- '{} {}{}'.format(value,name,end) if value|int > 0 else ''}}
          {%- endmacro %}

          {%- set values = [phrase('week',60*60*24*7),
                            phrase('day',60*60*24,7),
                            phrase('hour',60*60,24),
                            phrase('min',60),
                            phrase('sec',1,60)]
                            |select('!=','')|list %}
          {{values[:-1]|join(', ') ~ ' and ' ~ values[-1] if values|length > 1 else
            values|first}}

[petro]

That output is basically identical to a timedelta as a string.

{{ utcnow() - states('sensor.ha_uptime') | as_datetime | default(utcnow()) }}

[AllHailJ (J Gent)]

This would not give the OP the days as requested.

Am I missing something?

[petro]

You overwrote total_seconds with a time from 2 days ago, so your as_timestamp calc has a difference of 2 days. OP is asking for days hours and minutes, not seconds. So in that regard, they are both wrong. Either way, this is the real difference (without incorrectly overwriting the difference)

[AllHailJ (J Gent)]

DUH! Missed changing yours. Sorry for the stupidity.

[drinfernoo]

This might be an old post, but I solved this via:

sensor:
  - platform: uptime

template:
  - sensor:
      - name: Uptime Relative
        state: >-
          Up {{ states("sensor.uptime") | as_datetime | relative_time }}

[AllHailJ (J Gent)]

But this does not give you the HH:MM:SS format that the OP wanted.

[drinfernoo]

Whoops! I guess I solved a different problem… I didn’t read closely enough

[virgilm]

In case anyone else is struggling with this, the documentation is confusing to say the least.

sensor:
  - platform: uptime
    name: "HA Runtime"

makes your builtin sensor be called now sensor.ha_runtime, because… why not? it’s quite obvious right?, even if the docs say: “name: Name to use in the frontend.” (should be “while adding an underscore for good measure and changing the entity name for you”)

[arganto]

What did you expect instead? This normalization is common everywhere, isn’t it?

[petro]

For the most part, yes

[virgilm]

I have to agree that is obvious to someone who lives and breaths HA, I get that. It was not obvious for me.

Maybe you care to explain why this is too:

sensor:
  - platform: onewire
    names:
      28-8367301e64ff: temp_one_wire

But the sensor is called: sensor.28_8367301e64ff_temperature → note the underscore and the suffix.

I understand that under the hood any character you don’t like gets translated to underscore, but I fail to understand how is that obvious. Normal engineering decision I would say, but it should be documented, that’s all I’m saying.

[bschatzow (Bill Schatzow)]

So when someone finds this should the doc be corrected or should an issue be created in GitHub on the integration?

[petro]

At the bottom of all documentation pages, there’s a suggest an edit button that will walk you through the process of giving feedback (issue against doc) or making the change yourself.

[virgilm]

All my doc suggestions were summarily dismissed, so I gave up on that.

[petro]

It’s not going to obvious. If you create a entity via YAML, it will depend based on the integration. If you’re providing a name, you should go to developer tools → states page and search for that name to get the entity_id. This is how it’s done for yaml integrations as many old yaml integrations make up random crap for the entity_id.