Model S REST API

[dirkhh]

Did anyone else see a discontinuity in the charge_state.battery_level value during the first charge after FW v5.8?
timestamp battery_level battery_range
2013-11-17 06:46 44 76.49
2013-11-17 06:47 44 76.84
2013-11-17 06:48 44 77.19
2013-11-17 06:49 44 77.19
2013-11-17 06:50 44 77.89
2013-11-17 06:51 44 78.25
2013-11-17 06:52 49 78.6
2013-11-17 06:53 49 78.95
2013-11-17 06:54 49 79.3

This has resulted in a persistent reduction of 14 miles / 20 km in the displayed rated range for the same SOC compared to FW v4.5.

That is fascinating. I love our tools and how they show the algorithmic changes in the firmware...
It looks like they changed the way they calculate the SOC. I still wish they'd give us one decimal place in that data, instead of .6kWh or .85kWh increments...

 

[hans]

I learned a few new things while debugging my new 5.8 sleep friendly streaming code.

1) there are a few more values for the "state" field returned by /vehicles besides 'online' and 'asleep'. I saw 'waking' and 'unknown'. The 'unknown' state was common during sleep so I couldn't assume that a state == 'asleep' meant the car was sleeping. I ended up assuming that state != 'online' meant the car was asleep.

2) calling /vehicle_state seemed a more reliable way to reveal the current tokens and wake the car from the 'unknown' state. A few times calling /wake_up did not appear to wake the car but calling /vehicle_state did.

-- update --

Looks like I managed to get blocked by Tesla on both my home IP and my mobile hotspot IP address. I was so close to having a working program too. I was just chasing a final weird bug that thankfully showed itself because of a power failure during the night.

I set up the streaming app so that it monitors if the last two samples on any log poll of the streaming url returned "null" for the shift state, then I would put the app into "nap mode" which suppresses all streaming and REST calls to anything other than /vehicles.

Napping 20 minutes worked some times but not all the time. 30 minute naps always seemed to allow sleep to set in. Once the car is sleeping the polling will stop until it sees "online" in the REST /vehicles state field.

I added logic to avoid nap mode when the charge state was 'Charging'. I did this because the car never sleeps while charging and collecting data while charging is very useful so people wouldn't want 30 minute gaps in the telemetry while charging.

The only other enhancement I can think of is to monitor the car to see if it goes asleep and then wakes again before the end of the 30 minute nap time. That would happen if I are a short stop for a coffee or something. I figure if the car was asleep and then becomes online, it is safe to start polling for data again and skip the "nap".

 

[J in MN]

1) there are a few more values for the "state" field returned by /vehicles besides 'online' and 'asleep'. I saw 'waking' and 'unknown'. The 'unknown' state was common during sleep so I couldn't assume that a state == 'asleep' meant the car was sleeping. I ended up assuming that state != 'online' meant the car was asleep.

Confirmed, and I use the same approach.

2) calling /vehicle_state seemed a more reliable way to reveal the current tokens and wake the car from the 'unknown' state. A few times calling /wake_up did not appear to wake the car but calling /vehicle_state did.

I have not yet found a good use for /wake_up, and my code doesn't use it. Either /charge_state or /climate_state reliably starts sending tokens again.

I set up the streaming app so that it monitors if the last two samples on any log poll of the streaming url returned "null" for the shift state, then I would put the app into "nap mode" which suppresses all streaming and REST calls to anything other than /vehicles.

There are also other signs that the car is about to fall asleep. First charge_state.battery_heater_on, .charger_pilot_current, climate_state.fan_status, .is_auto_conditioning_on, .is_front_defroster_on, and .outside_temp disappear. And then .inside_temp will disappear.

The only other enhancement I can think of is to monitor the car to see if it goes asleep and then wakes again before the end of the 30 minute nap time. That would happen if I are a short stop for a coffee or something. I figure if the car was asleep and then becomes online, it is safe to start polling for data again and skip the "nap".

I poll /vehicles every 5 minutes while asleep (could be more often). If it shows online, start pulling the others.

 

[jackie]

Been trying to find out how to turn on front and rear defrosters. I have a very simple Java app which works for the commands I found documented. However searching this thread I find nothing about turn on the defrosting. Any ideas ? Thanks

 

[brianman]

