Model S REST API

[SG57]

Where would they get the charge rate which is crucial to know how long it will take to charge? Would they use history from charging at a given location? Would they do a pilot charge for a minute or two to test the charge rate?

This is a very interesting problem you've identified with adding end-time charge scheduling and likely why Tesla was hesitant to implement it. Starting a temporary, pilot charge to get the charge rate is unreliable as you don't know how long to wait until you're at the full charge rate. A few minutes may suffice in some places, but not in others and especially cold places.

I've solved this problem though as best I can by using a hybrid charge rate.

If the car's charge state provides a charge rate (or better yet, time to full charge), then I use that value to make my calculations. If not, then I use a manual, user-entered charge rate to make my scheduled charge start time calculation. I poll occasionally once charging to get actual charge rate and re-do my calculations for safety.

A not-so-bad downside to this method - if the manual charge rate is too low, then charging may start prematurely and require stoppage and a restart later to hit your desired completion time. No big deal.

Another not-so-bad downside to this method - if the manual charge rate is too high or your charge rate slows at any point, then charging may start too late to hit your desired completion time and there's nothing you can do about it. This isn't that big of a deal unless your users seriously botch the manual charge rate.

I can vouch that this method has worked for me and my testers successfully for nearly a month. I've grown quite fond of having regenerative braking in the morning again despite the single-digit weather.

 

[Andyw2100]

This is a very interesting problem you've identified with adding end-time charge scheduling and likely why Tesla was hesitant to implement it.

@SG57 --

Did you see my response to the same post up thread? Any chance you might implement some of them in your software?

I really think letting the user decide between "end time priority" or "charge completion priority" would make sense.

Thanks.

 

[wayner]

I can vouch that this method has worked for me and my testers successfully for nearly a month. I've grown quite fond of having regenerative braking in the morning again despite the single-digit weather.

Exactly, and this is something that the folks at Tesla may not understand since they never see the dreaded yellow dotted arc unless they do a range charge!

Another way to potentially do this is similar to what you mentioned above - charging in stages. You could do the first stage charge to ensure that the car is mostly charged up and you could find the charge rate. Then you could do a second top-up charge so that the battery warms up and you get to the desired charge just before the end-charge time.

In my jurisdiction I don't mind charging as soon as off-peak rates kick in and this has the advantage of having my car charged in case there is an unexpected emergency and I have to leave earlier than expected. But I do also want to give up the battery warming benefits of a just in time charge.

 

[ACDriveMotor]

If you need working code examples you may want to look at TeslaJS or TeslaMS. They are both JavaScript but show working examples of calling various endpoints.

 

[NicB72]

If you need working code examples you may want to look at TeslaJS or TeslaMS. They are both JavaScript but show working examples of calling various endpoints.

Very useful, thank you

 

[wayner]

And if you are into Python there is this GitHub - gglockner/teslajson: Simple Python class to access the Tesla JSON API

 

[SG57]

@Andyw2100 , yes I did read your response and you are not alone in wanting those sophisticated charging mechanisms.

For me, any idea of changing charging amperage is out the window unfortunately due to the inability to change the charging amperage remotely.

For your other idea, seems like you can sum it up by simply saying - do you want to prioritize a warm battery? If yes, then charging may overshoot your completion time slightly in order to keep the battery warm at your completion time. If not, then charging may stop at or just short of your completion time in order to maximize your charge by your completion time. Did I get that right?

The above idea is very easy to add to my Smart Charging solution. In my current solution, there is no priority set on either, you get one or the other naturally. In a perfect world, you'd get both naturally if we could guarantee a full charge right as we reach our completion time, but that doesn't happen due to varying charge rates and temperature changes and whatnot.

 

[Andyw2100]

@Andyw2100 , yes I did read your response and you are not alone in wanting those sophisticated charging mechanisms.

For me, any idea of changing charging amperage is out the window unfortunately due to the inability to change the charging amperage remotely.

