Welcome to pypowerwall-server Discussions!

[jasonacox]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[jasonacox]

[jasonacox]

[jasonacox]

[TristanBrotherton]

Is there any areas of the codebase / features you'd like some help or testing with?
I have a few PW3s and a lot of home assistant.

[jasonacox]

Hi @TristanBrotherton ! Thanks for the offer, and yes!

Connection: To get the extended metrics, we still require direct access to the Powerwall WiFi access point. This has not changed. This new server is backward compatible with the existing pypowerwall proxy that offers the same access methods for PW3: local (WiFI to TEDAPI endpoint), cloud (unofficial simple access to Tesla data), and fleetapi (official cloud API service from Tesla).

Development Help: Next step would be to add MQTT. I suspect that would make it easier to integrate with HA. Is that correct? The new server (this project) does proactive polling which would facilitate message updates. However, it would be good to define a schema that would work well with HA.

Next steps: I suggest getting the new server working to test out. There are a few options:

1. Replace Proxy in Powerwall Dashboard installation - Edit the powerwall.yml file and replace pypowerwall container image

pypowerwall:
    image: jasonacox/pypowerwall-server:0.1.7

2. Install and Run the Python Package (from host connected to PW WiFi)

# Install Package
pip install pypowerwall-server

# Run server interactively
pypowerwall-server --host 192.168.91.1 --gw-pwd ZZZZZZZZZZ --port 8675 # update password and port

Console: http://localhost:8675/

A big help would be to test, identify (or open) issues and submit PRs to fix. Of course, feature requests would be helpful as well.

[TristanBrotherton]

Hi @jasonacox - I finally installed a local wifi repeater, connected it to my powerwall wifi TeslaPW_ALUR** - I then set up the static route and i can connect locally:

python -m pypowerwall.tedapi
pyPowerwall - Powerwall Gateway TEDAPI Reader [v0.14.9]
 - Connecting to https://192.168.91.1... SUCCESS

But I am confused as to what password I use to auth - I tried the password printed on the Powerwall 3 QR code (upppercase), under the network SSID - but it failed. My setup is two Powerwall 3's - no gateway. Any idea?

[TristanBrotherton]

Aha - the issue seems to be it was falling back to an old static route, i need to find a better wifi bridge, the one I got seems to be failing to connect properly to the PW3

[jasonacox]

I should try to do that again. I just connect directly. I'm sure you are setting up the NAT, etc., but also I have found that the SSID doesn't always advertise so you likely need to tell your bridge to connect even if it doesn't see the SSID.

For any looking for it, the password required is inside the cover of the PW3:

[willhughes-au]

Next step would be to add MQTT. I suspect that would make it easier to integrate with HA. Is that correct?

After (another) cloud outage with Teslemetry I've finally decided to try and get local control of my Powerwall 3 + 2x DC Expansion packs.

So I've got the server up and running with TEDAPI mode over Wifi. I'm testing just in read-only mode at the moment until I'm happy it's stable.

Getting the data into HA was pretty easy:

But there's been some annoying bugs to squash. The biggest one is that either Tesla is booting me off the PW3 wifi, or the link is dropping for some other reason. Just waiting a few seconds is usually Ok, but I don't want to poll that frequently. I'm testing out a fix for that now, I seem to be down to one failure in the last hour, vs one failure every 4-5 minutes.

If you're OK with mostly LLM-generated code being submitted in a PR, then I'm more than happy to contribute it back. It might be this weekend or the next when I can do that. I've tried to stick to your coding standards, and make the minimal change set to implement this.

[jasonacox]

v0.1.10

[jasonacox]

Version v0.1.13

[nike-bytom]

Hi all, Love the Powerwall dashboard! . Installed on PI .... any idea why PW2 not showing Voltage, kW and Hz? It is showing correctly in NetZero app. Thank you

[jasonacox-sam]

Hi @nike-bytom — welcome! 👋

The missing Voltage, kW, and Hz readings on PW2 is a known limitation. PW2 via TEDAPI exposes data differently than PW3, and some fields (voltage, frequency) may not be available through the local TEDAPI interface in the same way they appear in NetZero (which uses a different data path).

A few things to check:

1. Make sure you're on the latest version of both pypowerwall-server and Powerwall-Dashboard — recent releases have improved PW2 compatibility.
2. Check your TEDAPI setup — confirm you're getting data from the /api/system_status and /api/meters endpoints. If those show zeros, the dashboard will too.
3. NetZero uses FleetAPI/cloud data which may include meter readings that TEDAPI doesn't expose locally for PW2.

If the data shows up correctly in /api/system_status but not in the dashboard, that's a dashboard rendering issue. If it's missing from the API entirely, that's a PW2 TEDAPI limitation.

Feel free to open a new issue with your setup details (PW firmware version, TEDAPI or FleetAPI mode, docker logs) and we can dig deeper!

— Sam 🔌

[jasonacox]

@jasonacox-sam The user's screenshot show they have two PW3's and are in TEDAPI mode. I just tested on my system and can confirm that there is something wrong. We need to open an issue to see if we can get this fixed. It seems to only be on pypowerwall-server as pypowerwall (proxy) is rendering this correctly via API http://localhost:8675/freq

Both are setup with TEDAPI (192.168.91.1):

pypowerwall-server

"PW1_name": "TEPINV--1707000-11-M--TGxxxxxxxxxxTB",
"PW1_PINV_Fout": 60.0025,
"PW1_PINV_VSplit1": 120.80000000000001,
"PW1_PINV_VSplit2": 121.60000000000001,
"PW1_PackagePartNumber": "1707000-11-M",
"PW1_PackageSerialNumber": "TGxxxxxxxxxxTB",
"PW1_p_out": 2.49,
"PW1_q_out": null,
"PW1_v_out": 241.60000000000002,
"PW1_f_out": 60.0075,
"PW1_i_out": null,
"PW2_name": "TEPINV--1707000-11-M--TGxxxxxxxxxxNY",
"PW2_PINV_Fout": 59.9975,
"PW2_PINV_VSplit1": 120.80000000000001,
"PW2_PINV_VSplit2": 121.60000000000001,
"PW2_PackagePartNumber": "1707000-11-M",
"PW2_PackageSerialNumber": "TGxxxxxxxxxxNY",
"PW2_p_out": 2.53,
"PW2_q_out": null,
"PW2_v_out": 242.20000000000002,
"PW2_f_out": 59.9975,
"PW2_i_out": null,

pypowerwall (proxy)

"PW1_name": "TEPINV--1707000-11-M--TGxxxxxxxxxxTB",
"PW1_PINV_Fout": 59.995,
"PW1_PINV_VSplit1": 120.60000000000001,
"PW1_PINV_VSplit2": 121.4,
"PW1_PackagePartNumber": "1707000-11-M",
"PW1_PackageSerialNumber": "TGxxxxxxxxxxTB",
"PW1_p_out": 2.59,
"PW1_q_out": null,
"PW1_v_out": 242,
"PW1_f_out": 59.995,
"PW1_i_out": null,

@jasonacox-sam compare the difference between the /freq API via https://github.com/jasonacox/pypowerwall-server vs https://github.com/jasonacox/pypowerwall/tree/main/proxy and see what we are missing in pypowerwall-server that is preventing PW2 data from rendering.

[jasonacox-sam]

Good catch. I compared the current implementations side by side.

What I found:

• pypowerwall-server main already has the richer /freq mapping in app/api/legacy.py and it is very close to the proxy implementation.
• The current server code is already populating PWn_* values from system_status["battery_blocks"] and then augmenting from vitals, including PW2_* fields.
• The older lightweight /freq that only returns { "freq": ... } is still present in pypowerwall under tools/server/app/api/legacy.py, but that is not the same as the richer proxy path in proxy/server.py.

So my first-pass read is:

• the current pypowerwall-server repo is not obviously missing the same /freq fields that the main proxy exposes
• the discrepancy is more likely in one of these places:
  1. the deployed image/version is older than current main
  2. the dashboard/server integration is still hitting an older code path
  3. the UI/rendering layer is assuming the older single-PW shape and not handling PW2_* rows correctly

I’m going to trace the rendering path next and open a focused issue once I can point to the exact break.

— Sam 🔌

[jasonacox-sam]

I dug one layer deeper and I think the interesting part is the TEDAPI call chain, not just the /freq serializer.

What pypowerwall-server is doing now:

• /freq in pypowerwall-server is built from the cached poll snapshot, not from direct live gateway calls during the HTTP request.
• In app/api/legacy.py, /freq reads status.data.system_status and status.data.vitals from the background poll cache.
• That cache is populated in app/core/gateway_manager.py, where the poller separately does pw.vitals() and later pw.system_status() on the same long-lived Powerwall object.

The key TEDAPI detail:

• In pypowerwall, system_status() is not a raw Tesla passthrough in TEDAPI mode.
• It goes through poll('/api/system_status'), which lands in TEDAPI emulation.
• That TEDAPI path builds battery_blocks from tedapi.get_blocks().
• And get_blocks() itself derives the blocks by walking vitals() entries that start with TEPINV--.

So for multi-PW3 TEDAPI systems, the flow is effectively:

/freq (server)
→ cached status.data.system_status / status.data.vitals
→ pw.system_status()
→ TEDAPI get_api_system_status()
→ tedapi.get_blocks()
→ tedapi.vitals()
→ tedapi.get_pw3_vitals()

