feat(vehicle): add navigation/messaging/media signed commands#92
Conversation
Wraps five previously-unimplemented VehicleAction fields: upcoming_calendar_entries and take_drivenote (signed-command siblings of the existing REST-only VehicleFleet methods of the same name), plus video_request, navigation_route, and get_messages. Both Fleet-signed and BLE transports get these for free via the shared Commands ABC.
e9f232d to
fdbc41e
Compare
![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: fdbc41eb0c
ℹ️ 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( | ||
| navigationRouteAction=NavigationRouteAction() | ||
| ) |
There was a problem hiding this comment.
For callers using VehicleBluetooth(confirmation="optimistic"), this no-arg route request is currently treated as a mutating command, so the BLE override skips the reply wait and returns best-effort success instead of the vehicle's navigationRouteResponse; in the normal ack path the response is also dropped because Commands._command only returns ping, vehicleData, or actionStatus responses. This makes the new API unable to deliver the route/traffic data it requests; pass it as mutating=False and decode the navigationRouteResponse branch before returning.
Useful? React with 👍 / 👎.
| Action(vehicleAction=VehicleAction(getMessagesAction=GetMessagesAction())), | ||
| mutating=False, |
There was a problem hiding this comment.
When the vehicle answers this read with a getMessagesResponse, Commands._command has no branch for that response oneof, so the new get_messages() method falls through to {"response": {"result": True, "reason": ""}} and discards every in-car message. A caller using this API will see success but never the messages it asked for; decode and return response.getMessagesResponse for this action.
Useful? React with 👍 / 👎.
|
Folded into #91 to avoid serial merge conflicts across the same commands.py regions - closing this in favor of the consolidated PR. |
1 participant
Intent
CarServer.VehicleActionproto field - this slice covers navigation/messaging/media.Commands, following the existing wrapper pattern:upcoming_calendar_entries/take_drivenote(signed-command siblings of the existing REST-onlyVehicleFleetmethods of the same name), plusvideo_request,navigation_route,get_messages.upcoming_calendar_entries/take_drivenotereuse the exact REST method names/signatures - onVehicleSigned, MRO already prefersCommandsoverVehicleFleetfor shared names, matching howdoor_lock,set_temps, etc. work today.tests/test_ble_nav_messaging_media_commands.pycover the BLE-built signed message for each command; cross-transport parity tests added totests/test_cross_transport_parity.pyfor the two REST-sibling commands.