Repository navigation
Cap tesla-protocol below 6 - #207
Conversation
tesla-protocol 6.0.0 renames and retypes symbols the library uses, so a fresh install resolves to it and local Powerwall calls and listen_ui_desire raise at runtime. uv.lock holds 5.0.0, so CI does not see this.
|
No actionable comments were generated in the recent review.
 |
| Layer / File(s) | Summary |
|---|---|
Version requirement and bump guidance .claude/skills/tesla-protocol-bump/SKILL.md, pyproject.toml |
pyproject.toml now requires tesla-protocol>=5.0.0,<6. The bump instructions say to raise the cap after porting to the target major version. |
Estimated code review effort: 2 (Simple) | ~5 minutes
Change: Bug fix
Possibly related PRs
- Teslemetry/python-tesla-fleet-api#204: Updates the
tesla-protocolversion floor and resolution that the new upper bound extends. - Teslemetry/python-tesla-fleet-api#205: Adds code and compatibility tests that use
tesla-protocol5.x symbols.
Merge Risk: 
2ed4f
-
The change prevents installation with the incompatible major version and documents the required porting step before the cap is raised.
Pre-merge checks: 
-
Check name Status Explanation Description check The description clearly explains the tesla-protocol 6.0.0 incompatibilities, the added upper-version cap, the skill update, and the verification performed. Title check The title clearly and concisely identifies the main change: capping tesla-protocol below version 6. Docstring Coverage No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentat… Linked Issues check Check skipped because no linked issues were found for this pull request. Out of Scope Changes check Check skipped because no linked issues were found for this pull request. Full details: Docstring Coverage
-
Explanation
No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 0 functions across 0 files. (2 skipped: 2 unsupported.)
-
Finishing Touches
-
Generate unit tests (beta)
-
- Commit to this branch
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Problem
pyproject.tomldeclarestesla-protocol>=5.0.0with no upper limit.uv.lockholds 5.0.0, so CI passes, but a fresh install resolves to 6.0.0 and these calls raise at runtime.Fix
Add the
<6cap.uv.lockchanges only in the recorded specifier and still resolves to 5.0.0. Thetesla-protocol-bumpskill now says to raise the cap only after a port.Reproduction on tesla-protocol 6.0.0 (at 6cb3d99)
_local_envelopeusestransport_pb2.LOCAL_PARTICIPANT_INSTALLERlocal_auth_api_pb2AttributeErroringet_status,get_firmware_details,get_device_controller,get_componentsget_backup_eventsreadsevt.sheduling_infoscheduling_infoAttributeErrorwhen an event exists_controllable_programreadsgetattr(schedule, field).secondsTimestamptoControllableDeviceProgram_Schedule_BoundaryAttributeErroron any scheduled programlisten_ui_desirereadsstatus.uiDesire(not in the original report)UIDesireAttributeErrorin the listener on the BLE broadcast pathtests/powerwall/test_tesla_protocol_compat.pycatches the first two on 6.0.0 and misses the.secondschange, because the field name still exists.tests/powerwall/test_client.pycatches that one.tests/test_ble_broadcast_listeners.pycatchesuiDesire. None of these tests can fail in CI today, because CI installs the locked 5.0.0.Why a cap instead of a port
The cap is one specifier. A port that keeps 5.x working is not as small:
Boundarymessage needs a new parsing decision and proof against a real gateway. A rename cannot cover it.Replacegoes from 1 to 0. The library passesorderas a bare int, so the wire value stays the same but its meaning changes, with no exception.The move to 6.x belongs in a
tesla-protocol-bumpchange that raises the floor and drops 5.x.Downstream resolver check
teslemetry-stream1.3.0 requires onlyaiohttp.devdoes not pintesla-protocol. Itsprotobuf==7.36.0pin resolves withtesla-protocol>=5.0.0,<6andteslemetry-stream==1.3.0.aiopowerwall==0.10.0conflict: that package requirestesla-protocol<5, so it is already unsatisfiable with this library's>=5.0.0floor, without this cap.Verification
Requires-Dist: tesla-protocol<6,>=5.0.0, resolved to 5.0.0.uv pip installof that wheel withtesla-protocol==6.0.0fails to resolve.pytest tests/powerwall tests/test_ble_broadcast_listeners.py tests/test_proto_compatibility.pyin that venv: 265 passed. The same powerwall and broadcast files on 6.0.0: 9 failures.No version bump in this PR. The cap reaches users only in the next release: released 1.20.0 declares
tesla-protocol>=3.0.0, so a fresh install of it still resolves to 6.0.0.