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.
That's not what I'm seeing. I get the "id" property and use that for requesting details. My "id" response in the vehicle status JSON is the same as id_s. The prior isn't bound by quotes, and the latter is bounded by quotes.

That's not the point at all. {id_s} is 'bounded by quotes' because it is (or was) just the string version of {id} (hence the '_s' suffix). The value of {id_s} itself does not include the quotes, as do none of the other JSON string values. That's just how strings are represented in JSON. Just like the string value of {state} is online not "online".

Up until recently, {id_s} was just the string version of the integer {id}. But since we're using it to construct a URL (string) to pass back to the API, you could use {id_s} directly if you didn't want to (or couldn't) convert the integer {id} to a string in your programming language of choice. (which is odd, since what language doesn't allow you to do that?). My guess is that {id_s} was included as a string version of {id} since some languages might have trouble handing/converting {id} as a long integer and it was getting mangled. But who knows for sure.

But the main point now is that for some unknown reason, and only for some people, {id} and {id_s} are not the same value and differ +/- 1 or 2. So when your code using {id} stops working, you too will have to just switch to {id_s} to get it working again.
 
my "ids" changed again last night. I was looking it up only on initial start of the app. I was thinking this only changed once in a great while but mine has changed twice in the last two weeks. Now I if I get an error I use the VIN to get a new "ids" and continue to run.

I have also noticed that the shift_state will temporary go to null and then back to "P" all in a few minutes (2019 Model X bought in late July). I was using the null state to trigger an "allow sleep" mode in my app. Since my app monitors charge cycles, I added the monitoring of the charger_actual_current value. If the charger_actual_current = 0 and shift_state = null, I then go into "allow sleep" mode. Just made that change yesterday will see how it works out.

One last observation: Last week before I got the latest update. I noticed my Model X would wake up about once an hour. Since that update she sleeps like a rock. I'm now seeing her sleep all night and all day unless I wake her with the Tesla IOS app. Before the update my app would detect that the car was awake and poll data once an hour. My app also monitors cabin temperature and sends it to a gauge on the wall. Since the car doesn't wake up, the temperature data is not getting updated. I think I'm going to have to add a wakeup to my app. Didn't really want to do that I like being passive as possible.
 
But the main point now is that for some unknown reason, and only for some people, {id} and {id_s} are not the same value and differ +/- 1 or 2. So when your code using {id} stops working, you too will have to just switch to {id_s} to get it working again.

As I just recently mentioned, mine is +6, so it’s not just +1 or +2

my "ids" changed again last night. I was looking it up only on initial start of the app. I was thinking this only changed once in a great while but mine has changed twice in the last two weeks. Now I if I get an error I use the VIN to get a new "ids" and continue to run.

Did your change last night just increment by 1-9, or an entire new number yet again?
 
  • Like
Reactions: HankLloydRight
That's not what I'm seeing. I get the "id" property and use that for requesting details. My "id" response in the vehicle status JSON is the same as id_s. The prior isn't bound by quotes, and the latter is bounded by quotes.

There was a change recently that broke my API calls because I was lazy and just used a hardcoded ID which was changed recently. Now I use the "id" property for my follow up details call rather than assuming it's always the same.

Advisable to change to ‘id_s’ because that’s the correct one to use when they diverge. Using ‘id’ fails to work when they are different values.
 
Has anyone had problems waking up their vehicle with the IOS app? I have a 2019 Model X and about three times now in the last month I have not been able to wake up my car with the IOS app. I can't do it with the API command either
'https://owner-api.teslamotors.com/api/1/vehicles/'+ this._carID +'/wake_up'
I have to go out with the key and stand next to it. I can then wake it up with the phone???

I get this if the car is on weak wifi sometimes. Do you get an upstream timeout or some other kind of error from the API?
 
Did your change last night just increment by 1-9, or an entire new number yet again?
My IDS is 5 + my ID value. I don't use the ID for anything should I? I have always used IDS.

I get this if the car is on weak wifi sometimes. Do you get an upstream timeout or some other kind of error from the API?
Great minds... I got in the car yesterday to check just that. I have Google Wi-Fi here at home and have good signal strength in the garage. The car has been setting for 3 days without moving an inch. So my Wi-Fi signal should be okay. I noticed something last night for the first time. In my system logs my app was reporting that the car was offline not asleep. This is a first I have seen the offline state?? I bet the way this all works is Tesla has a VPN between their servers and the car. The Tesla API access the car through this VPN. If the VPN is down or the has problems then you get the offline error. Not sure just guessing.
 
I'm pretty sure I read in the manual that the car will loose about one percent a day of charge when sitting idle. My Mode X has not been driven since Monday and here it is Thursday, and sure enough according to the charge rate the car has gone from 90% to 87% charge. The car sleeps a huge percentage of the time according to the API. I'm now waking up the car once an hour to read the cabin temperature and I let it go back to sleep as soon as it request it. Anyone have an idea on how much more (if any) battery drain this will cause? Seems to me bringing the API on-line (waking the car) really doesn't add that much of a load.
 
My IDS is 5 + my ID value. I don't use the ID for anything should I? I have always used IDS.

A lot of the unofficial API docs say to use the ‘id’ but this is wrong and doesn’t work, you need to use the “id_s” for it to work.

In my system logs my app was reporting that the car was offline not asleep. This is a first I have seen the offline state?? I bet the way this all works is Tesla has a VPN between their servers and the car. The Tesla API access the car through this VPN. If the VPN is down or the has problems then you get the offline error. Not sure just guessing.

Ya, that’s definitely one possible meaning for “offline”.

“Offline” could be no actual signal (e.g. out in the boonies, in a tunnel or underground parking). In this case the car could be awake or asleep. True state is unknown.
“Offline” could also mean there were protocol timeouts at some layer for some reason (say a lower layer fails ... e.g. VPN as you suggested, or TCP, wifi connection, etc).

I'm pretty sure I read in the manual that the car will loose about one percent a day of charge when sitting idle. My Mode X has not been driven since Monday and here it is Thursday, and sure enough according to the charge rate the car has gone from 90% to 87% charge. The car sleeps a huge percentage of the time according to the API. I'm now waking up the car once an hour to read the cabin temperature and I let it go back to sleep as soon as it request it. Anyone have an idea on how much more (if any) battery drain this will cause? Seems to me bringing the API on-line (waking the car) really doesn't add that much of a load.

IIRC, for the Model 3, the “awake” draw for the car is ~250 W +/- ... so it’s just preventing it from sleeping for a longer amount of time that drains the battery (not necesssrily the API-handling that causes the drain, just the whole car being ‘on’). If your car normally sleeps all night, but instead you wake it up once an hour, and it takes 12 minutes to go back asleep, you’d be using an extra 0.6 kWh overnight.

If it’s 15 minutes it’s 0.75 kWh. Not sure what the idle power consumption numbers are for other models though. That’s 1% of a 75 kWh pack in 12 hours.

The risk is that for whatever reason once it is awake it decides to stay awake for way longer (insomnia) :) ... then you could be looking at 3% overnight instead of 3% over 3 days :)
 
A lot of the unofficial API docs say to use the ‘id’ but this is wrong and doesn’t work, you need to use the “id_s” for it to work.



Ya, that’s definitely one possible meaning for “offline”.

“Offline” could be no actual signal (e.g. out in the boonies, in a tunnel or underground parking). In this case the car could be awake or asleep. True state is unknown.
“Offline” could also mean there were protocol timeouts at some layer for some reason (say a lower layer fails ... e.g. VPN as you suggested, or TCP, wifi connection, etc).



IIRC, for the Model 3, the “awake” draw for the car is ~250 W +/- ... so it’s just preventing it from sleeping for a longer amount of time that drains the battery (not necesssrily the API-handling that causes the drain, just the whole car being ‘on’). If your car normally sleeps all night, but instead you wake it up once an hour, and it takes 12 minutes to go back asleep, you’d be using an extra 0.6 kWh overnight.

If it’s 15 minutes it’s 0.75 kWh. Not sure what the idle power consumption numbers are for other models though. That’s 1% of a 75 kWh pack in 12 hours.

The risk is that for whatever reason once it is awake it decides to stay awake for way longer (insomnia) :) ... then you could be looking at 3% overnight instead of 3% over 3 days :)


Good stuff! Sounds like I need to rethink the every hour thing. Maybe do it based on time. Only wakeup once an hour between 6am and 6pm. Most of the time the car will be awake at that time anyway. Thanks for the input!!
 
  • Like
Reactions: darth_vad3r
Has anyone built a generic Swift app that they would be willing to share? Just something that communicates with the car and I could expand upon by slowly learning the API? All I need is the ability to poll my Sense Energy Monitor and if there is extra Solar Production turn charging on in the car when the production wanes, turn it back off. But no one has made such an app yet. Guess it's up to me.

Thx.
 
Has anyone built a generic Swift app that they would be willing to share? Just something that communicates with the car and I could expand upon by slowly learning the API? All I need is the ability to poll my Sense Energy Monitor and if there is extra Solar Production turn charging on in the car when the production wanes, turn it back off. But no one has made such an app yet. Guess it's up to me.

Thx.
That sounds cool. Have you thought about doing it with Node.JS on a Raspberry Pi? That way your Pi could set at home and monitor everything unattended. If you do it on your phone the app will have to be running all the time in background.

It would be cool if you could trigger a charge from a home automation app like SmartThings.

Just brain storming I know that is not what you asked. Sounds like a fun project.
 
In my system logs my app was reporting that the car was offline not asleep. This is a first I have seen the offline state?? I bet the way this all works is Tesla has a VPN between their servers and the car. The Tesla API access the car through this VPN. If the VPN is down or the has problems then you get the offline error. Not sure just guessing.

It's OpenVPN between the cars and the backend.

Bruce.
 
  • Like
Reactions: John Rucker
Has anyone built a generic Swift app that they would be willing to share? Just something that communicates with the car and I could expand upon by slowly learning the API? All I need is the ability to poll my Sense Energy Monitor and if there is extra Solar Production turn charging on in the car when the production wanes, turn it back off. But no one has made such an app yet. Guess it's up to me.

Thx.
If you need a hand with that, let me know. I've been on-again, off-again learning Swift for the last 6 months... I've got some algorithms running to get the car to charge when wind predominates on the grid. But it would be handier to put some of those thresholds/triggers into an iPhone or iPad.
 
That sounds cool. Have you thought about doing it with Node.JS on a Raspberry Pi? That way your Pi could set at home and monitor everything unattended.
Perhaps I don't know enough about this but I do know that there are unofficial APIs for both Teslas and the Sense Energy Monitor that I expect to use to tell me when there is spare production. Not sure I would know how to access an API or even begin to program a Pi, but with Swift on XCode which is likely what others writing Tesla apps are using I could get a jumpstart on accessing the car and then eventually pick up the API for Sense.

I already have my old iPhone 5 running the Sense app, so putting my app on that phone would be a great way to see what it's doing, vs a pi that has no output device or lights
 
Has anyone managed to schedule a software update via the API?
In my case the
{ "offset_sec" : 300 }
parameter is not recognized. The update will always start 2 minutes after the API-call.

And the cancel of a scheduled software update (https://owner-api.teslamotors.com/api/1/vehicles/111111111111/command/cancel_software_update).
returned:
"The page you were looking for doesn't exist.
You may have mistyped the address or the page may have moved."

Any ideas?