Add support for navigation_waypoints_request command - #443
Open
matthieu6010 wants to merge 3 commits into
Open
Conversation
The `navigation_waypoints_request` endpoint is documented in the Fleet API
reference[1] but was not implemented in this library. Vehicles with
`vehicle_command_protocol_required: true` reject the raw REST call with
"Tesla Vehicle Command Protocol required", and the proxy previously
returned `invalid_command` for this endpoint.
This change:
- Adds the `NavigationWaypointsRequest` protobuf message definition in
`car_server.proto`, matching the schema used by the Tesla mobile app:
* `string waypoints = 1` — comma-separated `refId:<placeId>` list
* `TripPlanOptions trip_plan_options = 2`
* `int32 destination_start_soe = 1`
* `int32 destination_arrival_soe = 2`
Wired into the `VehicleAction` oneof at tag 90.
- Regenerates `car_server.pb.go` via `make proto-gen` (the large diff is
due to protoc version drift; the actual logical change is limited to the
new `VehicleAction_NavigationWaypointsRequest` case, the new
`NavigationWaypointsRequest` / `NavigationWaypointsRequest_TripPlanOptions`
structs, and their wire-method scaffolding).
- Adds `(v *Vehicle) NavigateToWaypoints(ctx, waypoints)` in a new file
`pkg/vehicle/navigation.go`, following the same `executeCarServerAction`
pattern as other command helpers.
- Adds the `"navigation_waypoints_request"` case to the proxy command
switch, parsing the required `waypoints` string body and dispatching the
signed command.
Usage (via the proxy):
POST https://<proxy>/api/1/vehicles/<vin>/command/navigation_waypoints_request
{"waypoints": "refId:ChIJ...,refId:ChIJ...,refId:ChIJ..."}
The last entry is the final destination; preceding entries are intermediate
stops. The car navigates through all of them in order, and the built-in
trip planner automatically inserts Supercharger stops when the battery
range is insufficient.
Tested end-to-end against a Model 3 (firmware 2026.14.1) with three stops:
the API returns `{"result":true,"reason":""}` and the on-dash navigation
displays the full multi-leg route.
Addresses part of teslamotors#188 and the sub-request in teslamotors#334 for
`navigation_waypoints_request`.
[1] https://developer.tesla.com/docs/fleet-api/endpoints/vehicle-commands
Lets callers specify the trip planner's starting/arrival target SoC (in integer percent). Leaving both at 0 preserves the previous behaviour (Tesla applies its conservative defaults, which can insert Supercharger stops aggressively). - Adds `NavigateToWaypointsWithOptions` in pkg/vehicle/navigation.go. `NavigateToWaypoints` is kept as a thin wrapper for backward compat. - The proxy parses the optional `destination_start_soe` and `destination_arrival_soe` numeric body fields and forwards them.
| // The last place in the list is the final destination; preceding entries are | ||
| // intermediate stops. The car will route through all of them in order. | ||
| // | ||
| // See https://developer.tesla.com/docs/fleet-api/endpoints/vehicle-commands |
Collaborator
There was a problem hiding this comment.
| // "refId:ChIJxxx,refId:ChIJyyy,refId:ChIJzzz" | ||
| // | ||
| // The last place in the list is the final destination; preceding entries are | ||
| // intermediate stops. The car will route through all of them in order. |
Collaborator
There was a problem hiding this comment.
Refer to "vehicle" rather than "car" in documentation strings. Also in first paragraph.
| BatchRemoveChargeSchedulesAction batchRemoveChargeSchedulesAction = 108; | ||
| SetLowPowerModeAction setLowPowerModeAction = 130; | ||
| SetKeepAccessoryPowerModeAction setKeepAccessoryPowerModeAction = 138; | ||
| NavigationWaypointsRequest navigationWaypointsRequest = 90; |
| message NavigationWaypointsRequest { | ||
| string waypoints = 1; | ||
| TripPlanOptions trip_plan_options = 2; | ||
|
|
Collaborator
There was a problem hiding this comment.
Rearrange to match internal order:
message NavigationWaypointsRequest {
message TripPlanOptions {
int32 destination_start_soe = 1;
int32 destination_arrival_soe = 2;
}
string waypoints = 1;
TripPlanOptions trip_plan_options = 2;
}
Collaborator
|
Appreciate the PR. I left a few nits and will try to validate this week or next. |
- Replace 'car' with 'vehicle' in NavigateToWaypoints docstrings - Add full Tesla Fleet API doc link with anchor (#navigation-waypoints-request) - Move navigationWaypointsRequest = 90 into numeric field order in VehicleAction oneof - Hoist TripPlanOptions nested message definition before field declarations in NavigationWaypointsRequest
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
2 participants
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.
Summary
Implements the signed
navigation_waypoints_requestcommand so that Tesla vehicles withvehicle_command_protocol_required: truecan receive a full multi-stop route via the Fleet API.The endpoint is documented in the Fleet API reference but was not implemented here — raw REST calls return
"Tesla Vehicle Command Protocol required", and before this change the proxy returnedinvalid_command. Part of #188 and the sub-request in #334.Changes
pkg/protocol/protobuf/car_server.proto— addNavigationWaypointsRequestmessage (with nestedTripPlanOptions) and wire it into theVehicleActiononeof at tag 90, matching the schema used by the Tesla mobile app:pkg/protocol/protobuf/carserver/car_server.pb.go— regenerated viamake proto-gen(protoc 3.21.9, protoc-gen-go v1.28.1, same versions as the existing file header). The large diff is essentially protoc output noise; the substantive additions are theVehicleAction_NavigationWaypointsRequestoneof case, the two new structs, and their wire-method scaffolding.pkg/vehicle/navigation.go(new) — adds(v *Vehicle) NavigateToWaypoints(ctx, waypoints), which follows the sameexecuteCarServerActionpattern as other command helpers.pkg/proxy/command.go— adds the"navigation_waypoints_request"case that parses the requiredwaypointsbody field and dispatches the signed command.Usage
The last entry is the final destination; preceding entries are intermediate stops.
refId:values are Google Maps place IDs.Test plan
go build ./...cleango vet ./...clean{"result":true,"reason":""}Notes for reviewers
navigation_gps_request,navigation_sc_request,navigation_route_action, andnavigation_gps_destination_requestare also currently missing from the proxy switch but are out of scope for this PR. Can follow up in a separate change if there's interest.