Model S REST API

[dirkvm]

Nope, it's online

Model S here. No idea why it behaves differently on your model 3

 

[apoh]

Model S here. No idea why it behaves differently on your model 3

Yes, I've tried all the ways, it seems like it just not working for M3 (

 

[HankLloydRight]

Anyone else having API access problems?

I haven't been able to connect to my car via the mobile app, Teslafi, my own API code, or my tampermonkey script (Edit Telsa API Safe Tools: Token Generator, API Query Tool, and Referral Info Retrieval | OpenUserJS) .

I just get Vehicle Communication Error. I sent an email to customer support, but not sure if/when I'll hear back.

 

[markb1]

Anyone else having API access problems?

I haven't been able to connect to my car via the mobile app, Teslafi, my own API code, or my tampermonkey script (Edit Telsa API Safe Tools: Token Generator, API Query Tool, and Referral Info Retrieval | OpenUserJS) .

I just get Vehicle Communication Error. I sent an email to customer support, but not sure if/when I'll hear back.

I don't see any issues over here. "Vehicle Communication Error" sounds like a car-specific problem, but I don't recall ever seeing that message.

 

[HankLloydRight]

Yeah, I just had to go out and reboot the car (the one thing I didn't do ). Works now.

 

[darth_vad3r]

Wait, I think I figured it out. There's a *third* ID in that list response called id_s which does work.

id_s is just a string representation of id. Do you see something different?

My id, id_s, and vehicle_id are all different.

Interestingly, id_s = str(id + 1)

Very strange. I just double-checked mine, and id_s == str(id).

Woah! Very strange indeed. I just checked mine and it is +2!

I just tried the “id” and it doesn’t work, I have to use id_s variant. I have never had an issue — I must have fluked out and copy pasted that one the first time, not noticing they weren’t in fact identical as the docs imply. Or could they increment over time for some reason?

I noticed a key version in my model 3 vehicle config incremented from 1 to 2 after updating to 2019.24.x from 20.x so I thought maybe that was related, but I checked some logs and I was using id_s xxx2 since before when the vehicle_config.key_version was 1.

I’ve never seen this id_s discrepancy mentioned before.

Anyone else have a difference? Do “id” numbers end in 0 and then get incremented somehow?

@dlsspy wondering if we have something in common that’s made our id_s’s diverge from our id’s?

Is yours still 1 off, or has it incremented again somehow? I played with some Oauth token revoking... I don’t think that was it? Hmmm.

Also ... anyone know what “key_version” is referring to? Bluetooth key protocol?? Did it change in 2019.24?

 

[darth_vad3r]

First, many thanks to SG57 for posting the info on the new 'actuate_trunk' command for Model 3. For the life of me I could not figure out why 'trunk_open' would not work (error 400), and that new command did the trick.

Related, in the 'vehicle_state' query, is there a meaning for the 'ft' (front trunk) and 'rt' (rear trunk) numeric values? For my Model 3, these values are 0 when the trunks are closed. But when open, 'ft' = 16 and 'rt' = 32. Being both powers of 2, that looks like something perhaps bit-mapped. Not sure why the numbers are different for trunk and frunk. Does anyone have an idea of what the bits (or numbers) mean?

Ditto the thanks to all contributors.

I’d noticed the same 32, 16 and figured someone at Tesla got lazy and didn’t convert from an internal bit to a Boolean.

My guess is internal flag bits 1-4 are the doors (1, 2, 4, 8) and bits 5 and 6 are the trunks (16, 32)

 

[Carspotter Daily]

Does anyone know how to fetch data about the account?

I’m referring to the page one sees when logging into the myTesla portal online - the account details and documents associated with the account.

Thanks

(Added screenshot)

 

[darth_vad3r]

Related, in the 'vehicle_state' query, is there a meaning for the 'ft' (front trunk) and 'rt' (rear trunk) numeric values? For my Model 3, these values are 0 when the trunks are closed. But when open, 'ft' = 16 and 'rt' = 32. Being both powers of 2, that looks like something perhaps bit-mapped. Not sure why the numbers are different for trunk and frunk. Does anyone have an idea of what the bits (or numbers) mean?

My guess is internal flag bits 1-4 are the doors (1, 2, 4, 8) and bits 5 and 6 are the trunks (16, 32)

Ya, it’s exactly this. Checked it last night.

Bits values are: df (1), pf (2), dr (4), pr (8), ft (16), rt (32)
Driver, passenger front doors, driver passenger rear doors, front, rear trunks.

 

[darth_vad3r]

Back to 'id_s' being different than 'id' ... I looked at my logs from my first fooling around with the API and at that point both id and id_s were identical, and ended with the same digit (2). Since then, somehow, the 'id' field coming back has been decremented by 2 (now ends in 0), while the id_s has remained consistent.

What's up with the changing 'id' ?

 

[markb1]

So I was able to test out the websocket streaming API on friend's Model 3 today, and it worked! (I've only seen one report about it up thread, where it did not work.)

