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.
I like the proposal. Can you move it to the WTH category, so people can vote on this, please?
definitely a must 
what about going further and allow sprintf-like formatting?
3 Likes
uuuhh, that would be cool
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 
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.
2 Likes
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)
4 Likes
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.