Model S REST API

[Gesteur]

The streaming script is what determines whether the car is active and should be polled. It uses the websocket streaming API. It has proved to be an extremely reliable way to prevent my polling script from keeping my car awake, but it doesn’t work reliably on all cars.

My experience with streaming is that it keeps the car awake.

I use the vehicle endpoint to determine the status of the car (online, offline, asleep) . That endpoint doesn't wake the car up nor keeps it awake, because it queries the tesla servers only without getting a response from the car.

The other endpoints will return an error if the car is asleep.

 

[John Rucker]

The streaming script is what determines whether the car is active and should be polled. It uses the websocket streaming API. It has proved to be an extremely reliable way to prevent my polling script from keeping my car awake, but it doesn’t work reliably on all cars.

Ahh interesting. Are you using the streaming endpoint https://streaming.vn.teslamotors.com that returns speed, odometer, soc, elevation, est_heading, est_lat, est_lng, power, shift_state, range, est_range, heading? How do you use it to determine if the car would like to sleep? Does the car simply stop sending the stream when it sleeps? If that happens do you get an error or do you just detect the lack of data?

Wonder why it is not reliable on all cars??

I have a pretty reliable solution now by just polling. But I'm concerned it is going to require constant maintenance as Tesla updates the vehicle’s firmware. I also fear I’m going to run into problems when I run it against different vehicles with various CPUs. Always looking to improve!!

 

[markb1]

My experience with streaming is that it keeps the car awake.

I use the vehicle endpoint to determine the status of the car (online, offline, asleep) . That endpoint doesn't wake the car up nor keeps it awake, because it queries the tesla servers only without getting a response from the car.

The other endpoints will return an error if the car is asleep.

I haven't observed the streaming API keeping the car awake, but my testing has mostly been with V8. In my brief testing with V10, I also haven't observed the streaming API keeping the car awake, but the car just wakes up around 4:40am and stays away everyday, whether or not I'm using the streaming API.

But, yes, the REST API endpoints, other than the vehicle list, do keep the car awake.

 

[markb1]

Ahh interesting. Are you using the streaming endpoint https://streaming.vn.teslamotors.com that returns speed, odometer, soc, elevation, est_heading, est_lat, est_lng, power, shift_state, range, est_range, heading? How do you use it to determine if the car would like to sleep? Does the car simply stop sending the stream when it sleeps? If that happens do you get an error or do you just detect the lack of data?

Wonder why it is not reliable on all cars??

I have a pretty reliable solution now by just polling. But I'm concerned it is going to require constant maintenance as Tesla updates the vehicle’s firmware. I also fear I’m going to run into problems when I run it against different vehicles with various CPUs. Always looking to improve!!

Yes, that's the one. I'm not using it to determine when the car wants to sleep. I do not try to determine that. I simply use it to determine when the car is either driving or charging, and then I poll the REST API until the car is no longer driving or charging. Since I never poll the car when it is sitting idle, it has plenty of time to go to sleep.

I'm not sure why it doesn't work on all cars. I tested it on a friend's Model 3, and streaming sometimes works, but more often, does not.

 

[John Rucker]

Yes, that's the one. I'm not using it to determine when the car wants to sleep. I do not try to determine that. I simply use it to determine when the car is either driving or charging, and then I poll the REST API until the car is no longer driving or charging. Since I never poll the car when it is sitting idle, it has plenty of time to go to sleep.

I'm not sure why it doesn't work on all cars. I tested it on a friend's Model 3, and streaming sometimes works, but more often, does not.

Okay If I'm falling correctly, your logic looks like this:
Your app reads the https://owner-api.teslamotors.com/api/1/vehicles/:id end point and checks the state property. If state = online then start streaming to see if the car is driving or charging. At this point don't you keep the car from sleeping as long as the stream is connected? Maybe your app monitors the stream for a period of time and disconnects it if the vehicle is not charging or driving?

Thanks for the info. Good stuff!!

 

[markb1]

Okay If I'm falling correctly, your logic looks like this:
Your app reads the https://owner-api.teslamotors.com/api/1/vehicles/:id end point and checks the state property. If state = online then start streaming to see if the car is driving or charging. At this point don't you keep the car from sleeping as long as the stream is connected? Maybe your app monitors the stream for a period of time and disconnects it if the vehicle is not charging or driving?

Thanks for the info. Good stuff!!

Not exactly. I stay connected to the streaming API continuously, 24/7. It doesn't seem to affect when the car goes to sleep or wakes up. I poll https://owner-api.teslamotors.com/api/1/vehicles to keep the streaming tokens updated and to log the vehicle state, though I don't use that vehicle state for anything. If the streaming data indicates that the car is driving or charging (negative power) I start polling https://owner-api.teslamotors.com/api/1/vehicles/<id>/data, and then I stop when neither of those conditions are still true.

 

[John Rucker]

Not exactly. I stay connected to the streaming API continuously, 24/7. It doesn't seem to affect when the car goes to sleep or wakes up. I poll https://owner-api.teslamotors.com/api/1/vehicles to keep the streaming tokens updated and to log the vehicle state, though I don't use that vehicle state for anything. If the streaming data indicates that the car is driving or charging (negative power) I start polling https://owner-api.teslamotors.com/api/1/vehicles/<id>/data, and then I stop when neither of those conditions are still true.

