POST /api/operation

[swm11]

It would be really useful if I could locally instruct my powerwall to change operating mode, e.g. to force the battery to charge by changing the backup_reserve_percent.

I've tried adding the following to powerwall.py (should use enumeration for opmode in the final version):
def set_operation_mode(self, opmode: str, pc: int):
return self._api.post_operation_mode({"mode": opmode, "backup_reserve_percent": str(pc)})
and to api.py:
def post_operation_mode(self, body: dict) -> dict:
return self.post("operation", body, needs_authentication=True)

But I get the response:
tesla_powerwall.error.AccessDeniedError: Access denied for resource /api/operation: Unable to POST to resource

Though it appears that vloschiavo has gotten this to work:
https://github.com/vloschiavo/powerwall2/blob/master/README.md#apioperation

Any ideal how to fix this?

[jrester]

Try to perform the request manually with curl as described in vloschiavos documentation. This may result in a more descriptive error message and explain why the powerwall isn't accepting the post request.

[swm11]

Thanks for the feedback. Will try that though a sequence of curl commands to gain access and then perform a command isn't very helpful from a reproducibility point of view and it isn't clear how up-to-date the vloschiavos documentation is.

Have you tried to change the powerwall charge state (i.e. to ask the powerwall to charge) using your library? I would have thought that it was the main thing that is useful to automate.

[jrester]

Using curl is just for testing and to examine the error. That way we can find out how to interact with the powerwall and later implement it the library. I looked at the source code of the powerwall webpage and it seems like the documentation is still up-to-date.

Before the rewrite the feature was implemented but quite unstable as telsa often changed the API. As such I removed it from the library. But if you find a way to use this endpoint correctly, I would be happy readd this feature.

[scienceintheshed]

Has there been any success with this as the code from mlowijs/tesla_api#43 seems to now have an problem.

[omaliphant]

I would also really appreciate this feature! i had hoped i could use the solar predictions from solcast.com.au to allow me to estimate more accurately the likely solar power for the day and then adjust the backup% so i could force the powerwall to charge during cheap rate power from 12:30am to 4:30am to a level which would then avoid me having to touch the grid again during peak times.
any update on the ability to change the backup% ?

[omaliphant]

looks like there is a viable way to do it @jrester...

spoonwzd commented on 23 Oct 2020 •
You simply POST the backup_reserve_percent value in JSON to the /api/1/energy_sites/energy_site_id/backup API URL along with the authorization bearer @BJReplay

This is how I'm doing it in node-red with a custom JavaScript function:

msg.headers = {
Authorization: "Bearer " + MY_AUTH_TOKEN,
"content-type": "application/json"
}
msg.method = "POST"
msg.url = "https://owner-api.teslamotors.com/api/1/energy_sites/MY_SITE_ID/backup"
msg.payload = {
"backup_reserve_percent": 77
}

any chance of adding this to a future release?

[BJReplay]

It's really hard to understand what the original poster is asking for here (perhaps it is an update to this repo), but here is the current status.

• local control is no longer possible without toggling the switch on the side of the powerwall
• local monitoring is possible, provided that you log in with the customer credentials to obtain a local token for subsequent requests
• remote control is possible, but may be frustrated by captcha on login - especially, it seems, if your code is running in the cloud; I have not hit this issue running code on an always on PC (at the same public IP as my powerwall).
• you can set the backup reserve percentage remotely to initiate charging. With a short charge window of only four hours, I'd suggest to @omaliphant that you also set the mode to backup only (it will charge at 3.3kW vs 1.7kW in self-consumption mode) if you normallly run in self-consumption mode. If you run in autonomous mode, charging may be as fast at 5kW.

My code at https://github.com/BJReplay/PowerwallService/blob/master/PowerwallService/PowerwallService.vb#L825 and https://github.com/BJReplay/PowerwallService/blob/master/PowerwallService/PowerwallService.vb#L915 gives you a bit of an idea. It's VB.Net. Sorry. Not Sorry. I also use https://github.com/tomhollander/TeslaAuth but pull that in as source as I ran into a .Net versioning conflict that prevented me from pulling it in as a package.

[jrester]

@omaliphant What you are referring to is the external Tesla API but this library uses the local API which works differently afik.

@BJReplay I currently don't have access to a powerwall to test this. If you like to help out I would be happy to merge a PR implementing this functionality. Vloschiavo also has an example for this in his repo but I am unsure if this is up to date. Any help regarding this feature would be greatly appreciated!

[scienceintheshed]

@jrester I have a Powerwall 2 and would be happy to test this functionality.

This was a function that I had in my previous cloud implementation but it broke when Tesla change the oauth earlier this year. I'm using your current version for local access.

[jrester]

Great! I will prototype an implementation for you to test.

[scienceintheshed]

@jrester how are you going with the implementation?

[jrester]

