The History of Powerwall Dashboard

[jasonacox]

The History of Powerwall Dashboard

I should have done this before now. There are new members in the community who are confused about the different setup options, issues, discussions and even tools. Yes, I know we have work to do to make the project a bit easier to use. But in all fairness, we have had a lot of twist and turns along the way with our friends at Tesla and reacting to their changes. Some of those changes have left some deep marks and vestigial remnants that need to be cleaned up. I'm writing this in hopes that it will create some clarity, encouragement and maybe even inspire others to help.

The Beginnings

I just want to monitor my new Tesla Energy Solar and Powerwall system!

I love the Tesla app, don't get me wrong, but I'm a sucker for data. I wanted to see things graphed together, be able to tweak the view and even have an always-on monitor of how my system was performing. That mission started with an existing project that I found by mihailescu2m at https://github.com/mihailescu2m/powerwall_monitor. It was great! But it had some issues, especially with the way it was using a proxy to hit the Powerwall. I had some ideas I wanted to contribute, but the project wasn't really being maintained. I completely understand how demanding these OSS projects can be so I don't fault the maintainers there, but when my PRs were not going anywhere, I had to do something else. I started a new project, this one. I created a new library for the Powerwall in python, called pypowerwall. It added caching and a collection of other API. Soon, a community formed and other enthusiast joined me in making this a fun and rewarding project.

When we originally launched the project, there was only one mode to connect to the Powerwall, Local (1) mode. Tesla had built a really nice customer facing web portal on the Powerwall. You could surf over to it from your local network either by having the Powerwall join your WiFi network or by adding a hardwired ethernet cable to your Powerwall. The web portal let you log in as an installer or as a customer. It also exposed several nice APIs to let you gather basic information about our systems (solar, grid, home, and battery including soe, nominal full capacity).

A Galaxy of Vitals

After some spelunking through the API, we discovered a fancy "vitals" URI that provided a binary payload (protobuf) that contained a wealth of new information about our system, specifically data about strings, temperatures, voltages, frequencies and even alerts! The community swarmed this great data and created nice dashboard panels to give us greater insight into our systems. It was glorius! Most of us even spent time to hardwire our systems to eliminate problematic WiFi connections we experienced because the Powerwall and gateway were in less than ideal (often faraday cage equivalent) conditions.

Months went by and users continued to enjoy the rich data and great insights they were getting to help spot or troubleshoot issues with their systems. They would even try to help Tesla call center technicians unravel mysteries on why things weren't working perfectly. There were good reports of grateful and supportive Tesla technicians, and yes, also more than a few grumpy ones, irritated that we were using unofficial APIs and asking about problems that they deemed to be minor or lower priority. In any case, those were great times. It was easy to set up and run. The setup.sh script ran and as long as your system was on the LAN, you had the IP address of your Powerwall and customer password, you were up and running with little effort.

Cloud City

The community began building on top of the Dashboard foundation. Some even built tools to grab the lower fidelity "basic" data from Tesla's cloud and store that in our InfluxDB (e.g. @mcbirse 's tesla-history.py tool) to fill in gaps (or history), which also paved the way to bring this same Dashboard fun to our non-Powerwall Tesla Solar owner friends (aka mode 2 - solar-only) who had no local API to use.

Life was good! Community members posted graphs of fun events (eclipses, cloud solar lensing, seasonals shifts) and were enthusiastic owners enjoying their solar and battery systems. This incredible data and perspective the project was delivering was delightful and even addictive.

The API Wars Began

Then the dark times came. Tesla decided that the web portal was too difficult for installers to use, and too expensive for them to maintain. They were moving to a native mobile app that would be easier for installers to configure. It seemed that it would be too difficult to maintain both the web portal (and local APIs) and the newer Tesla One app method. Perhaps they had also grown weary of having Powerwall owners referencing their personal Powerwall Dashboards when asking about problems. In any case, the Firmware updates wars began.

First to go was our precious "vitals" API. We lost access to string data, temperatures, granular frequency, current and voltage data. We also lost alerts, which had become a key insight into system failures. It was starting to appear that we would loose all the rest, even the basic power data. It was depressing. There had been so much innovation, joy and excitement with what he had built and it all seemed to be disappearing quickly before our eyes.

Fleeting FleetAPI Hope

