Model S REST API

[aviators99]

Temp differences between charge completion time and subsequent SOC reading?

I note a bit of a range difference for a given SOC depending on temp. If the pack was colder when charging and then subsequently warmed up, might it read at a higher SOC?

No, I don't think so (physics-wise). I *could* see the SOC going down if it got colder overnight, but not up under any circumstances. I think there is a bug somewhere that is not stopping it at the right place.

I will monitor it through the whole charging and beyond, tonight.

 

[scaesare]

No, I don't think so (physics-wise). I *could* see the SOC going down if it got colder overnight, but not up under any circumstances. I think there is a bug somewhere that is not stopping it at the right place.

I will monitor it through the whole charging and beyond, tonight.

How is SOC determined though? At rest, the only metric the BMS can directly measure is voltage, correct?

Towards the end of the charge cycle, the charger is typically operating in a constant-voltage mode. Because a Li Ion cell has not only an internal resistance as ell as some capacitive component, the internal voltage of the cell will be some degree lower than the actual charge voltage applied.

Once the charge terminates, the cell voltage tends to "settle" somewhat. Thus for a given target SOC, the BMS has to estimate when to terminate. Temperature has a definite impact on a Li Ion cell, so is it possible for the cell voltage to not "settle" as much if the temp is rising, and thus the final SOC end up higher than the BMS anticipated?

 

[aviators99]

How is SOC determined though? At rest, the only metric the BMS can directly measure is voltage, correct?

Towards the end of the charge cycle, the charger is typically operating in a constant-voltage mode. Because a Li Ion cell has not only an internal resistance as ell as some capacitive component, the internal voltage of the cell will be some degree lower than the actual charge voltage applied.

Once the charge terminates, the cell voltage tends to "settle" somewhat. Thus for a given target SOC, the BMS has to estimate when to terminate. Temperature has a definite impact on a Li Ion cell, so is it possible for the cell voltage to not "settle" as much if the temp is rising, and thus the final SOC end up higher than the BMS anticipated?

Are you suggesting a change in the algorithm to account for the fact that the voltage is actually lower, so it intentionally stops later? If not, I'm not sure what you're saying, in a practical sense. In any case, my monitoring overnight had a "quantum" effect, in that it didn't go over. It's probably because the car could not go to sleep, which *could* be a clue as to why this is happening. However, there was some weirdness as it was losing its charge:

There are a bunch of entries like this (back and forth, almost every 60 seconds, for a while):

{"charging_state":"Complete","charge_limit_soc":90,"charge_limit_soc_std":90,"charge_limit_soc_min":50,"charge_limit_soc_max":100,"charge_to_max_range":false,"battery_heater_on":false,"not_enough_power_to_heat":false,"max_range_charge_counter":0,"fast_charger_present":false,"fast_charger_type":"<invalid>","battery_range":227.99,"est_battery_range":241.06,"ideal_battery_range":263.76,"battery_level":88,"usable_battery_level":88,"battery_current":-0.6,"charge_energy_added":38.52,"charge_miles_added_rated":130.5,"charge_miles_added_ideal":151.0,"charger_voltage":0,"charger_pilot_current":80,"charger_actual_current":0,"charger_power":0,"time_to_full_charge":0.0,"charge_rate":0.0,"charge_port_door_open":true,"motorized_charge_port":false,"scheduled_charging_start_time":1414207800,"scheduled_charging_pending":false,"user_charge_enable_request":null,"charge_enable_request":false,"eu_vehicle":false,"charger_phas\
es":null}

{"charging_state":"Complete","charge_limit_soc":90,"charge_limit_soc_std":90,"charge_limit_soc_min":50,"charge_limit_soc_max":100,"charge_to_max_range":false,"battery_heater_on":false,"not_enough_power_to_heat":false,"max_range_charge_counter":0,"fast_charger_present":false,"fast_charger_type":"<invalid>","battery_range":227.99,"est_battery_range":241.06,"ideal_battery_range":263.76,"battery_level":89,"usable_battery_level":89,"battery_current":-0.5,"charge_energy_added":38.52,"charge_miles_added_rated":130.5,"charge_miles_added_ideal":151.0,"charger_voltage":0,"charger_pilot_current":80,"charger_actual_current":0,"charger_power":0,"time_to_full_charge":0.0,"charge_rate":0.0,"charge_port_door_open":true,"motorized_charge_port":false,"scheduled_charging_start_time":1414207800,"scheduled_charging_pending":false,"user_charge_enable_request":null,"charge_enable_request":false,"eu_vehicle":false,"charger_phases":null}

{"charging_state":"Complete","charge_limit_soc":90,"charge_limit_soc_std":90,"charge_limit_soc_min":50,"charge_limit_soc_max":100,"charge_to_max_range":false,"battery_heater_on":false,"not_enough_power_to_heat":false,"max_range_charge_counter":0,"fast_charger_present":false,"fast_charger_type":"<invalid>","battery_range":227.99,"est_battery_range":241.06,"ideal_battery_range":263.76,"battery_level":88,"usable_battery_level":88,"battery_current":-0.6,"charge_energy_added":38.52,"charge_miles_added_rated":130.5,"charge_miles_added_ideal":151.0,"charger_voltage":0,"charger_pilot_current":80,"charger_actual_current":0,"charger_power":0,"time_to_full_charge":0.0,"charge_rate":0.0,"charge_port_door_open":true,"motorized_charge_port":false,"scheduled_charging_start_time":1414207800,"scheduled_charging_pending":false,"user_charge_enable_request":null,"charge_enable_request":false,"eu_vehicle":false,"charger_phases":null}

 

[scaesare]

Are you suggesting a change in the algorithm to account for the fact that the voltage is actually lower, so it intentionally stops later? If not, I'm not sure what you're saying, in a practical sense.

Well, I'm thinking out loud here... but my general point is that voltage is the only actual measurement that can take place at rest, correct?

And we know that cells are impacted by temp. We also know that the the cell voltage typically fluctuates downward after charging terminates.

I'm not suggesting a change in the algorithm, but rather that the algorithm all along may anticipate that downward fluctuation, and if it's less than anticipated after charge termination (due to temp) you might end up finding a higher SOC than anticipated...

