Struggling With Tesla API

[Haselsmasher]

I've written a program to control battery charging based on solar output. I'm using teslapy. Overall it's working well - but the code is bombing unpredictably based on various specific errors. Sometimes it's an Error 408. Sometimes it's a timeout. I think another time I got a "vehicle unavailable" or something like that.

Is teslapy commonly used by folks here who are using the Tesla API?

I'm running 2.20 - which I believe is the current version.

This is an example of one of the errors I got

Any ideas? I'm a real Python hack and don't have any experience with this auth/token stuff.

Thanks!

Jim

Traceback (most recent call last):
File "TeslaCharger.py", line 62, in <module>
vehicles[0].get_vehicle_data()
File "/home/pi/.local/lib/python2.7/site-packages/teslapy/__init__.py", line 446, in get_vehicle_data
self.update(self.api('VEHICLE_DATA')['response'])
File "/home/pi/.local/lib/python2.7/site-packages/teslapy/__init__.py", line 404, in api
return self.tesla.api(name, {'vehicle_id': self['id_s']}, **kwargs)
File "/home/pi/.local/lib/python2.7/site-packages/teslapy/__init__.py", line 288, in api
**{arg_name: kwargs})
File "/home/pi/.local/lib/python2.7/site-packages/teslapy/__init__.py", line 121, in request
response.raise_for_status() # Raise HTTPError, if one occurred
File "/usr/lib/python2.7/dist-packages/requests/models.py", line 940, in raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 408 Client Error: vehicle unavailable: {:error=>"vehicle unavailable:"} for url: https://owner-api.teslamotors.com/api/1/vehicles/<stuff deleted>

 

[GeneralPlatty]

It's normal. get_vehicle_data queries the live status of your vehicle and fails with "vehicle unavailable" when your car is sleeping. The only way to get around it is to wake up the vehicle first.

POST to https://owner-api.teslamotors.com/api/1/vehicles/{{:vehicleId}}/wake_up

I recommend giving it a few minutes between calls, though generally it wakes up within a minute.

 

[Haselsmasher]

Thanks!

I was waiting 5 mins between calls and it was still bombing at unpredictable times - sometimes on the wakeup call and sometimes on the get_vehicle_data.

I found the python "try:except" construct and it appears to be catching the timeout error.

Thanks again!

 

[israndy]

Did you ever get this working well? I just wrote my on version of this:

TesSense - Control your Tesla charging from your Sense Energy Monitor

The code is at GitHub if you still have issues with your setup, if not I may ask you about my issues

 

[Haselsmasher]

Did you ever get this working well? I just wrote my on version of this:

TesSense - Control your Tesla charging from your Sense Energy Monitor

The code is at GitHub if you still have issues with your setup, if not I may ask you about my issues

I have gotten mine going. It's working well enough for what we want it to do.

The Sense Energy Monitor looks VERY cool. I considered getting it but decided it was overkill for what we needed. But it's very tempting.

Happy to engage and exchange ideas.

 

[israndy]

What do you have for an energy monitor? Tesla?

 

[Haselsmasher]

I'm using an Eagle-200 from Rainforest Automation. It connects (via Zigbee) to our electric meter. It'll give Instantaneous Demand (net flow) at the meter.

We've got a Model Y Long Range.

Does the Sense give you a/the net-meter view?

I'd call the Eagle-200 "ok". Getting it to connect to the meter requires a weird dance/coordination with the utility. Fortunately it worked well for me. But I'm helping a friend right now get one connected and he's running into issues. It's not preventing him from using it in using the Tesla charge control solution (my wife and I call the solution we made Suncatcher). But this hardware product does seem a little finicky.

Product Page - EAGLE - Intelligent Energy Management | Rainforest Automation

EAGLE

www.rainforestautomation.com

 

[israndy]

Ah, I have something like that from Emporia that I use at our Cabin, of course we don't have solar there, and we are on flat rate so we just plug in whenever we wanna. Sadly my town has it's own municipal power company and they haven't gotten a feature like supporting the Zigbees of the world yet.

Sense does work great. Samples at 1 Mhz, and there are two grid CTs and two for solar so you get 4 million samples per second, I only sample once a minute, so it's overkill. Would love to look at your code, but it probably will be just like mine posted above.

 

