pypowerwall can't connect to PW3 TEDAPI interface with firmware 25.10.1 #606
Comments
pgatty
changed the title
|
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 |
|
Ping and curl both work so this doesn't appear to be a network issue. |
|
I'm experiencing issues as well timed with 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)')) |
|
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. |
|
Does the Powerwall 3 support querying the data from the TED wifi connection? |
|
I do not have a PW3, but I believe it does. |
|
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? |
|
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:
|
|
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 100Then setup would be: # Example
./add_route.sh 192.168.1.123 |
|
@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. |
|
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 ModeTo get your system running again, I would recommend switching to cloud mode: # Run setup
./setup.shSelect "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 |
|
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] |
|
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.
@pgatty Given the data you provided, the script that would work for you would be: 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 |
|
@pgatty Also, you may need to enable |
|
@pgatty Also because we've switched to |
|
Thanks @Nexarian. I'm assuming I need to remove the existing static route the was created using the add_roiute.sh script by commenting out the following line in root's cron file Is this correct? If so how do the network packets find their way to 192.168.91.1? |
|
I flashed a new RPi and was able to run this script to get access to the TEDAPI data. Keep in mind this is still on the old Firmware so may not work on the 25.10.1. #!/bin/bash
# This script configures networking on the Linux server.
# It prompts for POWERWALL_IP and uses auto-detection for the default network interface and host IP.
# Refresh sudo credentials.
sudo -v
# Determine default network interface from the default route.
default_interface=$(ip route | awk '/default/ {print $5; exit}')
if [ -z "$default_interface" ]; then
echo "Could not determine the default network interface."
read -p "Please enter the network interface: " default_interface
fi
# Determine the default host IP address for the selected interface.
default_host_ip=$(ip -o -4 addr list "$default_interface" | awk '{print $4}' | cut -d/ -f1)
if [ -z "$default_host_ip" ]; then
echo "Could not determine the host IP address."
read -p "Please enter the host IP address: " default_host_ip
fi
# Prompt the user for values with detected defaults.
read -p "Enter network interface to use [${default_interface}]: " user_interface
INTERFACE=${user_interface:-$default_interface}
read -p "Enter host IP address to use [${default_host_ip}]: " user_host_ip
HOST_IP=${user_host_ip:-$default_host_ip}
read -p "Enter POWERWALL IP address: " POWERWALL_IP
echo ""
echo "Using the following settings:"
echo " Interface: $INTERFACE"
echo " Host IP: $HOST_IP"
echo " POWERWALL: $POWERWALL_IP"
echo ""
# Enable IP forwarding (using tee to ensure redirection happens with sudo).
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
# Append custom routing table entry.
echo '100 inverter1' | sudo tee -a /etc/iproute2/rt_tables
# Configure the IP address on the selected interface.
sudo ip addr add 192.168.91.100/24 dev "$INTERFACE"
# Add a route for 192.168.91.1 using the provided POWERWALL_IP via the selected interface.
sudo ip route add 192.168.91.1/32 via "$POWERWALL_IP" dev "$INTERFACE" onlink table 100
# Set up NAT rules to handle source and destination translation.
sudo iptables -t nat -A POSTROUTING -s 192.168.91.100 -d 192.168.91.1 -j SNAT --to-source "$HOST_IP"
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
# Add a rule to use the custom routing table for marked packets.
sudo ip rule add fwmark 1 table 100
echo ""
echo "Done - Use this as your PW gateway: 192.168.91.100"
echo ""If you save that as I tested with |
|
@jasonacox - I ran your script and rebooted and I still can't connect. Should I see 192.168.91.100 IP assigned to my primary interface?
Also, I tried running your test above, but get the following error. I'm not sure how to add the pypowerwall.tedapi module
|
|
|
|
Please run: pip install pypowerwallAlso, the script was not set to persist a reboot (it would clear the ip routes). Here is a version that persists by using the reboot crontab method: #!/bin/bash
# This script configures networking on the Linux server and creates a boot script
# that will re-establish the network settings at every reboot.
# Refresh sudo credentials.
sudo -v
# Determine default network interface from the default route.
default_interface=$(ip route | awk '/default/ {print $5; exit}')
if [ -z "$default_interface" ]; then
echo "Could not determine the default network interface."
read -p "Please enter the network interface: " default_interface
fi
# Determine the default host IP address for the selected interface (only the first IP).
default_host_ip=$(ip -o -4 addr list "$default_interface" | awk '{print $4}' | cut -d/ -f1 | head -n1)
if [ -z "$default_host_ip" ]; then
echo "Could not determine the host IP address."
read -p "Please enter the host IP address: " default_host_ip
fi
# Prompt the user for values with detected defaults.
read -p "Enter network interface to use [${default_interface}]: " user_interface
INTERFACE=${user_interface:-$default_interface}
read -p "Enter host IP address to use [${default_host_ip}]: " user_host_ip
HOST_IP=${user_host_ip:-$default_host_ip}
read -p "Enter POWERWALL IP address: " POWERWALL_IP
echo ""
echo "Using the following settings:"
echo " Interface: $INTERFACE"
echo " Host IP: $HOST_IP"
echo " POWERWALL: $POWERWALL_IP"
echo ""
# Enable IP forwarding.
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
# Append custom routing table entry if it isn't already present.
if ! grep -q "^100 inverter1" /etc/iproute2/rt_tables; then
echo '100 inverter1' | sudo tee -a /etc/iproute2/rt_tables
fi
# Configure the IP address on the selected interface if not already assigned.
if ! ip addr show "$INTERFACE" | grep -q "192.168.91.100"; then
sudo ip addr add 192.168.91.100/24 dev "$INTERFACE"
fi
# Add a route for 192.168.91.1 using the provided POWERWALL_IP via the selected interface.
sudo ip route replace 192.168.91.1/32 via "$POWERWALL_IP" dev "$INTERFACE" onlink table 100
# Set up NAT rules without duplicating them.
if ! sudo iptables -t nat -C POSTROUTING -s 192.168.91.100 -d 192.168.91.1 -j SNAT --to-source "$HOST_IP" 2>/dev/null; then
sudo iptables -t nat -A POSTROUTING -s 192.168.91.100 -d 192.168.91.1 -j SNAT --to-source "$HOST_IP"
fi
if ! sudo iptables -t nat -C OUTPUT -d 192.168.91.100 -j DNAT --to-destination 192.168.91.1 2>/dev/null; then
sudo iptables -t nat -A OUTPUT -d 192.168.91.100 -j DNAT --to-destination 192.168.91.1
fi
if ! sudo iptables -t nat -C PREROUTING -d 192.168.91.100 -j DNAT --to-destination 192.168.91.1 2>/dev/null; then
sudo iptables -t nat -A PREROUTING -d 192.168.91.100 -j DNAT --to-destination 192.168.91.1
fi
if ! sudo iptables -t mangle -C OUTPUT -d 192.168.91.100 -j MARK --set-mark 1 2>/dev/null; then
sudo iptables -t mangle -A OUTPUT -d 192.168.91.100 -j MARK --set-mark 1
fi
# Add a rule to use the custom routing table for marked packets.
if ! sudo ip rule list | grep -q "fwmark 1 table 100"; then
sudo ip rule add fwmark 1 table 100
fi
# Generate the boot script that will run at each reboot.
BOOT_SCRIPT="/root/setup_powerwall.sh"
sudo bash -c "cat > $BOOT_SCRIPT" <<EOF
#!/bin/bash
# Boot script to set up Powerwall networking
echo 1 > /proc/sys/net/ipv4/ip_forward
if ! grep -q "^100 inverter1" /etc/iproute2/rt_tables; then
echo '100 inverter1' >> /etc/iproute2/rt_tables
fi
if ! ip addr show "$INTERFACE" | grep -q "192.168.91.100"; then
ip addr add 192.168.91.100/24 dev $INTERFACE
fi
ip route replace 192.168.91.1/32 via $POWERWALL_IP dev $INTERFACE onlink table 100
if ! iptables -t nat -C POSTROUTING -s 192.168.91.100 -d 192.168.91.1 -j SNAT --to-source $HOST_IP 2>/dev/null; then
iptables -t nat -A POSTROUTING -s 192.168.91.100 -d 192.168.91.1 -j SNAT --to-source $HOST_IP
fi
if ! iptables -t nat -C OUTPUT -d 192.168.91.100 -j DNAT --to-destination 192.168.91.1 2>/dev/null; then
iptables -t nat -A OUTPUT -d 192.168.91.100 -j DNAT --to-destination 192.168.91.1
fi
if ! iptables -t nat -C PREROUTING -d 192.168.91.100 -j DNAT --to-destination 192.168.91.1 2>/dev/null; then
iptables -t nat -A PREROUTING -d 192.168.91.100 -j DNAT --to-destination 192.168.91.1
fi
if ! iptables -t mangle -C OUTPUT -d 192.168.91.100 -j MARK --set-mark 1 2>/dev/null; then
iptables -t mangle -A OUTPUT -d 192.168.91.100 -j MARK --set-mark 1
fi
if ! ip rule list | grep -q "fwmark 1 table 100"; then
ip rule add fwmark 1 table 100
fi
EOF
# Make the boot script executable.
sudo chmod +x "$BOOT_SCRIPT"
# Add a crontab entry for @reboot to root's crontab if not already present.
CRON_ENTRY="@reboot $BOOT_SCRIPT"
if ! sudo crontab -l 2>/dev/null | grep -Fq "$BOOT_SCRIPT"; then
(sudo crontab -l 2>/dev/null; echo "$CRON_ENTRY") | sudo crontab -
fi
# Run the boot script now.
sudo "$BOOT_SCRIPT"
echo "Done! Set your Powerwall Gateway to 192.168.91.100" |
|
Do I need to remove the existing static route the was created using the original add_route.sh script by commenting out the following line in root's cron file Also, do I need make the other updates recommended by @Nexarian?
|
|
I think if you're running pypowerwall directly (not in docker for the dashboard), for this initial test no, you can skip those. The crontab should be running @jasonacox's new script instead. The old script is no longer going to work. |
|
@Nexarian is right... remove the existing entry in crontab. However, I've noticed that my script needs some updates to persist after reboot. You should be able to run the script and then run the test (no reboot): python3 -m pypowerwall.tedapi --gw_ip 192.168.91.100That will help us verify if this approach is even worth considering. If it does work, there is more work to make this actually work with the dashboard. Sorry, you are guinea pig since I don't have a local new Firmware version to test. 😉 Also, I'm "vibe coding" my way through this just to deduce the right path. |
|
I'm spinning up a new VM now for testing. |
|
@jasonacox Thanks for helping simplify things. One of my greatest weaknesses as an engineer is I tend to make things overly complex. It helps figure out solutions like this, but then one day I have to explain it to others and... 🤯 |
|
another stupid question... I've got the new VM up (ubuntu 24.04) and I installed python via I then tried to install pypowerwall with and I get the following error. error: externally-managed-environment This environment is externally managed To install Python packages system-wide, try apt install If you wish to install a non-Debian-packaged Python package, If you wish to install a non-Debian packaged Python application, See /usr/share/doc/python3.12/README.venv for more information. note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages. Any idea how to get pypowerwall installed? Should I just run |
|
You can set up a virtual python env and it will work: python -m venv .venv
source .venv/bin/activate
pip install pypowerwall
python3 -m pypowerwall.tedapi --gw_ip 192.168.91.100
# Do this so it always uses that venv
echo "source .venv/bin/activate" >> ~/.bashrc |
|
Well this doesn't look good. FYI... I used the
Enter Powerwall Gateway Password: redacted Connecting to Powerwall Gateway 192.168.91.100 ERROR: Unable to connect to Powerwall Gateway. Check your password and try again |
|
For reference, here's what mine looks like: |
|
Also @pgatty just to eliminate any issues with my script (and the conditions it has), did you try running what @Nexarian sent? Reboot and try: # 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
# And see if connection works
python -m pypowerwall.tedapi --gw_ip 192.168.91.100 |
|
I've confirmed the Tesla One app is still working and checked again with I think the only option might be the wifi gateway bridge. All my Raspberry Pi's are in use. I'll need to order a new one with wifi and see if I can get it working. Are the instructions in the link above still good? |
|
Just to verify, try I haven't used the gateway bridge in a while but it should still be good. |
|
I tried that and it yielded the same results. |
|
I set up a spare Raspberry Pi, hardwired it to my network LAN and set up the WiFi to join the TEG (Powerwall) access point. I recorded the steps in my setup this afternoon in case it is helpful to others: #607 |
|
@jasonacox @pgatty I woke up at 4:00 AM with another idea. The following line may be the problem:
Note: It's still indicating to the gateway that the source is Can you set up a static route on your router that does the equivalent of this command and remove the POSTROUTING rule and try again?
@erikgieseler said he "did the equivalent" of the rules I listed, but the POSTROUTING rule is not necessary if implementing at the router level. |
Alright, this could mean that as a community we have to get much better at helping with WiFi connections to TEG. For my specific situation, I'm going to need TWO TEG wifi connections. I can either do that with 2x RPis or add a WiFi dongle to the RPi. We might want to start maintaining a list of external wifi dongles for the RPi that work. Certainly that's all over the Internet, but I like to think our little community is a cut above the rest in terms of reliable quality :) |
|
I can recommend the D-Link DWA-131 (Rev. E1).
|
|
I'm trying to make sure everything has an egregiously large high-gain antenna. Generally I hate WiFi where a wired connection will do, so this is my best defense. As such, this looks to be a decent first try: https://www.amazon.com/dp/B08NPX2X4Z |
|
Nice @Nexarian ! 😄 And thanks @erikgieseler , good to know.
Yes, good point. I see a lot of threads about setting up simultaneous WiFi connections on an RPi's with just the single built-in WiFi, but I believe the Cypress CYW43455 chip does not do dual-band. Also, @Nexarian , on your 4am wake-up idea, you are right. I tried removing it and it breaks things. |
|
Yes, very few WiFi cards support connecting to multiple networks simultaneously. Additionally, I'd recommend looking into this or an equivalent. Effectively adding a high-gain antenna to your RPi. The TEG wifi, from reading many sources over time all over the Internet, has a reputation for being weak, so everything we can do to compensate will help. @jasonacox Yes, removing that will break things IFF you don't set up a reverse-static-route on your router. If you DO set up such a route, in theory it will work. That line was the last piece that took me nearly a month to find to get my crazy dual-route setup working in the first place. |
|
I decided to go down the road of installing the the Powerwall dashboard on a Pi. I had an 8GB Pi 5 with a 250GB SSD that I reprovisioned to run the Dashboard. Wireless was easy to setup and get connected to the Powerwall. Everything is running normally. Random question, Is there an easy way to transfer the historical data from the old dashboard server to the Pi? I'm assuming everything is in Influx. |
|
That's great news! Way to go @pgatty !
Well, yes, but does require some effort. This discussion may help: #326 but in summary: # On OLD host
cd Powerwall-Dashboard
# stop influxdb to ensure nothing is being written
docker stop influxdb
# create archive
sudo tar -zcvf snapshot.tgz influxdb
# start influxdb back up
docker start influxdb
# copy snapshot.tgz to new host...
# On NEW host
cd Powerwall-Dashboard
# Stop the stack
./compose-dash.sh stop
# unarchive and use same owner
sudo tar --no-same-owner -zxvf snapshot.tgz
# Start the stack
./compose-dash.sh up -d |
|
@jasonacox - Thanks. Restoring the data was a lot easier than I thought |
|
I'm going to make an offer here: I can usually follow network discussions, but some of this stuff is just outside my understanding. I'm just trying to say I can follow instructions, but I'm not good at sussing this stuff out myself. I'm willing to take what I have and work to find a way to get things connected up purely at the pypowerwall level without having to involve the dashboard. I just need suggestions of things to try. I have an RPi 5 that really has no other purpose than running pypowerwall to fetch data from the primary PW3 and make it available for me to stuff in my own database. This Pi has a USB Ethernet dongle on it. I had used it to put the eth1 in the 192.168.90.0/24 space so it could talk directly to the PW3. My routing was as follows: jjames@piwall:/space/cron/pywall $ sudo ip route show This was working for me until this morning. Using the Tesla One app, I found that I have a LAN connection on the primary PW at 192.168.1.174, and a Wifi connection at 192.168.1.198. I'm happy to try routing something somewhere else, pulling the dongle out, etc. |
Which firmware do you have now? |
|
My apologies: I'd mentioned I'm still on 25.2.6 - but I'd put that in another post on a different discussion. I'm not sure why this chose to stop working today for no apparent reason when it was working through most of the night. |
|
@JohnJ9ml A suggestion: Pick ONE: Wired ethernet or WiFi. Even if both are functioning properly, having both enabled will make troubleshooting anything that much harder. |
|
I'm trying to follow this whole discussion and got a little lost. Have we determined that 25.10.* refuses all connections that don't connect via the TEG WiFi regardless of IP source address or is there still some ability to spoof the source the traffic is coming from? |
|
@jgleigh At this time I know of no way to get TEG data through wired LAN/ethernet on firmware versions starting at 25.10.* -- Tesla appears to have blocked the static route path, and nobody in the community has found a workaround other than switching to wifi. We tried a lot of different things and @erikgieseler applied his network admin expertise, too, but thus far; nothing. The best path, I think, is to start trying to start a dialog with Tesla on a supported path here. This is how I solved mine. Note that on regular inverters, the antenna is on the top. On a good day, I get nearly -20 dBm signal strength. |
|
My garage gets way too hot in Arizona summers, but I should be able to pickup the TEG WiFi from a room near my Gateway. |
|
In addition to my PW3s I also have a SPAN panel. The SPAN communicates with the PW3 via ethernet, and I occasionally see an extra IP (10.42.1.1) on that switch port. I suspect that's a special IP used for partners to communicate with the PW3 via ethernet, but I don't know what port, protocol, or anything else it uses at this point. When I'm next there I plan to try using that IP to see if I can get it to work (I don't make changes when I'm not onsite because my routing setup is a bit complex). If someone's impatient they could try doing that before I head back there later this year. |
|
My home lab runs in the garage, conveniently in range of my PW3 Wi-Fi. Mapping the unused Wi-Fi adapter to the guest Ubuntu VM in Proxmox works. Below is my netplan config. Note my Wi-Fi was renamed from wlan0 to wls16. |
|
I tried moving the whole dashboard to the RPi but didn't like the performance and was having some issues with the WiFi connection. Not sure what was going on but the WiFi kept dropping the connection to the Gateway. Might be related to the external antenna. Went back to just using the RPi as the WiFi bridge using the built-in antenna and it again appears stable and my computer running the dashboard is able to access the TEDAPI through the bridge. I'm going to keep watching it but so far so good. I'm still on 25.2.1 but wanted to be ready for 25.10.x when it comes out. I'm also in Hybrid mode with PW+ units. |
Same for me @jgleigh - I have multiple configs set up so I can see what happens when it upgrades. Let us know what you see when yours upgrades. |
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
Checking telegraf
Checking influxdb
Checking grafana
Checking weather411
One or more tests failed.
The text was updated successfully, but these errors were encountered: