fix: add missing DetailedChargeState value; recommend against tesla-protocol dependency - #43
Merged
Merged
Conversation
Investigated deriving const.py's TeslemetryEnum value tables from the tesla-protocol package's proto enum descriptors. Nearly every table matches its proto enum byte-for-byte, but adopting tesla-protocol as a runtime dependency would pull in protobuf + googleapis-common-protos - disproportionate for sourcing ~40 static string lists, and risky for Home Assistant consumers sensitive to protobuf version pinning. Not adopted; see AGENTS.md for the recorded rationale. DetailedChargeState was missing the Calibrating value present in the proto, so that's fixed by hand, with a pinning test for the tables most likely to drift. Claude-Session: https://claude.ai/code/session_01AvS7kW3yp5jgSiMNuyj9cQ
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.
Intent
const.py's hardcodedTeslemetryEnumvalue tables (ShiftState,BMSState,DetailedChargeState, etc.) fromtesla-protocol's proto enum descriptors, where fidelity allows.tesla-protocolas a dependency. This repo currently depends on nothing butaiohttp.tesla-protocolrequiresprotobuf<8,>=6.32.0andgoogleapis-common-protos- adding it would add ~4.8MB of runtime footprint (a C-extension-backed serialization library) purely to source ~40 static string lists that barely change. Home Assistant integrations (this library's main consumer) are notoriously sensitive toprotobufversion pinning conflicts across dependencies, which makes the risk asymmetric to the benefit here.tesla-protocol==1.4.0in a scratch venv and diffed everyTeslemetryEnumtable inconst.pyagainsttesla_protocol.telemetry.vehicle_data_pb2's enum descriptors, stripping each table's prefix. 39 of 40 tables match byte-for-byte (includingShiftState, where the prefix-stripping is total:ShiftStateP->P).ChargeStatedoesn't match the proto at all - already flagged in a code comment as a deprecated, non-real enum.DetailedChargeStatewas missingCalibrating, present in the proto'sDetailedChargeStateValue. Fixed by hand.tests/test_enum_tables.pypinning the tables most likely to drift, and recorded the rationale inAGENTS.mdso this isn't re-litigated from scratch next time.Full narrative / original brief
Derive teslemetry-stream's hardcoded enum value tables from tesla-protocol where fidelity allows, per the captain's 2026-09-02 ask. The premise is that this repo does not currently depend on tesla-protocol - this would be a new dependency (plus transitive protobuf runtime) - so if the dependency cost looks disproportionate to what it replaces, the ask was to say so and stop with a recommendation instead of shipping.
🤖 Generated with Claude Code
https://claude.ai/code/session_01AvS7kW3yp5jgSiMNuyj9cQ