esphome
Implemente `HA suggested_display_precision` to correctly display the default decimal number starting from `HA 2025.6.0`
The problem
Since HA 2025.6.0, the display of the decimal number of sensors defined with a device_class no longer respects the number defined in accuracy_decimals. It has become mandatory to define the display precision of each sensor directly in HA, which is completely stupid.
This is a problem with the display of values in HA and automations linked to these values but has no impact on the values recorded in the statistics.
To fix this problem, it is necessary to communicate to HA the suggested_display_precision, which I believe should correspond to accuracy_decimals.
See this article : Sensor device classes now have default display precision
See this HA issue for more information
Which version of ESPHome has the issue?
2025.5.2
What type of installation are you using?
Home Assistant Add-on
Which version of Home Assistant has the issue?
2025.6.0
What platform are you using?
ESP32-IDF
Board
unrelated to a board
Component causing the issue
No response
YAML Config
Anything in the logs that might be useful for us?
Additional information
No response
Same problems here. Installation method Home Assistant OS Core 2025.6.1 Supervisor 2025.05.5 Operating System 15.2, Frontend 20250531.3
All cell Voltage display 3V,not dispaly decimal number...but from EspHome builder Log can see the value correctly: [D][sensor:093]: 'jk-bms cell voltage 1': Sending state 3.26700 V with 3 decimals of accuracy !!!! From log have also many of this massages,that before not have: [D][esp32_ble_client:191]: [0] [MAC ADDRESS] ESP_GATTC_NOTIFY_EVT
And if i try to reistall from Backup version 2025.5.3 i have error message: 'BackupManager.do_restore_partial' blocked from execution, no supervisor internet connection. Ps:I clean already browser cache.
Please fix issue.
Running Ha on Homeassistand Blue.
Not a big deal, after all how many people use HA to look at voltages and have automations around voltage settings anyway so it'll clearly bother only a small number of people.<\sarcasm> Seems like a YIKES moment to me but then again, I just started using HA and found this very troubling.
What troubles me is that the component already defines accuracy_decimals right at the origin of the sensor data https://github.com/syssi/esphome-jk-bms/blob/main/components/jk_bms/sensor.py
Why can't HA just do things the straightforward way and display things as they're intended😕
Exactly! If the suggested_display_precision is NOT set AND accuracy_decimals is set, set suggested_display_precision to accuracy_decimals ELSE set to system default = 0
So much better than having had a system default of 3 decimals and then switch to 0 without any regard to accuracy_decimals settings by the integrator.
WARNIING...................WARNING...................WARNING.....................WARNING....................WARNING. With this Ha update all values not have decimals.In my case from Inverter and from Bms. let's stop and think for a moment....how many users use for example Mppsolar and Jk Bms ,or other to monitor and control the battery charge?...especially the lithium ones that burn easilyThis is very dangerous, and can lead to battery damage, or the battery can catch fire, because it is overcharged!!! It could even burn down the house.... Who will be liable for these damages? This problem need to be fixed quickly. Thank you.
Running Ha on Homeassistand Blue.
P.S.: before to push update that modify something so important and dangerous ,should think twice before !
@ans-gw
Please note this is only a problem with the display of values that you can correct for each sensor by setting the number of decimal places to display. The values stored in the database are correct.
Yes I know that. Can you please explain how to correct the problem with a clear example?
@ans-gw your "warning" is unnecessary. The values that would be used for automations haven't changed.
The only workaround right now is to change the decimals in the entity settings.
Yes I know that. Can you please explain how to correct the problem with a clear example?
Same here. ESPHome does not accept 'suggested_display_precision' in sensor.py. Home Assistant now needs that, as 'accuracy_decimals' is not used anymore to decide how many decimals to display with sensors.
But watch out, even after you set the display decimal point resolution in the UI if you have to bounce your esphome device sending your sensor data or something else causes loss of signal, you can get some or all of those display resolution values being reset to 0 decimal points and you have to manually change them again.
But watch out, even after you set the display decimal point resolution in the UI if you have to bounce your esphome device sending your sensor data or something else causes loss of signal, you can get some or all of those display resolution values being reset to 0 decimal points and you have to manually change them again.
Yes, that is very annoying. Each time after updating the device, all display precision settings are reset to default.
I believe this fix has now caused the opposite problem in 2025.7, at least for me. Using accuracy_decimals to clamp the precision of a device to a given number of decimals (which, to me, is precisely what that name implies) no longer works.
For instance consider an SHT45 temperature sensor. Previously, I used accuracy_decimals: 1 to set it to only display 24.1C or the like, to only store values to 1 decimal place, etc.. With this update HASS is now getting some value like 24.120495920394 which is just noise, and which will also increase the rate at which the sensor updates flooding the states tracker with update events. Further now I'd need to, in any templates or custom cards, manually clamp this myself with round(1) statements or the like, instead of the sensor component just respecting the accuracy_decimals.
At the very least I'm of the opinion that ESPHome should add its own internal clamping function for this usecase, to permit device creators to define what they consider the maximum accuracy of the sensor and not report arbitrary precision. That used to be accuracy_decimals, but it would seem that due to upstream changes, a new one is needed. My facetious suggestion would be real_accuracy_decimals.
@ssieb I'm seeing the massive decimal values in custom cards (that don't currently define a display precision; apparently this is a brand new thing I guess?) as well as in templates (I have a lot of template sensor). But I think this is honestly more of a principle thing - I don't want my sensors reporting 12 decimal places of precision, which is why I used accuracy_decimals previously. Basically, if I seem vocal about it, it's just because I don't see the point in the way this fix was done. It seems backwards to me, trying to fix an upstream issue with not enough decimals but then creating another - opposite - upstream issue with too many decimals. Maybe I'm just thinking about it wrong but upgrading and then finding all my things looking like there's suddenly a massive math error was offputting, only to then find that it was apparently intentional.
Here's some screenshots of what I mean.
Me defining accuracy_decimals: 1 because, this is a temperature, why would I need more than 1 decimal place?
But in HASS templates, I have a ridiculous number of decimals...
And when I use that in particular in a MagicMirror template...
So I now have to go in anywhere this is displayed and manually clamp it with |round(1).
Now, that was a device I control, but let's take another one for which I have a bunch of custom cards: an Athom smart plug reporting the voltage/current/power now with way too many decimals to be reasonable; I can't possibly believe the chips in these things are accurate to this many decimal places, which makes this false precision.
Now, I know the obvious solution - and yes, I plan to do this - is to just fix my custom cards to respect this new display option, and to manually clamp the value in MagicMirror tmplates. But why require people to suddenly have to modify things that were working just fine to avoid this when, well, to me, that is precisely why accuracy_decimals existed in the first place and why I explicitly set it in ESPHome? Configuring that on the ESPHome side shows intentionality from the developer of the device; it's not a display suggestion, unless myself and possibly others have been using it completely wrong this whole time about what "accuracy" meant. And HASS already had display precision settings on top of that.
That seems to be a regression. The esphome integration used to use accuracy_decimals to clamp the value before passing it to HA. I don't know why that changed.
Yep that seems to be what changed in home-assistant/core#147849 - previously the integration would actually clamp the value based on accuracy_decimals, but now it doesn't - returns the full value reported by the originating sensor while treating accuracy_decimals as equivalent to suggested_display_precision. I'm no expert on the HASS/ESPHome codebase but that is my thinking exactly :-)
~~In the meantime, one approach can be to send accuracy_decimals and suggested_display_precision both. Once, migration to suggested_display_precision is complete, we can wean off 'accuracy_decimals'.~~
I like the information preserving approach of always sending the complete value of the float and leaving the handling at the display/presentation side of things.
This has made a lot of work to change each and every sensor, templates, etc. HA really should make it possible to change all at once, i.e. humidity sensors have two decimal places, I would really like to have the option to change all humidity entities at once to say one decimal place.
If it is there I haven't found it and if it isn't shame on them for not having thought of this and providing it. BTW this is not to criticize the developers themselves but their decision to implement a change such as this without considering the user impact, and this one is big.
{{ states("sensor.entity_id") }} returns the raw state.
If you want a state that follows the precision, you should be using {{ states("sensor.entity_id", rounded=True) }}
So what must one do to actually force a sensor value to have a defined amount of decimals ? I am trying
filters:
- lambda: return round(x *10)/10; #rounded via lambda
- round: 1 #rounded via filter
yet, my values still look like this
Please advise
Background: This sensor above is a simple pulse meter, outputting a maximum of about 100 pulses per second, the value shown above has nothing to do with "precision" but is plain noise. It's not about what is shown in the interface, it's about bloating the database with 10x more data than what is needed, putting more load on the state machine for "rounding off" useless decimals, breaking some older cards and templates as well as simple automations (e.g. "if value == 2.1").
And this sensor is just a simple example. Im afraid of updating all my power sensors which are generating MUCH more data than this simple water meter and their precision was more than accurate for my needs so far.
there must be a way to control precision at the device level....
You can't fix it in esphome, it's an issue in HA.
Hm... i don't completely agree with that. It's true that you can't fix it in esphome, however, it's not a HA issue, but rather esphome one, because even if i specifically tell esphome device to use only 1 or 2 decimal it still reports raw value with 12 decimals to HA...
It is not an issue with esphome. Esphome must provide the entire value. HA should have the ability to change all sensors of a type, I.e. temperature, to the same precision if desired. This is easy in software and it should be added as an option.Sent from my iPhoneOn Aug 8, 2025, at 10:04 AM, Pavel Veider @.***> wrote:Protoncek left a comment (esphome/issues#7120)
You can't fix it in esphome, it's an issue in HA.
Hm... i don't completely agree with that. It's true that you can't fix it in esphome, however, it's not a HA issue, but rather esphome one, because even if i specifically tell esphome device to use only 1 or 2 decimal it still reports raw value with 12 decimals to HA...
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
esphome sends the raw value along with the parameter to tell HA how to display it. If you only want to send the rounded value to HA, then you can use a filter. However, with this bug, that still won't help unless you are truncating it to an integer.
~In the meantime, one approach can be to send
accuracy_decimalsandsuggested_display_precisionboth. Once, migration tosuggested_display_precisionis complete, we can wean off 'accuracy_decimals'.~I like the information preserving approach of always sending the complete value of the float and leaving the handling at the display/presentation side of things.
The problem is this massively increases database size, HA now ends up storing each change.
