Time of use pricing

Adding my vote for variable pricing. I am on Hourly Pricing from ComEd in Illinois. The price fluctuates every hour and is only know after the fact. ComEd published estimated prices and then true prices at the end of the hour.

3 Likes

I second demand pricing. I’m hoping my state doesn’t go that way, but it is currently on the table…

1 Like

You seem to be about 20% below the national average.

In 2018 Kentucky was about 25% NG+Hydro+renewables (electric generation) and the rest in coal.

In March 2019, residential electric in the US averaged 12.83 c/kWh
Lowest: Louisiana at 9.29
Highest: Hawaii at 33.99

Hours of fun poking around here:

The feedback loops therein for Sense users are a little mind boggling.
Enough to make you want to move?

@RyanAtSense Updated ETA, please. I’m in a SoCal Edison region. A self-editing tool would be sufficient for my needs.

1 Like

What is the current eta, why is this taking so long, my cost info is useless at this point

@reuben.sterling, @dchurco,

If you really want TOU calculations today, you can do in Excel and downloaded Sense data. Pretty straightforward. Sample spreadsheet here:

  • Fill in in the Grid lookup table with pricing
  • Download your hourly data from Sense for Total Usage via the Web App.
  • Add the last four calculated columns
  • Use a pivot table to filter and a sum hourly cost for whatever period you want to.
2 Likes

We understand that this is an important feature for a certain subset of users, but that is still quite a small subset. We do intend on supporting the varieties of dynamic billing plans in time but implementation is far from simple, as has been elaborated on above.

I will update this thread when I have more news.

1 Like

Get on it please :slight_smile: I would love to have this to understand what I can do to save some coin during the winter. Even if you just allowed one to enter in rates by time block, it would be enough! :slight_smile:

1 Like

Adding my vote for this. Mainly as a way to determine if TOU pricing would make sense for me. at the current moment I am having to export and do the excel method. A straightforward simple approach would at least get me into the right ballpark.

1 Like

Adding my vote. I have Green Mountain Power utility in Vermont and subsidized/linked with Efficiency Vt to obtain Sense. I have TOU rate, Chevy Bolt, cold.climate heat pumps, 5.1 kw solar array on roof. Have wood stove and passive solar as.additional heat supply. Aquanta to monitor and control electric hot water heater which does have TOU capability. Only fossil fuel is small amount of propane for cook stove and wife has ICE car and works from home and her annual mileage is well below US average.

One comment above suggests that the hard part of adding ToU cost tracking is the UI, but I think the most sensible way to do this would be for Sense to make its own database of rate plans, and just have you tell it where you live and which rate plan you’re on. For PG&E, the rate plan structure is insanely complicated: the definitions of Summer, Winter, and Peak/Part Peak/Off-peak are all different from one rate plan to another, and on top of that, for some of them your “territory” determines your base rates. Plus, of course, some rate plans have different rates for weekends and holidays, while others do not. For a regular consumer to accurately input their rate structure would be extremely tedious and error-prone. On the other hand, if Sense had their own database of this stuff, all I’d have to do is tell them I’m on the EV2-A plan, and live on the San Francisco Peninsula (territory T), and that would do it. This strikes me as rather obviously the preferred way to do this. In addition, the Sense database could handle things like the 800% of baseline limit, which if you run over gets you kicked out of the rate plan into a much more expensive ToU plan, with no option to change to a different plan for a year. I’ve tried to calculate my baseline, but the wording in the official tariff document on how this is calculated simply doesn’t parse, so I’ve thrown up my hands. I’m sure there are a whole lot of new Tesla owners who would love some help with this.

@gobbel, that would certainly teach them the ins and outs of rate plans, though without feedback in terms of the actual billing statements, I’m guessing that they would have a hard time nailing everything 100%. I’m trying to move my R program that computes PG&E EV1 billing to EV1-A and that’s taking more time than I expected due to subtle changes that require feedback from reading the bills…

