Document the Streaming API #97
Comments
|
Streaming seems to not work on that endpoint anymore. Even for old cars. |
|
Having the same issue as @jonasman |
|
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: «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 ... » |
|
I tried the streaming API recently and it still doesn't work. |
|
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: 353cfc5 |
|
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: |
|
Mine works. It's actively running as I write this, for a project I'm working on right now. |
|
Will look into integrating into my processes. Thanks. |
|
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 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 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 EDIT---- Timeout seems to be 10s with no data |
|
There is a |
|
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. What works is simply sending the subscribe command again after you receive |
|
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 <notifications@github.com>
Sent: November 19, 2019 4:54 AM
To: timdorr/tesla-api <tesla-api@noreply.github.com>
Cc: TheSpaceCowboy <tyepan@hotmail.com>; Comment <comment@noreply.github.com>
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 GitHub<#97?email_source=notifications&email_token=AKJNQEETE73UBEVO3FRF2BTQUOZUXA5CNFSM4GJYU3PKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEENRZQQ#issuecomment-555424962>, or unsubscribe<https://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 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 receive the handshake and send the subscribe command but get absolutely nothing until it times out. 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 ***@***.***> 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 <#97 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANOMXTBVAW2YYGFFQMOOB3SLVUE3ANCNFSM4GJYU3PA>.
|
|
Thanks. |
|
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 #97 (comment) |
|
@timdorr what is the current status of the streaming API? I’m using python and would appreciate some pointers on where to start. |
Forked. I'll work on it in the next week or so. This might help some in the mean time. |
|
@mloyd |
@TeslaOwnerTips I believe there is a transport mode, so streaming might be stopped in this particular case. |
|
@itsMeDavidV okay bad example. My point was in his notes which @mloyd linked to he says parked in the driveway there won't be streaming. I'm trying to get at what the real technical criteria is: zero speed, in park, gps coordinates static etc. |
|
As far as I have seen, the criteria seems to be "something changing". E.g. speed, power consumption, gps and so on. Edit: for more details, i have seen my car stopped at a red light stopping streaming when the A/C is off (i.e. the power draw is minimal at that point). However, if the A/C is on and/or speed of A/C varies, the connection stays open as long as there is a regular change in the power consumption at the red light, even though speed is always 0. |
|
@TeslaOwnerTips I'd imagine it's dependent on speed per the linked notes:
GPS coordinates would be less accurate than speed and you'd prob still be in Drive at a stop light (though "Hold" could be a criteria in addition to Park). It also seems record intervals are determined by speed. So prob leaning towards speed here. |
|
Good questions. I'll present a scenario from one of my recent drives. See data from log file at the end. I'll include more examples like this in the PR for the documentation. @TeslaOwnerTips - to your question specifically, the likely scenario transport service provider will put the vehicle in service mode. When that happens, any call to General comments about the sample
Lines
|
|
@mloyd thank you for your hard work on this. So we need FSD to become street legal so that we can sit in the car to code and debug while in motion 😂 or wait for our significant other to go for a drive 😀 Personally I'm interested in streaming to see if a pi zero with a relay could be used to open the garage door for me when my Tesla gets close enough. I'm currently using our arrival home on Apple Home which works quite well. It also opens the garage door when we come home from a walk but I changed my habits to use the garage door to enter the house. I've tried BLE devices as well. I've also tried a dedicated iPod Touch placed in the car but I need to get back to that since I didn't debug why it didn't work. |
|
Teslamate, MQTT, Nodered are a set of perfectly working softwares for this
on my raspberry to open the garage door but also monitor my calendar to set
the preconditioning, charge amps and timing depending on the location and
power company contract, and much more... like overheat protection while
sentry is active, smartphone remote, ...
Le ven. 15 juil. 2022 à 17:29, TeslaOwner.tips ***@***.***> a
écrit :
… @mloyd <https://github.com/mloyd> thank you for your hard work on this.
So we need FSD to become street legal so that we can sit in the car to
code and debug while in motion 😂 or wait for our significant other to go
for a drive 😀
Personally I'm interested in streaming to see if a pi zero with a relay
could be used to open the garage door for me when my Tesla gets close
enough. I'm currently using our arrival home on Apple Home which works
quite well. It also opens the garage door when we come home from a walk but
I changed my habits to use the garage door to enter the house. I've tried
BLE devices as well. I've also tried a dedicated iPod Touch placed in the
car but I need to get back to that since I didn't debug why it didn't work.
—
Reply to this email directly, view it on GitHub
<#97 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADUNWNKFLCX57GJ6774RLUTVUF7VJANCNFSM4GJYU3PA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
I also try to use the Streaming API. But I always get a 403 back :( : Any ideas why this happens? |
|
arrrggg... Found it... |
|
Is here some actually using the streaming API, because I have some questions... It seems, that the streaming API is just for driving and charging, right? 1.) Detect the state: I detect, that the car is driving, when the shift state is != nil. 2.) About when to connect to the streaming? When the car goes to sleep, the WebSocket closes. 3.) Is it for charging? When Charging, after some time the API stops senden data. So perhaps, the streaming API is just for driving? 4.) What data does the streaming API offer? Can I request more data than this: speed,odometer,soc,elevation,est_heading,est_lat,est_lng,power,shift_state,range,est_range,heading Thanks for you help :) |
|
Hello @Urkman! The streaming code is an example of how to get streaming up and running. As you pointed out, it would require additional code to detect specific states of the vehicle's operation. I wrote my streaming in Java based on this model. I implemented a state machine to accommodate vehicle operation while driving. I found it both complex and rewarding to develop. It is still not perfect. Joe |
|
Hello @jdemeyer1 Thanks for your answer :) I experience the same with stops in the streaming data. But not only when standing at s stop light. It also happens in mid drive :( See my first screenshot, there it stop at 40 km/h... And don't resume till the end of the drive. Now my question: What do you think?
|
|
Hello @Urkman! I have also seen the streaming stop while driving. When that happens, the socket receives data:error message. I start a timer that waits 20 seconds before attempting to subscribe again. If there is no response, I wait 60 seconds and try again. If there is no response, I wait 80 seconds and try again. If there is no response, I close the socket. This generates an onStateChange event on the socket where I disconnect from the socket. This generates an onDisconnect event on the socket where I set the socket object to null and create another socket object. Everything starts again on the new socket. It is a lot of messing around but usually, the socket responds after the first attempt to subscribe. Open to suggestions for simplifying the error recovery process. I have read somewhere that waiting to reconnect is the best method to start the subscription again. I have been using a third-party socket implementation that I would like to simplify but I have been distracted by other projects. Joe |
|
Curious if the disconnects are from network issues between cell towers. The behavior may change when connected to mobile hotspot. Without more detail on how the output signals are generated, we're all literally just (intelligent-ish-ly?) guessing. We only get to see the outputs after all. |
and others
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?
The text was updated successfully, but these errors were encountered: