Looking for Daily Accumulator Data

[JohnJ9ml]

System: 8.8kw of solar panels, three PW3 units.

My installation is not yet complete - jumper wires from one primary panel to another don't quite fit cleanly, have to be redone. Because the team worked into the early evening trying to get things to fit, I have a functioning system, but they didn't run the ethernet connection, I don't have PTO from the utility, and am hanging out in this nether state until a couple weeks from now.

While I'm waiting, I'm using the cloud data access. I'm using pypowerwall to dump the raw data from the cloud into my own database. I've been tracking the entire house for years now, and want to continue on this piece too.

What I haven't been able to locate as yet is any "accumulators" that seem to report cumulative data from the day. I see the Powerwall Dashboard can summarize each day for the day, month, year for grid, solar, home, and powerwall, but I have not as yet located an API call from the pypowerwall instructions / examples that seems to produce anything other than instantaneous numbers (other than the battery level).

Where does this information get returned?

[jasonacox]

Hi @JohnJ9ml while there isn't a direct acumulator element, you can compute the energy by taking the samples, summing them and dividing it by time (hours). This is what the Dashboard is doing (technically integrating or computing the area under the time series curve). The cloud has historic data that you can access to do the math (see example https://github.com/jasonacox/Powerwall-Dashboard/blob/main/tools/tesla-history/tesla-history.py).

[JohnJ9ml]

I wondered about this. The Power Flow animation is nicely done, but in watching the data go by in one window and watching the animation in the other, I was reasonably certain the logic of deciding when / how much grid was being fed to battery, to house, etc. was inferred based upon the numbers: some of them directly support the conclusions, and some of them have to be somewhat fudged.

When pulling the data from the smart meter, I use Rainforest for this, and they emit two kinds of events from the grid flow: one that is labeled InstantaneousDemand, which is very much like grabbing the power() output, and another called CurrentSummation, which is the direct numbers that represent delivered and received from the meter head's perspective.

There are properties in several of the powerwall events that are labeled imported and exported, but I never see them with values. I didn't know if that was because these data are available direct but not over the cloud, or if they're still futures (hopefuls?).

Thanks for the pointer to the history. I'll have a look and see what I can glean from it. I'll have to look around a bit (though I confess I really have never programmed in python). I see this is what looks like a stand-alone module. Something to tease apart.

[jasonacox]

Our initial goal of the pypowerwall project was to pull the realtime data directly from the Powerwall every 5s. Using the local API (via WiFi or hardwire as you mentioned), the Powerwall provides instantaneous power data with positive values indicating one direction or negative for the other: load (home), solar, powerwall and site (grid). This provides much greater fidelity than what you can geet via the cloud API, but we added the cloud data access (which is what the Tesla App uses) for solar-only systems or for users that didn't have access to a local API (e.g. PW3 before option 4 was available).

Since you mention the Power Flow animation I assuem you have the wall-proxy-server running. Another possible option for you would be to run the pypowerwall proxy and use the simple csv API http://pypowerwall:8675/csv to capture and trend for computing. The /csv API provides key power data in CSV format: (grid, home, solar, battery, batterylevel)

Congrats on your new system! Have fun with your data project. ;)

[JohnJ9ml]

I've been having a lot of fun with this project thus far, and have largely decided to stand pat until they come next Wednesday, plug in the hardwire, and hopefully see how life changes once I have the all clear PTO from the utility.
While I'm stalling, I was curious what version of InfluxDB is being used. That's an intriguing piece, as so much of what I play with has a time series component to it, and I've always been aware my chosen database is easy for me to use, handy for data, but not entirely efficient for very small documents. That doesn't affect me for just working at home, but I've always been curious about something that was more or less tuned for time series data.

[jasonacox]

We are using community edition InfluxDB 1.8 for the project. Yes, there are newer version, but I didn't want to convert the project to Flux (and figure out how to migrate people for upgrades - gave me nightmares). About the time I got around to figure out how to it, InfluxDB announced they were moving away from Flux and back to InfluxQL. 🤷 Some in the community have manually switched to 2.x and updated all the CQs and Dashboad queries to work with that version. Anyway, InfluxDB does a great job for the Dashboard use case. Some have also added MariaDB (the better MySQL :) to handle more complex calculations, specifically related to complex utility rate schemes.

[jasonacox]

Also, you mention waiting for PTO. For my install, the Powerwalls and Solar were working months before PTO. I just couldn't export to the grid until after PTO. I would recommend getting the dashboard set up after install as it could help you troubleshoot issues even before PTO.

[JohnJ9ml]

I very much agree with you on getting set up as soon as possible. As soon as I have a final hardwired connection here, I plan to begin the process of migrating off cloud data and onto a direct connect solution.
I'm hoping PTO is faster here, only because I live in a very small town that still has a full complement of PG&E resources. However, like all things going through a distant desk, I'm not counting on it.
The system has a very "interesting" set of behaviors right now, and there is a lot of functionality that just isn't available. In the meantime, between the dashboard and my own data plotting, I can look back and see a bunch of "why did it decide that?" instances that I'm sure have to do with a state where it's not configured to push back to the grid in a meaningful way. I also strongly suspect this is a state they don't spend a lot of time optimizing, since it's supposed to be short term.
I'll put Influx on the stack of things to fight off boredom, but it did look interesting as a special purpose solution.