This is also another of the reasons why I write to a real database instead of just a flat file, I can use code logic to go backwards in time to the last time the car was driven and check if the GPS matches my garage when the car went into park, then check if the car was plugged in. You can do the same on a flat file but it'll be resource heavy and slow to query through all that data.
Model S REST API
- Thread starter timdorr
- Start date
-
- Tags
- Model S User Interface
This is also another of the reasons why I write to a real database instead of just a flat file, I can use code logic to go backwards in time to the last time the car was driven and check if the GPS matches my garage when the car went into park, then check if the car was plugged in. You can do the same on a flat file but it'll be resource heavy and slow to query through all that data.
insaneoctane
Active Member
Does anyone here know if the car sleeps while charging or if it is always awake during charging?
insaneoctane
Active Member
So I got your code mostly working on my flat csv file. Thanks again for giving me 90% of my project!
One of the problems I am having is probably related to my modified csv output.... One of the parameters (option_codes) contains values that include commas and are showing up as unique columns vs part of Option_codes. Here's my option_code result :
"option_codes":"AD15,MDL3,PBSB,RENA,BT37,ID3W,RF3G,S3PB,DRLH,DV2W,... "
None of the data in my csv file contains quotes and so there's no way to differentiate between new keys and values. I am not sure how to solve this problem yet, but I know that I am not up for learning SQL at this time!
Np, I had to learn PS and Rest the hard way so I don't mind paying it forward.
As for.l your quote issue you can either modify the property on the object and quote wrap it or replace the commas for something else.
Or you can use convert-csv to get the line as a string and then replace the commas for tabs and make the file a tsv, then pipe it to export-file.
Im on my phone so I can't give you examples let me know if you get stuck.
RyanDe
Member
Can you pull historical data from the api or do you have to take snapshots? I can't test yet as I don't have my car but I can't wait to play with this.
The API seems to be working only intermittently, the last two days. Most of the failures are for "bad gateway". What's weird is that Tesla announced planned maintenance for Monday night, but my script saw no errors then, querying every 5 minutes. But since Wednesday morning, I've had lots of errors.
SeBsZ
Former Vendor
Same here, had loads of problems the past two hours, even the official app. Seems to be okay again now. I even called Tesla and they were aware (in Europe) and told me it should be fixed within the hour.
insaneoctane
Active Member
@L-P-G , hope you don't mind, but I'm getting the following error often, but NOT always when I pull the Climate State data. Any ideas why?
Code:
VERBOSE: Getting Vehicles
VERBOSE: Getting Vehicle State
VERBOSE: Getting Vehicle Drive State
VERBOSE: Getting Vehicle GUI Settings
VERBOSE: Getting Vehicle Charge State
VERBOSE: Getting Vehicle Climate State
Invoke-RestMethod : {"response":null,"error":"operation_timedout for txid
`98259d826779cd9578d4fc10dcbcd35f`}","error_description":""}
At C:\xxxx\Script rev3.ps1:213 char:21
+ $restResponse = Invoke-RestMethod -Uri "https://owner-api.teslamotors.com/ap ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-RestMethod], WebExc
eption
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeRestMethodCommandThat an operation timed out error. Either the api is taking too long to respond or it's not responding for some reason.
You can add a -timeout switch to the invoke-rest method on that line and give it 5 or 10 seconds hard-coded timeout. The api shouldn't take any longer than 10 seconds to respond (unless the car is asleep or there is an issue with the api)
Or you can add a try catch and add your own logic to handle any errors.
insaneoctane
Active Member
I can't believe it's asleep, because it is pulling the climate data right at the end of pulling all the other data (vehicle, drive, GUI, and charge). These pulls all happen within seconds of each other. If I add the -timeout switch with 10 second timeout to the climate call, if it doesn't respond in 10 seconds, what happens differently?
On a side note, I've just about completed my version of your script and have it adding my "as measured" EVSE data to my data collection and am seeing charging efficiency. I also have it letting my know at 11pm if my car isn't plugged in. So far so good with everything (except the occasion timeout per above) and really appreciate the help!
The -timeout simply tells the command to wait at least 10 seconds for a response before giving up if it doesn't then you get the same error, hence why a try catch would be a better fix.
You could also add time sleeps between each api endpoint hit as that could also be it, this isn't an issue on my S but I have the older non-face-lift version so I'm a few hardware revisions behind.
Lastly you could switch over the code to use the /data enpoint instead as that will collect all the data in a single hit but you'll have to modify your export objects to match the new returned JSON.
insaneoctane
Active Member
I thought the API required the data to be pulled in separate calls, ie:
https://owner-api.teslamotors.com/api/1/vehicles/vehicle_id/data_request/charge_state = charging info
https://owner-api.teslamotors.com/api/1/vehicles/vehicle_id/data_request/climate_state = climate info
How would you make a single collection?
PS - Sorry if this is simple, my coding is purely a hobby not a profession!
A few months ago a new endpoint "/data" was found on an app update, this endpoint is what I was referring to. It does all the hits at once, I wrote my code before this endpoint was published so that's why it does individual hits.
Not that it matters much, but actually I think it's been there for around a year. I wrote some scripts last year and I used /data. And looking through this thread, I can see some references to the /data endpoint back to at least Feb 2017.
Anyways, I did the same thing - converted from using several calls to just /data. Just do a pull on that and you'll see what's going on - the charge_state, drive_state, etc. are data structures within the response.
Similar threads
