Time of use pricing

[kevin1]

@benjamin.t.brannon,

You inspired me to take another look at energy analysis software and other resources in the public domain that might help me develop accurate costing software for Sense data output, especially TOU. The good news is that there are some good resources like the OpenEI database (mentioned above). The bad news is that quirks of individual TOU plans defy easy categorization, requiring one-offs per utility or plan to make accurate.

For example, here are a few of the things I had to program around to get just the TOU usage right for my utility, PG&E.

• Had to to assign the data to a non month-aligned custom billing schedule where billing periods ranged from 29 days to 33 days (used a custom billing year file)
• Had to apply PG&E-specific holiday schedule to the hourly usage data to register holidays on the weekend schedule.
• Had to do a custom adjustment to TOU period assignment for PG&Es non-standard daylight savings time transitions.

Tariff Trade-off Analyzer using Sense Data

OK, I managed to muscle my way through a calculation using my Sense hourly net usage (Total Usage - Solar Production) for as much of 2019 as I have (Apr. 6 - Dec 31), for ALL 67 active PG&E tariffs. I have also done a comparison against my my matching 2019 billings, though there are still some ambiguities given I use a separate CCA (Community Choice Aggregation) supplier for generation. So comparison first. For 2019, I was on the EV-A EV Time of Use plan, but with a different generation suppli…

After trying the marvelous NREL PVWatts program, which does great solar forecasting, but only presents results in standard time for the entire year, I get the feeling that many of these programs are great starting places, but are missing the completeness that full productization would require (one can’t get solar “savings” right without accounting for DST).

So I can see why Sense would want to stay away from TOU calculations due to the high cost of productization and associated support.

Update - adding a few more accuracy challenges for TOU and general cost calculations

• Different TOU tariffs have different cost “resolution times”. PG&E currently use 1 hour for residential NEM2 and every 15min for commercial. Other utilities use their minimum reporting increments, plus some use “from grid” and “to grid” accumulations at the end of every billing month. I plan to eventually use “from grid” and “to grid” accumulations, once Sense adds them to hourly export, since that represents the worst case for TOU (except for a few weird tariffs that pay users more for solar than they charge for grid energy.)

• The OpenEI database doesn’t seem to contain the necessary NEM2 data for PG&E for non-bypassable charges used by TOU tariffs. I would assume that would show up as a sell price that is less than the rate/buy price by the non-bypassable charges.

• The OpenEI database also contains plenty of specialty tariffs that have all sorts of weird incentives built into them. For productization, the database would need to be pruned to just typical residential rates.

• Plus the OpenEI database doesn’t contain data for some of the new common split generation/distribution tariff introduced by CCAs (Community Choice Aggregators).