Yes that would be nice, but there are so many utility providers (and rate structures within those providers) that this might be somewhat impractical. PG&E is one of the more complicated ones, so I’m not sure that’s the best example, though it’s got a huge territory so it certainly is important to consider. I think that a first pass just allowing basic TOU rates and demand charges (that users set on their own) would take care of 80% of people, and then perhaps hard coding certain structures in for big utilities would be helpful. Having said that, PG&E changes their rates monthly, so that would be a big effort.

On a personal note: professionally I work as a building engineering consultant and most of what I do is building energy models of these buildings. A while back we only looked at energy, but now we are more interested in detailed cost (and even time of use carbon). I mention this because all of the software I use has utility rate structure inputs in the UI and have had it there for decades. None are are perfect, but there’s no reason that Sense needs to reinvent the wheel here, especially as some of these tools (EnergyPlus, eQuest/DOE2) are completely or fairly open source.

3 Likes

@benjamin.t.brannon,
Thanks for the pointers. I actually looked at the open source programs you highlighted and they were really cool, but seemed mostly focused on HVAC energy and modeling heating/cooling requirements. But you also spurred me to find the OpenEI database of rate tables… At one fell swoop I can download most of the rate schedules in the US. Sorting through them is another story since they have some many different structures.

The good news is that I have been able to download and parse the .json version of the database. The bad news is that is a complex schema with a lot of context built into the comments. 52,251 different rates with up to 60 different variables, where variables can actually be lists of data. The json database is probably a good training ground for representing all the possible rate schedules.

The gist of my current rate is here, but there are some missing details…

1 Like

@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.

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).

1 Like

Q.E.D.!
or is it Q.E.F.?

Can definitely see quoting this moving forward.
Well demonstrated sir.

3 Likes

Voting for this feature as well. Not sure how this request would be a “small subset of users” it’s possible the product isn’t mature enough to be in enough areas to gather an accurate amount of data to determine how many places actually do utilize TOU rates. I would guess more areas do use this method than those that do not. Maybe not adding simple features like this is what keeps the product from maturing faster.

To keep it easy adding a place where the user can input their own TOU rates that the app then looks at for its rate input would be plenty useful IMHO.

Im not a developer so maybe I’m way off in my thinking of what would be considered keeping it easy.

@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).

1 Like

@kevin1 You recently called this out from one of @ramon’s posts

I’ve been thinking similarly.

So perhaps the only practical solution to get this crazily complicated TOU data into any given Sense data stream in some digestible form would be to have a “TOU proxy” that likewise looks something like a smart plug to Sense. As you point out, there’s every reason to suspect that future TOU will move into the sub-day, and sub-hour timeframe. Easy to imagine pricing at 1s samples.

A 1s resolution pricing waveform would be a goal that would seem to accommodate future permutations?

All the taxing waveform (pricing) generation would be done outside of Sense. You would “simply” subscribe Sense to your local Sense-readable proxy HS110-like TOUGh (Time Of Use Generator, heuristic).

Of course the problem is also that TOU can be a post-processing task. Sigh.

[My reference point for pondering the complexities of electricity pricing is my local ISO dashboard. It only takes a minute to realize that adding local solar into the mix is going to make such things look quaint very soon:

Real-Time Dashboard - NYISO ]

This is all great and amazing information that sheds a whole new light on how power is billed in tons of different areas which I honestly had no idea even existed.

I can understand the hurdle from a development side now. Why not start in steps? First add an option to at least start with maybe two different charges that are manually entered. Like peak and off peak times. Then expand at a later point to allow for more times based off times of year like you mentioned. Then lastly start to tackle the bigger hurdles where there are by the minute type calcs, and credit back type instances? Maybe the result falls a little on the end user to figure out as well instead of sense being responsible to try and find your local data/billing rate or style?

Really just thinking out loud, no need to solve every problem in a single update in my opinion. Let it grow over time and add improvements as they are available even if they are small. (Like moving the live power button to the front of the GUI)

1 Like