P&E's own hourly data doesn't match their B&W Bill. What am I doing wrong? [solved]

[sorka]

So I just realized the DOB breaks down peak, part peak, and off peak for both usage and export. So I summed those up via EV2A and its still comes out to $160.

So even according to their own DOB, the breakdown of peak, part peak, and off peak kWH multiplied by the EV2A rate still comes in at the right value. So it's a total mystery why I only got $145 in credit.

 

[dareed1]

The CSI-EPBB calculator that estimates your monthly production as used in Rule 9.c.3) (i)
For my most recent 10 page B/W statement, the estimated solar generation capability is within a couple of percent of the PG&E estimated cap. I interpolated the monthy estimates to try to align with my billing period. The estimate appears to be closely related to the PVWatts estimator. The surprise, should there be one, is that any excess above the cap is deducted from the peak period exports first.
The idea is, I believe, to make sure that an installation isn't exporting more power than its solar panels can produce. I don't expect that our house will ever exceed the cap, given that we do consume power in the house, including a heat pump.

@h2ofun
I suspect your setup is over the 150% rule (9.c.2 including footnote 10) for storage kW compared to PV peak kW. The rule doesn't take effect until August 2023, but if over the limit, the installation has to be billed as NEMMT if the storage is over 10kW. I guess you shouldn't accept any upgrade from Tesla that would increase your PW power ratings.

 

[h2ofun]

The CSI-EPBB calculator that estimates your monthly production as used in Rule 9.c.3) (i)
For my most recent 10 page B/W statement, the estimated solar generation capability is within a couple of percent of the PG&E estimated cap. I interpolated the monthy estimates to try to align with my billing period. The estimate appears to be closely related to the PVWatts estimator. The surprise, should there be one, is that any excess above the cap is deducted from the peak period exports first.
The idea is, I believe, to make sure that an installation isn't exporting more power than its solar panels can produce. I don't expect that our house will ever exceed the cap, given that we do consume power in the house, including a heat pump.

@h2ofun
I suspect your setup is over the 150% rule (9.c.2 including footnote 10) for storage kW compared to PV peak kW. The rule doesn't take effect until August 2023, but if over the limit, the installation has to be billed as NEMMT if the storage is over 10kW. I guess you shouldn't accept any upgrade from Tesla that would increase your PW power ratings.

what is the 150%? Right now I have 5 batteries and 15KW of solar. (Maybe going to 29kw)

 

[sorka]

The CSI-EPBB calculator that estimates your monthly production as used in Rule 9.c.3) (i)
For my most recent 10 page B/W statement, the estimated solar generation capability is within a couple of percent of the PG&E estimated cap. I interpolated the monthy estimates to try to align with my billing period. The estimate appears to be closely related to the PVWatts estimator. The surprise, should there be one, is that any excess above the cap is deducted from the peak period exports first.
The idea is, I believe, to make sure that an installation isn't exporting more power than its solar panels can produce. I don't expect that our house will ever exceed the cap, given that we do consume power in the house, including a heat pump.

@h2ofun
I suspect your setup is over the 150% rule (9.c.2 including footnote 10) for storage kW compared to PV peak kW. The rule doesn't take effect until August 2023, but if over the limit, the installation has to be billed as NEMMT if the storage is over 10kW. I guess you shouldn't accept any upgrade from Tesla that would increase your PW power ratings.

Do you mean 10 kWH of storage instead of kW?

 

[miimura]

This is the NEM2 tariff language under Section 9 "NEM Paired Storage" sub-item g, "Billing for NEM Paired Storage". The intent is to disallow charging from the grid and exporting in excess of your solar generation. Obviously if one was to do this you would charge Off-Peak and discharge during Peak to earn extra NEM credits. This applies to Small systems 10kW and below because there is only one net meter. In theory, large systems have production metering, so they would be able to detect exports in excess of renewable production. If you're interested in the Large system billing terms, read the Tariff here: https://www.pge.com/tariffs/assets/pdf/tariffbook/ELEC_SCHEDS_NEM2.pdf

 

