-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proxy: actuate_trunk
always sends "vehicle not awake" with error 503
#56
Comments
Same problem. Because the proxy retries the "failed" command automatically this means it opens and closes the trunk repeatedly. As an emergency measure we have disabled trunk controls for Vehicle Command Protocol vehicles. |
My workaround is to change the proxy code to send a different error and then process that error in a special way on the client. Couldn't figure out how to fix the proxy code properly |
@stx I haven't been able to reproduce. Is still an issue for you? What model? |
@sethterashima can confirm this is still happening for me on my model 3 as of right now frunk and trunk return I haven't tried other closure move requests like opening doors to see if this is just isolated to closure move requests or trunk/frunk specifically |
@sethterashima Still happening. I'm testing on a 2023 Model X but this is happening to many different vehicles across the Tesla fleet. Email me at james@tessie.com and I can provide more details to help you reproduce. Ran this just now against signed_command and this is actually moving the trunk:
|
I also tried this an I get a 500 back... Here is the log:
|
@stx Can you run with |
Here you go. Email me if you need the redacted info.
|
@stx : Looks like there might be two related issues: (1) the SDK isn't retrying correctly on a 503 and (2) The 503 should not be easily reproducible when the vehicle is online, as seen by the successful handshake messages that return 200. The fleetnet team is investigating the second issue and may reach out to you separately. As for (1), could you try the code from this branch to see if it makes actuate_trunk more reliable: #108? |
I can reproduce the problem every single time the "open trunk" message is sent to proxy. Specifically, I make sure while is awake and then send the "open trunk" message. It opens the trunk but then it issues a 503 error. |
@sethterashima so I just reproduced this issue while not using the SDK, same exact behavior/result: trunk opens, I also noticed that (at least for trunk) |
What do you mean by "while not using the SDK". How else are you sending the command to the car? |
by sending a POST request directly to /api/1/vehicles/{vehicle_tag}/signed_command |
I see. By signing the message yourself using the recently published protos? |
This is still not fixed, correct? |
Do you still experience this issue? |
I can check when I get back to my Mac, but this was a vehicle server issue not an issue with the proxy |
@avinoamr Yep, this looks fixed now. Thank you! |
When sending an
actuate_trunk
command, the proxy does send the signed command to the car and the car does act on it correctly, but the proxy returns a 503 http error. This happens when the car is actually awake.2023-11-22T19:57:04Z [debug] Server returned 503: Service Unavailable: {"response":null,"error":"vehicle is not available","error_description":""}
The text was updated successfully, but these errors were encountered: