pypowerwall can't connect to PW3 TEDAPI interface with firmware 25.10.1

[pgatty]

My powerwall 3s were updated to 25.10.1 last night and pypowerwall can no longer connect to the TEDAPI interface. The loss of connectivity corresponds exactly to when the firmware was updated. Here's the output from verify.sh. Any ideas?

./verify.sh
Verify Powerwall-Dashboard 4.6.3 on Linux - Timezone: America/Los_Angeles

This script will attempt to verify all the services needed to run
Powerwall-Dashboard. Use this output when you open an issue for help:
https://github.com/jasonacox/Powerwall-Dashboard/issues/new

Checking pypowerwall

• Config File pypowerwall.env: GOOD
• Container (pypowerwall): GOOD
• Service (port 8675): ERROR: Not Listening
• Version: Unknown
• Powerwall State: ERROR: Not Connected - Firmware: Unknown
• Gateway TEDAPI: Available (192.168.91.1)
• TEDAPI Vitals: Not Connected
• Cloud Mode: NO

Checking telegraf

• Config File telegraf.conf: GOOD
• Local Config File telegraf.local: GOOD
• Container (telegraf): GOOD
• Version: Telegraf 1.28.2 (git: HEAD@8d9cf395)

Checking influxdb

• Config File influxdb.conf: GOOD
• Environment File influxdb.env: GOOD
• Container (influxdb): GOOD
• Service (port 8086): GOOD
• Filesystem (./influxdb): GOOD
• Version: InfluxDB shell version: 1.8.10

Checking grafana

• Config File grafana.env: GOOD
• Container (grafana): GOOD
• Service (port 9000): GOOD
• Filesystem (./grafana): GOOD
• Version: Grafana CLI version 9.1.2

Checking weather411

• Container (weather411): GOOD
• Service (port 8676): GOOD
• Weather: {"temperature": null}
• Version: 0.2.3

One or more tests failed.

[pgatty]

Looking at the docker logs I see this. It's complaining about a bad/missing password. The pypowerwall.env file still has the proper password under the PW_GW_PWD= setting.

docker logs -f pypowerwall
04/03/2025 08:23:25 AM [proxy] [INFO] pyPowerwall [0.12.7] Proxy Server [t68] - HTTP Port 8675
04/03/2025 08:23:25 AM [proxy] [INFO] pyPowerwall Proxy Started
04/03/2025 08:23:25 AM [pypowerwall.tedapi] [ERROR] Access Denied: Check your Gateway Password
04/03/2025 08:23:25 AM [pypowerwall.tedapi] [ERROR] Failed to connect to Powerwall Gateway
04/03/2025 08:23:25 AM [pypowerwall.tedapi] [ERROR] Access Denied: Check your Gateway Password
04/03/2025 08:23:25 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?")

[pgatty]

Ping and curl both work so this doesn't appear to be a network issue.

[Screen-nam3]

I'm experiencing issues as well timed with the firmware update.
verify.sh shows the same output as yours does buy my docker logs complain about max retries. Everything was working fine and the only thing that changed was the firmware update:

04/03/2025 10:01:28 AM [pypowerwall.tedapi] [ERROR] Error fetching config: HTTPSConnectionPool(host='192.168.91.1', port=443): Max retries exceeded with url: /tedapi/v1 (Caused by ConnectTimeoutError(<urllib3.connection.HTTPSConnection object at 0x7ffee7c9a260>, 'Connection to 192.168.91.1 timed out. (connect timeout=5)'))
04/03/2025 10:01:28 AM [pypowerwall.tedapi] [ERROR] Error fetching controller data: HTTPSConnectionPool(host='192.168.91.1', port=443): Max retries exceeded with url: /tedapi/v1 (Caused by ConnectTimeoutError(<urllib3.connection.HTTPSConnection object at 0x7ffee75fb010>, 'Connection to 192.168.91.1 timed out. (connect timeout=5)'))
04/03/2025 10:01:33 AM [pypowerwall.tedapi] [ERROR] Error fetching status: HTTPSConnectionPool(host='192.168.91.1', port=443): Max retries exceeded with url: /tedapi/v1 (Caused by ConnectTimeoutError(<urllib3.connection.HTTPSConnection object at 0x7ffee71456c0>, 'Connection to 192.168.91.1 timed out. (connect timeout=5)'))
04/03/2025 10:01:33 AM [pypowerwall.tedapi] [ERROR] Error fetching config: HTTPSConnectionPool(host='192.168.91.1', port=443): Max retries exceeded with url: /tedapi/v1 (Caused by ConnectTimeoutError(<urllib3.connection.HTTPSConnection object at 0x7ffee7147460>, 'Connection to 192.168.91.1 timed out. (connect timeout=5)'))
04/03/2025 10:01:34 AM [pypowerwall.tedapi] [ERROR] Error fetching controller data: HTTPSConnectionPool(host='192.168.91.1', port=443): Max retries exceeded with url: /tedapi/v1 (Caused by ConnectTimeoutError(<urllib3.connection.HTTPSConnection object at 0x7ffee7cd1ae0>, 'Connection to 192.168.91.1 timed out. (connect timeout=5)'))

