Repository navigation
Find circuits by any id when topology is unavailable, and show unknown readings as unknown - #22
Merged
Merged
Conversation
…y is unavailable The entity-registry fallback, used when the integration cannot report the panel's layout, took a circuit only from a unique id with a long hex segment, so circuits with other ids were missed. It now takes one circuit from each circuit power sensor.
An unknown or unavailable power, current or battery state read as 0, so the card drew 0 W, 0 A and 0 % for a measurement nobody took and added it to sums as 0. One helper now reads a state as a number or null. A null reading shows as "--", is not production, draws no utilization, and sorts after every measured circuit in the list. The header's sum of the circuits leaves out an unknown term and marks itself partial, and every header reading starts unknown rather than 0.
The current monitor can report 0 % before its first reading and keeps its last figure after the current sensor goes unavailable, so a circuit showed "--" A beside a utilization figure. A circuit whose current sensor has no reading now draws no utilization, whatever the monitor holds.
The fallback used when the integration cannot report the panel's layout took the circuit id as everything after the second `_` segment, which is wrong for a serial that contains `_`. It now strips `span_{serial}_` with the serial lower-cased, as the integration writes it, and the `_power` suffix, and falls back to the second segment only when the unique id does not start with the panel's serial. The changelog entry now says which discovery changed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two fixes.
When the integration cannot report the panel's layout, the card still finds every circuit from its power sensor. That fallback reads the
entity registry, and took a circuit only from a unique id with a long hex segment. It now takes one circuit from each circuit power sensor. The
circuit id is everything between
span_{serial}_(the serial lower-cased, as the integration writes it) and the_powersuffix,_included.A circuit whose power sensor is disabled is no longer found through its energy or current sensors, which before also made one of them its
"power" entity.
A reading the panel has not published shows as "--", never 0. An
unknownorunavailablestate read as 0, so the card drew 0 W, 0 Aand 0 % and added the term to sums. One helper,
readNumber, now reads a state as a number ornull:nullreading shows as "--", is not styled as production, and sorts after every measured circuit in the list;stat-partial);MonitoringPointInfo.utilization_pctis typednumber | null, as the integration sends it.A published
0stays a reading.The last commit rebuilds
dist/.Checks
npm test: 561 passed in 56 files (520 in 53 before)npm run typecheck,npm run lint,node scripts/validate-i18n.mjs: cleannpm run build: clean