5.2.3 seems to revert to a SolarOnly install

[ViktorJp]

It's been a while! :) So, my install will sometimes revert to SolarOnly, but it will quickly correct itself. After installing 5.2.3, for some reason it will no longer recover from being in SolarOnly mode. I've tried reboots (first thing), reran setup, restarted containers, etc. The route is still in place, and not seeing anything else out of the ordinary. My 3 x Powerwall 2's are on FW: 26.26.2

Hoping you might have some ideas? I may need to try to revert to a previous version to see if that helps fix this. Is there an easy way to possibly do this if all else fails?

==== pypowerwall logs ====
08/26/2026 10:18:19 PM [pypowerwall.local.pypowerwall_local] [ERROR] Timeout waiting for Powerwall API /api/sitemaster - check network connectivity to 192.168.91.1
08/26/2026 10:18:19 PM [pypowerwall.local.pypowerwall_local] [ERROR] Timeout waiting for Powerwall API /api/meters/aggregates - check network connectivity to 192.168.91.1
08/26/2026 10:18:20 PM [pypowerwall.local.pypowerwall_local] [ERROR] Timeout waiting for Powerwall API /api/devices/vitals - check network connectivity to 192.168.91.1
08/26/2026 10:18:20 PM [pypowerwall.local.pypowerwall_local] [ERROR] Timeout waiting for Powerwall API /api/meters/aggregates - check network connectivity to 192.168.91.1
08/26/2026 10:18:20 PM [pypowerwall.local.pypowerwall_local] [ERROR] Timeout waiting for Powerwall API /api/system_status/grid_status - check network connectivity to 192.168.91.1
08/26/2026 10:18:20 PM [pypowerwall.local.pypowerwall_local] [ERROR] Timeout waiting for Powerwall API /api/system_status/soe - check network connectivity to 192.168.91.1
08/26/2026 10:18:20 PM [pypowerwall.local.pypowerwall_local] [ERROR] Timeout waiting for Powerwall API /api/operation - check network connectivity to 192.168.91.1
08/26/2026 10:18:21 PM [pypowerwall.local.pypowerwall_local] [ERROR] Timeout waiting for Powerwall API /api/system_status/soe - check network connectivity to 192.168.91.1
08/26/2026 10:18:21 PM [pypowerwall.local.pypowerwall_local] [ERROR] Timeout waiting for Powerwall API /api/sitemaster - check network connectivity to 192.168.91.1
08/26/2026 10:18:21 PM [pypowerwall.local.pypowerwall_local] [ERROR] Timeout waiting for Powerwall API /api/meters/aggregates - check network connectivity to 192.168.91.1

Let me know what else I could share? Thank you!

[jasonacox]

@jasonacox-sam - Help troubleshoot this for us.

@ViktorJp are you able to ping 192.168.91.1 from that host running pypowerwall?

Also, any useful output from running ./verify.sh ?

[jasonacox-sam]

@ViktorJp — great detail here, and the "it used to correct itself" observation is the key clue. Nice to see you back, by the way — PWRMON-on-Asus-Merlin is vintage-era around here. :)

TL;DR — this looks like a known bug in the proxy image that 5.2.x pins (jasonacox/pypowerwall:0.16.2t97): the SolarOnly fallback can latch and never recover until a restart. It's already fixed upstream in pypowerwall v0.16.4.

What's going on:

• 5.2.x moved the pinned proxy image from 0.15.13t94 (v5.1.2) to 0.16.2t97 (v5.2.0+). t97 added the TEDAPI SolarOnly fallback: when the gateway path at 192.168.91.1 drops, the proxy keeps serving solar data, and a background recovery thread is supposed to reconnect and resume full telemetry.
• The bug: on t97 that recovery thread can wedge after a failed attempt — attempt pypowerwall container for arm64 and arm/v7 #1 fails, no further attempt is ever made, and the proxy stays in SolarOnly until the container restarts. Documented in pypowerwall proxy latches into "SolarOnly" after a startup network blip and never recovers; /health returns 200 so the healthcheck and watchdog.sh can't detect it #821 and upstream pypowerwall#366 (fixed in PR Pypowerwall is stopped working after firmware upgrade - Tesla Pros screen? #367, released as v0.16.4). The wedge is intermittent — sometimes attempt Generating and String Power do Not Equal #2 fires and everything recovers, which is why this can look random.
• So there are two separate things here: the transient drops of the 192.168.91.x path you've always had (your original "sometimes reverts" symptom), and the new part — recovery no longer happening — which arrived with the proxy swap.

Quick confirmation while it's stuck:

# 1) Fallback state — "is_fallback_mode": true with frozen recovery_attempts /
#    last_recovery_attempt is the wedge signature from pypowerwall#366
curl -s http://localhost:8675/health

# 2) If full data comes straight back after this, diagnosis confirmed
docker restart pypowerwall

To build on the ping test above: 26.x firmware often blocks ICMP while the API still answers, so curl is the definitive reachability check:

# from the docker host — validates host → static route → gateway
curl -sk https://192.168.91.1/api/system_status/soe

# from inside the container — the exact path the proxy uses
docker exec pypowerwall curl -sk https://192.168.91.1/api/system_status/soe

If ping fails but curl works, the network is fine and it's purely the latch.

The fix — no need to revert the whole dashboard, it's a one-line image bump. In powerwall.yml:

    pypowerwall:
        image: jasonacox/pypowerwall:0.16.4t99

then bring the stack back up with ./compose-dash.sh down && ./compose-dash.sh up -d. Heads-up that this is a local override — git stash it before your next git pull/upgrade.sh, and drop it once the dashboard bumps its own pin (main still pins t97 today). 0.17.0t100 is the newest image if you'd rather take latest; 0.16.4t99 is the minimal targeted fix.

If the transient drops persist after the fix, the next thing I'd check is ip route get 192.168.91.1 on the host — if the gateway's LAN address ever changed, a "still in place" static route can silently blackhole. The verify.sh output, plus /stats (shows the active mode — TEDAPI/hybrid vs plain local), will help pin down the rest.

— Sam 🌊

[jasonacox]

@jasonacox-sam Create a PR to pin to the latest pypowerwall proxy. Update VERSION and update.sh to represent new version (v5.2.4)

[jasonacox-sam]

PR is up: #856 — pins the proxy to jasonacox/pypowerwall:0.17.0t100 and releases as v5.2.4 (VERSION + upgrade.sh + RELEASE.md, matching the v5.1.7 pin-bump convention).

No migration steps: ./upgrade.sh recreates the stack with the new image — the old pypowerwall container is torn down and rebuilt as part of the normal flow. Anyone who applied the manual powerwall.yml override suggested above can drop it; upgrade.sh stashes local edits before pulling.

@ViktorJp — once this merges, ./upgrade.sh should clear the stuck-SolarOnly behavior for good: t100 carries the recovery-wedge fix (upstream pypowerwall#367, plus the lifetime energy accumulators from #372 and bearer auth from #359). The transient drops of the gateway path are environmental, but the proxy will now keep retrying recovery instead of latching in fallback. If it ever sticks on t100, grab curl -s http://localhost:8675/health while it's wedged and post it — that'll tell us where the retry loop gave up.

— Sam 🌊