[Nexarian]

Max retries means you're using a newer version of pypowerwall, that's fine.

It looks like from this discussion Tesla has changed something regarding the TEDAPI access in their firmware. Currently the only known workaround is to use the TED wifi connection directly.

[pgatty]

Does the Powerwall 3 support querying the data from the TED wifi connection?

[Nexarian]

I do not have a PW3, but I believe it does.

[pgatty]

Prior to 25.10.1, the only way to pull dashboard data from a Powerwall 3 was to use the TEDAPI interface listening on 192.168.91.1. Unless Tesla enabled the API on the wifi interface with 25.10.1, there's no way for us to pull the data. Do you know of any commands I can run against the wifi interface to test?

[jasonacox]

Hi @pgatty - It would be sad if this Firmware update breaks our ability to get to the TEDAPI endpoint over the network. I know others are looking at this (and other options), but for now, there are two options:

1. Switch to cloud mode (using Tesla Owners API or FleetAPI) - this can be done by re-running setup.sh and switching to one of these cloud modes (https://github.com/jasonacox/Powerwall-Dashboard?tab=readme-ov-file#cloud-and-fleetapi-mode and https://github.com/jasonacox/pypowerwall?tab=readme-ov-file#setup) - Downside is that this will have only the basic metrics at lower fidelity (sample rate), no extended data.
2. Create a WiFi bridge - See https://gist.github.com/jasonacox/91479957d0605248d7eadb919585616c) - This is a lot more complex but if it becomes the only option, we will need to consider more automated ways to make it easier.

[jasonacox]

Based on some discussion findings, and suggestions by @Nexarian, we may be able to update the add_route.sh script to something like this belwow. This is UNTESTED - I don't yet have this update, but putting it out there for consideration.

#!/bin/bash

# Check for required parameter GATEWAY_LAN_IP
if [ "$#" -lt 1 ]; then
    echo "Usage: $0 <GATEWAY_LAN_IP> [LAN_IP_OF_LINUX_MACHINE]"
    exit 1
fi

GATEWAY="$1"

# If LAN_IP_OF_LINUX_MACHINE is not provided, retrieve the IP address of eth0.
if [ -n "$2" ]; then
    LINUX_IP="$2"
else
    LINUX_IP=$(ip -4 addr show eth0 | grep -oP '(?<=inet\s)\d+(\.\d+){3}' | head -n1)
fi

# Enable IP forwarding
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward

# Assign IP address to eth0
sudo ip addr add 192.168.91.100/24 dev eth0

# Add custom routing table entry (append only if not already present)
echo '100 inverter1' | sudo tee -a /etc/iproute2/rt_tables

# Add route in table 100 using the specified gateway
sudo ip route add 192.168.91.1/32 via "$GATEWAY" dev eth0 onlink table 100

# Apply iptables rules using iptables-restore for efficiency
sudo iptables-restore <<EOF
*nat
-A OUTPUT -d 192.168.91.100 -j DNAT --to-destination 192.168.91.1
-A PREROUTING -d 192.168.91.100 -j DNAT --to-destination 192.168.91.1
-A POSTROUTING -s 192.168.91.100 -d 192.168.91.1 -j SNAT --to-source $LINUX_IP
COMMIT
*mangle
-A OUTPUT -d 192.168.91.100 -j MARK --set-mark 1
COMMIT
EOF

# Add routing rule based on the packet mark
sudo ip rule add fwmark 1 table 100

Then setup would be:

# Example
./add_route.sh 192.168.1.123

[pgatty]

@jasonacox - Thanks for taking the time to respond and the wonderful dashboard. It has been invaluable in helping me troubleshoot issues with my solar/battery installation. I've read through the discussion of this issue and from what I understand it sounds like the TEDAPI that's listening on 192.168.91.1 is no longer accepting queries from anything outside of 192.168.91.0/24.

I'm currently running the dashboard on a Linux VM. The IP of the VM is 10.255.250.38 on interface ens160. This IP is on the same subnet as the wifi interface of the powerwall (10.255.250.39). When I originally installed the software I ran add-route.sh to route traffic to 192.168.91.1 through the IP of the powerwall 10.255.250.39.

Apologies, but I'm struggling a little to understand the updated routing script you posted. It looks like it's trying to set the IP of eth0 to 192.168.91.100. Do I need to create a second interface on the VM (say ens161), change eth0 to ens161 in your script and run it to assign 192.168.91.100 to ens161? If so how will the traffic get to the 192.168.91.1 TEDAPI interface.

Apologies again for not grasping this.

[jasonacox]

No worries @pgatty - this is "hard mode" right now and I don't have any way to validate without getting the upgrade.

Switch to Cloud Mode

To get your system running again, I would recommend switching to cloud mode:

# Run setup
./setup.sh

Select "2 - Tesla Cloud" mode, have it wipe out existing configuration settings and follow the instructions (includes logging into Tesla website and copying and pasting the URL when prompted. At least you will get the basic metrics again.

Example Setup

pi@rpi:~/Powerwall-Dashboard $ ./setup.sh 
Powerwall Dashboard (v4.6.5) - SETUP
-----------------------------------------
Select configuration mode:

Current: Local Access

 1 - Local Access   (Powerwall 1, 2, or + using the Tesla Gateway on LAN) - Default
 2 - Tesla Cloud    (Solar-only systems or Powerwalls without LAN access)
 3 - FleetAPI Cloud (Powerwall systems using Official Telsa API)
 4 - Powerwall 3    (Powerwall 3 using the local Tesla Gateway)

Select mode: [1] 2

You are already using the Local Access configuration, are you sure you wish to change? [y/N] y

Timezone (leave blank for America/Los_Angeles)
Enter Timezone: 

Enter email address for Tesla Account...
Email: xxxxxxx@xxxxx.xxx
If you have a Solar-only system, you can customize the dashboard for Solar and
hide the Powerwall metrics.

Set dashboard to Solar-only system? [y/N] 

Using America/Los_Angeles timezone...
-----------------------------------------

Found existing location coordinates for sun cycle.
   Your current location appears to be Latitude: 34.3xxxxxx, Longitude: -118.xxxxx

Enter Latitude (default: 34.xxxxxx): 
Enter Longitude (default -118.xxxxxxx): 

Weather Data Setup
-----------------------------------------
Weather data from OpenWeatherMap can be added to your Powerwall Dashboard
graphs.  This requires that you set up a free account with OpenWeatherMap
and enter the API Key during this setup process.

Do you wish to setup Weather Data? [y/N] 
No problem. If you change your mind, run weather.sh to setup later.

Running Docker Compose...
[+] Running 5/5
 ✔ Container influxdb     Running                                                                                  0.0s 
 ✔ Container pypowerwall  Started                                                                                  2.9s 
 ✔ Container weather411   Running                                                                                  0.0s 
 ✔ Container grafana      Running                                                                                  0.0s 
 ✔ Container telegraf     Started                                                                                  2.1s 
-----------------------------------------
pyPowerwall [0.12.9] - Cloud Mode Setup

Tesla Account Setup
------------------------------------------------------------

  Email address: xxxxxxx@xxxxx.xxx

Open the below address in your browser to login.

https://auth.tesla.com/oauth2/v3/authorize?xxxxxxxxxxxxxx

After login, paste the URL of the 'Page Not Found' webpage below.

Enter URL after login: https://auth.tesla.com/void/callbackxxxxxxxxxxxx
------------------------------------------------------------

1 Sites Found (* = default)
------------------------------------------------------------
 *1 - Energy Gateway (xxxxxxxxxx) - Type: battery

  Select a site [1]: 

Selected site 1 - Energy Gateway (xxxxxxxxxx)
Setup Complete. Auth file .auth/.pypowerwall.auth ready to use.
Restarting...
pypowerwall
-----------------------------------------
Waiting for InfluxDB to start...
 up!
Setup InfluxDB Data... ('already exist' errors harmless)
2025/04/05 21:37:22 error: retention policy already exists
2025/04/05 21:37:22 error: retention policy already exists
2025/04/05 21:37:22 error: retention policy already exists
2025/04/05 21:37:23 error: continuous query already exists
2025/04/05 21:37:23 error: continuous query already exists
2025/04/05 21:37:23 error: continuous query already exists
Fetching local weather...
weather411
------------------[ Final Setup Instructions ]-----------------

Open Grafana at http://localhost:9000/ ... use admin/admin for login.

To complete *Grafana Setup*:

* From 'Dashboard\Browse', select 'New/Import', browse to /home/pi/Powerwall-Dashboard/dashboards
  and upload 'dashboard.json' or 'dashboard-solar-only.json'.

NOTE: The datasources for InfluxDB and SunAndMoon are already configured.
If you need to modify them via Configuration\Data Sources:

* InfluxDB
  - URL: 'http://influxdb:8086'
  - Database: 'powerwall'
  - Min time interval: '5s'
  - Click "Save & test" button

* Sun and Moon
  - Enter your latitude and longitude (tool here: https://bit.ly/3wYNaI1 )
  - Click "Save & test" button

[jasonacox]

For any linux/network gurus, help us try to find a way to do SNAT routing from the host to the Powerwall/GW TEDAPI endpoint. Speculation:

sudo echo 1 > /proc/sys/net/ipv4/ip_forward
sudo ip addr add 192.168.91.100/24 dev eth0
sudo echo '100 inverter1' | sudo tee -a /etc/iproute2/rt_tables
sudo ip route add 192.168.91.1/32 via [GATEWAY_LAN_IP] dev eth0 onlink table 100
sudo iptables -t nat -A OUTPUT -d 192.168.91.100 -j DNAT --to-destination 192.168.91.1
sudo iptables -t nat -A PREROUTING -d 192.168.91.100 -j DNAT --to-destination 192.168.91.1
sudo iptables -t mangle -A OUTPUT -d 192.168.91.100 -j MARK --set-mark 1
sudo ip rule add fwmark 1 table 100
sudo iptables -t nat -A POSTROUTING -s 192.168.91.100 -d 192.168.91.1 -j SNAT --to-source [LAN_IP_OF_LINUX_MACHINE]

[Nexarian]

Apologies, this script was written for a very specific purpose for my own inverter setup: 2x standalone inverters, which means I have 2x independent gateways, each with their own TEG wifi and site controller. I had planned on making it more palatable but didn't realize it would be needed this soon. I recognize it is wildly complex. It took me weeks to get right.

From what I understand it sounds like the TEDAPI that's listening on 192.168.91.1 is no longer accepting queries from anything outside of 192.168.91.0/24

• This is the supposition. I also don't have the the 25.10 version.

It looks like it's trying to set the IP of eth0 to 192.168.91.100

• No, it's adding a "virtual" IP address TO eth0. But your network interface isn't eth0, it's ens160, so we use that instead. We don't need to create new interfaces.

Do I need to create a second interface on the VM (say ens161), change eth0 to ens161 in your script and run it to assign 192.168.91.100 to ens161?

• See above, I don't believe this to be necessary.

@pgatty Given the data you provided, the script that would work for you would be:

# Makes things easier
sudo -v
sudo echo 1 > /proc/sys/net/ipv4/ip_forward
sudo echo '100 inverter1' | sudo tee -a /etc/iproute2/rt_tables
#These 3 lines use the data you've given me
sudo ip addr add 192.168.91.100/24 dev ens160
sudo ip route add 192.168.91.1/32 via 10.255.250.39 dev ens160 onlink table 100
sudo iptables -t nat -A POSTROUTING -s 192.168.91.100 -d 192.168.91.1 -j SNAT --to-source 10.255.250.38
# These 4 lines do not change
sudo iptables -t nat -A OUTPUT -d 192.168.91.100 -j DNAT --to-destination 192.168.91.1
sudo iptables -t nat -A PREROUTING -d 192.168.91.100 -j DNAT --to-destination 192.168.91.1
sudo iptables -t mangle -A OUTPUT -d 192.168.91.100 -j MARK --set-mark 1
sudo ip rule add fwmark 1 table 100

Make sure you reboot your linux machine before running this, to clear out any previous settings.

@jasonacox I'm not sure if we want to use iptables-restore because it could clobber any existing rules.

[Nexarian]

@pgatty Also, you may need to enable nework_mode: host on your powerwall.yml file. See my example