Cannot set reserve lower than 5%

[spoonwzd]

Is there a reason I can't set a reserve lower than 5? I get no response from the API when I set a value lower than 5.

Ideally I want to set the reserve to 0 as 0 set by cloud is actually 5% SoC if you look at the local API's battery level. At the moment setting the value to 5 leaves me at a local 10% SoC.

[jasonacox]

Good question. I'll have to take a look.

[jasonacox]

Found the issue. The code was preventing anything <5 and the exception was being raised instead of handled. I updated to log the error for any value outside range of 0-100.

Give this container a try and let me know if it addresses this issue:

jasonacox/pypowerwall:0.8.4t54-beta

[spoonwzd]

It now accepts values <5, however the API response and queried reserve after it's set still says it's set to 5.

{"set_backup_reserve_percent": {"backup_reserve_percent": 5.0, "din": "1099752-01-B--T17K0001234", "result": "Updated"}, "set_operation": {"real_mode": "self_consumption", "din": "1099752-01-B--T17K0001234", "result": "Updated"}}

[spoonwzd]

Update: Setting to 1 works, just not 0. If you set 0, it doesn't change anything and just reports back the current setting.

I'm content with 1. I suspect it's the Tesla API not allowing 0?

[jasonacox]

I don't know why I didn't notice that. You are right. I figured it out. It will take 1 but for 0, it needs to be set to False, evidently indicating that you want to disable reserve. I updated the code to handle this condition if you want to test:

jasonacox/pypowerwall:0.8.4t54-beta2

Interesting note: The Tesla App will let you set it to 0, but above zero, it goes directly to 5. However, our API seems to let me set it to 1, 2, 3 and 4 as well.

[spoonwzd]

Done some more testing. Setting value=1 sets the value to 1 as expected, but setting 0 sets the value to 1.0 ?

{"set_backup_reserve_percent": {"backup_reserve_percent": 1, "din"

{"set_backup_reserve_percent": {"backup_reserve_percent": 1.0, "din"

I'm not really fussed about setting value to 0 as 1 is close enough, but the behaviour doesn't seem to match your expectation.

Not sure what the CANCEL lines are about either in the logs?

04/19/2024 03:00:08 AM [proxy] [INFO] Control Commands Activating - WARNING: Use with caution!
04/19/2024 03:00:09 AM [proxy] [INFO] Control Mode Enabled: Cloud Mode Connected
04/19/2024 04:34:01 AM [proxy] [INFO] Control Command: Set Reserve to 55
04/19/2024 06:33:55 AM [proxy] [INFO] Control Command: Set Reserve to 30
04/19/2024 07:00:06 AM [proxy] [INFO] Control Command: Set Reserve to 1
 CANCEL 

 CANCEL 

[jasonacox]

Thanks @spoonwzd - Yes, my code should be setting it to "False" instead of "0". Just to confirm, you are using the latest container? jasonacox/pypowerwall:0.8.4t54-beta2

[spoonwzd]

Double-checked. Defo using jasonacox/pypowerwall:0.8.4t54-beta2

The console logs show me setting it to 0, but the API response is saying 1.0

[jasonacox]

Ok, I wasn't able to reproduce but perhaps there is an edge case I'm missing.

[spoonwzd]

Let me know if you need anything further to assist with troubleshooting

[jasonacox]

04/19/2024 07:00:06 AM [proxy] [INFO] Control Command: Set Reserve to 1 CANCEL

ah... The cancel means it is crashing. Can you turn on debug mode to see if we can figure out why? Edit pypowerwall.env:

PW_DEBUG=yes

[jasonacox]

I find the issue @spoonwzd ! If you are willing, please try this one:

jasonacox/pypowerwall:0.8.4t54-beta5

Also, now supports POST:

curl -X POST -d "value=20&token=1234" http://localhost:8675/control/reserve
curl -X POST -d "value=backup&token=1234" http://localhost:8675/control/mode

[spoonwzd]

Sorry for the delay. I did enable debug but the logs were being spammed by my repeating polling and I never go around to stopping them :/

Not sure if it's working or not until battery levels drop, but at least the response is different now when setting 0!

{"set_backup_reserve_percent": {"backup_reserve_percent": false, "din": "1099752-01-B--T17K0001234", "result": "Updated"}, "set_operation": {"real_mode": "self_consumption", "din": "1099752-01-B--T17K0001234", "result": "Updated"}}

Additionally I tried using POST as the method, but it doesn't seem to work. I get the output:

"{"unauthorized": "Control Command Token Invalid"}"

Setting the method back to GET makes it behave again.

[jasonacox]

Thanks @spoonwzd !

You can get the current setting by using the API call but omitting the value data.

curl -X POST -d 'token=1234' http://localhost:8675/control/reserve

Also, for the POST test, I suspect you have special characters in your token. I realized that I use double-quotes instead of single quotes in my examples so bash will translate any special characters like $. Can you try this:

curl -X POST -d 'value=20&token=1234' http://localhost:8675/control/reserve