Respect gas entity display precision in energy dashboard

[martin-g-it]

Breaking change

No.

Proposed change

Respect the configured display precision of the gas consumption entity across the Energy dashboard.

Previously, several gas-related views used the generic number formatter, which could ignore the display precision configured on the selected gas entity.

For example, when the configured gas entity has a display precision of 3 and the calculated usage is:

• 0.009 m³ — the Energy dashboard could display 0.01 m³ instead of 0.009 m³
• 0.015 m³ — the Energy dashboard could display 0.02 m³ instead of 0.015 m³

This change applies the configured gas entity's display precision to:

• Energy distribution gas usage
• Individual gas source rows
• Gas total rows
• Gas graph total chip
• Gas graph total tooltip
• Gas graph y-axis

The number of decimal places is not hardcoded. The Energy dashboard reads the display_precision from the entity configured as the gas consumption source and uses that precision when the source unit matches the displayed gas unit. When the value is converted or automatically scaled to a different unit, the existing formatter determines the appropriate precision.

Screenshots

Before:

0.015 m³ was rounded to 0.02 m³ despite the configured gas entity having a display precision of 3.

After:

The Energy dashboard respects the configured display precision and displays 0.015 m³.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New feature (thank you!)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue or discussion: "Gas consumption" graph on Energy Dashboard (often) shows way too many digits of precision #53180
• Link to documentation pull request:
• Link to developer documentation pull request:
• Link to backend pull request:

Checklist

• I understand the code I am submitting and can explain how it works.
• The code change is tested and works locally.
• There is no commented out code in this PR.
• I have followed the perfect PR recommendations
• Any generated code has been carefully reviewed for correctness and compliance with project standards.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[home-assistant]

Hi @martin-g-it

It seems you haven't yet signed a CLA. Please do so here.

Once you do that we will be able to review and accept this pull request.

Thanks!

[home-assistant]

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍

Learn more about our pull request process.

Stale

[karwosts]

I forget if the unit of display is always the same display unit as the entity registry for item 0 in the gas, the precision kind of has to match the unit that you're using. Also I'm not sure if item 0 should be special cased.

[martin-g-it]

I forget if the unit of display is always the same display unit as the entity registry for item 0 in the gas, the precision kind of has to match the unit that you're using. Also I'm not sure if item 0 should be special cased.

@karwosts Thanks, good catch. I’ve removed the source-0 special case and now use the highest configured display precision across all gas sources for aggregate values. Individual source rows still use their own entity precision.

Fully accounting for unit conversions performed by Core would add quite a bit of complexity, and would only really matter when multiple gas sources use different display units. This approach keeps the logic simple while handling the common case correctly..

[Copilot]

Pull request overview

Updates gas consumption formatting to respect entity display precision.

Changes:

• Applies entity precision to gas source and total rows.
• Formats distribution and graph totals using gas precision.
• Uses the highest precision for aggregated sources.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
hui-energy-sources-table-card.ts	Formats gas rows and totals.
hui-energy-gas-graph-card.ts	Formats graph total chip and tooltip.
hui-energy-distribution-card.ts	Formats distribution gas usage.

Suppressed comments (1)

src/panels/lovelace/cards/energy/hui-energy-gas-graph-card.ts:224

• This precision is refreshed only when the energy collection emits. An entity-registry display_precision update changes hass.entities, but this card's shouldUpdate() filters out entity-only hass changes and _getStatistics() is not rerun, leaving both the chip and tooltip at the old precision until a later statistics refresh. Please include the configured gas entities' registry entries in invalidation and derive/refresh the precision when they change.

    const gasDisplayPrecisions = gasSources
      ?.map(
        (source) =>
          this.hass.entities[source.stat_energy_from]?.display_precision
      )
      .filter((precision): precision is number => precision !== undefined);

    this._displayPrecision = gasDisplayPrecisions?.length
      ? Math.max(...gasDisplayPrecisions)
      : undefined;

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[MindFreeze]

We should only take the precision of entities that match the final gasUnit. If the entity is converted, it's configured display_precision is irrelevant.

[martin-g-it]

@MindFreeze Before I rework the implementation, I wanted to check whether a slightly different approach would make more sense.

The main difficulty with using the entity's display_precision is that the Energy Dashboard may display the statistic in a different unit. For example, a source can be recorded/displayed in GJ while the Energy Dashboard shows the converted value in kWh. In that case, the configured precision for GJ does not really tell us what precision the user wants for the resulting kWh value.

Would it make sense instead to make display precision an optional setting in the Energy Dashboard configuration itself?

Something like:

• Automatic — preserve the current behaviour
• 0, 1, 2, ... decimal places — explicitly override the precision used for the final displayed value

That would make the precision apply to the value after any unit conversion, so it is unambiguous and does not require deriving a target-unit precision from the source entity's configuration.

It would also avoid questions around which source's precision should win when multiple gas sources are aggregated.

Would you consider that a better direction for this?

[MindFreeze]

I don't see the need for an option for this tbh. We should derive the precision from the value like the distribution card already does. Just use values that make sense and fit on the card.
For example, if you used 15000 KWh, you don't need to see 15 000.17234. If you have <10 KWh however, we can show 2 digits like 1.12

[martin-g-it]

I don't see the need for an option for this tbh. We should derive the precision from the value like the distribution card already does. Just use values that make sense and fit on the card. For example, if you used 15000 KWh, you don't need to see 15 000.17234. If you have <10 KWh however, we can show 2 digits like 1.12

and thats the exact issue; with usages like 0,016 the value is shown as 0,02..

As-is:

To-be:

[karwosts]

and thats the exact issue; with usages like 0,016 the value is shown as 0,02..

The difference here is something like a tenth of a penny of gas. Why do you feel like you need that level of precision.

[martin-g-it]

Why do you feel like you need that level of precision.

The current unit price is €40.97/GJ, so the rounding can have a meaningful impact. For example, rounding 0.005 GJ to 0.01 GJ represents a cost difference of approximately €0.20.

[MindFreeze]

Not a gas user myself but looking at the code, we just use the unit of the source entity unless they are mixed. Mixing multiple gas sources with different units seems like an edge case. So using the precision of the source entities that match the final unit should cover almost all cases.

[maartenla]

I agree. We can use the precision of the source if it's a unit we dont auto scale, so the final unit is the same as the source unit.
It needs to make sense to the user why the precision is different. If we scale, we decide the precision. Otherwise we use the source precision.

Maybe also abstract it a bit higher so it also works for the water meter.

[martin-g-it]

Addressed the review feedback and made the remaining changes accordingly.

Gas display precision is only applied when the source unit matches the displayed gas unit.
Converted or automatically scaled values continue to use the existing formatter precision.
The energy distribution card, sources table, and gas graph now update when relevant gas entity precision or unit settings change.
The gas graph y-axis now also respects the configured display precision.