Initially, I was getting a "client_error" when the car was asleep, but now I'm getting no error at all. Contrast that with my Model S (still running V8), which gives a "vehicle_disconnected" error when it's asleep. But either way, both cars report data when they are driving.

 

[markb1]

So I was able to test out the websocket streaming API on friend's Model 3 today, and it worked! (I've only seen one report about it up thread, where it did not work.)

Initially, I was getting a "client_error" when the car was asleep, but now I'm getting no error at all. Contrast that with my Model S (still running V8), which gives a "vehicle_disconnected" error when it's asleep. But either way, both cars report data when they are driving.

I take that partially back. It did work for a while, but not anymore. When my subscription request gets no response, there is also no data when the car wakes up. So the session looks like this:

> subscribe
< client_error
> subscribe
< client_error
.
.
.
> subscribe
< connected
< data!
> subscribe
< silence!

The rest of my subscription requests have been met with silence ever since.

 

[KWReid]

Trying to figure out a reasonable strategy for a test app I'm working on for detailed logging of my 2018 x that doesn't keep the car awake.

I'd like to be able to retrieve data every 1min while the car is being driven. When it's not being driven I don't need that frequent details.

If it's asleep, I want it to stay asleep.
If it's online, I want to know if it's being driven. If it is, I want to get details for it.

The common problem is that while the "Vehicles" API call wont wake up a sleeping car, and it does tell you if the car is online or asleep, it doesn't give any indication as to whether it's being used or not. To find out if the car is being used, you need to make a "Details" call, and that will keep the car awake.

I think this was a problem about a year ago that others were also having. Are there any newer APIs yet that might give me the ability to get this status without waking the car?

 

[SeBsZ]

Yeah I believe we're all running into that issue. How much easier life would be if instead of online, offline or sleeping it would tell us driving as well.

For now you'll need to either work on a schedule of not polling at certain times, and risk losing drives. Or every so often stop polling for 15 minutes or so and check if that put the car to sleep. Then stop polling regularly until the car stops sleeping. Repeat.

It's horribly inefficient. As for newer APIs I'll let someone else chime in, but I haven't heard of anything.

 

[markb1]

Trying to figure out a reasonable strategy for a test app I'm working on for detailed logging of my 2018 x that doesn't keep the car awake.

I'd like to be able to retrieve data every 1min while the car is being driven. When it's not being driven I don't need that frequent details.

If it's asleep, I want it to stay asleep.
If it's online, I want to know if it's being driven. If it is, I want to get details for it.

The common problem is that while the "Vehicles" API call wont wake up a sleeping car, and it does tell you if the car is online or asleep, it doesn't give any indication as to whether it's being used or not. To find out if the car is being used, you need to make a "Details" call, and that will keep the car awake.

I think this was a problem about a year ago that others were also having. Are there any newer APIs yet that might give me the ability to get this status without waking the car?

What I do is use the streaming API to determine if the car is driving or charging. If it is, I poll the REST API once per minute until the car is idle, again. The streaming API does not keep the car from going to sleep.

I think the the streaming API should work on your X. On the 3, it seems to work sometimes and not others, but it works reliably on my S. I haven't tried with an X, but I'm betting it works.

 

[KWReid]

