Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Model S REST API

This site may earn commission on affiliate links.
I enable 2FA on my account and the APIs continued working as before. Doesn't seem like there is any change on that front right now.

Do you mean that you were already authenticated into the REST API, and enabling 2FA did not kick you out?

I would expect, if you need to re-authenticate, you'll have to figure out 2FA. But perhaps renewal will keep working as it did before. But that's just a guess.
 
Do you mean that you were already authenticated into the REST API, and enabling 2FA did not kick you out?

I would expect, if you need to re-authenticate, you'll have to figure out 2FA. But perhaps renewal will keep working as it did before. But that's just a guess.

I'm not sure about the first part of the question. It might have invalidated old tokens when I turned on 2FA. I just assumed the old token had expired and got new one.

Asking for a new token doesn't seem to trigger 2FA though.
 
Hey there, first time poster here.
I aim to develop my own app to fit my requirements, will receive my M3 late November.
Is there a mock of the Endpoint to where i can test my app against? (i do not have an accountor vehicle number for ownertesla)

Thanks and BR
Tahomma
 
Hi, I've been using TeslaJS and its implementation of the streaming API since the start of this year without issue.
Mid-last week it started returning the following error (which is passed directly from the Tesla response) "
Error: Basic Auth Disabled".
Vehicles/vehicle both return the correct response without any issue.
No changes to my code have been made in respect of the call in months, I was driving at the time the error first appeared.
I did not have 2FA enabled on the account, I have subsequently enabled/disabled that with no effect on streaming/vehicles/vehicle.
My original code used authToken/id_s in the streaming call, I have tried all variants of username/options token[0]/id/ all with the same error message.
I've generated new tokens, again without any change.
I had the HW3-/MCU2 update at start October with numerous software updates, so well outside of this issue.

Mark (@mseminatore) has responded on github that maybe the API has changed, is anyone else experiencing this issue?
 
Hi, I've been using TeslaJS and its implementation of the streaming API since the start of this year without issue.
Mid-last week it started returning the following error (which is passed directly from the Tesla response) "
Error: Basic Auth Disabled".
Vehicles/vehicle both return the correct response without any issue.
No changes to my code have been made in respect of the call in months, I was driving at the time the error first appeared.
I did not have 2FA enabled on the account, I have subsequently enabled/disabled that with no effect on streaming/vehicles/vehicle.
My original code used authToken/id_s in the streaming call, I have tried all variants of username/options token[0]/id/ all with the same error message.
I've generated new tokens, again without any change.
I had the HW3-/MCU2 update at start October with numerous software updates, so well outside of this issue.

Mark (@mseminatore) has responded on github that maybe the API has changed, is anyone else experiencing this issue?

Here's the git issue, others are now getting the failure:
Something wrong with streaming auth · Issue #210 · mseminatore/TeslaJS
 
https://github.com/timdorr/tesla-api/issues/97#issuecomment-549613978 does the trick for me, at least for now :)

Code:
msg_type: "data:subscribe_oauth",
token: options.authToken,
...

When you submit authToken, is it in the form of
Bearer authToken

or just authToken?

I have been using the same JSON suggested in the issues/97/ thread but keep receiving "Can't validate token."

To be clear, authToken is the OAuth token returned through the oauth/token endpoint, correct?

I have also seen examples where the token is converted to Base 64. Is that necessary?

Joe
 
When you submit authToken, is it in the form of
Bearer authToken

or just authToken?

I have been using the same JSON suggested in the issues/97/ thread but keep receiving "Can't validate token."

To be clear, authToken is the OAuth token returned through the oauth/token endpoint, correct?

I have also seen examples where the token is converted to Base 64. Is that necessary?

Joe

Correct, use only the token returned by the oauth/token endpoint and not base64 encoded.

Dirk
 
  • Like
Reactions: JDOhio
Correct, use only the token returned by the oauth/token endpoint and not base64 encoded.

Dirk

Thanks a bunch! I received the data_update message!

I used the OAuth token without "Bearer " in front of it. I'm saying that because for API endpoints like /vehicle_data, it requires "Bearer " in front of the token in a header.
Second, I used the value in the vehicle_id field of the /vehicle_data endpoint. I'm saying this because I've had conflicting (conflicting to me) information on using the value in vehicle_id or id_s. The value in id_s is used in API endpoints like /vehicle_data.