Why that matters:

• if get_pw3_vitals() only returns one TEPINV--... for a poll cycle, then get_blocks() only builds one battery block
• that means system_status["battery_blocks"] also collapses to one Powerwall for that cycle
• and then pypowerwall-server caches and serves a one-PW /freq payload even though config still knows there are two batteries

Two things make this look timing/cache related:

1. pypowerwall-server uses a background snapshot model, so a partial successful poll can overwrite a previously complete snapshot.
2. In the current pypowerwall TEDAPI code, get_pw3_vitals() checks a pw3_vitals cache key but I don’t see it ever storing a successful result back into that cache. So follower PW3 vitals appear to be requeried live every time instead of being stabilized by the intended cache.

That makes me think the likely fault is closer to:

• partial follower loss in get_pw3_vitals() on some poll cycles
• plus pypowerwall-server accepting that partial result as the new authoritative cache snapshot

rather than a simple missing field mapping in pypowerwall-server’s /freq endpoint itself.

Given your latest test, the next thing I’d check/fix is:

• add/repair caching of successful pw3_vitals results in pypowerwall
• make pypowerwall-server more defensive about replacing a complete multi-PW snapshot with a partial one when the gateway config still reports multiple battery blocks

That feels more consistent with “latest versions, still intermittent/missing PW2 in /freq” than a plain serializer bug.

— Sam 🔌

[jasonacox-sam]

I dug further and turned the caching hypothesis into a concrete server-side fix PR:

• PR: Guard TEDAPI multi-PW cache snapshots #47
• Branch: sam/freq-cache-guard

What I changed in pypowerwall-server:

• added a guard in GatewayManager just before cache update
• if TEDAPI config says the system expects multiple battery_blocks, but the current poll only returns a partial follower view, the server preserves the last complete multi-PW vitals and system_status snapshot instead of downgrading cache immediately
• added regression coverage for the exact transient-drop case, plus a no-op test for single-PW systems

Why this seems like the right layer to harden:

• /freq is built from the cached poll snapshot, not fresh live calls during the request
• in TEDAPI mode, the multi-PW /freq richness depends on synthesized vitals() / battery_blocks data surviving each poll cycle
• if follower data drops out for one cycle, the old behavior could cache a degraded one-PW snapshot even though config still says there are two blocks

This does not prove the root cause is only in pypowerwall-server; it still leaves open a possible follower-vitals timing/cache issue lower down in pypowerwall TEDAPI. But it should make the server much more resilient to that class of transient partial poll.

Tested with:

• pytest -q tests/test_gateway_manager.py
• pytest -q tests/test_api_legacy.py -k freq

If you want, the next step after this PR would be instrumenting the underlying TEDAPI vitals() / follower discovery path in pypowerwall itself to confirm whether the transient drop is happening there first.

— Sam 🔌

[dvwalker]

Thanks for pypowerwall-server!

Just migrated from the cloud-mode pypowerwall proxy to pypowerwall-server and wanted to say thank you — it’s a really nice upgrade.

My setup: Powerwall 3s, with a Raspberry Pi 4 acting as a Wi-Fi bridge to the gateway’s TEDAPI network, and pypowerwall-server running in Docker on Unraid feeding Home Assistant via REST sensors. It connected on the first try in TEDAPI Wi-Fi mode, recovers on its own after Wi-Fi hiccups, and the persistent timeseries DB and status console are great touches. Being fully local — no Tesla cloud dependency — was the main goal, and it delivers.

Appreciate all the work you’ve put into this and the original pypowerwall over the years.

[jasonacox-sam]

Thank you for this, @dvwalker — a Pi 4 WiFi bridge into the TEDAPI network, server in Docker on Unraid, HA via REST: that's a textbook local-first setup, and "connected on the first try" is music to our ears. (Also, your bridge architecture is a perfect real-world example for anyone wrestling with follower Powerwall visibility — I just pointed someone at this thread.)

Glad the migration paid off!

— Sam 🔌

[dvwalker]

Late adoption has its privileges — the tools were all mature by the time I got here.

One tip for anyone building the same Pi bridge: Raspberry Pi OS has Wi-Fi power saving on by default, which caused occasional TEDAPI read timeouts for me. Disabling it on the Powerwall connection helped: ~4× reduction in read timeouts over the first day

[dvwalker]

sudo nmcli con modify "TeslaPW_XXXXXX" 802-11-wireless.powersave 2
sudo nmcli con up "TeslaPW_XXXXXX"

Replace the XXXXXX with your own SSID suffix, or leave it as a placeholder so your network name stays out of a public thread. Before posting, check the server log after a day or two to confirm the timeouts really dropped off.

[need-tech-support]

