fix: decode PassengerSeatBelt as BuckleStatus enum, not a bool - #37
Conversation
make_bool's string handling only ever recognizes the literal "true", so wrapping the BuckleStatus-valued PassengerSeatBelt signal in make_bool silently turned every real state (Unlatched/Latched/ Faulted/SNA) into a permanent false. Decode it via BuckleStatus.get, matching the lookup-map pattern already used by listen_DetailedChargeState. This is a breaking change: the callback type changes from bool to str. Also corrected both seat belt docstrings against live telemetry: PassengerSeatBelt reports the 2nd row centre belt, not the front passenger; DriverSeatBelt is true only when the driver seat is occupied and its belt is undone (the safety-warning condition), not raw belt state. Removed the stale "# BuckleStatus?" comment, which sat on the driver listener (a plain bool) instead of the passenger one. Swept the rest of vehicle.py's make_bool call sites for other enum-valued fields wrapped this way; none of the other Signal names match a defined TeslemetryEnum, so this appears to be the only instance of the defect. Bumped to 0.12.0 (minor, matching this project's pre-1.0 convention for breaking changes - see the prefer_typed removal in 0.11.0) and regenerated uv.lock.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ead8897811
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| # Unused | ||
| BuckleStatus = TeslemetryEnum( | ||
| "BuckleStatus", ["Unknown", "Unlatched", "Latched", "Faulted"] | ||
| "BuckleStatus", ["Unknown", "Unlatched", "Latched", "Faulted", "SNA"] |
There was a problem hiding this comment.
When PassengerSeatBelt reports its fault state, the protobuf wire value is BuckleStatusFault, but this options list contains Faulted. The newly used BuckleStatus.get() therefore strips the prefix to Fault, fails the membership check, and invokes the callback with None, conflating a real buckle fault with an unrecognized or absent value; use Fault here.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Rejecting this suggestion: the wire value is BuckleStatusFaulted, not BuckleStatusFault. Verified against three independent authoritative sources: Tesla's upstream fleet-telemetry proto (protos/vehicle_data.proto:417), our tesla-protocol mirror (proto/telemetry/vehicle_data.proto:424), and api's schema (src/schema/fields.ts:2085) — all three define the enum member as BuckleStatusFaulted. Applying this change would break the fault case that currently works correctly. Keeping Faulted as-is.
1 participant
Intent
listen_PassengerSeatBeltwas typedCallable[[bool | None], None]and wrappedmake_bool, but the wire value is theBuckleStatusenum (Unknown/Unlatched/Latched/Faulted/SNA).make_bool's string handling is justdata == "true", which none of those values ever match, so every consumer received a permanently-false boolean with no way to recover the real state.BuckleStatus.get, following the existing lookup-map pattern already used bylisten_DetailedChargeState.bool | Nonetostr | None. Bumped to 0.11.1 (patch): the field never returned a usable value, so this is a bugfix to broken behavior rather than a change to a working contract, and we only just bumped to 0.11.0 nine days ago. Regenerateduv.lockto match.SNAoption toBuckleStatusinconst.py.PassengerSeatBeltreports the 2nd row centre belt, not the front passenger belt.DriverSeatBeltistrueonly when the driver seat is occupied and its belt is undone (the safety-warning condition), not raw belt state.# BuckleStatus?comment - it sat on the driver listener (a plain bool) instead of the passenger one it was actually asking about.vehicle.py'smake_boolcall sites for other enum-valued fields wrapped the same way; none of the otherSignalnames match a definedTeslemetryEnum, so this looks like the only instance of the defect.