TEDAPI with PW3 not working for me

[SeanNazareth]

Hello,
I feel like I'm close, but I must be missing something simple.

I've spun up a host to test this dashboard. I've got 2 PW3s. They are hardwired to my home network. I've got a UNIFI based home network with the PW3s on the IOT VLAN/Network.

I've set up a static route to the 192.168.91.0/24 network that is pointed at the IP address of the leader PW3. I found the IP to use for the route by finding the IP of the Leader power wall in the UNIFI client list. With my route, I can ping 192.168.91.1. If I try to run the setup, the utility sees that there is a power wall at that address.

But, when the stack fully loads, it doesn't work, and looking at the logs, it appears that the authentication isn't successful as shown below

05/09/2025 03:11:20 AM [proxy] [INFO] pyPowerwall [0.12.11] Proxy Server [t72] - HTTP Port 8675
05/09/2025 03:11:20 AM [proxy] [INFO] pyPowerwall Proxy Started
05/09/2025 03:11:20 AM [pypowerwall.tedapi] [ERROR] Access Denied: Check your Gateway Password
05/09/2025 03:11:20 AM [pypowerwall.tedapi] [ERROR] Failed to connect to Powerwall Gateway
05/09/2025 03:11:20 AM [pypowerwall.tedapi] [ERROR] Access Denied: Check your Gateway Password
05/09/2025 03:11:20 AM [pypowerwall.fleetapi.pypowerwall_fleetapi] [ERROR] Failed to retrieve sitelist - MissingSchema("Invalid URL '/api/1/products': No scheme supplied. Perhaps you meant https:///api/1/products?")
05/09/2025 03:11:20 AM [pypowerwall.fleetapi.pypowerwall_fleetapi] [ERROR] No sites found for
05/09/2025 03:11:20 AM [pypowerwall] [ERROR] Failed to connect to Powerwall with all modes. Waiting 30s to retry.

I started up a shell on the PYPOWERWALL docker host, and used a sample script from the PYPOWERWALL site and I see this

/tmp $ python3 test.py 
Access Denied: Check your Gateway Password
Failed to connect to Powerwall Gateway
Access Denied: Check your Gateway Password
Failed to retrieve sitelist - MissingSchema("Invalid URL '/api/1/products': No scheme supplied. Perhaps you meant https:///api/1/products?")
No sites found for 
Unable to connect to Powerwall.
Traceback (most recent call last):
  File "/tmp/test.py", line 33, in <module>
    print("Site Name: %s - Firmware: %s - DIN: %s" % (pw.site_name(), pw.version(), pw.din()))
  File "/usr/local/lib/python3.10/site-packages/pypowerwall/__init__.py", line 499, in site_name
    payload = self.poll('/api/site_info/site_name')
  File "/usr/local/lib/python3.10/site-packages/pypowerwall/__init__.py", line 319, in poll
    payload = self.client.poll(api, force, recursive, raw)
  File "/usr/local/lib/python3.10/site-packages/pypowerwall/cloud/pypowerwall_cloud.py", line 193, in poll
    raise PyPowerwallCloudTeslaNotConnected
pypowerwall.cloud.exceptions.PyPowerwallCloudTeslaNotConnected

However, if I connect directly to the PW3 WIFI access point, then this seems to run. I do see some errors that show up in some runs and not others, but at least the power wall access seems to complete.

Can you give me any insight into what may be going wrong?

I would really like to connect to this from ETHERNET rather than using the WiFi AP of the PW3.

Thanks,

Sean

[jasonacox]

I've set up a static route to the 192.168.91.0/24 network that is pointed at the IP address of the leader PW3.

Sadly, this no longer works. With Firmware 25.10.1 and above, Tesla prevents static route access. You will need to have your Dashboard host connect directly to the Powerwall WiFI access point. One way to do this is to have your Dashboard host (e.g. Raspbrerry Pi) connect to your LAN with an ethernet cable and use it's WiFi adapter to connect to the Powerwall. Details are here:
#607

For troubleshooting purposes, you can use the pypowerwall library directly:

# Create a virtual python env
python -m venv venv
source venv/bin/activate

# Install package
pip install pypowerwall

# Scan for Powerwall
python -m pypowerwall scan

# Connect to TEDAPI
python -m pypowerwall.tedapi

Note to self: Since there seems to be a majority now moving to the newer firmware, I need to update the README and setup script to remove the static route option. :)

[SeanNazareth]

Hi Jason,