Lastly, I have an M3 which I took delivery in Mar 2020. Since there is no corresponding thread as awesome as this one in the M3 forum, I posted here and appreciate the responses.

Hope this helps others on their streaming journey!

Joe
 
Lastly, I have an M3 which I took delivery in Mar 2020. Since there is no corresponding thread as awesome as this one in the M3 forum, I posted here and appreciate the responses.

Yeah, this thread is really for all vehicles supported by the Tesla app. It was started before the Model 3 existed. Probably should have a different title and be in a different sub-forum!
 
  • Like
Reactions: JDOhio
Greetings Streamers!

I am able to stream data when the car uses wifi, and I'm able to stream data when the car uses the cellular link. I know about the cellular because I turned off the wifi, waited, and started my streaming app.

However, when the car transitions from wifi to cellular, my app detects a disconnection and sends the subscribe_oauth again. The stream does not start. I tried sending the subscribe_oauth a couple of times 30 seconds apart. The stream does not start.

Thoughts on how to resolve this?

Thanks!
Joe
 
Greetings Streamers!

I am able to stream data when the car uses wifi, and I'm able to stream data when the car uses the cellular link. I know about the cellular because I turned off the wifi, waited, and started my streaming app.

However, when the car transitions from wifi to cellular, my app detects a disconnection and sends the subscribe_oauth again. The stream does not start. I tried sending the subscribe_oauth a couple of times 30 seconds apart. The stream does not start.

Thoughts on how to resolve this?

Thanks!
Joe

I'm unclear what you're doing here as the data is steamed from the Tesla servers and not directly from the cat, so the communication on WiFi/cellular is managed by the Tesla serverss
 
Thanks @goRt!

I appreciate your response and support.

I thought Telsa managed the connection from the car but wasn't sure if the change from wifi to cellular impacted the stream. When I'm in my garage, I'm connected to wifi. By the time I'm at the end of my driveway, the car has switched to cellular. I can imagine some delay in reconnecting with Tesla.

It appears that my app never gets connected again when there is a switch from wifi to cellular; that is what I'm attempting to understand/solve.
I usually see the subscribe sent, one data set is streamed (perhaps more depending on what the car is doing), and a disconnect. In my app, I see that pattern while the car sits in the garage. The pattern stops when there is a switch from wifi to cellular. Perhaps I need to wait longer (I'm happy to be patient) but I wondered if other had seen this and had solutions.

Joe
 
  • Like
Reactions: goRt
Thanks @goRt!

I appreciate your response and support.

I thought Telsa managed the connection from the car but wasn't sure if the change from wifi to cellular impacted the stream. When I'm in my garage, I'm connected to wifi. By the time I'm at the end of my driveway, the car has switched to cellular. I can imagine some delay in reconnecting with Tesla.

It appears that my app never gets connected again when there is a switch from wifi to cellular; that is what I'm attempting to understand/solve.
I usually see the subscribe sent, one data set is streamed (perhaps more depending on what the car is doing), and a disconnect. In my app, I see that pattern while the car sits in the garage. The pattern stops when there is a switch from wifi to cellular. Perhaps I need to wait longer (I'm happy to be patient) but I wondered if other had seen this and had solutions.

Joe

Greetings!

I have not resolved this issue.

When my app starts, I receive data through the stream. The car shows a wifi connection. I place the car in Drive and there is a switch to cellular. My app shows a disconnection and it sends the subscribe message to the server. The server never replies even when the car starts moving.

Do I need to have Premium Connectivity?
Do I need to reset the websocket?
What have others seen in this scenario?

Thanks!
Joe
 
Greetings!

I have not resolved this issue.

When my app starts, I receive data through the stream. The car shows a wifi connection. I place the car in Drive and there is a switch to cellular. My app shows a disconnection and it sends the subscribe message to the server. The server never replies even when the car starts moving.

Do I need to have Premium Connectivity?
Do I need to reset the websocket?
What have others seen in this scenario?

Thanks!
Joe

Perhaps your car is taking some time to figure out that it's no longer connected to wifi, so there's a brief "hole" in the data transmission, and you happen to be reconnecting at just the wrong time?

If there's no data for a short time period, it will timeout and won't send anymore data until you resubscribe. What I do is terminate the websocket and start over if I haven't received any data for one minute. (I think Tesla's timeout is considerably shorter than a minute!) I'm not sure if it's really necessary to terminate the websocket, but that works for me.

I do have premium connectivity, so I'm not sure if that could be the cause. It's conceivable!