Been trying to find out how to turn on front and rear defrosters. I have a very simple Java app which works for the commands I found documented. However searching this thread I find nothing about turn on the defrosting. Any ideas ? Thanks

So far nobody has uncovered (and reported here) anything in the REST API that directly relates to changing the state of defrosting in the car.

Note that most of what was discovered quickly was found via analyzing the Tesla-provided phone app's communication. As such, until/unless the Tesla apps gets updated and shows some new functionality, new capabilities will likely be discovered very slowly or not at all.

 

[brianman]

Definitely - that's how our REST calls can keep the car awake :-(

There are flavors of this:
1. Keeping the car awake by deterring it from sleeping with REST calls.
2. Waking the car up after its been put to "Energy Saver" sleep.

I haven't seen much discussion of #2 so I'm not certain you can do that with REST, though I suspect you can. For me, I keep the logger running and haven't updated it for 5.8 so I don't have a way of testing #2 (without disabling my logger).


That said, I'm certain Tesla can do it regardless of what the REST API allows.

 

[dirkhh]

There are flavors of this:
1. Keeping the car awake by deterring it from sleeping with REST calls.
2. Waking the car up after its been put to "Energy Saver" sleep.

I haven't seen much discussion of #2 so I'm not certain you can do that with REST, though I suspect you can. For me, I keep the logger running and haven't updated it for 5.8 so I don't have a way of testing #2 (without disabling my logger).


That said, I'm certain Tesla can do it regardless of what the REST API allows.

1. is still a bit of a challenge (as in "we are doing too much of it"). 2. Is fairly well understood. Log in, look for token, if car is asleep, call wake up.

 

[brianman]

1. is still a bit of a challenge (as in "we are doing too much of it"). 2. Is fairly well understood. Log in, look for token, if car is asleep, call wake up.

I haven't seen anyone report that they have done the following:
1. turn off all loggers
2. turn off all remote apps (VisibleTesla, phone apps, etc.),
3. enable Energy Saver
4. ensure that the key fob is "sufficient distance" from car
5. wait a day
6. send a request via REST API
7. walk to car without fob
8. look for signs that the car has awoken from Energy Saver sleep

I'm not talking "awake to REST", but rather "awake from Energy Saver". I'm also not saying that it won't work. I just haven't seen any thorough reporting on this subject. So I guess my point is that we're light on data here.

 

[dirkhh]

I haven't seen anyone report that they have done the following:
1. turn off all loggers
2. turn off all remote apps (VisibleTesla, phone apps, etc.),
3. enable Energy Saver
4. ensure that the key fob is "sufficient distance" from car
5. wait a day
6. send a request via REST API
7. walk to car without fob
8. look for signs that the car has awoken from Energy Saver sleep

I'm not talking "awake to REST", but rather "awake from Energy Saver". I'm also not saying that it won't work. I just haven't seen any thorough reporting on this subject. So I guess my point is that we're light on data here.

How would you do 8 without the fob? For me the difference is this (with fob): car is asleep, I open the door, instrument cluster boots (big T in the center). car is awake, I immediately see the "normal" screen on the instrument cluster.
And while I haven'd done #5 (I only waited 30 minutes), I can verify that the car goes to sleep, and I can verify that I can wake up the car as described above.
Case in point, I was able to have the car be asleep (as reported by the API) and then start the heat remotely via the API so the car was nice and warm when I got in this morning
This is with 5.8

 

[hans]

I haven't seen anyone report that they have done the following:
1. turn off all loggers
2. turn off all remote apps (VisibleTesla, phone apps, etc.),
3. enable Energy Saver
4. ensure that the key fob is "sufficient distance" from car
5. wait a day
6. send a request via REST API
7. walk to car without fob
8. look for signs that the car has awoken from Energy Saver sleep

I'm not talking "awake to REST", but rather "awake from Energy Saver". I'm also not saying that it won't work. I just haven't seen any thorough reporting on this subject. So I guess my point is that we're light on data here.

I have done most of this. I didn't do 7 & 8 but rather called /vehicles to see if "state" was changed from 'asleep' (or 'unknown') to 'waking' or 'online'. I did confirm with hours of polling /vehicles every minute that calling this REST call does not wake the car. If a car wakes after you call /vehicles it most likely to charge the 12V battery or some other normal waking function unrelated to your calling /vehicles

