New PyPowerwall Server

[jasonacox]

The current pypowerwall proxy does a good job of being a proxy to the Powerwall gateway. It was designed during the days when the Powerwall had a local gateway we could use, including a GUI. This is no longer the case, yet it still emulates "proxy" mode for backward compatibility with systems using those APIs.

Some of you, like @Nexarian, have raised issues that there is no good way to manage multiple gateways. The proxy was never built for this. I've been inspired by @Nexarian to consider a full refactor of the proxy. Since this does not impact the pypowerwall library (but will use it), we can start fresh with a new concept.

The Start:

https://github.com/jasonacox/pypowerwall/tree/main/tools/server

Design Goals:

• Drop-in replacement - Honor all existing proxy APIs and environment variables (PW_HOST, PW_PASSWORD, PW_CACHE_EXPIRE, etc.)
• Orchestrated polling - Move from as requested polling to scheduled polling (default 5s) with caching for improved responsiveness
• Network resilience - Exponential backoff on failures (5s → 120s), graceful degradation serving cached data during outages, non-blocking startup
• Multi-gateway support - Manage multiple Powerwalls with per-gateway status and aggregate functions
• Management console - Real-time dashboard for monitoring gateway health, connection status, and troubleshooting (see example below)
• Modular architecture - FastAPI with async handlers for reliable, testable, high-performance operation and easy extensibility
• Power Flow animation - Hosted at / with /example showing iframe embed

Technical Approach:

• Async-first with ThreadPoolExecutor for blocking pypowerwall calls
• Lazy gateway initialization - server accepts connections immediately
• Per-gateway health tracking with /health and /stats endpoints
• TEDAPI, Cloud, and FleetAPI mode support

Example /console display (no, this is not final--sort of gross--just a test):

Provide powerflow animation via /example or /

[Nexarian]

More thoughts!

• Gemini's token window is now big enough to ingest all of the old Powerflow animation (1M+). I think we should ask it to refactor out the bits we care about in a more readable way, so we can actually own this ourselves and not be beholden to the weird UI quirks that come from using frozen-in-time JavaScript (BTW: TypeScript refactor anyone?)
• Exponential backoff WITH JITTER (Everyone forgets the Jitter, please don't forget the jitter).
• We need to figure out the "Start and Stop" commands. I'm so close, but not quite there. Then we can add those buttons to the dashboard. There are two: Inverter start/stop and "PVI" start/stop (at least on mine). I'm most interested in the PVI version. Then put those on the dashboard.
• Mobile UI compat is probably a must. I don't like it, but it's true, we have to test for that.
• The "multiple gateway" thing also implies some form of NAT-ing this is the version I use
  • It aliases the two 192.168.91.1 gateways into two standalone IPs: 192.168.92.100/101
  • Unfortunately it's very tightly coupled to Linux iptable insanity. I know one of the goals of this project is also Windows and MacOS compat, but I could not figure out how to port it.
  • Should the new server have a built-in way of doing this?

[jasonacox]

Great points!

Updated UI Layout (needs work)

[Nexarian]

Coding a UI like that by hand in the good-ole-days would take days, maybe even weeks.

[mccahan]

Wow this is incredibly pertinent to my interests... I decided last week I wanted to make a little ESP-powered monitoring display, but I ran into the issue where the platform I was using couldn't do http requests asynchronously so it wouldn't animate while updating. Over the weekend I vibe-coded a proxy to sit in front of the pypowerwall proxy, with caching and auto-polling, so that it could publish MQTT messages that I could subscribe to.

All that to say if you end up in a position where it's easy for me to hook in to responses so I can do my little MQTT publishing, I would love you forever. Sitting a proxy in front of a proxy feels a little redundant if I don't have to.

AudioRemovedDisplay.mov

My workflow ended up as generating a UI with Google Stitch, exporting the code, and letting Copilot run wild with it. Results ended up better than my little weekend vibe-code project deserves lol:

[mccahan]

• Gemini's token window is now big enough to ingest all of the old Powerflow animation (1M+). I think we should ask it to refactor out the bits we care about in a more readable way, so we can actually own this ourselves and not be beholden to the weird UI quirks that come from using frozen-in-time JavaScript (BTW: TypeScript refactor anyone?)

I've been happily running my own version of that diagram for the better part of a year now if you want to steal anything. Though mine was made with Vercel v0 and at this point I bet any of the AI options could do an even better version of it.

[jasonacox]

Oh, @mccahan that is a great idea. With the new approach we are actively polling so there is no reason we couldn't have it publish MQTT messages. Let's get it added.

I love your little display and have made many of my own ESP powered devices too. What device / display are you using? I want one. :)

Ok - I've decided to move the PyPowerwall Server to it's own repo: https://github.com/jasonacox/pypowerwall-server and will move it out of Tools at some point. I started a new issue to mention MQTT but feel free to pile on.

[jasonacox]

Beta container to test: jasonacox/pypowerwall-server:0.1.0-beta1

