Firmware 1.50.1 Breaks Automation using API

[cwied]

I'm a little late to the game, but I switched to the server API some time ago and have been happy with the decision. Now that the changes take effect immediately, there's less of a reason to talk to the Powerwalls locally. The power switch requirement actually seems reasonable since it prevents attacks from someone who has network access to the Installer but doesn't have physical access. I'm not sure on the timing, but I think such an attack was just published by some security researchers.

The remote API should be safe to use since it uses https. It is also token-based so you don't have to store username and password for the Tesla account after the initial login.

The good news is that in my experience the server API has been more reliable than local control. They know the right way to commit changes, so I haven't had any trouble with changes not happening since switching API's.

 

[BJReplay]

I've now switched to the server API for settings and mode status (but local API for high speed monitoring).

I would have switched earlier, but the re-write never made it to the top of the long to-do list; it wasn't broken so it didn't make a lot of sense to make the change while the local API was working, working well, and didn't rely on internet access.

The server API is useable (perhaps even better, now) as it changes near enough to instantly, compared to initially when it would take an hour or more.

Code is a mess - now the item on the to-do list is clean up and re-factor - there's a lot of redundant code sitting around .

 

[pv135]

After a complete gateway and powerwall replacement last year I had instant reserve changes via the app so I've been running the cloud API for reserve changes since (after being accused of "abusing the interface" with direct API control) This way their cloud can do what ever it wants to me if I call a change and they don't want it (it is in the middle of a firmware update or I have done too many in a period for their liking). I have had no problems running this (gateway has again been replaced but not because of this) and I can't see how a command to their servers the same as pressing a button in their app can be treated as a problem (or stopped for that matter). In fact last year when I went into great detail with them about why I run my own control they actually directed me to the unoffical cloud API.

While I prefer local control for independence if their cloud is reliable enough it would be better all round if they just did an authorised one.

 

[NuShrike]

The only thing to keep and out for is Internet outage taking out automation. :-/

Cloud API definitely is safer otherwise as it prevents interfering with any system updates or other process.

 

[blueice89]

I have seen a few of you mention the “cloud api” can you share code links or just share code in general for how you connect to the cloud api .

i tried just making rest calls and using oath2 following this guide :
Introduction

Is there another guide you can point to or some code cause when I make my calls I am getting errors ::
MFA support · Issue #215 · timdorr/tesla-api

How are you all not getting this same error unless it’s a different api :

When I call for a token using the old api, i keep getting challenged with:
response:
{"response": "https://myt-websvc-vip1.tesla.com:443/teslamobileservices/users/authenticate_=>_authorization_required"}

 

[blueice89]

Does the non-Installer login give API access? It doesn't ask for power-switch toggle, and still lets people change modes/etc via the web-UI (when it originally didn't iirc).

I'd migrated all of my automation couple months ago to use the Owner/App API since it no longer has lag, and everything works just fine. Though I still can't figure out how to control Storm Watch yet.

The customer login does not work from my testing today.

 

[pv135]

I have seen a few of you mention the “cloud api” can you share code links or just share code in general for how you connect to the cloud aapi .

i tried just making rest calls and using oath2 following this guide :
Introduction

Is there another guide you can point to or some code cause when I make my calls I am getting errors ::
MFA support · Issue #215 · timdorr/tesla-api

How are you all not getting this same error unless it’s a different api :

When I call for a token using the old api, i keep getting challenged with:
response:
{"response": "https://myt-websvc-vip1.tesla.com:443/teslamobileservices/users/authenticate_=>_authorization_required"}

I still use the original code, I have not enabled any MFA so assume this is the difference?

 

[blueice89]

Okay I finally got it working!
The cloud automation API still works ( its just my username / password ) were broken so I had to get the right user name and pass and good>


Happy to report we migrated our code to cloud automation from local and you can download the newest code here, just change lines 33-35 to your credential for Tesla and let it rip, use at your own risk!
Newest powerwall code – Solar Coder (this code can help you schedule your powerwall if you have double peaks like we do on the SRP powerplan from 5am-9am and 5pm-9pm which as a reminder for Arizona SRP start November 1st)