-
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
tliving
Member
I think that would depend on what they use to calculate projected. If its just from the drive then that could work but if its from last 30 miles, or last 30 days or something else then it wouldn't.
Why not just use the percentage value instead of "range".
Seems pretty simple that if the battery was at 90% when you start your measurement, then you drive X miles and you are at 50% you have consumed 40% and you should be able to calculate your predicted range that way... And 40% of 90KW battery is 36KW.
Am I missing something?
BTW, I have chosen % instead of range for my battery display and you can get this easily from the API as well.
Seems pretty simple that if the battery was at 90% when you start your measurement, then you drive X miles and you are at 50% you have consumed 40% and you should be able to calculate your predicted range that way... And 40% of 90KW battery is 36KW.
Am I missing something?
BTW, I have chosen % instead of range for my battery display and you can get this easily from the API as well.
HankLloydRight
No Roads
tliving
Member
Percentage is coarse. It can be +/- 0.5% so its not a great measure. Also the 85kWh battery degrades over time so that also isn't a great way of doing the math.
AFAIAA projected range only shows up in the vehicle on the energy graph where it is tied to distances of 5/15/30 miles. My belief (not currently verified) however is that the API reported Projected range is calculated using the SINCE LAST CHARGE miles driven and KWh used which themselves are used to generate the displayed Wh/mi.
Sure, but 0.5% is less that 2 miles of "rated range." So not perfect but good enough, isn't it?
Isn't it still better than using the calculated range which seems to be way off based on so many other variables as well? From what I've read, than can be off by way more than 0.5%.
Out of all the imperfect options, which one gives you the least margin of error?
tliving
Member
The degradation is slow, so if you're willing to occasionally use trip kWh data taken visually from the instrument panel trips app, along with trip starting and ending SOC, you can get a pretty good estimate of current battery capacity. For a given trip with starting SOC of S% with ending SOC of E% and kWh used of U, implied battery capacity is 100U/(S-E).
I think the dashboard SOC% is the amount remaining of total available capacity at 100% SOC, where kWh at 100% SOC is yielded by the foregoing calculation. That would be 75-76kWh for new-ish 85Kwh batteries.
The percentage SOC is indeed, alas, coarse. But the numbers would be typically be used in calculating averages or trends.
Last edited:
tliving
Member
I was really trying to find a good way to get to the Wh/mile shown on the dash in an API form but the numbers don't add up.
At the end of the day the dash shows 20.2 kWh used at an average of 279 Wh/mi for 72.2 miles. The overnight charge reports (via the API) charge added of 22.03 kWh. I assume the 22.03 kWh vs 20.2 kWh may be overhead for battery pre-heating so it can charge at the right temp or something.
My wall meter shows charge used overnight is 24.51 kWh (no preconditioning). The 22.03 vs 24.51 is likely charging efficiency loss and is very consistent at 90%. Thats specific to my charging setup I think and different charger setups may yield different ratios.
All this leads to a difference of what Tesla shows you on the dash of 279 Wh/mile which sounds very good vs the actual real world number of 339 Wh/mile which is a lot different.
Im thinking there's no math thats going to reliably give you the Wh/mile shown on the dash as its calculated on the fly and. It does seem that the charge used reported by the API is pretty reliably 90% of the actual wall power used so you can get to a real world Wh/mile by using that charge used number and factoring it and then using the mileage driven from the API.
Is there a way to set the charge scheduler time in the API? I don't see it in the API doc web page, but you can do this in Remote S. I want to set an intelligent end charge time that will (hopefully) complete my charge at 7 am which is a bit before I leave for work. That way the battery will be nice and warm.
edit - It looks like their is a python-crontab module that should help to do this in Python.
edit - It looks like their is a python-crontab module that should help to do this in Python.
Last edited:
tliving
Member
If you're using the API you can just do a cron job to start charge at the time you want. If you want it to end at a certain time you'd have to collect some historical data/do some math and then back off from the end time to when it should start and then have it fire then. The warm pack issue hasn't bothered me yet this season so I didnt add the charge end time yet to my little collection of widgets.
Thanks - the math isn't too tricky to do except the charging can take longer in very cold temperatures so I may have to add a scaling adjustment based on the temp as well. I guess I could start the climate at 4 am read the temp and then set the cron job based on current SoC, temp, desired final SoC and desired final SoC.
tliving
Member
I'd avoid starting climate to read the temp because one of the two will happen:
1) You have to turn it off after getting the temp, but then when you get in your car next it will be off and you have to turn it on manually (unless you add more software to do this before you go to your car daily).
2) Or you let it run its 15 minutes and go back to the normal setting but that wastes heating the car for 15 minutes just to get a temp read.
Better to use something like dark sky api to get current weather conditions:
The Dark Sky Forecast API Docs
You're right. I hadn't thought about thT. I figure that getting a reading from inside my garage would be a bit better. I actually have my own weather station that is connected to wunderground and I can use the winderground API to get at it. Thanks for the advice.
tliving
Member
What are best practices for using OAuth tokens?
So about a year ago Tesla switched the authentication method to use OAuth tokens. I am starting to play with the API a bit but I am wondering what is the best way to use these tokens.
Should I get a token once and then continue to reuse this same token until it expires?
How long is it until a token expires?
Or should I get a new token every time I run code to access the API? Are there any negative ramifications to doing this?
If I just keep reusing the same token for a while then what is the best way to use this token in my code? Should I send the token every time as an argument when I run the code? Should I hard code the token into my source files? Should I put the token in a text file (assuming that this is a secure PC) and call it every time I run code?
So about a year ago Tesla switched the authentication method to use OAuth tokens. I am starting to play with the API a bit but I am wondering what is the best way to use these tokens.
Should I get a token once and then continue to reuse this same token until it expires?
How long is it until a token expires?
Or should I get a new token every time I run code to access the API? Are there any negative ramifications to doing this?
If I just keep reusing the same token for a while then what is the best way to use this token in my code? Should I send the token every time as an argument when I run the code? Should I hard code the token into my source files? Should I put the token in a text file (assuming that this is a secure PC) and call it every time I run code?
tliving
Member
You should cache the token. If the token expires re-authenticate and get a new token.
hans
P631
When you get the token is says how long its good for. Something like "{ expires_in: 7776000 }" which means 7776000 seconds = 90 days.
Similar threads