Thanks for the response. I did look at the thread you referenced for running this dashboard on a RPi. Ideally, I'd run the dashboard on my proxmox box, but maybe there's a way to run a proxy on a RPi or similar to allow this? It would seem an RPi configured to run as a router might work, if you connect the WIFI to the PW3 AP, and then route from the ethernet to the WIFI, and then use a static route to send transactions to 192.168.91.x to the ethernet IF of the router. Any thoughts or info on anyone who might have already configured something like this? I think my main intent is to not store any data on the PI as I don't want to rely on SDCard storage, so alternately the PI could read the data and then post it somewhere else might also be possible. One question in such a mode, if the PI goes down, would you "lose" the data for the period it is offline? Or is there a way to re-fetch the missing data?

One other thing to note... to test the dashboard, I had spun up a VM on my macbook pro to run proxmox with a VM to host the powerwall dashboard. I then connected my laptop's WIFI directly to the PW3 AP. This enabled the dashboard to start getting data. Asit was running, I did notice a number of "failed" queries (dashboard would show a "!" or similar warning), but if I would click on the error and resubmit the query, I would get a valid answer back. Is this expected?

I didn't yet try the FLEET API method. Maybe I'll give that a spin tonight.

A few more quick questions:

1. If we have this working correctly, how much data are we generating per day into the influxDB?
2. What resolution data is stored, and once stored, is there a method to keep coarser data to reduce the size? For instance capture 5min resolution data for 1 yr, and then transition to 30min or 1hr data for older data?
3. Is there a way to go back and get historical data? Say if you use the FLEET API mode, TESLA is storing the original data, right? If I run in that mode, can I get older data?

Thanks for your contribution to this great project!

Sean

[SeanNazareth]

Thank you so much for your quick response. At least my data seems to make sense then. A quick additional question then...

When I look at the default power flow dashboard, I don't see any data on the top "Energy Flow" panel until I "click" on ZoomToData button on one of the lower panels. Is this expected? Also, it seems like the day/night cycle is and time on the graph don't align with where I am, even though my timezone is set to LosAngeles In the image below, my current time was near 3:20pm, but the image is showing something near 6am for the current data..

[JohnJ9ml]

I have made the jump over to running a single proxy by itself on an RPi5, pointing my client at it, and also pointing the PD client at it. I'll see how it holds up with two inquisitive consumers.

[JohnJ9ml]

Reporting in after roughly 24 hours:

The proxy running on its own RPi5 is holding up nicely with both the PD load and my own client pointed at it.

I do continue to see the api_lock timeouts noted elsewhere rather frequently, but I'm not seeing any adverse effects I've noticed.

I to note that even having made the changes to the telegraf.conf file and confirming the requests are going to the standalone Pi, there is still a Docker instance running server.py on port 8675 on the PD box, and it continues to log errors occasionally when trying to reach 192.168.91.1. I'm not sure why this container still starts up, and why it occasionally attempts to talk to the inverter. Do I need to manually remove that container so that it doesn't restart on reboot?

My hope was to remove the external Wifi adapter and move the box back inside, but until I know why it's still trying to talk to the inverter I'm not going to make that next step.

[jasonacox]

any reason it's the IP address for the new node as opposed to the hostname (provided it's in hosts)?

Docker compose creates its own DNS and will override anything in hosts.

Do I need to manually remove that container so that it doesn't restart on reboot?

Yes it is starting because it is in the powerwall.yml file if you used the ./compose-dash.sh script (or setup.sh) to get it started. You can manually remove it and rerun ./compose-dash.sh up -d to remove it. If you didn't use those scripts, you can just manually stop and remove it:

docker stop pypowerwall
docker rm pypowerwall

[JohnJ9ml]

Following up:

I've had this up and running for over a week, and with the proxy on its own RPi5 it support my needs and the dashboard needs just fine.

There's just one bit of information apparently missing: since I've made this change, the animation no longer works. Every graph seems just fine, but the animation never finds data, the firmware version is never displayed, and the animation just continues to play it's dash dash dash searching image. I'm not sure where there might be a reference in there that isn't picking up a pointer to the proxy - I'm assuming that's what's wrong, as that's when it stopped working.

[jasonacox]

The animation is set to use the hostname of the URL you type in the browser, so it will be wrong in your case. What you could do is install a port forwarding proxy on your dashboard host to proxy requests to your pypowerwall host. Maybe something like this:

On your host you are running Grafana:

Create file: nginx.conf (make the proxy_pass the IP address of your pypowerwall host)

worker_processes 1;

events {
    worker_connections 1024;
}

stream {
    server {
        listen 8675;
        proxy_pass 192.168.0.100:8675;
    }
}

Run docker:

# Run docker
docker run -d \
  --name pypowerwall-proxy \
  -p 8675:8675 \
  -v $(pwd)/nginx.conf:/etc/nginx/nginx.conf:ro \
  nginx:stable

# Test
curl localhost:8675/version