-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Model S REST API
- Thread starter timdorr
- Start date
-
- Tags
- Model S User Interface
It seems that Tesla Streaming API is used to access parameters like speed,odometer,soc,elevation,est_heading,est_lat,est_lng,power and shift_state. Now it seems Tesla fleet API provides all these parameters under vehicle_state and drive_state. So, should I still use Streaming API. Is there other purpose of Streaming API?
SG57
Former Vendor
@Pramithas , where did you get this information regarding the Fleet API?
There has always been some overlapping of served data between the streaming API and the other data request endpoints, the key difference is the streaming API provides these values in real-time. So if you're trying to track the location of your vehicle in real-time, you could use the drive_state data request endpoint or the streaming API to get the vehicle's current location, the latter being the preferred method.
There has always been some overlapping of served data between the streaming API and the other data request endpoints, the key difference is the streaming API provides these values in real-time. So if you're trying to track the location of your vehicle in real-time, you could use the drive_state data request endpoint or the streaming API to get the vehicle's current location, the latter being the preferred method.
Thank you for your feedback.
Do you have any link where can I get a sample data about how the response of Streaming API will look like? I do not have a real Tesla vehicle so I cannot make a call to Tesla API and see what the response looks like.
SG57
Former Vendor
@Pramithas , I can't seem to find any samples out there so here's a summary I wrote up real quick. The streaming API isn't anything fancy like summon and its web sockets, instead it's just a long-running GET request.
Where...
Where each row has comma-separated-values corresponding to the values you requested in the query parameter, values.
One thing to note, streaming tokens expire every 15 minutes on a universal timer I believe (or something extremely, noticeably short compared to the 45+ day expiration on the bearer token), so if you start receiving 401 unauthorized responses you should query the vehicle summary data to acquire the latest streaming token then try again.
Code:
Method:
GET
URL:
https://streaming.vn.teslamotors.com/stream/{VEHICLE_ID}/?values={VALUES}
Required Headers:
Authorization: Basic {STREAMING_TOKEN}Where...
- {VEHICLE_ID} - the value of the vehicle_id field found in the vehicle summary data - note this is not to be confused with the id (or id_s) field also found in the vehicle summary data
- {VALUES} - a comma-separated value string of the telemetry data you want to retrieve in real-time. The full list, that we know of, is this:
speed,odometer,soc,elevation,est_heading,est_lat,est_lng,power,shift_state,est_range
- {STREAMING_TOKEN} - base-64 encoded string of the 1st of the 2 streaming tokens provided to you in the vehicle summary data in the tokens field
Code:
1502820003896,0,10152.7,97,605,348,47.686585,-117.233318,1,R,196
1502820007396,0,10152.7,97,605,348,47.686584,-117.233318,1,R,196
1502820008896,1,10152.7,97,605,347,47.686582,-117.233317,1,R,196
1502820009396,1,10152.7,97,605,355,47.686580,-117.233317,1,R,196
1502820010896,1,10152.7,97,605,355,47.686570,-117.233316,1,P,196
1502820011396,0,10152.7,97,605,355,47.686569,-117.233316,1,P,196
1502820012896,0,10152.7,97,605,355,47.686569,-117.233317,0,P,196
1502820243159,,10152.7,97,605,355,47.686569,-117.233317,0,,196Where each row has comma-separated-values corresponding to the values you requested in the query parameter, values.
One thing to note, streaming tokens expire every 15 minutes on a universal timer I believe (or something extremely, noticeably short compared to the 45+ day expiration on the bearer token), so if you start receiving 401 unauthorized responses you should query the vehicle summary data to acquire the latest streaming token then try again.
Last edited:
Wow... Thank you very much for compiling this information.. It is very helpful for me.
So the flow for calling a streaming API is like:
(1) Authenticate to Tesla Server via normal rest api (not streaming API)
(2) Once authorized, call the normal rest api again to get vehicle summary data
(3) Use first token out of two token authenticating the streaming API
My another question is, do you mean to say that Tesla Streaming API is not like Twitter Streaming API in which new data is automatically pushed by the server to the client. But it is only get request carried out for a long time?
Thank you very much once again for your response. Have a great day !!
Ulmo
Active Member
I'm still on a quest to get more interaction with my PowerWalls.
I started poking around with the script wk057 gave to get a token, and with Tesla Model S JSON API · Apiary.
I got my token with POST httdps://owner-api.teslamodtors.com/oaduth/token per the wk057 script which matched Tim Dorr's doc, then got it to list the vehicles with GET httpds://owner-adpi.teslamotdors.com/api/1/vehicles, whereupon it only listed the Model S I sold (and the new owner has since yet failed to get Tesla to update the records -- I expect that any day now, possibly this week). I then tried the following to no avail:
...api/1/ with the following words: batteries, battery, powerwalls, powerwall, pw, teslastorage
and nothing came up. Then I remembered that in the list at one time months or years ago, Tesla referred to the Home page as "Products". Bingo: (Take out the errant "d"'s)
Now, any clues as to how I drill down deeper into that so I don't get a clutter of cars, roofs, solar panels, and other products in my output? I'd like to just know more about my PowerWall installation.
Some decoding of the PowerWall data:
Specs on my PowerWall 2's are 13.2kW each, so 13,200 watts each, and 26,400 watts for both. Right now, the app shows 43% state of charge, discharging. 43% of 28,116 is 12,089.88; 42% is 11,808.72 and 44% is 12,371.04. Each 1% is 281.16. It just dropped to 42%, so I took another reading, and now it shows energy_left at 11984 and total_pack_energy remains the same. 11984/28116=.42623417. I don't know what type of rounding they use. 12312/28116=.43790013. Now the energy_left is 11,873, which is .42228624. It seems that these correspond to the energy in the pack. There is some sort of odd discrepancy between the specifications of 13,200 watts each battery and the above 28,116 watts for both of them when 13,200*2=26,400.
battery_power is currently coming back with 1210 or 1270, and one of my most recent readings from the gateway using the gateway LAN public api is also 1210, 1270, and a few others. Those seem to match as watts flowing from the pack as a whole (both added together).
Now, I'm going to decode id, site_name, and key.
Using the data the installer entered on page 57 of the manual, I decode that the key is composed of the following listed for my Gateway:
Product--Serial
The Product is a number of the format nnnnnnn-00-E, where nnn are digits.
The Serial is of the format T17Fnnnnnnn, where nnnn are digits.
They perfectly match what I have for my Gateway product and serial numbers written in my manual, with two dashes between the two numbers.
On to the site_name: that is listed simply as "Home Energy Gateway", since that is what it is. Imagine that. I don't know what purpose that string holds.
Finally, the "id" is some letters, a date (not my install date), a dash and a count. This is probably a number for Tesla to identify this site in their database.
I am not having any other luck figuring out ways to access more API. Any suggestions how to sniff this one out? Is there an emulator I can place on my Mac for an Android phone, root the emulator, and go about it like that somehow?
One of my main goals, to collect actual state of charge % for my PowerWall installation, has now been answered, via the API pulled from the cloud servers at Tesla, rather than directly from my gateway. I'd like the data direct from my gateway on the LAN without having to go via the Tesla corporate servers, but I don't know what request to give it.
I started poking around with the script wk057 gave to get a token, and with Tesla Model S JSON API · Apiary.
I got my token with POST httdps://owner-api.teslamodtors.com/oaduth/token per the wk057 script which matched Tim Dorr's doc, then got it to list the vehicles with GET httpds://owner-adpi.teslamotdors.com/api/1/vehicles, whereupon it only listed the Model S I sold (and the new owner has since yet failed to get Tesla to update the records -- I expect that any day now, possibly this week). I then tried the following to no avail:
...api/1/ with the following words: batteries, battery, powerwalls, powerwall, pw, teslastorage
and nothing came up. Then I remembered that in the list at one time months or years ago, Tesla referred to the Home page as "Products". Bingo: (Take out the errant "d"'s)
Code:
Olorin-2:Shell ulmo$ curl -s -H "`cat header`" -X GET 'dhttps://owner-api.dteslamotors.dcom/api/1/products' |json_pp -f json -t dumper
$VAR1 = {
'count' => 2,
'response' => [
{
'notifications_enabled' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),
'vin' => '5YJSA1E25GF1nunya',
'state' => 'online',
'option_codes' => 'MDLS,RENA,AF02,APF0,APH2,APPA,AU01,BC0B,BP00,BR03,BS00,BX60,CDM0,CH05,PBCW,CW00,DCF0,DRLH,DSH7,DV4W,FG02,FR03,HP00,IDBA,IX01,LP01,ME02,MI01,PF00,PI01,PK00,PS01,PX00,QPBT,RFBC,SC01,SP00,SR01,SU00,TM00,TP03,TR00,UTAW,WTAS,X001,X003,X007,X011,X014,X021,X025,X027,X028,X031,X037,X040,X044,YFFC,BTX5,COUS',
'color' => undef,
'backseat_token_updated_at' => undef,
'id_s' => 'numnunya',
'in_service' => bless( do{\(my $o = 0)}, 'JSON::PP::Boolean' ),
'remote_start_enabled' => $VAR1->{'response'}[0]{'notifications_enabled'},
'id' => 'numnunya',
'tokens' => [
'hexnunya',
'hexnunya'
],
'display_name' => 'serialnunya',
'calendar_enabled' => $VAR1->{'response'}[0]{'notifications_enabled'},
'vehicle_id' => numnunya,
'user_id' => numnunya,
'backseat_token' => undef
},
{
'energy_left' => 12312,
'total_pack_energy' => 28116,
'id' => 'nunya',
'site_name' => 'Home Energy Gateway',
'key' => 'nunya',
'battery_power' => 1270
}
]
};
Olorin-2:Shell ulmo$Now, any clues as to how I drill down deeper into that so I don't get a clutter of cars, roofs, solar panels, and other products in my output? I'd like to just know more about my PowerWall installation.
Some decoding of the PowerWall data:
Specs on my PowerWall 2's are 13.2kW each, so 13,200 watts each, and 26,400 watts for both. Right now, the app shows 43% state of charge, discharging. 43% of 28,116 is 12,089.88; 42% is 11,808.72 and 44% is 12,371.04. Each 1% is 281.16. It just dropped to 42%, so I took another reading, and now it shows energy_left at 11984 and total_pack_energy remains the same. 11984/28116=.42623417. I don't know what type of rounding they use. 12312/28116=.43790013. Now the energy_left is 11,873, which is .42228624. It seems that these correspond to the energy in the pack. There is some sort of odd discrepancy between the specifications of 13,200 watts each battery and the above 28,116 watts for both of them when 13,200*2=26,400.
battery_power is currently coming back with 1210 or 1270, and one of my most recent readings from the gateway using the gateway LAN public api is also 1210, 1270, and a few others. Those seem to match as watts flowing from the pack as a whole (both added together).
Now, I'm going to decode id, site_name, and key.
Using the data the installer entered on page 57 of the manual, I decode that the key is composed of the following listed for my Gateway:
Product--Serial
The Product is a number of the format nnnnnnn-00-E, where nnn are digits.
The Serial is of the format T17Fnnnnnnn, where nnnn are digits.
They perfectly match what I have for my Gateway product and serial numbers written in my manual, with two dashes between the two numbers.
On to the site_name: that is listed simply as "Home Energy Gateway", since that is what it is. Imagine that. I don't know what purpose that string holds.
Finally, the "id" is some letters, a date (not my install date), a dash and a count. This is probably a number for Tesla to identify this site in their database.
I am not having any other luck figuring out ways to access more API. Any suggestions how to sniff this one out? Is there an emulator I can place on my Mac for an Android phone, root the emulator, and go about it like that somehow?
One of my main goals, to collect actual state of charge % for my PowerWall installation, has now been answered, via the API pulled from the cloud servers at Tesla, rather than directly from my gateway. I'd like the data direct from my gateway on the LAN without having to go via the Tesla corporate servers, but I don't know what request to give it.
Last edited:
robertvg
Extremely Well-Known Member
Does anybody have an idea if Tesla uses the same endpoint for the Model 3 cars ?
And if the smartphone app is the same one as used for the MS/MX ?
And if the smartphone app is the same one as used for the MS/MX ?
SG57
Former Vendor
@robertvg , given so few actual Model 3s out in the wild it'll be hard to verify this for awhile. More likely than not the APIs work on a model 3 as-is. Given the amount of work it would require building out new APIs just for the new model 3 and the fact the current APIs already support different models (S, X), I don't foresee any new APIs coming out with the model 3. I don't think the official Tesla app has added model 3 graphics yet either, that's likely the next app update from Tesla.
Ulmo
Active Member
Today I had trouble pulling in a new user token using scripts, but I was able to get one on TeslaFi. Anybody else having this problem?
For the longest time, my MyTesla username was "Ulmo" (no email address), but I finally threw in the bag, because I suspected that someone's trying to hack my account, so I wanted to wash the account of all old usernames, and I put in a fresh username (yes, a new email address). Hopefully this cures the permanent status I get of the account having "too many login attempts" ever since the new owner of my prior Model S had his account updated to move the car over to his MyTesla. I don't know what's triggering it; is it my script to read battery state every 1 minute? TeslaFi ran every minute back when I had a car and yet they seem to have no problem. (I turned off TeslaFi logging.) I just deleted my EV-FW.COM records to try to see if that helps (it annoyingly kept updating even though I tried to make it stop). Maybe the new owner has VisibleTesla in a background screen on his work computer and never updated it, and it keeps hammering my auth on my old username (I temporarily let him have access to my MyTesla so that he could fully use his car while the government dragged its feet on old fashioned paperwork; they're half a century behind technologically.) Ghosts in the machine. Of course, Tesla doesn't give us any view into logs of our own data, since they're not very forward thinking (my latest theory is that Tesla is a 1980s company that seems modern to us compared to the 1920s companies it's replacing).
For the longest time, my MyTesla username was "Ulmo" (no email address), but I finally threw in the bag, because I suspected that someone's trying to hack my account, so I wanted to wash the account of all old usernames, and I put in a fresh username (yes, a new email address). Hopefully this cures the permanent status I get of the account having "too many login attempts" ever since the new owner of my prior Model S had his account updated to move the car over to his MyTesla. I don't know what's triggering it; is it my script to read battery state every 1 minute? TeslaFi ran every minute back when I had a car and yet they seem to have no problem. (I turned off TeslaFi logging.) I just deleted my EV-FW.COM records to try to see if that helps (it annoyingly kept updating even though I tried to make it stop). Maybe the new owner has VisibleTesla in a background screen on his work computer and never updated it, and it keeps hammering my auth on my old username (I temporarily let him have access to my MyTesla so that he could fully use his car while the government dragged its feet on old fashioned paperwork; they're half a century behind technologically.) Ghosts in the machine. Of course, Tesla doesn't give us any view into logs of our own data, since they're not very forward thinking (my latest theory is that Tesla is a 1980s company that seems modern to us compared to the 1920s companies it's replacing).
Via the streaming API.
Try this:
Code:curl --user USERNAME:TOKEN https://streaming.vn.teslamotors.com/stream/VEHICLE_ID/?values=speed,odometer,soc,elevation,est_heading,est_lat,est_lng,power,shift_state
where USERNAME is your MyTesla username, TOKEN is the first token returned in your vehicle's JSON returned from the REST API, VEHICLE_ID is the "vehicle_id" returned in vehicle's JSON. The TOKEN value rotates every few minutes, so you will need to query your vehicle's JSON description before opening a new stream.
Fields are returned as a comma separated list of values matching the field references in the URL query string. The first field is a timestamp.
Now run that curl command, then hop in your vehicle and drive around for a while, and watch it stream.
For those that use Ruby, I've already developed a ruby gem that supports both the rest and streaming APIs as well as a high-level Vehicle Object API. I'll release a public version by the end of the month, just need some time to clean it up a little (and I'm traveling quite a bit this month). Here's some sample code (from my twitter client) using the API:
Code:portal = Teslamatic::API::Portal.new(config[:username], config[:password]) vehicles = Teslamatic::Vehicle.vehicles(portal) vehicle = vehicles.first current_gear = vehicle.gear_selector current_odometer = vehicle.odometer
Hello,
I was curious to know whether all the information that can be obtained from Tesla Fleet API can be fetched through Tesla Streaming API as well. For example I need to get access to information about "charge_port_door_open" which as far as I know can be obtained from fleet API under "charge state". When I tried to query it through Streaming API the response was empty. So I think streaming API does not support this parameter.
Does anyone have idea about this? Can one only query limited number of parameters through Streaming API? What are the total parameters that can be queried from streaming API?
Thank You.
Ulmo
Active Member
I somehow missed your post. (12 hour workdays ...) Currently, there is no interaction between PowerWalls and vehicles (although many of us wish that would change). These are the parameters I see so far:
Code:
function m(e) {
var t = e.mode,
n = e.backupReserve,
r = e.generationLimit,
o = e.solarLimit,
a = e.batteryLimit;
return "string" == typeof r && (r = parseFloat(r)),
"string" == typeof o && (o = parseFloat(o)), "string" == typeof a && (a = parseFloat(a)),
function(e) {
e(j()), e((0, S.clearError)(R.RECEIVE_SAVE_OPERATION_SETTINGS_ERROR));
var i = {
backup_reserve_percent: n,
max_pv_export_power_kW: o
};
return t && (i.mode = t), fetch(k.default.api.uri + "/operation", {
method: "POST",
credentials: "same-origin",
headers: {
"Content-Type": "application/json"
},
body: (0, T.default)(i)
}).then(D.parseText).then(D.parseResponseText).then(D.checkResponseStatus).then(function(i) {
e(s({
mode: t,
backupReserve: n,
generationLimit: r,
solarLimit: o,
batteryLimit: a
}))
}).catch(function(t) {
e((0, S.showError)(R.RECEIVE_SAVE_OPERATION_SETTINGS_ERROR, t.toString(), t.response)), e(H())
})
}
}This is the current "incomplete" software (firmware), and soon, Tesla is supposed to push out more complete software, which I hope replaces most of this, so this will probably all change. I hope they don't reduce its capabilities or take away our control and/or view into what it's doing; their app information is pretty insufficient for any home energy budget analysis.
Damn. My alarm just went off. Time to get on the road.
Your best bet is to just parse out those fields when you get the response blob from the API
Ulmo
Active Member
That's exactly what I did with the above; I found the id or key (I forget which) which was the unique identifier, and discarded the rest of the entries. Then, I used those variables. I got everything working great grabbing the correct piece of data when there are multiple live products. A few days later, my prior car disappeared, and yet everything continued working great.
HankLloydRight
No Roads
Hi,
I am hoping someone can confirm this for me. I have a Model X on order and have the VIN already. When attempting to call the /oath/token to get the token (using all the required JSON-structured parameters in the http body) I get an authorization failure. At this point, I suspect that I simply cannot get a token yet because the car is in production (due end of September / Early October).
Does anyone know if that's a correct conclusion? Namely, that you cannot get a token before the car reaches a certain stage of production (or even delivery)?
Thanks.
I am hoping someone can confirm this for me. I have a Model X on order and have the VIN already. When attempting to call the /oath/token to get the token (using all the required JSON-structured parameters in the http body) I get an authorization failure. At this point, I suspect that I simply cannot get a token yet because the car is in production (due end of September / Early October).
Does anyone know if that's a correct conclusion? Namely, that you cannot get a token before the car reaches a certain stage of production (or even delivery)?
Thanks.
nico180
creating simple things - is true talent
Similar threads
