I’m guessing that your buddy hasn’t looked at PG&E’s ToD/ToU pricing. I actually wrote a program to price my energy based on PGE’s pricing calculations and learned a lot. The issue is not so much programming it, but figuring out the UI for inputing all the complex variables that go into ToD calculations for many different utilities:
Billing periods - PGE billing doesn’t line up with months or even specific days in a month. It moves around so one really has to input a list of all the billing periods for a specific year ahead of the calculations.
Classes of days - PGE has two classes of days for billing schedules, but some utilities have more. PGE separates weekdays from weekends and holidays. That means one has to have a way of inputing classes plus specifications for each class. That includes inputing a list of PGE holidays before calculating cost
Billing schedule pricing levels - PGE has 3 possible pricing levels in a day for each class of days - peak, partial-peak and off-peak. Weekday classed days have 3 pricing levels (4 pricing periods in the schedule), weekends and holidays only have 2 levels (2 pricing periods).
Billing seasons - PG & E has two billing seasons, Winter and Summer, but some utilities have more. For each billing season, the pricing schedule can move around a little. That means you have to have a way of inputing the seasons, which may vary by a few days from year to year. Plus the prices vary for each pricing level based on the season.
Separate per kWh transmission and delivery charges - I actually use a different energy supplier than PG&E, so my transmission, and other “junk” charges are calculated separately from my TOU, but are simple per kWh calculations.
I ended up with the multi-dimensional rate schedule below where some charges are simple kWh charges all the time and other vary with period per the schedule for that specific day and by season.
- Tiering - In addition PGE charges an tiered efficiency surcharge on top of all the other costs to steer customers to conservation. IN PGE’s 3 tier case, customers who stay within the lowest per month tier (based on a daily baseline allowance) are subsidized (negative surcharge), but the surcharge becomes positive for all incremental energy used beyond the next two baseline tiers.
It’s hard for me to imagine Sense building a one-size-fits-all partially programable calculator for the final calculation that works for every utility. There are really two parts to the problem:
- Annotating/decorating the power data with all the time varying parameters (pricing period, season, billing period) that are needed to do the needed billing calculations.
- Doing the multi-part calculation - ToD component, non-ToD calculations, tiering calculations, tax calculations, etc. to reach a final value.
I would like to see Sense focus first on annotating / decorating the the power data with needed data for the billing calculations, so they can start showing usage graphs in terms of different pricing regimens (slightly different color green bars for peak, off-peak, and partial-peak for examples).