POST /api/operation - Githubissues

swm11 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Has there been any success with this as the code from https://github.com/mlowijs/tesla_api/issues/43 seems to now have an problem.

omaliphant commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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

scienceintheshed commented 3 years ago

@jrester how are you going with the implementation?

jrester commented 3 years ago

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

dailow commented 3 years ago

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 commented 3 years ago

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

jrester commented 3 years ago

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

dailow commented 3 years ago

@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 commented 2 years ago

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

scienceintheshed commented 2 years ago

Any updates on this?

jrester commented 2 years ago

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

jrester commented 2 years ago

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

zigam commented 11 months ago

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 commented 11 months ago

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 commented 11 months ago

@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 commented 11 months ago

@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 commented 9 months ago

@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 commented 9 months ago

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

@ejbatts the updated process for /tedapi investigation is here: https://github.com/jasonacox/Powerwall-Dashboard/discussions/392

jrester / tesla_powerwall

POST /api/operation #20