We pleaded. There wasn't a lot of hope coming back from our petitions. We were told that there was only one official API path for Tesla Energy systems, the FleetAPI. This is a commercial service that Tesla offers to third party companies that want to integrate with their systems. It was never meant to be a consumer or hobbyist path. It requires that you register a company, domain and configure a full time internet facing server. It also came with a warning that fees would be required after a certain usage level. Enthusiasm died a lot. But the community still responded. We added the FleetAPI support (this is mode 3 - fleetapi) and did what we could to make the setup process a little less onerous.

Powerwall 3 was launched. Unlike the Powerwall 2 and + systems that we had been supporting, the Powerwall 3 was void of any consumer facing web portal and therefore, no local APIs. All configuration happend through the mobile app (Tesla One). It was clear now that this new model was signaling the future direction of Tesla. While the local APIs still remain for the Powerwall 2 and +, it wasn't clear for how much longer. Powerwall 3 owners would be required to use one of the cloud offerings (2-Cloud or 3-FleetAPI) but sadly, the data would be limited (only basics like solar, power, grid and battery data) and the fidelity would be lower (sample rate locally is every 5s versus the cloud's ~5m samples).

A New Hope - TEDAPI

A new hope! The return of the vitals! Just when all hope was lost, a discovery was made. There was a new API discovered that seemed to have the rich data we were looking for, TEDAPI (see research). This was what the app was using and it turned out, it was available on the Powerwall 3! The only problem was that it was only available if you connected to the WiFi access point on the Powerwall (PW3) or Powerwall Gateway (PW2/+). Immediately the community sprung to action and found out ways to get that to work. We added the TEDAPI access information to pypowerwall (mode 4-TEDAPI) and provided guidance on how to connect directly or NAT bridge to get access to that TEDAPI endpoint. During that process, a wise Jedi Knight in our community offered up a pro-tip. If your Powerwall was hardwired to your LAN, you could actually add a route between your system and the TEDAPI endpoint (192.168.91.1) without ever needing to use the WiFi. That was spectacular! Suddenly, it made it easier for enthusiast to connect again to their precious vital data on their Tesla systems. But just went all seemed well...

Firmware Strikes Back

Tesla updates stike back. A new series of Firmware updates (25.10.0+) were launched to smother out the rebellion. All the routed connections to the TEDAPI endpoint were now being denied. To be fair to Tesla, I'm sure they saw it as a potential security risk, however unlikely to be exploited, that they were obligated to address. In any case, this set back is where we are today. The TEDAPI is still accessible, but only via direct WiFi access to the Powerwall access point.

The Future Awakens

Where does this journey go from here? I know a lot of us would love to go back to the glory days of mode 1 for all Powerwalls. We would love to have a simple, read only, local API, with or without a web portal, that allowed us access to the vital data about our systems like we had before. I hope our friends at Tesla understand how much we admire and appreciate the hard work they have put into these systems. We love seeing these amazing technical wonders work! However, if history is any indication, I suspect it is unlikely we will see much more on development on the local API front. I think the latest firmware updates continue to prove that. So we will continue to do what we can. We will tunnel through the icy surface of Hoth to avoid detection from imperial droids... and while we have it, we will enjoy our Dashboard and hang on to our hope that better days are just ahead.

I hope you will all join me in this journey. I'm still getting a lot out of this project, my Dashboard and this community. Thank you all for your incredible engagement, contributions and help. While there will be challenges, I'm convinced that fun days are still ahead. :)

[Scrub000]

Is there a hardware hacking scene for Powerwalls?

I'm thinking of something like Valetudo for robot vacuums which removes the device from the cloud altogether and allows for full local control.

[hulkster]

GREAT writeup @jasonacox (aka Yoda) - informative and hilarious! ;-)

[anewton25]

@jasonacox as someone who is completely new to HA...and who specifically got it to control their Powerwall (to stop mine dumping into my car). What is the best available solution to setup today. (I simply want to tell it to charge if the car charges during the day and to go back into discharge mode otherwise). I have been trying, and failing, to set up via the Fleet API. Thank you for pointing a novice in the right direction!

[jasonacox]

You don't need to use FleetAPI. You can use Tesla owners Cloud API. There is a command line interface if you don't want to use the python package:

https://github.com/jasonacox/pypowerwall?tab=readme-ov-file#pypowerwall-command-line-interface-cli

pip install pypowerwall

# Setup Connection with Tesla Cloud
python -m pypowerwall setup

# read
python -m pypowerwall get

# update mode examples
python -m pypowerwall set -mode self_consumption
python -m pypowerwall set -mode backup