Understanding device class duration better

And this is the point where I put my foot in my mouth: With all my experimentation I missed adding device_class: duration to the original sun2 sensor (I had it everywhere else). No issue, and no inconsistencies.

1 Like

Anyway, in my tests the customization affected after HA restart only, which is not right.

1 Like

Customizations can be reloaded from the UI on Developer Tools → YAML tab, they fall under “Location & Customizations”. However unlike all the other things you can UI reload on that page they don’t take effect immediately which is a bit confusing. From the warning at the bottom of the doc:

New customize information will be applied the next time the state of the entity gets updated.

This is the behavior I see. Nothing happens immediately after I reload customizations but next time the state of the entity I customized is changed for any reason then I see my new customizations. Is that what you see?

1 Like

Starting from now I will observe it with a more attention.

What I observed so far:

  1. I customized some template sensor in a yaml file (homeaasistant / customize); let it be an icon.
  2. Then reloaded customization (Dev tools → yaml → reload).
  3. Not affected, the icon not changed.
  4. Reloaded template sensors.
  5. Now I see that the icon is changed.

One time I started thinking that oddly customizations are applied after template reloading - even was thinking about writing an issue about it.
Now I think that reloading templates affected their states somehow - and then it made customizations to apply.

Reload removes the entities from the system and then readds them with the new config. Anytime an entity is added to the system it counts as a state change and thus new customizations are applied. Even if from your perspective the state hasn’t changed to HA it has.

If you check last_updated you’ll see it’s set to the time you clicked reload. Same thing happens when you restart HA, every entity gets an updated last_updated value even if nothing else seems to have changed.

1 Like

Thanks a lot for explanations!

On my system didn’t make any visual difference
Before
image

and after multiple restarts too, the state was being updated too.
image

It looks like you’re showing me a sensor that is correctly outputting the result of your template. What does that have to do with customization and what I said?

1 Like

What I was thinking/assuming changing device_class: duration will add units of time to the sensor, I.e make it human readable, e.g 3 days 12 Hours 20 mins and 12 secs, instead of current template, which mention largest unit only. 3 days 12:20:12.

That’s not a timestamp. If you add device_class: timestamp to that sensor it won’t do anything except maybe create an error. See the docs for sensor device class:

timestamp: Datetime object or timestamp string (ISO 8601)

Your template clearly does not output a datetime object or a date string in ISO-8601 format so that’s not the correct device class for that sensor.

Change your template to this and add that device class and it might do what you want:

{{ now() - timedelta(seconds=states('sensor.huawei_igd_uptime') | int) }}

I think I should know device-classes better as well :wink:

I’d like to know how much time I have to spend heating the hotwater-boiler untill it is 100% “charged”
Looking at this post I thought I could add as device-class and state-class in the template-sensor, but it is not working, how might I get it to work ??
when adding unit of measurement, device-class and state-class the sensor goes “unavailable”
Have not tried customizing, as I believe it should work directly in template-sensor?

template:
  - sensor:
      - name: "Hotwater SoC chargetime float"
        unique_id: hotwater_soc_chargetime_float
        icon: "mdi:lightning-bolt-outline"
        unit_of_measurement: "t"
        state: >
          {% set p = states('input_number.hotwater_soc_elementsize') | float %}
          {% set kwh = states('sensor.hotwater_soc_energy_chargable') | float %}
          {{ (kwh / p) | round(2) }}
        # attributes:
        #   <<: *solution_attribute

      - name: "Hotwater SoC chargetime"
        unique_id: hotwater_soc_chargetime
        icon: "mdi:store-24-hour"
        # unit_of_measurement: "h"
        # device_class: duration
        # state_class: measurement
        state: >
          {% set hours = states('sensor.hotwater_soc_chargetime_float') | float %}
          {% set minutes = ((hours % 1) * 60) | int %}
          {% set hours = (hours - (hours % 1)) | int %}
          {{ '%02i:%02i'%(hours, minutes) }}

I guess the consensus in the post was to customize, but I’m trying to create a template sensor which should be able to add the correct attributes?

I think I am missing something obvious?
the entities are presenting data that is correct, but should it not be possible to add the right classes somehow?

duration sensors need to have a unit of measurement that match the given output. I.e. a UOM of minutes and you output just minutes.

In your case, you output hours… so simply add a unit of measurement to your first one…

template:
  - sensor:
      - name: "Hotwater SoC chargetime"
        unique_id: hotwater_soc_chargetime
        icon: "mdi:lightning-bolt-outline"
        unit_of_measurement: "h"
        device_class: duration
        state_class: measurement
        state: >
          {% set p = states('input_number.hotwater_soc_elementsize') | float %}
          {% set kwh = states('sensor.hotwater_soc_energy_chargable') | float %}
          {{ (kwh / p) | round(2) }}

Keep in mind that on the states page you will see the hours as the state. But wherever you put it in the UI, you’ll see the H:M:S.MS

1 Like

Not really a consensus, since it’s not about opinion. :wink:

You can always (AFAIK) add these to customize.yaml. Some sensors and other entity types support this in the definition, but not all. The documentation is accurate in that regard. Just check the specific integration’s docs. If the option isn’t there, it isn’t supported. In this case, for the new-style template sensors, both device_class and state_class can be set, as you’ve noted.

Can you elaborate?

EDIT: I think Petro spotted the missing piece.

Just noting that on cards with charts the raw state gets used on the y-axis – it won’t be formatted.

1 Like

THAT was the obvious part I missed, :slight_smile:
Thanks :wink:

device classes help the frontend know how to display the icon and the format of the state text. The backend state will always be a raw value that’s untranslated.

1 Like

so just trying to get it in with the smallest of spoons;)

device clases and unit of measurement are linked to front-end and how to display ?
state class is linked to “back-end” and decides calculation of statistics (with a little help from last_reset?
(Sensor Entity | Home Assistant Developer Docs)

Would love some guidance (for a noob), but not sure if there is any documentation other than Data | Home Assistant Data Science Portal? (which for me is waaaaay over my competancy-level (so reverting to case by case nagging in communities and forums :wink: )

device_class, UOM, and state_class are used by the frontend and the backend to do various things.

I would say, don’t worry about the details too much until you hit a special case. Just describe your data and sensors as accurately as possible, and set your locale: things will be displayed just fine most of the time. You can since a few months ago also change the unit prefix and precision from the UI — for some.

1 Like

I’ve just stumbled across this thread as I’m dealing with the same issue (I think). I’ve got two ‘duration’ sensors from an ESPHome device. In the “Device Info” tab in HA those sensors are displayed as hh:mm:ss, but if I add the same sensors on a dashboard using an Entity card the raw sensor values are displayed. Entering ‘h’ in the ‘Unit’ field in the entity card doesn’t change the number displayed, it just adds ‘h’ after it.

Screenshot 2023-07-19 at 15-04-54 Settings – Home Assistant
Screenshot 2023-07-19 at 15-04-39 Test – Home Assistant

Show the sensors with their data/config as one would see it under the states tab of the dev tools.