That sounds like a clean straightforward solution. I'm going to have to give it a try next time I have trouble with my current process. I wonder why your streaming solution is not reliable across multiple vehicles? I also wonder why some people say polling keeps their car from sleeping? I'm going to just have to dig in and do some testing. My current app tracks the sleep time and on days we don't drive the car it easily sleeps 85% to 95% of the time (unless there was a recent firmware update).

My poller logic allows me to run it concurrently on multiple hosts pointed at the same vehicle. I'm getting the 85% to 95% sleep (over 24 hours) with two pollers running on completely independent hardware against my model X. To do this I have to sync up the pollers based on time. Once they are in sync they will then let the vehicle sleep. The time sync process can take up to 10 minutes (max). On the other hand If I could just use a stream on each host to see when the car is charging and not worry about keeping the car awake that would be much cleaner!! I Wonder what kind of network traffic the stream generates vs a one minute poll cycle. Since it is a web socket I would imagine the stream is more efficient??

 

[israndy]

So if I have more than one app that accesses the Tesla will they get out of sync and NOT allow the car to sleep? I am using TezLab and Stats and Tesla Remote. Plus I am going to have to learn how to program my own app that will cycle the charging of the car off and on based on how much unused power is being generated by my solar panels. I am using the Sense Energy Monitor which also has an unpublished API that I can get those numbers from.

Kinda surprised no one else has written such an app.

 

[KlokkProjects]

Does anyone know whether the Tesla API endpoints are the same in China?

 

[John Rucker]

So if I have more than one app that accesses the Tesla will they get out of sync and NOT allow the car to sleep? I am using TezLab and Stats and Tesla Remote. Plus I am going to have to learn how to program my own app that will cycle the charging of the car off and on based on how much unused power is being generated by my solar panels. I am using the Sense Energy Monitor which also has an unpublished API that I can get those numbers from.

It is going to depend on how often your 3rd party apps poll your vehicle's data endpoints and on what schedule. The 3rd party apps that I have seen have a sleep setting (determines how aggressive they are at keeping the CPU on-line). I'm betting there is no coordination between the various apps.

 

[nightowl]

Regarding "id" vs "id_s" in the JSON data:

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

This caught me out when I was poking around with the APIs.

If using an ECMAScript-based language (such as Node), it's due to how big the number is. For example, this:
console.log(58318403984667471);
console.log(58318403984667474);
console.log(58318403984667477);
console.log(58318403984667479);

...outputs:
58318403984667470
58318403984667470
58318403984667480
58318403984667480

The constant Number.MAX_SAFE_INTEGER indicates the maximum integer value that can be stored:
9007199254740991

Anything above this will lose precision, which might not be much of a problem for a simple measurement for example, but for something that needs to be an exact value, it's obviously not much good.

 

[HankLloydRight]

I don't think that's the problem. I'm using PHP to access the API and all the values are stored as strings. No numerical overflow, truncation, or rounding here. Yet {id} and {id_s} are still different values. And only using {id_s} in the API calls will work.

 

[NorfolkMustard]

I don't think that's the problem. I'm using PHP to access the API and all the values are stored as strings. No numerical overflow, truncation, or rounding here. Yet {id} and {id_s} are still different values. And only using {id_s} in the API calls will work.

using the JSON_BIGINT_AS_STRING option in json_decode() ?

 

[markb1]

using the JSON_BIGINT_AS_STRING option in json_decode() ?

It doesn't matter. The id_s field is a string, so no conversion necessary. The id field is number, but for some people, it just doesn't match id_s. It's easy to see by simply looking at the raw JSON.

 

[HankLloydRight]

It also doesn't matter in Javascript (in Chrome):

My Tampermonkey script that runs on Tesla's own domain to get the API token without sharing credentials to any third party (see: Telsa_API_Safe_Tools_Token_Generator,_API_Query_Tool) loads the JSON directly and both {id} and {id_s} display properly when sent to the console.

        $.each(json["response"], function(i, car) {
                    console.log(car["id"]);
                   console.log(car["id_s"]);
        });

returns (blurred for privacy):

 

[HankLloydRight]

using the JSON_BIGINT_AS_STRING option in json_decode() ?

I just checked my PHP code and nope, just using json_decode with no options.

 

[HankLloydRight]

But looking at the raw JSON again, perhaps the real problem is on the API server side doing the rounding of {id} and sending that in error, which is why only {id_s} as a string works.

 

[John Rucker]

I have created a wall gauge that shows the estimated cost of my vehicle's last home charge. The Pic below is from last nights charge process. It is showing an estimated cost of $7.75 for yesterday’s driving. I get the cost information from the response.charge_energy_added value. This is the amount of DC kilowatt hours it took to charge the battery. Once I have the kWh it is a simple matter of multiplying it by my home kWh cost of 13 cents to get the charge cost.

The gauge works great. In the morning we can see the cost of yesterday’s drive. However, this is not the true cost. If I understand things correctly the response.charge_eneregy_added value is only the DC current (after it has been rectified by the car’s charger) and doesn’t take into account the rectification process or any power it takes to manage the batteries temp during charge. My question is this. Does anyone have a feel or a guideline for the efficiency of the charge process? I would like to add that to my cost estimate for my gauge.

 

[HankLloydRight]

It’s probably easier and more accurate to just use an AC watt meter to measure the total power going into the wall charger. There are lots of different ways to do this depending on your setup.

 

[BigD0g]

Anyone had issues getting oauth tokens today?