For now you'll need to either work on a schedule of not polling at certain times, and risk losing drives. Or every so often stop polling for 15 minutes or so and check if that put the car to sleep. Then stop polling regularly until the car stops sleeping. Repeat.

I'm trying something out now that the guys at TeslaFi documented. It's a bit convoluted, but signs are that it may work.
Enabling sleep settings to limit vampire loss. / Knowledge base / TeslaFi

Basically, while it is "online" if I do a details call and see an indication that the drive_state.shift_state has switched to "null". This seems to be an indication that the car is "online" but it's attempting to sleep. Likely not an intentional behavior, but a useful "bug" on the car/API.

Once I see that, I pause the car details calls for up to 15min while still making the Vehicles call. This has allowed the car to go to sleep.

After that, the 1min interval calls for "Vehicles" I can use to restart the details calls once it goes "online" again.

 

[KWReid]

What I do is use the streaming API to determine if the car is driving or charging. If it is, I poll the REST API once per minute until the car is idle, again. The streaming API does not keep the car from going to sleep.

I'll need to give this a try. Googling...

 

[markb1]

I'll need to give this a try. Googling...

See this post up thread:
Model S REST API

 

[darth_vad3r]

I'm trying something out now that the guys at TeslaFi documented. It's a bit convoluted, but signs are that it may work.
Enabling sleep settings to limit vampire loss. / Knowledge base / TeslaFi

Basically, while it is "online" if I do a details call and see an indication that the drive_state.shift_state has switched to "null". This seems to be an indication that the car is "online" but it's attempting to sleep. Likely not an intentional behavior, but a useful "bug" on the car/API.

Once I see that, I pause the car details calls for up to 15min while still making the Vehicles call. This has allowed the car to go to sleep.

After that, the 1min interval calls for "Vehicles" I can use to restart the details calls once it goes "online" again.

Interesting idea, but ... couldn’t null shift_state also be BEFORE you are going to start a drive, and not just after when you want to back off to let it sleep?

I’d set the “try to let it sleep” poll interval to whatever is required (11 or 12 minutes?) and if it is online, check for pre-conditioning being on (climate_state.is_preconditioning) and then shorten up into a “pre-drive” state of more frequent polling. Or if the doors are unlocked also do this.

Then if any doors are open or vehicle_state.is_user_present, really get geared up even more into a “drive is imminent” state and you should be able to catch the start of the drive fairly well.

Then if you just get into the habit of preconditioning or unlocking your car 10 minutes early it will be like sending a signal to your logging service to “get ready for a drive”

Of course if you are manually doing this just to signal the service, then you could design a way to actually trigger your service to shift into pre-drive state directly and manually do that instead

 

[KWReid]

Interesting idea, but ... couldn’t null shift_state also be BEFORE you are going to start a drive, and after when you want to back off to let it sleep?

This is definitely the gap in this partial workaround. If I'm in the "let the car go to sleep" mode because the car is ONLINE and SHIFT_STATE is null... and I get in to start driving I'm going to miss some part of the drive because my app will not get details for 10-15min while it lets it try to sleep. Then it'll make a call and find it's SHIFT_STATE is no longer null and start reading details again.

... if it is online, check for pre_conditioning being on and then shorten up into a “pre-drive” state of more frequent polling. Or if the doors are unlocked also do this.
Then if vehicle_state.is_user_present, really get geared up even more into a “drive is imminent” state and you should be able to catch the start of the drive fairly well.
Then if you just get into the habit of preconditioning or unlocking your car 10 minutes early it will be like sending a signal to your logging service to “get ready for a drive”

I'd like to avoid having to manually do something to prep the car before driving. Also, if the car is in this "waiting to sleep" state already, and I turn on preconditioning, my app won't know that because it's not making details calls to get that info, nor will it know that user_present.

Of course if you are manually doing this just to signal the service, then you could design a way to actually trigger your service to shift into pre-drive state directly

Yea. if I'm that concerned about losing a part of the drive details, I could just build in a one button web call to temporarily switch to details polling mode for the next few minutes. Until there's a better option (streaming API?) I'll keep an eye out to see how often I run into this case.

thx!