@brandon.keilman,
The Sense product is accurate enough to provide the needed energy data for the calculation, so it’s not a question of “product maturity” in the accuracy dimension. The bigger issue is the wide variety of tariffs (TOU/Net/other) that would need to be supported. I just went through a database of pretty much all the residential tariffs in the US to see if I could build a calculator that used that database to compare costs between all the tariffs.
That was instructive in understanding the features that Sense would need to build into their product to accommodate most tariff calculations:
-
2 customizable 24 hour x 12 month “grids”, one for weekdays and one for weekends, to assign pricing TOU periods to specific hour/month pairs. The largest number of TOU periods I saw for a tariff in the database was 9, so the app would likely need to accommodate up to 15/20 or so to be future ready. Presumably the UI would let you assign informative names for each period (in the OpenEi database, they are just numbers). Names like “winter partial-peak”, “summer peak”, “winter off-off-peak”.
-
1 customizable rate table for each named period. The rate table for each period needs to accommodate both a flat rate or a set of rate tiers, where rate tiers are defined by the rates and either per monthly or per daily maxes for each tier (except the highest tier). Optionally, each rate table should also include sell-back rates and rate adjustments if those exist for that billing environment. It should be noted that I saw a maximum of 6 tier levels in couple of rate plans so the UI should probably allow for up to 10 tiers per period. The hour/month and rate tables are linked so that every time one creates a new period type, a blank rate table is created, and deletions work the same way.
-
1 customizable table/calendar that allows the user to set their billing period boundaries. It’s not good enough to specify just a recurring monthly date like they do today, because many utilities have billing periods that are not monthly aligned.
-
1 customizable table/calendar that allows users to specify their utility’s holidays that are treated as weekends for purposed of TOU periods.
-
I’m ignoring for the moment, a small number of tariffs that include demand charges that add a whole additional level of complexity.
-
Plus a place to enter additional parameters that affect billing:
Fixed monthly rate
Resolution period for TOU (this is a tricky one - more on this later)
True-up period for TOU and Net Metering
Minimum monthly payment
I mentioned the resolution period - that’s the minimum period that the TOU cost ((buy rate * from grid) - (sell rate * to grid)) is calculated. Theoretically, this could be every second (or less) but practical considerations force the utility company to take a simpler approach. For California, the NEM2 current increment is 1 hour for residential and 15 min for commercial, but both could get smaller over time. And with NEM2 the calculation is simply the net * (buy rate if positive or sell rate if negative). There are probably some TOUs that require an hourly ((buy rate * from grid) - (sell rate * to grid)) cost calculation. For those Sense probably still needs to do some work aggregating the hourly “from grid” and “to grid” since that isn’t exposed to the users today.
This is all possible but would require extensive UI additions across 2 1/2 different platforms (iOS, Android and web). There is also a need to maintain consistency within data entry, setting up defaults for easy single rate operation, and major support/education considerations (how do I enter this complex rate, and why am I not getting the answer I expect). For fun, see why my calculator was exactly correct for some months, but way off for a few others.
Finally the costing and a more complex bill cycle model would need to be webbed back into the places where costs and bill cycle aggregation shows up in the app (that strikes me as the hardest part).