jasonacox / Powerwall-Dashboard

Grafana Monitoring Dashboard for Tesla Solar and Powerwall Systems
MIT License
301 stars 65 forks source link

Export Everything Feature? #341

Open aesculus opened 1 year ago

aesculus commented 1 year ago

Some of us have the ability to send our stored solar power back to the utility using the Tesla Powerwall feature, Export Everything.

Without this toggled on, solar power is only exported when it is produced. But with it toggled on, the Powerwalls will store the solar energy in the battery and then send it out during the most price optimal period. Note that this is not the same as arbitration which would also required the Grid Charge feature to be toggled on.

Can you comment on how the PW Dashboard shows this capability today? I have enclosed a picture of an event where the stored solar was returned to the utility for your review.

image

jasonacox commented 1 year ago

Can you comment on how the PW Dashboard shows this capability today? I

Hi @aesculus , I not sure I fully understand the question. Which panel or data point are you wondering about?

Do you mean, how does it compute "Savings"? If so, it is not terribly intelligent and difficult to make accurate due to complex TOU and other utility rate variability, but it would still represent your use case. The values are coming from basic equations you can see here: https://github.com/jasonacox/Powerwall-Dashboard#savings-errors

When Powerwall is flowing to Grid, it would will end up in "from powerwall" (fp) and the "powerwall > home" savings data.

aesculus commented 1 year ago

OK. Apologies for being obtuse, but I did not want to take you down some big rabbit hole you had already gone down or did not want to spend the time on. You nailed it though.

Basically I guess I wonder if there is some value to add a pw>grid savings bar for this scenario. Simply I guess it would be the total of negative grid less a new solar>grid component.

I did not dive into the Grafana math yet but it may be captured in the current solar>grid figure? It looked close when I checked the values. Technically this is true, it just has a round about way of getting there in this scenario.

Now if someone does do arbitration, where they buy power at a low cost, store it, and then send it back at a higher rate, that may not reflect properly?

So would there be value in both cases to have the solar>grid be real-time where pw>grid would be delayed?

BTW the models Tesla uses to do this are pretty impressive. The sample I gave above is trivial. My consumption was pretty fixed and was not hard to estimate so the PW just started dumping and kept an eye on the end game. But if my energy consumption was more erratic, which it can be as AC use climbs, they have to play a much more cautious approach. And in days where my demand is huge I usually just turn off this feature as I am lucky to get to end of peak at reserve and there is no use in risking it.

jasonacox commented 1 year ago

Ok, so here is the raw data we get from the Powerwall:

We have a continuous query (CQ) in InfluxDB that provides some helpful variables based on those 4 data points:

home = Home load solar = Solar production from_grid = Grid power (if positive) to_grid = Grid power (if negative) from_pw = Powerwall power (if positive) to_pw = Powerwall power (if negative)

The from/to is just a simple trick we used to sort positive/negative values [e.g. abs((1-x/abs(x))*x/2)]:

See here: https://github.com/jasonacox/Powerwall-Dashboard/blob/ee9a64b33038dc28be0dd5372d9bcb893cbb853d/influxdb/influxdb.sql#L15

The link I mention (here) shows how we use those variables to compute the different savings elements:

I'm not sure how to identify if the power is coming from the Powerwall or Solar that is going to the Grid (in the graph you posted, it could be one or both). If anyone can figure out a better equation, based on the variables we get, please let me know.

BuongiornoTexas commented 1 year ago

| I'm not sure how to identify if the power is coming from the Powerwall or Solar that is going to the Grid

As the utility can't (or at least shouldn't be able to) tell the difference, I don't think it is meaningful to try and differentiate these two - as far as the utility is concerned, this is just export from the house and an electron is an electron.

@aesculus - Are you working with fixed time of use tariff (there is strict schedule for high and low export rates and known tarriffs) or a dynamic system driven by real time network demand where both export timing and tariff are variable and unknown?

aesculus commented 1 year ago

I'll admit this may be a daunting task and its not important to decide where every electron is going.

Solar can have three destinations: the home, the grid or the PWs which later can go to the home or grid.

