Empower Core Statistics Cards for non-energy domains (MB/GB, Liters, Air Quality) with YAML-only 'precision' option #3794
Unanswered
stooky01
asked this question in
Core functionality
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Describe your core improvement
Hi Devs,
First of all, a quick note on my philosophy regarding Home Assistant: I strongly prefer keeping my system as lean, clean, and performant as possible. For this reason, I am a huge supporter of native Core features and try to implement everything using built-in Core capabilities instead of relying on heavy third-party cards.
I would like to enhance the Core "statistic" and "statistics-graph" cards by adding a "hidden", YAML-only advanced configuration option: precision (or decimal_digits). This would allow users to override the hardcoded rounding rule via YAML code.
Example:
type: statistic
entity: sensor.network_data_total
period:
calendar:
period: day
precision: 3 # Optional YAML-only override, defaults to 2 if not present
Current limitations
The Core statistic and statistics-graph cards are incredibly powerful tools, especially with their native integration into the dashboard's period/date selector. However, they currently have a hardcoded limitation: they forcefully round values to 2 decimal places when displaying calculated periods.
While 2 decimal places are perfectly fine for daily kWh energy tracking, this strict limitation handicaps these cards for many other measurement domains supported by Home Assistant's long-term statistics (LTS). When using these cards for sensors with a state_class (like total_increasing or measurement) in non-energy domains, 2 decimal places lack the necessary technical precision:
Data Tracking (MB / GB / TB): Missing the third decimal place can mean losing track of up to 1000 Megabytes of precision on larger scales.
Flow/Volume (Liters / m³): Precise tracking of water or gas consumption often requires 3 decimal places (e.g., liters vs. milliliters).
Environmental Data (Particulate Matter / µg/m³ / Chemical levels): These metrics fundamentally rely on higher precision.
Technical benefits
Zero UI Bloat: The standard visual UI editor remains absolutely untouched. Focusing on a clean, uncluttered UI is a fantastic strategic decision by the core team to protect the broad user base from being overwhelmed by too many niche configuration toggles. Keeping the UI simple makes Home Assistant highly accessible for the masses.
Minimal Dev Effort: The underlying cards already fetch the correct raw data from the LTS database. Implementing this is likely just a minor modification to pass a custom precision variable to the existing string-formatting function.
Massive Value for Core-Purists: Many power-users prefer working with native Core features rather than installing heavy custom cards (like ApexCharts) just to change a decimal point. Introducing a YAML-only parameter allows power-users to unlock advanced functionality without compromising the clean user experience for basic users. We don't care about custom fonts or complex styling—we just need technical accuracy for diverse units while keeping our systems lightweight and performant.
Additional context
Many advanced users are currently forced to abandon the native core statistic cards entirely and install resource-heavy custom frontend cards via HACS, solely because they cannot adjust the decimal display for non-kWh measurements. Providing a minimal YAML-only parameter satisfies the technical needs of power-users perfectly while keeping the visual editor 100% clean and accessible for the general audience.
Thank you for considering this enhancement to make the native statistics cards even more versatile!
Note: I have checked the existing issues and discussions regarding card rounding. While the general rounding behavior has been discussed in the past, this specific proposal for a non-breaking, YAML-only 'precision' override to preserve the UI simplicity seems new and unique to me and has not been proposed yet.
Beta Was this translation helpful? Give feedback.
All reactions