Formatting numbers in Lovelace

It would be nice to be able to format the numbers that Lovelace displays in various ways. Primarily the formatting would use the comma to delineate powers-of-a-thousand and use the period or full-stop to indicate the decimal point or, as in some places, the reverse where the comma and period swap duties. I thought additionally it might be nice to be able to format the numbers in scientific notation. However, this seems less useful in the normal workings of the average HA install. I’m not a programmer, so don’t know the relative amount of work involved in implementing one or both of these ideas. I only know I find it difficult to read large numbers like SpaceX starman distance/speed or, regrettably, the ever-climbing COVID-19 numbers and concluded that having the powers of a thousand separated would make these numbers more easily understood at a glance.

Interesting side note: while researching this suggestion it appears that in some languages use more than just the comma and period to delineate numbers as this table on Wikipedia shows. Perhaps this is more of a localization issue? It might require additional global variables for the power-of-thousands and decimal separators in the general section of the configuration. Then the formatting would rely on those two variables being filled by the administrator or from the operating system of the HA install to format numbers as users expect to see them. It also means that you could use emoji as separators, that could be fun for the nonconformist user?

Don’t forget to vote for your own request :grinning:!

Thanks, @sota, this is my first feature request so I didn’t see the vote option. I’ve voted for it now.

And it looks like this formatting has been done in recent versions of HA, although perhaps not as comprehensively as I imagined it in my post.

Is there any card in which I can format numbers without creating a template for it?

Would be great to be able to set the amount of decimals in Lovelace! :grinning:

5 Likes

need this for cards and badges.

2 Likes

type: custom:button-card

Wow, yes, we need this!

I just stumbled on this request, searching for a way to round the numbers in my badges so the fonts don’t resize. In other words, show them all as integer, even if the underlying values may have one or more decimal places.

This is such a simple concept, I figured there would be an easy way. Maybe I’m missing something, but this FR is all that came up (except of course creating template values for each entity, then making sure to exclude them from Recorder, which doesn’t seem very elegant.)

Entity values are not always smooth and rounded, but can present themselves as 21.345783 etc. For being usable in for example a sensor card, gauge card or entity card you have to template them using yaml or with a helper, creating a new entity with the formatted value.

From a developers perspective this is the right thing to do: separating data from presentation. From a simple users perspective it’s annoying…

In the context of ‘streamlining experiences’ it would be a nice feature to be able to format entity values within cards, withouting formatting the entity itself or templating new ones. This should be available in all built-in-cards that can present values.

1 Like

Besides rounding numbers, another use case is unifying units when different entities offer different units: like one is seconds, one is hours, but I’d like both to be the same in a card.
Or an entity provides too much accuracy which is not needed, like seconds for something that very quickly turns into hours… What’s the point of seeing 54760 seconds? It doesn’t give the idea.

Templating sensors just to change display is the only way so far, but it feels like a sin… :slight_smile: Cards should accept everywhere either an entity, or a template.

1 Like

I don’t think anything has been done with this yet, but I would love to see simple formatting being possible in the presentation of a sensors values. For some sensors it make sense to use decimals, 1 or 2, but for other sensors it’s enough to use the whole number. So if there would be implemented a way of just limiting the presentation of the sensors decimals, that would go a long way.

  • entity: sensor.1
    name: Sensor 1
    decimals: 0

That would be the perfect way to resolve it if you ask me, but it may not be technically as viable.

2 Likes

I’d love to see this to! I have an integration that seems to sometimes give a temp with about 8 decimal places lol

There are also times where I have an automation that would benefit from one or two decimal places but on the Lovelace panel whole numbers would be fine.

2 Likes

I found a few frontend components in HACS that could do the formatting without having to create separate template sensors. They have varying tradeoffs between power/generality and ease of use. (search for repositories containing “template” in HACS). The template-entity-row customization pointed to in this thread is the closest fit but it would be nice to see something a bit simpler yet almost as flexible.

If you look at the formatting problem as one of “filtering” the value returned when reading an entity value before it’s displayed then there are a pile of “template filter” functions that can handle almost any kind of formatting or calculation. (E.g. the “round()” function, see Templating .) So what if a string comprised of template filter functions could be provided in the card description? A default that applies to any entity could be provided once for the entire card, with entity specific ones when the default needs to be overridden. The filters would behave as if any reference to the value of an ‘<entity>’ would be replaced with '{{ <entity> | <filter> }}'.

This would seem to keep simple things pretty simple but provide almost as much power as the solutions I found in HACS.

An example might be (taken from the yaml code editor of an entity card I use now):

type: entities
entities:
  - entity: sensor.ro_inlet_pressure
  - entity: sensor.ro_system_pressure
  - entity: sensor.tank_pressure
  - entity: sensor.tank_pressure_stddev
  - entity: sensor.ro_inlet_pressure_stddev
title: Water Pressure

becomes (the “filter_template” attribute is new):

type: entities
filter_template: 'round(2)'               # Default for all entities
entities:
  - entity: sensor.ro_inlet_pressure
  - entity: sensor.ro_system_pressure
  - entity: sensor.tank_pressure
  - entity: sensor.tank_pressure_stddev
    filter_template: 'round(4)'               # specific to sensor.tank_pressure_stddev 
  - entity: sensor.ro_inlet_pressure_stddev
    filter_template: 'round(4)'               # specific to sensor.ro_inlet_pressure_stddev 
title: Water Pressure

This seems pretty simple and the meaning is (I hope) obvious.

Using template-entity-row the yaml is more complicated and might look like this (I think, untested):


type: entities
entities:
  type: 'custom:template-entity-row'
        icon: 'mdi:gauge'
        name: sensor.ro_inlet_pressure
        state: {{ (states('sensor.ro_inlet_pressure') | round(2) }} 
  type: 'custom:template-entity-row'
        icon: 'mdi:gauge'
        name: sensor.ro_system_pressure
        state: {{ (states('sensor.ro_system_pressure') | round(2) }} 
  type: 'custom:template-entity-row'
        icon: 'mdi:gauge'
        name: sensor.tank_pressure
        state: {{ (states('sensor.tank_pressure') | round(2) }} 
  type: 'custom:template-entity-row'
        icon: 'mdi:calculator'
        name: sensor.tank_pressure_stddev
        state: {{ (states('sensor.tank_pressure_stddev') | round(4) }} 
  type: 'custom:template-entity-row'
        icon: 'mdi:calculator'
        name: sensor.ro_inlet_pressure_stddev
        state: {{ (states('sensor.ro_inlet_pressure_stddev') | round(4) }} 
title: Water Pressure

Although the meaning is still pretty obvious I had to do several things manually that the card normally does automatically (e.g. icon name, row name text and create the entire template to get and format the entity value. The learning curve is much steeper.

At some point I’d like to ramp up enough to be able to implement this rather than just drop an idea I think might work. But, one step at a time, I guess.

Nice work, it seems these cards/components just use YAML or jinja2 to filter or format the numbers in the frontend. If that’s possible, in my opinion the most thorough solution would be to use these kind of codes in the official frontend cards of HA (lovelace) as configurations that can be made from UI. Like a sensor card, with the option to specify the number of decimals to be displayed as a configuration option.