For your other idea, seems like you can sum it up by simply saying - do you want to prioritize a warm battery? If yes, then charging may overshoot your completion time slightly in order to keep the battery warm at your completion time. If not, then charging may stop at or just short of your completion time in order to maximize your charge by your completion time. Did I get that right?

The above idea is very easy to add to my Smart Charging solution. In my current solution, there is no priority set on either, you get one or the other naturally. In a perfect world, you'd get both naturally if we could guarantee a full charge right as we reach our completion time, but that doesn't happen due to varying charge rates and temperature changes and whatnot.

Thanks!

Yes, I know there is currently no way to change the charging amperage via API. That part of my suggestion was limited to how Tesla could implement this, if they so desired.

As for your summary of my "warm battery or complete charge" priority, I'm not sure we're quite on the same page.

If someone were to choose "Warm Battery Priority" I think you'd want the charge to end, if all goes perfectly and the charge happens as fast as it possibly could, say ten minutes before the set departure time. If something slows the charging down at all, the car simply won't be charged to the set percentage at departure time, and then the person can either wait for the charge to complete, or leave with a lower than desired SOC.

If someone were to choose "SOC Priority", the charge would have to start earlier enough that it will definitely complete by the departure time, which means it may complete 30-60 minutes before departure time if all goes really well. For this option you could add an additional option to stop and restart the charge if it appears the charge would end on the extreme early side.

Make sense?

Thanks!

 

[robertvg]

^^ Very good thoughts and suggestions!

 

[SG57]

@Andyw2100 , hmmm okay. So the difference between your 2 scenarios there is simply the charge start time? The SOC Priority starts 30 minutes earlier than calculated to hit your desired completion time acting as a huge buffer against any unforeseen outages or slower charge rates. The Warm Battery priority starts at the calculated time to hit your desired completion time with a chance you may not have full charge due to slower charge rates or outages.

 

[Andyw2100]

@Andyw2100 , hmmm okay. So the difference between your 2 scenarios there is simply the charge start time? The SOC Priority starts 30 minutes earlier than calculated to hit your desired completion time acting as a huge buffer against any unforeseen outages or slower charge rates. The Warm Battery priority starts at the calculated time to hit your desired completion time with a chance you may not have full charge due to slower charge rates or outages.

Yes, that is basically it.

But you would be the better judge of how much earlier the SOC Priority should start, based on max amperage, how much juice needed to be added, etc. I would think just a blanket "30 minutes sooner" would be a massive and somewhat inaccurate over-simplification. You could work in all the factors, possibly including temperature, and then decide on the start times accordingly.

 

[sebas]

Thanks!

Yes, I know there is currently no way to change the charging amperage via API. That part of my suggestion was limited to how Tesla could implement this, if they so desired.
...

Depending on the charger you have you may be able to do this with changing the setting on the charger. The charger I use can be set on set amperage settings or scaled from 6% to 100% using PWM. I'm currently working on getting the communication with the charger up and running. This way I could start off slow at e.g. 10% and move that up to 100% just in time to complete the charge. Or set it to a fixed percentage that would have the charge take the time it needs to take.

 

[SG57]

Depending on the charger you have you may be able to do this with changing the setting on the charger. The charger I use can be set on set amperage settings or scaled from 6% to 100% using PWM. I'm currently working on getting the communication with the charger up and running. This way I could start off slow at e.g. 10% and move that up to 100% just in time to complete the charge. Or set it to a fixed percentage that would have the charge take the time it needs to take.

But by lowering amperage to artificially lengthen your charge time to control your completion time you're now more vulnerable to interruptions ruining things or possibly charge times extending past off-peak hours? Is there a good reason not to charge at full amperage? Aside from reducing the live load on your breaker box.

 

[dpskipper]

Does anybody here know how to tell which model car the user has? I've been digging into the option codes and can't find a solid way to tell which battery and motor(s) the car has. I need to reliably tell if the user has for example, a P90 or P90D or 70 etc. I've been doing some digging in the Tesla Design Studio, and found in the webpage, option codes for 60,75,90,and 100kWh batteries.

