PyPowerwall stopped connecting

[KevM]

Pypowerwall proxy stops working when the pypowerwall.env file has PW_CONTROL_SECRET set. If the value is empty things work on. This happens for me on both the latest container and jasonacox/pypowerwall:0.8.4t54-beta2

Env

PW_EMAIL=me@me.com
PW_PASSWORD=password
PW_HOST=192.168.7.87
PW_TIMEZONE=America/Chicago
PW_STYLE=grafana-dark
TZ=America/Chicago
PW_DEBUG=no
PW_CACHE_EXPIRE=30
PW_POOL_MAXSIZE=1
PW_CONTROL_SECRET=password.here

Logs

2024-04-18 16:14:08 NameError: name 'pw_control' is not defined
2024-04-18 16:14:09 04/18/2024 04:14:09 PM [proxy] [INFO] pyPowerwall [0.8.4] Proxy Server [t54] - HTTP Port 8675
2024-04-18 16:14:09 04/18/2024 04:14:09 PM [proxy] [INFO] pyPowerwall Proxy Started
2024-04-18 16:14:09 04/18/2024 04:14:09 PM [proxy] [INFO] pyPowerwall Proxy Server - Local Mode
2024-04-18 16:14:09 04/18/2024 04:14:09 PM [proxy] [INFO] Connected to Energy Gateway 192.168.7.87 (Harrison)
2024-04-18 16:14:09 04/18/2024 04:14:09 PM [proxy] [INFO] Control Commands Activating - WARNING: Use with caution!
2024-04-18 16:14:09 04/18/2024 04:14:09 PM [pypowerwall.cloud.pypowerwall_cloud] [WARNING] Missing auth file .auth/.pypowerwall.auth - run setup
2024-04-18 16:14:09 04/18/2024 04:14:09 PM [proxy] [ERROR] Control Mode Failed: Unable to connect to cloud - Run Setup
2024-04-18 16:14:09 Traceback (most recent call last):
2024-04-18 16:14:09   File "/app/server.py", line 205, in <module>
2024-04-18 16:14:09     if pw_control:
2024-04-18 16:14:09 NameError: name 'pw_control' is not defined

Scan

Host: 192.168.7.87 ... OPEN - Found Powerwall 1232100-00-H--GF2231140002H0
                     [Firmware 23.44.0 eb113390]

[KevM]

Missing auth file .auth/.pypowerwall.auth

I do have a file present at this path. When I stop the service and remove it. Then restart it reappears so it seems like auth is working.

[KevM]

I forgot that I was going to experiment with setting the battery reserve and added this setting to my pypowerwall.env PW_CONTROL_SECRET=password.password.password. Removing it corrects the issue. Editing the Issue to relate this...

[jasonacox]

Thanks @KevM ! You identified an error when control mode is selected but the user has not set up "cloud mode". I added code to handle that and instruct the user to run cloud setup.

Latest container: jasonacox/pypowerwall:0.8.4t54-beta4

I know you mention that the auth file is set up. But for you to get that error means that it was not able to set up the cloud connection. Check your settings:

# check to ensure the cloud credentials are correct
docker exec -it pypowerwall python -m pypowerwall setup 

[KevM]

I know you mention that the auth file is set up. But for you to get that error means that it was not able to set up the cloud connection. Check your settings:

Interesting I've never setup the cloud connection before. I have always been using local mode.

04/22/2024 08:57:08 AM [proxy] [INFO] pyPowerwall [0.8.3] Proxy Server [t54] - HTTP Port 8675
04/22/2024 08:57:08 AM [proxy] [INFO] pyPowerwall Proxy Started
04/22/2024 08:57:08 AM [proxy] [INFO] pyPowerwall Proxy Server - Local Mode

I believe I did use the cloud on my laptop and working with your Powerwall Dashboard project when loading historic data. Currently I am using pypowerwall via Docker for a personal project. How does pypowerwall behave differently between Local and Cloud modes?

[jasonacox]

Local mode provides more data and better fidelity of the data (more samples). Cloud was set up originally to allow Solar-only users to get their power data and became important when the Powerwall 3 came out because it doesn't have a local API.

You should use local mode for pypowerwall setup if possible, I wouldn't recommend changing that. However, if you want to control your Powerwall, that is only available via cloud mode. If you run the cloud setup on pypowerwall (don't change it with setup.sh), it will operate in a hybrid mode of using local mode to get the Powerwall data but calling the cloud when you wish to make changes to the mode or reserve settings.

[KevM]

Thanks for the heads up. I did switch to controlling the powerwall with the FleetAPI. I wanted something that I knew would work after the ownerapi goes away.

[jasonacox]

@KevM did you happen to use the process and code from https://github.com/jasonacox/pypowerwall/tree/main/tools/fleetapi ? The plan is to add this in to pypowerwall to replace the cloud mode functionality. The process is more intense than the oweners api. I would love to hear your experience or recommendations.

Thanks for your help! 🙏

[KevM]

I rolled my own go client. Yes setting up a fleet api app is a little tricky. You have to have a website for the registration step and you have to manage secrets but in theory someone could setup a fleet api app to just be a pass through authentication and let users do what they want with their auth token. I built a go TUI as a proof of concept for app I want to build. So I have the auth part figured out. My TUI uses a sveltekit web app to be an auth pass through.

On Sat, May 11, 2024, at 6:35 PM, Jason Cox wrote:

@KevM https://github.com/KevM did you happen to use the process and code from https://github.com/jasonacox/pypowerwall/tree/main/tools/fleetapi ? The plan is to add this in to pypowerwall to replace the cloud mode functionality. The process is more intense than the oweners api. I would love to hear your experience or recommendations.

Thanks for your help! 🙏

— Reply to this email directly, view it on GitHub https://github.com/jasonacox/pypowerwall/issues/88#issuecomment-2106057976, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAAMHLT5AD6FKBMT4BISYTZB2TNBAVCNFSM6AAAAABGOBMUPCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBWGA2TOOJXGY. You are receiving this because you were mentioned.Message ID: @.***>

[jasonacox]

Thanks @KevM ! I do appreciate the help and feedback. I'll close this as it is no longer an issue or relevant for you. Good luck with your app!