Skip to content

Use official entity state formatting functions when available.#336

Closed
mill1000 wants to merge 3 commits into
benct:masterfrom
mill1000:issue/precision
Closed

Use official entity state formatting functions when available.#336
mill1000 wants to merge 3 commits into
benct:masterfrom
mill1000:issue/precision

Conversation

@mill1000

@mill1000 mill1000 commented Apr 4, 2024

Copy link
Copy Markdown
Contributor

HA 2023.9 introduced new functions to enable custom cards to format entity state and entity attributes values.

This PR uses these new functions (if supported) unless the user specified a custom format option.

More here: https://developers.home-assistant.io/docs/frontend/data#entity-state-formatting

Should close #333, close #308, close #286 and maybe #220

@studioIngrid

Copy link
Copy Markdown

Please merge, I have been using this fork.

@melyux

melyux commented Mar 6, 2025

Copy link
Copy Markdown

Paging @benct

@mikosoft83

Copy link
Copy Markdown

Seems like @benct abandoned this project or doesn't have time to update it.
I am also a victim of the latest HA update breaking formatting and I don't really want to go through my dashboard putting precision everywhere.

@mill1000

Copy link
Copy Markdown
Contributor Author

My fork has this fix and I just add it as a custom repository in HACs.

@mikosoft83

Copy link
Copy Markdown

My fork has this fix and I just add it as a custom repository in HACs.

Thanks, worked great!

@jpettitt

jpettitt commented Jul 2, 2026

Copy link
Copy Markdown
Collaborator

Thanks for this — the approach (delegating to HA's official hass.formatEntityState/formatEntityAttributeValue functions) was exactly right, and it's now merged as #382. That also fixes #304's precision-loss bugs and adds the same async-stub-swap re-render fix #373/#379 introduced for formatEntityName, extended to cover the two functions this PR depends on — otherwise cards would have shown raw unformatted values whenever that swap happened after initial render. Appreciate the contribution, this closed out a long-standing cluster of decimal/precision issues (#333, #308, #286, #220, and a few more found along the way: #375, #363, #357, #320).

@jpettitt jpettitt closed this Jul 2, 2026
@mill1000 mill1000 deleted the issue/precision branch July 2, 2026 20:14
tomatenkopp pushed a commit to tomatenkopp/lovelace-multiple-entity-row that referenced this pull request Jul 5, 2026
HA 2023.9+ exposes hass.formatEntityState/formatEntityAttributeValue,
which apply the user's own locale/number-format/precision preferences
the same way HA's own UI does. Delegate to them when present instead
of this project's own formatNumber/computeStateDisplay
reimplementation, falling back to the existing logic otherwise. A
custom `format:` config still takes precedence over both.

Based on the approach in benct#336 (originally by @mill1000), which should
close benct#333, benct#308, benct#286, and benct#220 - a cluster of long-standing
decimal/precision formatting complaints.

That PR alone would have introduced a regression, though: HA installs
stub formatEntityState/formatEntityAttributeValue functions on initial
connection that return completely raw, unformatted values (confirmed
by extracting the actual implementations from a running instance's
frontend bundle - the stub is literally `(e,t) => (t ?? e.state) ?? ""`),
and swaps in the real implementations asynchronously. This is the same
race benct#373/benct#379 fixed for formatEntityName, but benct#336 didn't extend that
re-render check to the new functions it depends on - so cards would
have been stuck showing raw values whenever the swap happened after
initial render, same bug class as benct#370/benct#371 but for values instead of
names.

Generalized hasConfigOrEntitiesChanged's formatEntityName check into a
list covering all three formatter keys, and added tests simulating the
swap for each. Also added tests covering the new delegation paths in
entityStateDisplay, which the original PR's diff had zero coverage for.

Fixes benct#333, benct#308, benct#286, benct#220

Co-Authored-By: Tucker Kern <mill1000@users.noreply.github.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

The sensor is displayed with a decimal part that should not be there Dezimal precision not shown Sensor precision not respected

5 participants