The option code for AWD is still the same (DV4W) however a 60kWh battery is BX60. 75kWh=BTX5. 90kWh=BTX4 and P100D=PX6D.
I found no mention of these codes in any other documentation I found. The BTX5 code is present in my 70D API call, which means according to the option codes, I have a 75kWh battery. I have not chosen to upgrade to more range yet. How do I check if the user has the range upgrade? According to the existing documentation I've found BR01 means the range upgrade has happened and BR00 means it has not. However I think this only applies to 85 cars which can upgrade to a 90kWh battery. That being said, a code BR02 is present with my other codes.

 

[hans]

Does anybody here know how to tell which model car the user has? I've been digging into the option codes and can't find a solid way to tell which battery and motor(s) the car has. I need to reliably tell if the user has for example, a P90 or P90D or 70 etc. I've been doing some digging in the Tesla Design Studio, and found in the webpage, option codes for 60,75,90,and 100kWh batteries.

The option code for AWD is still the same (DV4W) however a 60kWh battery is BX60. 75kWh=BTX5. 90kWh=BTX4 and P100D=PX6D.
I found no mention of these codes in any other documentation I found. The BTX5 code is present in my 70D API call, which means according to the option codes, I have a 75kWh battery. I have not chosen to upgrade to more range yet. How do I check if the user has the range upgrade? According to the existing documentation I've found BR01 means the range upgrade has happened and BR00 means it has not. However I think this only applies to 85 cars which can upgrade to a 90kWh battery. That being said, a code BR02 is present with my other codes.

You can probably get what you need from the VIN

Decoding Tesla Model S VINs
VIN Decoder | TeslaTap

Make is position 4 and battery type is position 8

 

[SG57]

I tried to make use of the option codes, but there were ultimately too many and felt unreliable moving forward. I use the VIN to decode the information I need avoiding option codes as much as possible, but there are some places I still need to parse it, such as body paint color.

-

On another note, does anyone know off the top of their head a better solution than quickly starting and stopping the HVAC system for waking up the temperatures sensors to get a reading?

 

[wayner]

On another note, does anyone know off the top of their head a better solution than quickly starting and stopping the HVAC system for waking up the temperatures sensors to get a reading?

No, but somebody that I was working with on the Alexa Skill swears that he always gets valid temps on his Model X. I told him that on the Model S you have to start the HVAC system to ensure that you get a reading.

If you are looking for outdoor temperatures at the car's location you can always read the Lat & Long and then use something like Wunderground to get the outdoor temp at the car's location. Of course, that will not properly reflect the temp of the car if it is indoors.

 

[SG57]

@wayner , clever work around for out door temperatures if accuracy isn't as important. Is there any system in the car that requires the temperature sensors to be on? The HVAC is the obvious one so it knows if it needs to do something or not, curious if there is another not-so-obvious command that wakes them up. Perhaps the wake-up command?

 

[gback]

Hello, I am attempting to access the stream data as indicated by a previous post

curl --user USERNAME:TOKEN https://streaming.vn.teslamotors.co...est_heading,est_lat,est_lng,power,shift_state

This works just fine in a Terminal window (Mac OS X), but my question is how would I handle the authorization --user USERNAME:TOKEN in a WebSocket call. I have tried in the socket header but that did not work.

I am able to get all non stream api working including login, etc. through traditional get/post but it is the stream data that has me searching the web and confused. I am using Swift.

Thank you

 

[dpskipper]

@wayner , clever work around for out door temperatures if accuracy isn't as important. Is there any system in the car that requires the temperature sensors to be on? The HVAC is the obvious one so it knows if it needs to do something or not, curious if there is another not-so-obvious command that wakes them up. Perhaps the wake-up command?

I'm pretty sure if you move the sun roof it will wake up the temp sensors. However, this may not work for cars without a sun roof. Also, you said you use option codes to get the car colour, however there is an api field just for this. exterior_color. Its present in the car state call that shows which doors are open etc.