Calling /wake_up turned out to be the LEAST reliable way to wake up a sleeping car. Most of the time a car in 'unknown' state (which is really 'asleep' but for some reason Tesla can't see that because perhaps it's a deeper sleep) could not be revived by calling /wake_up.

Calling /vehicle_state, /climate_state, or /charge_state would ALWAYS wake a sleeping car, first by entering 'waking' state, and then soon after entering 'online' state in a few seconds time. Streaming tokens are always revealed after waking a car to 'online' state.

Streaming tokens can be present when a car is in 'asleep' state but polling the streaming URL will return HTTP 408 (timeout) with no data in the response body. Polling the streaming URL on a sleeping car does not wake the car.

 

[Kipernicus]

Looks like I managed to get blocked by Tesla on both my home IP and my mobile hotspot IP address.

Stunned at this statement, and nobody has talked about it! Did you regain access, hans?

 

[brianman]

Stunned at this statement, and nobody has talked about it! Did you regain access, hans?

Stunned why? We've had many reports of this when people have loggers, etc. being "aggressive" with rapid fire querying.

 

[apacheguy]

Just out of curiosity - why would TM block a specific IP address? If someone is logged in and is spamming the server, wouldn't they block the user? If someone is trying to brute force a password that would be different.

Is it a time controlled blacklist meaning that after 10-30 min (whatever the interval may be) you can log back in?

 

[brianman]

Just out of curiosity - why would TM block a specific IP address? If someone is logged in and is spamming the server, wouldn't they block the user? If someone is trying to brute force a password that would be different.

Is it a time controlled blacklist meaning that after 10-30 min (whatever the interval may be) you can log back in?

Both have their merits. I would expect any decent webserver software these days would have settings (and probably defaults for those settings) that go into self-protect mode if they detect abuse from a specific IP -- without requiring any human intervention.

Blocking on user id would require something more custom, and they might have that as well or might not.

Also, blocking on IP will be "gentle" to the user who has a "busted" desktop machine logger (blocking it) while letting the phone app of that same user through. Makes for a happier customer.


Some have discovered that after some time period (I forget the durations, but <= 24 hours) the ban goes away.

In some early (and egregious?) cases people have gotten emails (and/or phone calls?) from Tesla informing them of the issue.

 

[hans]

Stunned at this statement, and nobody has talked about it! Did you regain access, hans?

I did indeed regain access on both IP addresses. I had a bug in my code that caused too many requests so I think it's totally legit of Tesla to shut me down for the 12-24 hours that they did. My access just came back without me having to send an email or anything. I'm quite sure this is an automated task because I was shut down less than 20 seconds after I started flooding them with REST requests.

The block is also confirmed to be by IP address because I had a third internet connection that continued to work when the other two were blocked.

I knew I was blocked because REST calls to /vehicles returned "You have been blocked for making too many requests!".

Anyway, my debugging is done and I now have a working version of the teslams JavaScript streaming code that has been running for two days and allows the car to fall asleep as well as detects when the car wakes back up so it can start logging again.

 

[Kipernicus]

Stunned why? We've had many reports of this when people have loggers, etc. being "aggressive" with rapid fire querying.

oh, thanks to all of you for the explanations. I don't frequent this thread much and didn't know.

 

[araxara]

I don't know if anyone noticed, but there is a new iPhone app (V1.2) out. I checked the package contents of the app and it appears to have a bunch of new graphics such as the new wheels, including the Aero wheels (which don't display for me). The new app also makes an attempt in waking the car up when first started, which worked for my car, but took about 2 minutes. It also includes a slider for setting the charge limit.

 

[hans]

I don't know if anyone noticed, but there is a new iPhone app (V1.2) out. I checked the package contents of the app and it appears to have a bunch of new graphics such as the new wheels, including the Aero wheels (which don't display for me). The new app also makes an attempt in waking the car up when first started, which worked for my car, but took about 2 minutes. It also includes a slider for setting the charge limit.

So basically Tesla has almost caught up to what all the third party apps do ;-)

 

[araxara]

So basically Tesla has almost caught up to what all the third party apps do ;-)

I guess that my post was not to show how wonderful the Tesla software developers are, but to suggest that there may be some new API data going back and forth with the new app and thus enhancing the third party apps :biggrin:.

 

[gg_got_a_tesla]

The app update's discussed here:

Phone App: iPhone/Android app - Page 47