[h2ofun]

This is the NEM2 tariff language under Section 9 "NEM Paired Storage" sub-item g, "Billing for NEM Paired Storage". The intent is to disallow charging from the grid and exporting in excess of your solar generation. Obviously if one was to do this you would charge Off-Peak and discharge during Peak to earn extra NEM credits. This applies to Small systems 10kW and below because there is only one net meter. In theory, large systems have production metering, so they would be able to detect exports in excess of renewable production. If you're interested in the Large system billing terms, read the Tariff here: https://www.pge.com/tariffs/assets/pdf/tariffbook/ELEC_SCHEDS_NEM2.pdf


View attachment 662526

So I assume this would mean, try to keep as much of ones solar being used at ones home, and only send to PGE solar when its in our best interest, like during peak times with max costs?

 

[miimura]

So I assume this would mean, try to keep as much of ones solar being used at ones home, and only send to PGE solar when its in our best interest, like during peak times with max costs?

Basically, yes. However, you need to ensure that PG&E has the proper records for your actual installed solar system. That is the problem that @arnolddeleon has. Some of his solar exports have been disallowed because PG&E lost the records of his oldest and largest solar system. In theory, as long as PG&E knows the details of your solar system and you have a Tesla Powerwall system, you should never have exports disallowed.

 

[Redhill_qik]

Do you mean 10 kWH of storage instead of kW?

The 10 kW refers to the power delivery and not the power storage. I haven't been following the Powerwall+ discussion, but when I heard of the planned increased power delivery my mind went immediately to worrying about violating the interconnect agreements that are either less 10kW or greater than 10kW.

 

[h2ofun]

Basically, yes. However, you need to ensure that PG&E has the proper records for your actual installed solar system. That is the problem that @arnolddeleon has. Some of his solar exports have been disallowed because PG&E lost the records of his oldest and largest solar system. In theory, as long as PG&E knows the details of your solar system and you have a Tesla Powerwall system, you should never have exports disallowed.

Yep, so far, everything I have is totally above board. No extra solar added that they do not know about!! This is why the comments about not getting full credit are confusing.

 

[h2ofun]

The 10 kW refers to the power delivery and not the power storage. I haven't been following the Powerwall+ discussion, but when I heard of the planned increased power delivery my mind went immediately to worrying about violating the interconnect agreements that are either less 10kW or greater than 10kW.

Yep, I read things the same way. Meaning, right now the spec for the batteries is 5kw. With new fw, could be 7.5kw. So 2 batteries might then go over the 10kw limit I think? In my case, that would kick me over the 30Kw, which I have no desire to know what that might mean.

 

[sorka]

So I assume this would mean, try to keep as much of ones solar being used at ones home, and only send to PGE solar when its in our best interest, like during peak times with max costs?

Yes, unfortunately Tesla's TEG algorithms suck at doing doing this. The only way to really do it now is to use self consumption mode after the sun rises to when peak or part peak starts and then switch over to advanced. Leaving it on advanced balanced is supposed to do this but my PWs end up filling up to 100% 2 hours before peak starts resulting in me sending back to the grid during off peak. If it just used more direct from the sun during the early to middle part of the day rather than charging to he powerwalls with most of the solar production, the powerwalls wouldn't fill up for an extra few hours and I'd not only save on NBCs from off peak grid usage (since the solar is charging the powerwalls), I'd avoid the 10% round trip cost for those extra 10kW or so that don't need to go into the powerwalls.

Now as the summer heats up and I'm using a ton of AC during peak, this may become a non factor but it's not at all efficient for spring in for my setup.

 

[h2ofun]

