feat(vehicle): add remaining signed commands (UI/unit, nav/messaging/media, charging/utility, connectivity/diagnostics)#91
Conversation
![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: 792d8afe3c
ℹ️ 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".
| font_size: PhoneFontSize | int = PhoneFontSize.STANDARD, | ||
| *, | ||
| distance_unit: DistanceUnit | int | None = None, | ||
| temperature_unit: TemperatureUnit | int | None = None, |
There was a problem hiding this comment.
This signature allows callers to update only one phone preference, but the underlying proto fields are implicit proto3 enum fields whose omitted values read back as their zero defaults (STANDARD, MILES, FAHRENHEIT). For example, set_phone_setting_preferences(distance_unit=DistanceUnit.KILOMETERS) also leaves font_size at the default STANDARD and temperature_unit at the default FAHRENHEIT, so a vehicle currently using large phone text or Celsius can be silently reset while changing distance. Please require/pass the full current preference set instead of treating these fields as independently optional.
Useful? React with 👍 / 👎.
792d8af to
4df9447
Compare
…media, charging/utility, connectivity/diagnostics) Consolidates four previously-separate command-group PRs into one to avoid the same-file merge conflicts serial merging kept re-creating. Wraps 20 previously-unimplemented VehicleAction fields: - UI/unit preferences: set_temperature_unit, set_distance_unit, set_time_display_format, set_tire_pressure_unit, set_energy_display_format, set_phone_setting_preferences. - Navigation/messaging/media: upcoming_calendar_entries and take_drivenote (signed-command siblings of the existing REST-only VehicleFleet methods of the same name), video_request, navigation_route, get_messages. - Charging/utility: set_rate_tariff, get_rate_tariff, add_managed_charging_site, remove_managed_charging_site, get_managed_charging_sites, set_discharge_limit (a distinct feature from the existing set_powershare_discharge_limit). - Connectivity/diagnostics: bluetooth_classic_pairing_request, bandwidth_test, fetch_keys_info. set_rate_tariff takes tesla_protocol message types directly for its deeply-nested tariff schedule rather than a parallel flattened API. Both Fleet-signed and BLE transports get every command for free via the shared Commands ABC. Purely additive - no existing signatures touched.
4df9447 to
427d3ac
Compare
Bre77
changed the title
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 427d3ac6ce
ℹ️ 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".
| return await self._sendInfotainment( | ||
| Action( | ||
| vehicleAction=VehicleAction(getRateTariffRequest=GetRateTariffRequest()) |
There was a problem hiding this comment.
When the vehicle answers this new getter, the protobuf response is carried in Response.getRateTariffResponse, but _command() only unwraps ping, vehicleData, and actionStatus before falling through to {"result": True}. In practice get_rate_tariff() will report success while discarding the tariff data; the same applies to the other newly-added response-producing reads such as managed charging sites, messages, and keys info unless their Response oneof fields are explicitly returned.
Useful? React with 👍 / 👎.
1 participant
Intent
commands.py, so merging them serially just re-created the same conflict each time. Closing feat(vehicle): add navigation/messaging/media signed commands #92/feat(vehicle): add charging/utility signed commands #93/feat(vehicle): add connectivity/diagnostics signed commands #94 in favor of this one.Commands(tesla_fleet_api/tesla/vehicle/commands.py), following the existing wrapper pattern (_sendInfotainment), so both the Fleet-signed and BLE transports get them for free:set_temperature_unit,set_distance_unit,set_time_display_format,set_tire_pressure_unit,set_energy_display_format,set_phone_setting_preferences- with matchingIntEnums added toconst.py(TemperatureUnit,DistanceUnit,TimeDisplayFormat,TirePressureUnit,EnergyDisplayFormat,PhoneFontSize).upcoming_calendar_entries/take_drivenote(signed-command siblings of the existing REST-onlyVehicleFleetmethods of the same name),video_request,navigation_route,get_messages.set_rate_tariff,get_rate_tariff,add_managed_charging_site,remove_managed_charging_site,get_managed_charging_sites,set_discharge_limit(a distinct feature from the existingset_powershare_discharge_limit- confirmed against the proto, separate messages).bluetooth_classic_pairing_request(Bluetooth Classic, not BLE),bandwidth_test,fetch_keys_info.set_rate_tarifftakestesla_protocolmessage types (SetRateTariffRequest.Seasons/.Tariff) directly as arguments rather than a parallel flattened dataclass API, since the tariff schedule is deeply nested (up to 5 named seasons x 4 time-of-use period types).tests/test_ble_ui_unit_preference_commands.py,tests/test_ble_nav_messaging_media_commands.py,tests/test_ble_charging_utility_commands.py,tests/test_ble_connectivity_diagnostics_commands.py) covering each command's built signed message over the mocked BLE transport, plus cross-transport parity tests intests/test_cross_transport_parity.pyfor the two REST-sibling commands.