Unit Fixes: timestamps, charge time, connector status. - #181
Open
kurtisnelson wants to merge 3 commits into
Open
Unit Fixes: timestamps, charge time, connector status.#181kurtisnelson wants to merge 3 commits into
kurtisnelson wants to merge 3 commits into
Conversation
bhaggs
added a commit
to bhaggs/ha-toyota-na
that referenced
this pull request
Aug 11, 2026
Connector Status showed a bare integer. widewing#181 establishes the mapping - 2 Disconnected, 4 Unlocked, 5 Locked - and readings from a 2026 Solterra corroborate it: 5 while charging, 2 with the cable removed. The 4 case is what the connector reports plugged in but unpowered, which fits the observed plugStatus distinguishing that state from unplugged. The mapping lives in a new ev_codes module with no Home Assistant imports, so the vehicle parsers can use it without pulling in the entity layer, and so the remaining undecoded codes (plugStatus, chargeType) have somewhere to go. Unknown codes pass through unchanged rather than becoming "unknown". A new value then shows up in the UI as itself, which is what makes the next one discoverable - the same way these three were found. Rewritten from the upstream version, which inlines the int coercion as a nested conditional inside the .get() call. Same behaviour, including tolerating the string digits the API sometimes returns. Connector Status also loses its state_class, since it now reports a string and statistics over a latch state mean nothing. The charging binary sensor still derives from the raw code, now via a named constant rather than a bare 5. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
bhaggs
added a commit
to bhaggs/ha-toyota-na
that referenced
this pull request
Aug 11, 2026
Remaining Charge Time reads 65535 on an unplugged vehicle. That is 0xFFFF, the usual unsigned-16-bit "not applicable" sentinel, not a reading. Displayed literally it is either 45 days or 18 hours depending on the unit, and either way it lands in long-term statistics and skews them. It now reports unknown instead, which is what an inapplicable reading should look like. The unit stays unset. widewing#181 asserts minutes; a local reading of 1070 at 85% state of charge is hard to square with that (17.8 hours) where 1070 seconds is about 18 minutes. The sentinel is weak evidence for minutes - 65535 makes a better "infinity" when real values top out far below it, whereas 65535 seconds is only 18 hours and plausibly real - but that is an argument, not a measurement. Comparing two history points while charging settles it. The helper is deliberately general, since other 16-bit fields may use the same sentinel; only remainingChargeTime is known to. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
bhaggs
added a commit
to bhaggs/ha-toyota-na
that referenced
this pull request
Aug 17, 2026
Confirmed by measurement rather than inference. Across a 15 hour Level 1 session the counter fell 975 units in 900 minutes of wall clock - about one per minute, which is what a minute countdown looks like. Seconds would have meant 1640 units was 27 minutes of remaining charge while 15 hours actually elapsed. The battery side corroborates independently: 14 percentage points in 12 hours is roughly 0.85 kW into the pack, which is what a 110V outlet delivers after charging and thermal losses. This settles the doubt recorded earlier. An isolated reading of 1070 at 85% state of charge looked implausible as minutes, on the assumption that no Solterra would report a 17 hour estimate. On Level 1 from 77% that estimate is simply correct, and 1070 sits on the observed curve between ~1215 at 84% and ~915 at 88%. widewing#181 had it right. The sensor now carries UnitOfTime.MINUTES and device_class DURATION, so it renders as a duration rather than a bare number. The 65535 sentinel still reports unknown. Icons: Charging moves to mdi:car-electric and Charging time remaining to mdi:battery-clock. README drops the note about the unit being unconfirmed, and refers to the charging sensors by their current names. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
1 participant
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.
Fix #178