Yes, unfortunately Tesla's TEG algorithms suck at doing doing this. The only way to really do it now is to use self consumption mode after the sun rises to when peak or part peak starts and then switch over to advanced. Leaving it on advanced balanced is supposed to do this but my PWs end up filling up to 100% 2 hours before peak starts resulting in me sending back to the grid during off peak. If it just used more direct from the sun during the early to middle part of the day rather than charging to he powerwalls with most of the solar production, the powerwalls wouldn't fill up for an extra few hours and I'd not only save on NBCs from off peak grid usage (since the solar is charging the powerwalls), I'd avoid the 10% round trip cost for those extra 10kW or so that don't need to go into the powerwalls.

Now as the summer heats up and I'm using a ton of AC during peak, this may become a non factor but it's not at all efficient for spring in for my setup.

I need as much credit stored for winter, so getting credit at peak or non peak is great for my needs. So I just leave on balanced and pull from solar and or batteries 99% of the time. Only time I am seeing the grid kick in big time, like now, is when the wife just turned on the electric dryer.

 

[sorka]

I need as much credit stored for winter, so getting credit at peak or non peak is great for my needs. So I just leave on balanced and pull from solar and or batteries 99% of the time. Only time I am seeing the grid kick in big time, like now, is when the wife just turned on the electric dryer.

Right, it's just that during off peak while the sun is shining, you want to the house to consume directly as much as possible. This means you'll have more to export to the grid.

The exception is that you still need to charge the powerwalls from solar during off peak to cover your peak usage so that you can export 100% of your peak production to the grid. If you don't put enough into the powerwalls earlier in the day during off peak then you'll end up using peak off the grid later on which is the #1 thing you want to avoid. But in my case, it's overshooting and putting more into my powerwalls than I need.

 

[sorka]

Can folks take the "BILLING TOU ENERGY" table in their DOB bill and multiply each of the lines by their energy rate to see if that matches their "Current Month Energy Charge or Credit"? Can anyone tell me that the this credit should not follow exactly that table indexed by their energy rate on their tariff? I'm willing to bet that it doesn't match for anyone and that the "Current Month Energy Charge or Credit" is less than it should be.

 

[Redhill_qik]

The kwh are agreeing between Tesla and PG&E. It's the dollar amount for the export credit that they are under paying me by 9%. How's yours adding up?

I was never able to fully understand the B&W bill and finally just gave up. I went back today to give it another go, but I still wasn't able to get the numbers to work out. My billing is further complicated with as I am on E-TOU-C which reduces the charge below 100% of the baseline which is 10.5kWh * days in the billing period as a credit which reverses and becomes reduction in the credit for the baseline hours.

I am also with Silicon Valley Clean Energy CCA, so my generation isn't from PG&E and needs to be removed from the tariff schedule. Since I am with a CCA there is a Power Charge Indifference Adjustment (CCA DA POWER $0.04760/net kWh) and a Energy Cost Recovery Amount (CCA ECRA $0.00032/net kWh) which are positives as they become extra credits. Also according to E-TOU-C because I am with a CCA I get hit again for Wildfire Fund (CCA WILDFIRE FUND same $0.00580/import kWh) and the Competition Transition Charge (CCA ONGOING CTC same $0.00004/import kWh) which are part of the NBC and a Franchise Fee (FFS $0.00048/import kWh), so it seems like PG&E is double dipping here.

The only thing that I can say with respect to your bill is that the number that you are getting $145.04 is coming from the "TRUE-UP HISTORY SUMMARY" table and is the total of all the charges/credits to the left. I can calculate everything here from the hourly data and the E-TOU-C tariff except for the "E84 BL CHG" column that I can get to add up to the same number.

 

[slcasner]

He really should look for the discrepancy between the Green Button data and the B&W bill data. I did this once and found that there was missing interval data and PG&E just threw in whatever "estimate" that it wanted. Their value was not reasonable by my estimation, but the number of cents in dispute was not worth getting my knickers in a twist about. I also found that they estimated usage during an outage, which on the face of it is pretty outrageous, but the billed amount was $0.48 and I wasn't going to raise a stink about that either.