[mccahan]

I love your little display and have made many of my own ESP powered devices too. What device / display are you using? I want one. :)

@jasonacox thanks! This is a little esp32-s3-powered 480x480 display, I got mine on Aliexpress but I think there might be the Amazon equivalent. I also overengineered as per usual so when we've got MQTT API stabilized I've got a web installer for it lol https://mccahan.github.io/esp32-powerwall-screen/

[mccahan]

The "multiple gateway" thing also implies some form of NAT-ing this is the version I use
...

• Should the new server have a built-in way of doing this?

@Nexarian I've been experimenting with a little ESP32-S3 ETH board for this running some vibe-coded software and have been happy so far. For $20 you can plug it into your local network over ethernet (even optionally using PoE) near your Powerwall and it can bridge the PW's WiFi but get a regular DHCP address on your network; it's been quite handy. Incoming requests to the device just get transparently forwarded to 192.168.91.1.

Previously I was doing the travel router bridge technique, but the configuration on that is annoying and complicated. With a little ESP32 board, you can flash it from a web browser with purpose-built software, configure it with your PW credentials right from the browser, and off you go. No messing with weird routing, no USB WiFi sticks, etc. It has one job, it just kinda works.

I even added a little mDNS responder on it so it can advertise itself to my network, I figure when the new pypowerwall server is out I could easily set that up to automatically detect them on the network and pop them up in the UI for easy adoption. I can ping powerwall.local and there it is, even if the IP changes.

You could just as easily have one of them for each of your PWs and not worry about Linux iptables routing hacks again.

[zi0r]

Adding support for standalone tesla inverters is also fairly trivial to do and will work the same way as multiple gateways do.

The existing pypowerwall_proxy works fine with a standalone inverter, provided that you are connected to its SSID. Only /strings and /alerts/pw appear to be useful though.

The only issue is needing to rename its string data (it will give you a string named "A" which is going to conflict with your existing gateway data collection). I'm currently doing this via telegraf's [[processor.rename.replace]] and a tag match, but, it would likely be smarter to integrate this into the new server.

So, as long as the new server has support to rename strings to ensure there is no collision, it should be fine.

There might also be value in having a separate Alerts section, per gateway/standalone inverter. This will enable you to differentiate between the different systems. In my existing setup, I've just created a duplicate alerts CQ in influx and am populating it via "invalerts." There's probably a smarter way to differentiate the separate devices.

With respect to travel router/wifi, you can use a GL.iNet GL-SFT1200 ($34) to join the TEG-* SSID and configure port-forwarding on it to obviate the need to worry about routing or dealing with multiple 192.168.91.1 IPs. The current pypowerwall_proxy lacks support to interact with the gateway/inverter on a non-standard port; however, if this can be added, you can have port 8443 on the travel router forward to the Tesla IP:443 on the other side. You can then assign each travel router its own IP on whatever your home lan is. You would end up with one travel router per Tesla SSID.

Lastly, to add PoE to the travel router, a USB-C PoE splitter can be used.

[mccahan]

@zi0r having run my little $21 ESP32 Ethernet board with PoE for the last month on my little bridge firmware, I'm probably going to start pointing people that way if they ask. Yes it's possible to set up the travel routers with port forwarding but it's a bit complex, whereas doing the WiFi microcontroller firmware route on a dedicated device makes the setup process sooooo much more straightforward.

Bonus auto-discovery later.

[jasonacox]

Adding support for standalone tesla inverters is also fairly trivial to do and will work the same way as multiple gateways do.

The existing pypowerwall_proxy works fine with a standalone inverter, provided that you are connected to its SSID. Only /strings and /alerts/pw appear to be useful though.

The only issue is needing to rename its string data (it will give you a string named "A" which is going to conflict with your existing gateway data collection). I'm currently doing this via telegraf's [[processor.rename.replace]] and a tag match, but, it would likely be smarter to integrate this into the new server.

So, as long as the new server has support to rename strings to ensure there is no collision, it should be fine.

There might also be value in having a separate Alerts section, per gateway/standalone inverter. This will enable you to differentiate between the different systems. In my existing setup, I've just created a duplicate alerts CQ in influx and am populating it via "invalerts." There's probably a smarter way to differentiate the separate devices.

With respect to travel router/wifi, you can use a GL.iNet GL-SFT1200 ($34) to join the TEG-* SSID and configure port-forwarding on it to obviate the need to worry about routing or dealing with multiple 192.168.91.1 IPs. The current pypowerwall_proxy lacks support to interact with the gateway/inverter on a non-standard port; however, if this can be added, you can have port 8443 on the travel router forward to the Tesla IP:443 on the other side. You can then assign each travel router its own IP on whatever your home lan is. You would end up with one travel router per Tesla SSID.

Lastly, to add PoE to the travel router, a USB-C PoE splitter can be used.

Great points @zi0r ! I'll open this as an issue in pypowerwall-server.