The grid can either consume or provide. When it consumes the power can come from solar or the PW (which was energy it might have given before or from site generated solar). When it provides it can be consumed immediately by the home or as above, stored in the powerwalls for later consumption.

The solar, grid and PWs all have CTs that measure current at the movement. The home value is not measured but always the remainder of current from these three. This makes it even more difficult to try to understand the flow.

It will take some time to see if we can come up with a course way to determine what went on over a given period vs the real-time data we get from the CTs. I'll noodle on it a bit.

My use case is pretty simple. For the most part any power I get paid for comes from a fixed period each day (there can be a bit of spill over to an adjacent period but its rare). I can send as little as I want but can never exceed the max rate of the two PWs (10 kW) at any moment and at least monthly (maybe daily) I cannot send back any more than the estimated power the utility and I agreed to when I was given a permission to discharge to the grid. Pretty standard for California where I live. If I do send back more they have the option to cap my reimbursement to what was agreed to. My actual production is always short of what was agreed to BTW.

BuongiornoTexas commented 1 year ago

Mmm - from what you are describing, it sounds as though it may fit within the capabilities of the ToU engine I put together earlier this year.

https://github.com/BuongiornoTexas/pwdusage

There's at least one place it won't fully match your system, and that is truncating export per month. But if you are not going over the limit, this may work for what you are looking for? And if you really cared, you could build a custom agent.

It does lazy accounting - basically if the energy costs or generates export or usage value, it gets accounted for. All other energy is assumed to have zero value (solar charging is worth nothing until used or exported, losses are worth nothing). So:

aesculus commented 1 year ago

@BuongiornoTexas Yes. I am using your dashboard and it is quite detailed. But I was just thinking of the little tweak to @jasonacox dashboard on the Savings bar charts to add the pw>grid export. You could probably make this algorithm in your sleep. :-)

BuongiornoTexas commented 1 year ago

In that case, I think you can get what you want by tweaking the drop in replacement for the savings panel that is in:

https://github.com/jasonacox/Powerwall-Dashboard/tree/main/tools/usage-service

Right now, this should report: savings from powerwall used to power the home, solar used to power the home, and export to the grid. It doesn't differentiate between solar export and grid export, but also doesn't have the potential double counting issue jason highlighted above. But given the data available, I think you could break in down in grafana from:

solar export = max(0, min(SOLAR_SUPPLY - SOLAR_TO_HOME, GRID_EXPORT)) pw export = max(0, min(PW_SUPPLY - PW_TO_HOME, GRID_EXPORT - solar export))

Depending on how you have set up your supply priorities, one of the residuals may also help in calculating what you want.

aesculus commented 1 year ago

@BuongiornoTexas Missing something here: I tried the "drop in replacement" and while I can see the json is different, the only thing that changed for me was the title. Looking at it, it appears that the underlying query is limiting what is being displayed?

Maybe I don't know how to do "drop in replacement".

BuongiornoTexas commented 1 year ago

Hi @aesculus,

If the title has changed to "Savings - ToU Month to Date" and "solar > grid" has changed to "export > grid" than it's probably working as expected. Also, if you go to edit the panel and check the Transform tab, there should be 4 or 5 "Add field from calculation" and "Organise field" tranforms that I don't think @jasonacox uses at all.

The panel looks much the same as the old one, but the values should change a fair bit.

You could try setting up the original and new panels side by side to check what is happening.

Also - I'm really happy to spend time on helping with this, but could you include screen grabs/snap shots or other information to help debug? It's hard to know what's going on with just a sentence or two of description of the problem.

aesculus commented 1 year ago

Not sure what happened last time but this time I see more bars. All I am doing is swapping the json. Is that what I should do or is there more I should be doing?

BTW I have to fix another problem first before I pursue this. I am now getting an message across the top of the panel (wonder if that is because of the negative value?):

image

BuongiornoTexas commented 1 year ago

BTW I have to fix another problem first before I pursue this. I am now getting an message across the top of the panel (wonder if that is because of the negative value?):

I have seen this before, and can't remember what caused it. Can you try setting a different time range and seeing what happens? As this is the original savings panel, I wouldn't expect it to have any issues?

aesculus commented 1 year ago

I added this report #345 to see if @jasonacox has some ideas.