(This begs another question: how is battery voltage measured while charging? knowing that the charger is in constant-voltage mode, you can't take the measurement while charging is active, otherwise you measure the charger voltage, not the battery voltage. Does the charger pulse off briefly for a voltage measurement then resume? If so, how often? Or is it strictly monitoring current at this time?)

 

[aviators99]

Well, I'm thinking out loud here... but my general point is that voltage is the only actual measurement that can take place at rest, correct?

And we know that cells are impacted by temp. We also know that the the cell voltage typically fluctuates downward after charging terminates.

I'm not suggesting a change in the algorithm, but rather that the algorithm all along may anticipate that downward fluctuation, and if it's less than anticipated after charge termination (due to temp) you might end up finding a higher SOC than anticipated...

(This begs another question: how is battery voltage measured while charging? knowing that the charger is in constant-voltage mode, you can't take the measurement while charging is active, otherwise you measure the charger voltage, not the battery voltage. Does the charger pulse off briefly for a voltage measurement then resume? If so, how often? Or is it strictly monitoring current at this time?)

Yes. Interesting question. But don't my logs from last night point the cause more likely being related to a straight bug? Note that the rated range is unchanged, but the percent SOC keeps changing. One would think that the rated range would be linearly related to the SOC, no?

 

[kwenix]

https://portal.vn.teslamotors.com/ is no longer responding (correctly); unable to login ?
Temporary glitch or the end of this API ?

half hour later: working again... (temporary glitch)

 

[scaesare]

. One would think that the rated range would be linearly related to the SOC, no?

I'm not sure. Certainly the voltage-to-SOC relationship is a non-linear curve.

One thought is that the car may be just tipping over to the next rounded percentage point (i.e. the initial measurement was 90.47% and the next was 90.52%), so it's enough to change the SOC%, but not enough to change the estimated mileage?

 

[rdrcrmatt]

https://portal.vn.teslamotors.com/ is no longer responding (correctly); unable to login ?
Temporary glitch or the end of this API ?

half hour later: working again... (temporary glitch)

Mine glitched out as well, I didn't restart things this morning as I dropped the car off at the service center, and when they disable the remote access, continuing to try to query the car is a sure fire way to get blocked.

 

[aviators99]

I'm not sure. Certainly the voltage-to-SOC relationship is a non-linear curve.

One thought is that the car may be just tipping over to the next rounded percentage point (i.e. the initial measurement was 90.47% and the next was 90.52%), so it's enough to change the SOC%, but not enough to change the estimated mileage?

And was still over, 9 hours later?

 

[apacheguy]

Anyone else notice that owner-API cuts out more often than the portal did? It seems like 1 in every 10 requests placed randomly throughout the day don't go through. This is most apparent in my overnight charging data because I'll notice that the SOC jumps and then sure enough I'll find that my logs are missing a data point.

 

[Olen]

Yeah. It's pretty unstable. Whether it is the car losing its connection with Teslas servers, or the servers are unavailable for clients is hard to know.
But I have seen on several occasions that I lose contact with the car both in my own logger (exploiting the API) and in the official android app, while the car has a good 3G connection (ie. streaming radio works fine, maps and traffic is updated live on the main screen and so on).

I hope they add some more resources to the "middle ware" between the cars and the clients.

 

[jpasqua]

I've been keeping some stats in VisibleTesla about the failure rate of requests using the new API and it is not encouraging. My code will now retry failed requests up to two times to try to get a valid result. Errors are almost always [503] Service Unavailable -- {"response":null,"error":"timeout in request to 172.26.195.110:7654","error_description":""}.

For the most recent run of VisibleTesla there were a total of 190 attempts to query the charge state. I found that:

• 53% of requests succeeded on the first attempt
• 15% succeeded on the first retry
• 15% succeeded on the second retry
• 17% (the rest) failed after 2 retries

That's pretty abysmal, but pretty normal for what I've been seeing since the server upgrade. BTW, this is the failure rate I see after dropping the query rate to once every 5 minutes.

I raised this with Tesla and had some initial engagement with them, but nothing for quite some time and no improvement in the stats. The person at Tesla I corresponded with first suggested that I would see failures if the car was asleep. I supplied several examples of failed calls while I was driving. He then suggested that I could have been in dead spots for cellular connections when the errors occurred. That wasn't the case either. The last thing he said was that my car in particular might have problems with the cellular radio. I'll have this checked (if possible) when I take my car in for service. I really think he was trying to help, but after all, this is an unsanctioned use of the API so I'm not surprised he didn't keep the conversation going.

If I learn anything new I'll post it here.

 

[apacheguy]

Yep. I have noticed this trend as well. I don't have a built in switch to retry an attempt in my code, though. Maybe I'll get around to doing that soon. I noticed the failure rate increased once I made the switch to owner-API. The iOS app also takes a long time to connect to my car despite it being awake and in an area with good coverage.

 

[Olen]

While I don't have specific numbers, my feeling is that I would see similar stats. My app simply ignores the errors and will retry the same query a minute later, so they are not fatal here. But they seem to be grouped so if a request fails, all requests will fail for the next 20-30 seconds, and then everything is fine for a while.

I still believe the problem is some kind of overload of Teslas servers.

 

[jpasqua]

Over the past 24 hours I saw a 56% failure rate in calls querying the charge state (44% success rate).

I have a retry mechanism in place so the app sees a much lower effective failure rate of 15% (85% success rate).

While 85% is much better than 44%, it's still pretty miserable and of course the retries end up putting more load on Tesla's servers.

-- UPDATE --

The story is somewhat better for the streaming api. While the initial failure rate is still a whopping 42%, only 1% of requests fail after a maximum of 2 retries. That is, 1% of attempts to start streaming fail on the initial request, then fail a retry, then fail another retry. I give up after that.

So, with a max of 2 retries, initiating streaming works 99% of the time, but querying the charge state succeeds only 85% of the time.

 

[jpasqua]

I pushed a new version of TeslaClient to github. This version uses the "owner" API to Tesla's servers. If you want to keep using the earlier API, refer to tag 0.5. This version has a large set of changes. Some are due to changes in Tesla's API, but there is also a lot of cleanup and simplification.

 

[raffiniert]

Hey guys

first, thanks for the great API / documentation.

I am fiddling around with the JS-API and at the moment, I only get a "XMLHttpRequest cannot load https://private-anon-1f16ee4d0-timdorr.apiary-mock.com/login. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost' is therefore not allowed access."

What am I doing wrong? Is it something related to CORS?

Thanks
Raphael

 

[rdrcrmatt]

When trying to authenticate on the portal today I'm getting this.

matt@server:~/tesla/commands$ curl --include --header "Content-Type: application/x-www-form-urlencoded" --request POST --data-binary "user_session%5Bemail%5
> [email protected]&user_session%5Bpassword%5D=password" "https://portal.vn.teslamotors.com/login"
HTTP/1.1 500 Internal Server Error
Server: nginx
Date: Wed, 03 Dec 2014 18:30:57 GMT
Transfer-Encoding: chunked
Connection: keep-alive


matt@paradox:~/tesla/commands$


I kinda ignored the JSON part of this conversation because I don't really understand it. Do I need to modify the way I'm making my queries / logins?

 

[raffiniert]

It seems neither Tesla nor Apiary did implement the CORS-specification (Cross-origin resource sharing - Wikipedia, the free encyclopedia) so the Javascript-API is pretty useless to build a public website

Or are there other ideas?

 

[apacheguy]

Well, API seems to be down again. Unable to establish a connection even after several retries with the iOS app.