It appears that the Smart Meter telemetry data is only incremental (usage during an interval) rather than absolute (current meter reading). Consequently, if communication is interrupted for any reason, PG&E estimates the usage based on prior usage. That may be significantly wrong for customers with highly varying usage, like those of us who charge EVs and use solar and batteries. Furthermore, I found that the sum of all the Green Button hourly data did not match the current reading of the Smart Meter.

Since my solar panels were installed in 2000, I have been reading the meter every morning and manually recording the value. The SmartMeter was installed on 2013-04-17 with an initial value of 00000 and hourly kWh usage data has been available since 2013-04-22 00:00. When I added up all the hourly kWh values from the downloaded SmartMeter data through 2017-08-01, the sum was about 6 kWh higher than the total kWh that was displayed on the SmartMeter itself at the same time. I asked PG&E about this discrepancy at the time, but their response was lame. The following was derived from my exchange with them.

Since I have solar panels, the net kWh consumed between the time the SmartMeter was installed and the first available downloaded data from five days later may have been negative. If I assume a net -2.5 kWh for those first five days, then the sum of the downloaded hourly values compares within +/- 1 kWh with my visual meter readings for some months. However, the difference increased slowly over the subsequent four years so it would be 3.73 kWh on 2017-08-01. I have attached a table showing monthly readings of the meter and the sum of the downloaded data for the same time. The difference fluctuates because no fractional kWh is displayed on the meter and because my reading may not be exactly on the hour. However, there is a clear trend in the data.

The PG&E Smarter Energy person who replied tried to dismiss the difference as a difference in the precision of the Green Button data versus the full precision values used for the billing calculation, citing an example of the reading 1.05435485 being truncated to 1.054. She asserted that the sum of the billing data would match the meter, but that fails in a few ways to explain the difference:

1. If the readings presented in the data that I can download were always truncated rather than being rounded then the sum of the hourly readings would be smaller than the reading I get from the display on the meter. What I observed is that the sum is larger than the reading I get from the meter.

