Utility outage simulation data dump

[gpez]

Wanted to share with those of you who are data geeks what I pulled as part of my utility outage test this weekend.

Configuration
- Late afternoon on a partly cloudy day.
- 8.5kw array was producing about 2.5kw.
- Home was consuming 900w-1200w at the time.
- 1x Powerwall on firmware v1.37.1 with updated configuration to resolve 66hz problem.
- Battery was reporting 97.77% state of charge (SoC).
- Data pulled every 500ms from the api/meters/aggregates (power stats) and api/system_status/soe (state of charge) Powerwall APIs via a custom script.
- I turned lights and appliances on/off during to see different results on the data, for example the spikes you see in the load is due to microwave use during those few seconds.
- Simulation ran for approximately 45 minutes (~5400 data points) including set up, opening breakers, simulating different levels of draw, and utility restoration.

Full data dump is here: Powerwall 1.37.1 outage simulation - efe9a57b. I've also attached a graph of the data from my Excel poking on it.

Learnings:
- With the new firmware and my updated configuration it appears that the frequency is correlated to both the battery SoC (which I think we knew) but ALSO with the load power. This was really interesting to me to see the frequency drop as the load increased only to return to previous levels as the load dropped. Running the data through a linear regression calculator with just those two variables doesn't seem to be accurate so I'm going to guess it's either a nonlinear equation or has another variable as input which I need to discover.

- I don't believe my Powerwall settings are quite aligned with the "ramp down" capabilities of my inverter, though it is tough to tell from the data since the sun was setting at the time of this simulation.

- I have some work ahead of me to integrate the Powerwall with my home automation system (Homeseer) which will give the smart home the ability to manage loads and configuration during an outage.

- When I opened the utility breaker and stepped back inside my wife, who was working in the dining room, said she didn't even notice I did anything happened! So it passes the wife test

Hope this helpful for folks. Feedback appreciated!

 

[gpez]

Now I wish I had the data scraper running yesterday...

Got a notification during the middle of the day that the utility was out and the Powerwall was supplying power which went on for about 6 minutes. The utility outage map showed no problem and when I got home my neighbors said they didn't have an outage and my oven, which is not backed up by the Powerwall, had it's clock still on the correct time indicating that it never really lost power. Since the app is painfully light on outage details (doesn't even say what time the outage happened!) I called Tesla. They pulled the logs and turns out the Powerwall noticed the utility voltage dropped to 226v (below the 228v-252v range) and kicked in.

I put in a feature request to get more data in the app on outages and now I've configured the data scraper to run 24/7

 

[miimura]

Now I wish I had the data scraper running yesterday...

Got a notification during the middle of the day that the utility was out and the Powerwall was supplying power which went on for about 6 minutes. The utility outage map showed no problem and when I got home my neighbors said they didn't have an outage and my oven, which is not backed up by the Powerwall, had it's clock still on the correct time indicating that it never really lost power. Since the app is painfully light on outage details (doesn't even say what time the outage happened!) I called Tesla. They pulled the logs and turns out the Powerwall noticed the utility voltage dropped to 226v (below the 228v-252v range) and kicked in.

I put in a feature request to get more data in the app on outages and now I've configured the data scraper to run 24/7

If you're going to run it 24/7, I would recommend increasing the polling interval from 500ms. Logical values would seem to be 1, 6, 15, or 30 seconds.

 

[gpez]

If you're going to run it 24/7, I would recommend increasing the polling interval from 500ms. Logical values would seem to be 1, 6, 15, or 30 seconds.

While it can be configure any way collecting data every half second creates less than 10 megabytes of data a day and gives me the fidelity to track very granularly. The API calls are quick and over the local network so impact there is minimal.

Why would you suggest changing it?

 

[miimura]

While it can be configure any way collecting data every half second creates less than 10 megabytes of data a day and gives me the fidelity to track very granularly. The API calls are quick and over the local network so impact there is minimal.

Why would you suggest changing it?

IIRC, Tesla complained to people using the Powerwall API interface in this way. If you're looking for something in particular, there's no real problem with fetching that fine grained data, it's just that polling so often for an extended period of time when it wasn't designed to be used that way could cause problems.

 

[NuShrike]

While it can be configure any way collecting data every half second creates less than 10 megabytes of data a day and gives me the fidelity to track very granularly. The API calls are quick and over the local network so impact there is minimal.

Why would you suggest changing it?

What's the refresh rate of the APIs? You can tell because they're date-time stamped. You should sample no faster than its existing rate, and as miimura says, impact had notices.

 

[woferry]

The timestamps reported by the gateway suggest something like nanosecond accuracy, which (IMO) can't possibly be real. But it's seemed to me that no matter how fast I read things the numbers are always changing. I settled on once every ~2 seconds for my data capture, though at times I've run this on multiple hosts (a backup server while testing code changes and ensuring I still collected data on the primary, etc), plus having a browser window or two open looking at the gateway UI, and of course whatever is being reported back to Tesla which doesn't update quite as frequently as the local UI. And I've never seen any issues with my Gateway doing this (have never had to reset it, or had it fail to respond, etc).

 

[NuShrike]

The timestamps reported by the gateway suggest something like nanosecond accuracy, which (IMO) can't possibly be real. But it's seemed to me that no matter how fast I read things the numbers are always changing. I settled on once every ~2 seconds for my data capture, though at times I've run this on multiple hosts (a backup server while testing code changes and ensuring I still collected data on the primary, etc), plus having a browser window or two open looking at the gateway UI, and of course whatever is being reported back to Tesla which doesn't update quite as frequently as the local UI. And I've never seen any issues with my Gateway doing this (have never had to reset it, or had it fail to respond, etc).

Delta when time-stamps change and you can calculate the refresh interval. The accuracy of the time-stamp doesn't matter.

I believe I've seen only a few-seconds refresh interval, manually refreshing.

 

[woferry]

Like I said, as fast as I could poll http data (at least several times a second), every reading was different. Timestamps, export/import power levels, voltage, etc. were all changing every time.

 

[miimura]

Does anyone know what the Neurio internal sampling rate is? How about the Neurio to Gateway update rate? Those both seem relevant to what the Gateway could report without internal data smoothing.

 

[cwied]

According to this data sheet, the sampling rate is 1Hz: https://www.neur.io/wp-content/uploads/Neurio-Cut-Sheet-High-Res-Web-.pdf

However, the Gateway also talks to the Powerwalls. The rate there may be higher.