WTH is it not possible to define amount of decimals displayed for sensor readings in Lovelace

In Lovelace it is currently not possible to define the amount of decimals displayed for sensors. If you want to define / limit the amount of decimals displayed you will need to use the code editor -> use a template.

1 Like

I like the proposal. Can you move it to the WTH category, so people can vote on this, please?

definitely a must :slight_smile:

what about going further and allow sprintf-like formatting?


uuuhh, that would be cool :slight_smile:

I use template to create a second sensor just as a dirty hack for that. Some calculations need much more decimal places than it is necessary to see. For instance electricity price calculations use fractions that user never needs to see.

1 Like

Won’t work in every case… for example synology integration returns consumed volume size in TB, with 2 decimals accuracy… I need to monitor small dedicated volume, with consumption that is single GB, so below threshold of displaying anything. Multiplying 0 even by 1000 would not change anything :frowning: If it would be pissble to show 6 decimals, then multpying by 1000 would give reasonable result.

Yeah, if the source data doesn’t have enough decimals then you can’t get it back. You can remove decimals but not add them back. It is more a specific integration (synology in this case) problem if its output accuracy is low.

1 Like

Would love to see this solved either in Lovelace or as an adjustment in the “edit entitiy properties”

Yes, please add a way to control the formatting of the output. Numbers like these make no sense at all in the UI

And don’t forget the thousands separator. Also important for numbers with many digits.

I often see the suggestion to use a template sensor for this. But I do not want to change the values themselves but only how they are shown on screen.


You aren’t changing the value. You’re creating a new sensor that has the display you want. You still track the original sensor but display the new one.

Thanks @petro, I do understand. This creates a second entity where the same data is stored in another format only for viewing purposes. It needs more resources (processing, storage) and breaks more-info popups as the entity does no longer provide the additional attributes or a way to show a graphic for the last hours.

So for me it boils down to “WTH: Why is formatting of data not done in the UI?”. There are a few open topics in this forum regarding the same issue. Some about rounding numbers other about thousands separators. I think this is all basically the same.

IMHO the value should always be stored as plain number in a base unit like Bytes. This makes sure it is always possible to compare to other numbers and allows to get graphs showing the data. Converting this to GB for example should be done when displaying it – independently of the data stored. We don’t gain anything by storing the same value additionally as a string.

Zabbix does it nicely IMHO. For base units like B it automatically converts to KB, MB, … depending on the number to display. It’s always easy to read. There are a few well-known codes for unit like uptime. uptime expects a number of seconds and converts it in a value like 3 days ago.

A few custom frontend components started to add things like number of decimals to display. Other components even try to change an uptime-value (in s) to a nice printout. I’ve also seen components adding a factor to change from base units like Byte to others like GB. I hope this becomes a core feature in the future.

The main reason is that the UI does not know what it’s presenting. The only thing the UI keys off of to present data is unit_of_measurement and device_class.

UI does know as much as template sensor, doesn’t it?

Formating numbers is FE job. creating another entities just to mimic FE functionality is workaround at best. Shouldn’t be considered as serious approach.
It’s surprising that such debates must have place nowadays.

There’s no debate, it should be done in the front end but it’s not. Simply explaining why it is the way it is.

but if we can create template entity, which takes string as input data, then format this string as a number, it could be done on FE the same way. Isn’t it?

Template sensor can return text. The only things that the front end keys off of is unit_of_measure and device_class. Remember, all states are strings under the hood.

I’m not saying it can’t be added. I’m sure it could. But it may not be an easy feat. And it’s gotta go through HA politics.

This 100% should be a thing, being able to specify decimal places should be easier than defining a template sensor for every value we want to “format”, for some things I don’t want to have to 15 decimal places!

I would say it’s not ‘defining’ template sensors what is wrong here. But having all sensors multiplied just to have their values formatted is overkill (architecture-, performance- or user-experience-wise, you name it)


any updates?

My config is full of sensors just to get the number formats right and especially the “#.##0” thousand separators. It is a nightmare here cause my wife goes crazy if she sees the dot as decimal separator simply due to the fact that internal cards support local settings and customs most likely not - even the same figures will be displayed differently depending on the card used.