2. If the readings were correctly rounded without any bias then there should be no accumulation of error assuming that the fractional values are uniformly distributed (and I can't think of any reason why that assumption should not be valid). The difference should be sometimes positive and sometimes negative. There is a lot of "noise" in the visual meter readings I have recorded because the meter does not display fractions of kWh and because my readings were not always exactly on the hour, nevertheless in the data I have observed there is a definite slope of about 0.00005 kWh per hour. This could be explained by always rounding up in the 0.0001 digit, but that would be incorrect, and possibly illegal.

3. I am using the downloaded data in the XML format which has another digit of precision compared to the CSV data. I assume the limit to 10 Wh precision in the CSV download is just to improve readability. However, the XML download data is limited to 1 Wh precision (no fraction) when there is no reason for that. They should provide the full resolution available.

4. The cited example postulated 8 digits of fraction, but the bill only shows 6. And in the "detail bill" spreadsheets I received before the new format of B&W NEM bills was introduced, there were only three digits of fraction shown and they were always .000 so essentially there were no digits of fraction available. Furthermore, the bill shows only the incremental values for the month. The precise total meter reading is not available anywhere, so I can't really tell whether the kWh as billed matches the meter reading.

 

[sorka]

I was never able to fully understand the B&W bill and finally just gave up. I went back today to give it another go, but I still wasn't able to get the numbers to work out. My billing is further complicated with as I am on E-TOU-C which reduces the charge below 100% of the baseline which is 10.5kWh * days in the billing period as a credit which reverses and becomes reduction in the credit for the baseline hours.

I am also with Silicon Valley Clean Energy CCA, so my generation isn't from PG&E and needs to be removed from the tariff schedule. Since I am with a CCA there is a Power Charge Indifference Adjustment (CCA DA POWER $0.04760/net kWh) and a Energy Cost Recovery Amount (CCA ECRA $0.00032/net kWh) which are positives as they become extra credits. Also according to E-TOU-C because I am with a CCA I get hit again for Wildfire Fund (CCA WILDFIRE FUND same $0.00580/import kWh) and the Competition Transition Charge (CCA ONGOING CTC same $0.00004/import kWh) which are part of the NBC and a Franchise Fee (FFS $0.00048/import kWh), so it seems like PG&E is double dipping here.

The only thing that I can say with respect to your bill is that the number that you are getting $145.04 is coming from the "TRUE-UP HISTORY SUMMARY" table and is the total of all the charges/credits to the left. I can calculate everything here from the hourly data and the E-TOU-C tariff except for the "E84 BL CHG" column that I can get to add up to the same number.
View attachment 662592

Yes, but all of those components are supposed to be included in the TOU energy rate tariff so regardless of whatever complexity there is in the BOD, the breakdown of peak, part peak, off peak kwh's multiplied by their respective energy rate should match exactly.

The NBCs are already called out separately and they appear to be correct in my case.

What do you get when you multiply our TOU energy components by their respective tariff rate? How close does it come to your $171.24 credit that you actually got.

 

[sorka]

He really should look for the discrepancy between the Green Button data and the B&W bill data. I did this once and found that there was missing interval data and PG&E just threw in whatever "estimate" that it wanted. Their value was not reasonable by my estimation, but the number of cents in dispute was not worth getting my knickers in a twist about. I also found that they estimated usage during an outage, which on the face of it is pretty outrageous, but the billed amount was $0.48 and I wasn't going to raise a stink about that either.

In this case they match. The green button data, the BOD peak, part peak, off peak to and from the grid, my Emporia meter, and Tesla's CT all match to within a 2 kwh.

The point here is that the BOD already lists exactly the correct TOU usage but the price for each TOU component indexed through the EV2A rate doesn't match. It comes out to $160 in credit using the BODs own TOU usage but the actual credit is $145.

 

[sorka]

I goes the next thing for me to do is to take the each of the TOU kwh components and match them to the "RESIDENTIAL ENERGY CHARGES" section which has multiple line items for each of the components and them together to get the energy rate. They SHOULD match exactly the EV2A rates but obviously they can't. Something that I'm getting charged for on import is being left out on export.

 

[wwu123]

It appears that the Smart Meter telemetry data is only incremental (usage during an interval) rather than absolute (current meter reading). Consequently, if communication is interrupted for any reason, PG&E estimates the usage based on prior usage. That may be significantly wrong for customers with highly varying usage, like those of us who charge EVs and use solar and batteries. Furthermore, I found that the sum of all the Green Button hourly data did not match the current reading of the Smart Meter.

Since my solar panels were installed in 2000, I have been reading the meter every morning and manually recording the value. The SmartMeter was installed on 2013-04-17 with an initial value of 00000 and hourly kWh usage data has been available since 2013-04-22 00:00. When I added up all the hourly kWh values from the downloaded SmartMeter data through 2017-08-01, the sum was about 6 kWh higher than the total kWh that was displayed on the SmartMeter itself at the same time. I asked PG&E about this discrepancy at the time, but their response was lame. The following was derived from my exchange with them.

If I'm understanding your discrepancy, over 17 years from 2000-2017, your downloaded Green Button data was 6 kwh higher than the meter itself has accumulated. But isn't it as you said, the Green Button data includes estimated consumption for interruptions? Like when I have occasional <1 hr power outages, they do their estimate and I'm pretty sure that gets added into the online and Green Button data, but the meter itself was unpowered (not just interrupted communication) and was not spinning. So that will cause a permanent and growing discrepancy over time?

Side note, just curious if you've considered automating your daily meter reading routine with a Rainforest Eagle or other Zigbee device to your Smartmeter, since those have been available for the last several years? It's not the absolute meter reading (accumulated kwh), instead sends the interval's rate (kw), so maybe has some small rounding errors over time at the precision level you're seeking. But much easier - since I got solar, I have the last 8 years of SmartMeter net consumption data archived in pvoutput.org at 5 minute intervals.

EDIT: slight correction, the Rainforest Eagle actually gets the absolute meter readings at each timestamp (both the Send and Receive accumulated kwh). It's realtime dashboard converts that to show the consumption rate (kw) for the interval...