tesla-api
tesla-api copied to clipboard
timdorr
Document the Streaming API
While there is support in the Ruby code for the Streaming API, the docs are completely empty. We should fix that by filling them in. Anyone want to help?
Streaming seems to not work on that endpoint anymore. Even for old cars. Used my iOS lib and got this:
Opening Stream to: https://streaming.vn.teslamotors.com/stream/XX/?values=speed,odometer,soc,elevation,est_heading,est_lat,est_lng,power,shift_state,range,est_range,heading
Stream open
Stream data: <html>
Stream data: <head><title>502 Bad Gateway</title></head>
Stream data: <body bgcolor="white">
Stream data: <center><h1>502 Bad Gateway</h1></center>
Stream data: <hr><center>nginx</center>
Stream data: </body>
Stream data: </html>
Stream error: nil```
Seems like i can get a few values out of the streaming before the 502 starts.
I see one possible thing to test out here: https://www.lifewire.com/502-bad-gateway-error-explained-2622939
«Clear your browser cache [and/or cookies]. Outdated or corrupted files that are being stored by your browser could be causing 502 Bad Gateway issues ... »
The HTTP streaming endpoint is completely dead. It 502's for my car, which was still supported as of last year.
I've updated the gem to use the new WebSocket endpoint: 353cfc57bdcf7e411dcc115b5637da6c582536f7
My experience is that the 502's began in May/19 and have persisted. At that point I switched to a web-socket streaming implementation by dirkvm ( https://github.com/dirkvm/teslams ) forked from teslams. That worked until late summer at which time I began getting "data:error" messages indicating "vehicle_disconnected". At that point the code close the socket and retires with no success. The complete message from the data:subscribe attempt is: data:error { msg_type: 'data:error', tag: 'XXX my vid XXX', value: 'disconnected', error_type: 'vehicle_disconnected' } Are there any current streaming endpoint descriptions available, that are known to work?
I will also implement this on TeslaSwift lib as soon as i get some time. Will report if it works. The HTTPSteamEvent stream is totally dead even for older cars.
A couple of things to add to this:
You can send a "data:subscribe_oauth" msg_type instead of "data:subscribe". This uses the oauth token string instead of the token returned with the vehicle details.
If you respond to the "data:error" with a "data:subscribe_oauth", it seems to continue sending data so it does not look like closing and reopening the socket is necessary. Probably works the same with "data:subscribe" but I have not tested that.
EDIT: On further testing this does not seem to be as reliable as I had at first thought. And it seems that the Tesla app also performs a disconnect/reconnect if it receives a "data:error" as well.
My guess is that there's probably some message that needs to be sent in response to the "data:update" to indicate that further updates are wanted. Either that or the vehicle sends one update and then disconnects if it is parked and locked? (Would make sense - I've not yet tried streaming any data and had the vehicle in motion but I'll give that a try at some point.)
EDIT: The app does not seem to send anything in response to the "data:update", though I may have missed something. Also there are disconnections even if the vehicle is moving, but that may be due to it switching from WiFi to cell data (I'll test further and update if I find anything else.)
I've been playing with this today and i've come to the conclusion that data:error vehicle_disconnected is a time out issue, albeit a very small timeout window.
If I connect to the stream while my car is parked, I get 1 result with data, then a couple of seconds later I get the data:error.
If i'm driving when I connect, it streams fine.
If I come to a stop, but have my heating on, it streams fine as the power(kw) keeps changing between 1 & 2 which pushes data to the stream.
If I then turn off my heater, so none of the data from the stream is changing (Same location, same speed 0, same power etc..) then a few seconds later it disconnects with the error.
I can't yet confirm if the timeout is coming from Tesla or from my code. The web socket connection is greeted with {"msg_type":"control:hello","connection_timeout":0} so I wonder if there is a control command we can send to extend the timeout, or else an alternative command we can send to keep the socket alive before timeout.
EDIT----
Timeout seems to be 10s with no data I've tried sending all sorts of comment to ping or extend the timeout but nothing seems to give a response.
Yes I tried that amongst other things. I tried sending the ping every second and although it didn’t return any error, it still timed out after 10s. The connection to the socket doesn’t close, just the subscription to vehicle data.
What works is simply sending the subscribe command again after you receive vehicle_disconnected.
Hi, My experience with the timeout matches yours. I'm using the dirkvm version of streamws which originally closed the socket when a "data error" occurred. I removed the close and now the program just carries on after logging the error. Seems to work just fine except for the occasional hiccup.
From: ddaddy [email protected] Sent: November 19, 2019 4:54 AM To: timdorr/tesla-api [email protected] Cc: TheSpaceCowboy [email protected]; Comment [email protected] Subject: Re: [timdorr/tesla-api] Document the Streaming API (#97)
Yes I tried that amongst other things. I tried sending the ping every second and although it didn’t return any error, it still timed out after 10s. The connection to the socket doesn’t close, just the subscription to vehicle data.
What works is simply sending the subscribe command again after you receive vehicle_disconnected.
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/timdorr/tesla-api/issues/97?email_source=notifications&email_token=AKJNQEETE73UBEVO3FRF2BTQUOZUXA5CNFSM4GJYU3PKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEENRZQQ#issuecomment-555424962, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKJNQEHK3OW72LLXIYGLOETQUOZUXANCNFSM4GJYU3PA.
My partner is borrowing the car today for a short journey so I had an opportunity to observe the data whilst the car was being driven.
Sometimes after a vehicle_disconnected message, even subscribing again does not seem to work, so my previous suggestion might not be useful after all.
Observations:
Generally you'll get 1 or 2 messages if the car is parked and awake before it sends the vehicle_disconnected message. Certain things trigger more frequent messages to be sent (the car being in motion is the obvious one, but simply having the driver-side door open seemed to result in more frequent messages being sent.)
While the car was being driven, I'd get multiple messages per second. The car stopped at a red light and this resulted in a vehicle_disconnected after I received a message indicating its speed being 0. My script sent several subscribe messages 10 seconds apart, and after a minute gave up and reconnected. It then did not receive any messages after attempting to subscribe (on the new connection), and again sent several subscribe messages 10 seconds apart, giving up after a minute. The third connection attempt was successful and I started getting messages, however the car was already moving and had made significant progress along the road at that point.
I suspect if I had just disconnected and reconnected immediately each time upon receiving the vehicle_disconnected message, this would've worked.
I want to confirm if anyone else is seeing this behaviour when using the streaming API in a third-party app like Teslamate while also using the (official) Tesla mobile app.
It appears the streaming API only supports one client at a time, which the Tesla mobile app also uses. While a third-party app is using the streaming API, the Tesla mobile app seems to have issues with the location display while the car is in motion. Frequently it would error (I assume it doesn't handle error responses well) and display the car's location in a random location on the map like in the middle of the ocean or in another continent.
For example while my car was in Melbourne, Australia, it is displayed as in the middle of the Pacific Ocean
If this is a widespread issue, I think it is worth adding some warnings to this API that it may cause issues with the Tesla mobile app.
I want to confirm if anyone else is seeing this behaviour when using the streaming API in a third-party app like Teslamate while also using the (official) Tesla mobile app.
It appears the streaming API only supports one client at a time, which the Tesla mobile app also uses. While a third-party app is using the streaming API, the Tesla mobile app seems to have issues with the location display while the car is in motion. Frequently it would error (I assume it doesn't handle error responses well) and display the car's location in a random location on the map like in the middle of the ocean or in another continent.
For example while my car was in Melbourne, Australia, it is displayed as in the middle of the Pacific Ocean
If this is a widespread issue, I think it is worth adding some warnings to this API that it may cause issues with the Tesla mobile app.
I have noticed same issue and my Android phone doesn't show real time update when my family member is driving Tesla Model 3. I am using TeslaMate which uses real time streaming I guess and that shows real time update on my computer/browser but not Tesla App on my Android phone.
I was doing something with the streaming API the other day, and half way through the day I stopped getting any data returned from the car. I've not been able to get any streaming data since.
I receive the
{"msg_type":"control:hello","connection_timeout":0}
handshake and send the subscribe command
{"msg_type":"data:subscribe","tag":"1305444632","token":"Base64(<email:1stToken>)","value":"speed,soc,power"}
but get absolutely nothing until it times out. I've tried sitting in the car and messing with the AirCon, driving forwards and backwards. Nothing.
Anyone else seen this before?
One user reported a bug in the car location in the app. The car was always in fremont lol. He contacted Tesla and tesla forced a map update. It could be that your car has a buggy map and this can happen too.
On 20 Oct 2020, at 13:56, Darren Jones [email protected] wrote:
I was doing something with the streaming API the other day, and half way through the day I stopped getting any data returned from the car. I've not been able to get any streaming data since.
I receive the
{"msg_type":"control:hello","connection_timeout":0} handshake and send the subscribe command
{"msg_type":"data:subscribe","tag":"1305444632","token":"Base64(email:1stToken)","value":"speed,soc,power"} but get absolutely nothing until it times out. I've tried sitting in the car and messing with the AirCon, driving forwards and backwards. Nothing.
Anyone else seen this before?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/timdorr/tesla-api/issues/97#issuecomment-712767715, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANOMXTBVAW2YYGFFQMOOB3SLVUE3ANCNFSM4GJYU3PA.
Thanks. The Tesla app seems to work fine with the correct location. I just get absolutely nothing from the socket without any changes. I haven't had an update for a while, so hoping things aren't just stuck in the car.
I keep seeing so many conflicting stories on this subject. Is this something that is still working, any links to something working for android or Windows (I am clueless on ruby)?
Despite combing through others code in languages/dialects I have no experience with, but confident I've implemented the same interface (in C++) Ive seen nothing except endless {"msg_type":"control:hello","connection_timeout":0} on the streaming websocket. And just today I'm now getting a 408 on the (REST) wake_up endpoint unless I first poke the API with the Tesla app, whereas It was working a week ago
@coleged, I got some code going today but looks like the wss stopped working due to tesla changing something or some kind of problem. I am not the only one getting the error from what I am reading, which is "Basic Auth Disabled". You get it right after you send the "subscribe" request.
They must have shut down the basic auth. Send the oauth header instead https://github.com/timdorr/tesla-api/issues/97#issuecomment-549613978
Yeah, that makes sense with the new SSO system going live (must have been what took MFA so long). I'll get the Ruby gem updated soon.
Yep, I can confirm you need a new connect message. Here's what we generate in Ruby:
def streaming_connect_message
{
msg_type: 'data:subscribe_oauth',
token: client.access_token,
value: 'speed,odometer,soc,elevation,est_heading,est_lat,est_lng,power,shift_state,range,est_range,heading',
tag: self['vehicle_id'].to_s,
}
end
So, just send the msg_type: 'data:subscribe_oauth' and the token set to the Oauth access token you use for the Owner API. Pretty simple change, luckily.
Now I wonder what they're doing with the tokens from the vehicle data... 🤔
@timdorr, How do I get the "Oauth access token you use for the Owner API"? I cannot seem to find a way to do this. Thanks
Lol, I swear I tried that yesterday using my vehicle token. I will try again.