A test implementation is on the operation branch. Would be glad if you could test it!

[dailow]

Getting an error when trying to do post_operation. Getting information from the API seems to be working just fine with the same login.

api.post_operation({"mode":"self_consumption","backup_reserve_percent":30})

File "/opt/tesla_powerwall/tesla_powerwall/api.py", line 210, in post_operation
return self.post("operation", payload=payload)
File "/opt/tesla_powerwall/tesla_powerwall/api.py", line 145, in post
return self._process_response(response)
File "/opt/tesla_powerwall/tesla_powerwall/api.py", line 89, in _process_response
self._handle_error(response)
File "/opt/tesla_powerwall/tesla_powerwall/api.py", line 68, in _handle_error
response_json.get("message"),
tesla_powerwall.error.AccessDeniedError: Access denied for resource /api/operation: Unable to POST to resource: User does not have adequate access rights

[jrester]

It seems like you have to be logged in as installer to change the operation mode.

[jrester]

@dailow @scienceintheshed could you try this when being logged in as installer?

[dailow]

@dailow @scienceintheshed could you try this when being logged in as installer?

Unfortunately I have a PW+ and it needs physical access each time to get into installer mode so I couldn’t get it to work.

[scienceintheshed]

@jrester @dailow same problem here...I need to physically toggle the power switch on the PW2 to get into installer mode.

[scienceintheshed]

Any updates on this?

[jrester]

As long as you need physical access to switch to installer mode I don't believe this is realy usefull.

[jrester]

Closing this. May be reopened if you don't need physical access anymore.

[zigam]

A few updates here that might enable setting mode and backup reserve without physical access. Tesla is now promoting the Tesla Pros app on the gateway web login page. I was testing the app and noticed it has the ability to set operation mode and backup reserve. To log in, the app uses the TEG wifi network but does NOT require flipping the Powerwall switch. So as long as a Raspberry Pi is in range of the TEG wifi, setting the operation mode and reserve should be automatable.

It would require reverse-engineering the new API calls however, since the Tesla Pros app uses a different /tedapi/v1 gateway endpoint. It looks like an RPC protocol that would need to be unpacked. I can post more details if folks think this is useful.

[BJReplay]

Tesla is now promoting the Tesla Pros app on the gateway web login page.
To log in, the app uses the TEG wifi network but does NOT require flipping the Powerwall switch.

I had to flip the switch to log in.

Once I'd logged in, I could leave and re-enter the Powerwall in the app without flipping the switch again.

However, if I Force Stopped the app, and started it again, I had to flip the switch to log in again.

I have an older (V1) gateway, so it may differ depending on what version gateway you have whether or not you need flip the switch to log in, but I definitely did need to.

[jrester]

@zigam that sounds interesting. If you can reverse engineer the protocol and you can confirm that the operation mode can be controlled this way, I would be happy to implement that feature in this library/accept a PR.

@BJReplay interesting behavior and also something that must be considered and investigate more in depth, if we add that feature.

[zigam]

@BJReplay interesting, I didn't need to flip the switch after restarting the app (this is on iOS and with GW2). The flow I used: kill and reopen the app (already logged in using my Tesla credentials), then: Installs / More / Tesla Device Setup / Scan QR Code.

More importantly: looking at the /tedapi requests, they just use basic auth with the gateway password, so I'm not sure if "physical access" is enforced. Might be worth exploring this further.

Starting to unpack the API:

# Log in to the TEG wifi (the password is the full password shown on the label inside the gateway).

# Store the gateway password (full version).
$ export GW_PWD="<FULL_GATEWAY_PWD>"

# Get the device din, e.g. 1232100-10-E--CN321329G1E123.
$ curl -k -u Tesla_Energy_Device:$GW_PWD https://192.168.91.1/tedapi/din

# Request the configuration (binary request is attached below and includes the din from above).
$ curl -k -H 'Content-type: application/octet-string' -u Tesla_Energy_Device:$GW_PWD --data-binary @request.bin https://192.168.91.1/tedapi/v1

request.bin.txt

The last request will return the full configuration of the gateway, a large config.json file. Configuring reserve and mode seems to be modifying that json and posting it back (I'm not including details here yet, wanted to confirm first that this works for others too).

Maybe others can test this with their own systems. Replacing the din in the request.bin file with your device might work, just make sure to keep everything else after the ...123 part the same (confirm the file size and hex contents are the same). Alternatively, you can use Charles Proxy on your mobile device to capture the traffic the Tesla Pros app generates.

[ejbatts]

@zigam Where do I sore the request.bin file to run the command?

When I go to replace the din I see this:

9��������
�1232100-10-E--CN321329G1E123z�
����
config.json����

How should I be edting the file?

[zigam]

@zigam Where do I sore the request.bin file to run the command?

@ejbatts the updated process for /tedapi investigation is here:
jasonacox/Powerwall-Dashboard#392