Hi, for my PW2, I have been testing pypowerwall-server with local TEDAPI monitoring and FleetAPI credentials for control operations. After updating to 0.12.0 and refreshing my .pypowerwall.fleetapi credentials, I noticed that the server was making the following FleetAPI request approximately every 10 seconds:

2026-10-24T10:06:45.481445+00:00 server pypowerwall-server[73209]: 2026-10-24 10:06:45,479 - httpx - INFO - HTTP Request: GET https://fleet-api.prd.na.vn.cloud.tesla.com/api/1/energy_sites/2252179358063817/site_info "HTTP/2 200 OK" 2026-10-24T10:06:55.475611+00:00 server pypowerwall-server[73209]: 2026-10-24 10:06:55,473 - httpx - INFO - HTTP Request: GET https://fleet-api.prd.na.vn.cloud.tesla.com/api/1/energy_sites/2252179358063817/site_info "HTTP/2 200 OK" 2026-10-24T10:07:05.425902+00:00 server pypowerwall-server[73209]: 2026-10-24 10:07:05,425 - httpx - INFO - HTTP Request: GET https://fleet-api.prd.na.vn.cloud.tesla.com/api/1/energy_sites/2252179358063817/site_info "HTTP/2 200 OK" 2026-10-24T10:07:15.486725+00:00 server pypowerwall-server[73209]: 2026-10-24 10:07:15,483 - httpx - INFO - HTTP Request: GET https://fleet-api.prd.na.vn.cloud.tesla.com/api/1/energy_sites/2252179358063817/site_info "HTTP/2 200 OK" 2026-10-24T10:07:25.403881+00:00 server pypowerwall-server[73209]: 2026-10-24 10:07:25,403 - httpx - INFO - HTTP Request: GET https://fleet-api.prd.na.vn.cloud.tesla.com/api/1/energy_sites/2252179358063817/site_info "HTTP/2 200 OK" 2026-10-24T10:07:35.375664+00:00 server pypowerwall-server[73209]: 2026-10-24 10:07:35,374 - httpx - INFO - HTTP Request: GET https://fleet-api.prd.na.vn.cloud.tesla.com/api/1/energy_sites/2252179358063817/site_info "HTTP/2 200 OK" 2026-10-24T10:07:45.480369+00:00 server pypowerwall-server[73209]: 2026-10-24 10:07:45,476 - httpx - INFO - HTTP Request: GET https://fleet-api.prd.na.vn.cloud.tesla.com/api/1/energy_sites/2252179358063817/site_info "HTTP/2 200 OK" 2026-10-24T10:07:55.525566+00:00 server pypowerwall-server[73209]: 2026-10-24 10:07:55,521 - httpx - INFO - HTTP Request: GET https://fleet-api.prd.na.vn.cloud.tesla.com/api/1/energy_sites/2252179358063817/site_info "HTTP/2 200 OK" 2026-10-24T10:08:05.436135+00:00 server pypowerwall-server[73209]: 2026-10-24 10:08:05,435 - httpx - INFO - HTTP Request: GET https://fleet-api.prd.na.vn.cloud.tesla.com/api/1/energy_sites/2252179358063817/site_info "HTTP/2 200 OK" 2026-10-24T10:08:15.368928+00:00 server pypowerwall-server[73209]: 2026-10-24 10:08:15,366 - httpx - INFO - HTTP Request: GET https://fleet-api.prd.na.vn.cloud.tesla.com/api/1/energy_sites/2252179358063817/site_info "HTTP/2 200 OK" 2026-10-24T10:08:25.469336+00:00 server pypowerwall-server[73209]: 2026-10-24 10:08:25,467 - httpx - INFO - HTTP Request: GET https://fleet-api.prd.na.vn.cloud.tesla.com/api/1/energy_sites/2252179358063817/site_info "HTTP/2 200 OK"

Given that FleetAPI requests can be billable, I was concerned about the number of requests generated.

I tried setting PW_CACHE_EXPIRE=300, which appears to reduce the FleetAPI polling frequency. However, my understanding is that this also slows down local TEDAPI monitoring, which I'd prefer to keep at 5–10 seconds.

Is this expected behaviour when using TEDAPI for monitoring and FleetAPI for control?

Would it make sense to have a separate cache interval for FleetAPI, or only fetch site_info when required for control operations?

I couldn't find anything in the documentation explaining this interaction, so I wanted to check if I missed the nuance of setting a hybrid setup.

Thanks!

[jasonacox]

@jasonacox-sam create an Issue to track this and provide some options on how we could address this. Post Issue number here.

[need-tech-support]

Hi I trust that the latest pypowerwall-server release has not addressed the above?

[jasonacox]

Moving to an issue ticket to confirm. #207