[Haselsmasher]

The code is on GitHub. Although it works I'm kind of embarrassed about it. As I found errors and such I fixed 'em frequently by adding additional 'if' conditions....and it has evolved to be somewhat unwieldy. I would like to do a re-implementation to see if I can make it more efficient and easier to understand. (For example, I'm probably "over-polling" and causing battery draw down because of unnecessary polling.)

Some basic concepts implemented that might help with some explanation:

• We have time-of-day pricing - so it does manage knowing whether we're in the high-tier rate or not.
• We decided on a "minimum charge" we want to have every night. (The Tesla is our only car.) So a battery level can be set in the code where, if the car is below that when high-tier pricing ends at night, the car will charge from the grid just to that minimum level. For us that level is 50%. We want that to either go to the Emergency Room or to our kid who lives 60 miles away....and not have to wait for the car to charge. LOL
• We stop daytime charging when we reach a battery level that accommodates our typically daily driving needs. Once we reach that point we figure it's best to sell back as much as we can. In our case that is 15%, so we stop charging at 65%.

I use the word "Source" in the file name to draw attention to the fact there are places in the code the user needs to set - such as the Tesla account's email address.

GitHub - Haselmaier/Suncatcher

Contribute to Haselmaier/Suncatcher development by creating an account on GitHub.

github.com

 

[fryeBE]

I'm also struggling with Tesla Api's...
I made a own api endpoint where i want to turn on the airconditioning but sometimes I got a 408...
what I do:

1. check if car is asleep (200)
   1. if asleep --> wake the car with api
   2. loop to check if car is online, if online --> proceed
2. set temperature to a specific amount (200)
3. turn on climate control. (408)

It makes no sense of getting a 408 on the last part when the previous part (set temperature) is successfully.

I'm 100% sure the car is online and awake...

Maybe... the car is in a bad wifi connection where the tesla-api's are struggling to get data from the car?

 

[Haselsmasher]

I'm also struggling with Tesla Api's...
I made a own api endpoint where i want to turn on the airconditioning but sometimes I got a 408...
what I do:

1. check if car is asleep (200)
   1. if asleep --> wake the car with api
   2. loop to check if car is online, if online --> proceed
2. set temperature to a specific amount (200)
3. turn on climate control. (408)

It makes no sense of getting a 408 on the last part when the previous part (set temperature) is successfully.

I'm 100% sure the car is online and awake...

Maybe... the car is in a bad wifi connection where the tesla-api's are struggling to get data from the car?

At first I was wondering if setting the temperature (#2 in your sequence) also turned on climate control - and the 408 error was because climate control was by default turned on in step #2. But you say the 408 happens "sometimes" - so I'm concluding setting the temp doesn't turn on climate control. Is that correct?

As I recall (not totally sure on this) I'd get some sort of error what seemed like relatively soon after having "woken up" the car. Have you tried the try:except construct? It has worked great. This is how I'm using it to wake up the car and get basic status info. I think I was finding that even if the wakeup call was successful there were times the get vehicle data request failed.

 

[israndy]

The Try: construction is practically mandatory for calling TeslaPy.

Looking at your code, Haselsmasher, I don't see a print statement in that while loop if either of the first two Try's fail. Going straight into a continue w/o feedback could leave the app hung

 

[Haselsmasher]

The Try: construction is practically mandatory for calling TeslaPy.

Looking at your code, Haselsmasher, I don't see a print statement in that while loop if either of the first two Try's fail. Going straight into a continue w/o feedback could leave the app hung

Thanks Randy! Your timing is perfect. There's an instance of this code running at a friend's house and it has been hanging. I've been postponing diagnosing it.....because I've been dreading trying to figure out if the problem is with my code or at the system level.

You've given a solid place for me to look.

Thanks again. Much appreciated!

Jim

 

[israndy]

I was getting cocky and left the Wake() call outside of the Try: construct and ran a script I am working on overnight and it caused the TeslaPy function to choke. I don't know a LOT about coding, especially with Python, I think I am on week 3, but it sure seems like a productive language if I could just get a little deeper into it. But, that will come with time.