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
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:
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
@brandon.keilman,
Good question and thinking. 3 thoughts:
- Sense has been enhancing billing and costing data incrementally. They recently added the solar āfrom gridā and āto gridā data as well as a separate āsell-backā price to help solar users.
- But sometimes the cost of re-doing the infrastructure for the incremental improvement is 80% of the cost of doing the infrastructure for the more general solution. For example, the cost to build a āgrid editorā for 2 TOU periods, plus the cost to rework the infrastructure so that 2 TOU period-based costs show up in the Devices lists is pretty much the same as doing it for 10 TOU periods.
- And once you are doing āopen heart surgeryā on the infrastructure related to costing/billing, Sense might feel it is more valuable to add at least the infrastructure āstubsā for adding billing tiers and custom billing periods without going in for āsurgeryā again. Both those items, custom billing periods and tiered rates, are hot items on the Wish List as well.
2 Likes
I am in So Cal and have TOU Pricing. The current TOU is like this
For April - May:
High Peak - 0.19935 - 12pm - 5pm
Low Peak - 0.19935 - 10am - 12pm, 5pm - 8pm
Base - 0.17581 - 8pm - 10pm
Currently in the Sense app I can only enter one price. This topic was discussed since May of 2018. Any updates if this feature will be available anytime soon?
Not yetā¦ Although Sense did recently add a āsell priceā and solar āto gridā and āfrom gridā cost calculations, so that shows the are adding new pricing cost/features with new releases.
With this whole COVID Iāve had more time to play with my home automation and sense, any news on the tiered plans being implemented. Iād be happy to beta it if itās in beta!
1 Like
3 years now and still not even a simple 24/7 grid that us users can put in our own price per kw.
just sad
2 Likes
Hi @rex. @kevin1 did an amazing job at showing how this is anything but simple here: Tariff Trade-off Analyzer using Sense Data. That being said, we recognize thereās a lot of feedback for this feature. Weāre currently working through some other highly demanded features from the community, so thank you for adding a +1 to this wishlist item so we can gauge community/user interest moving forward.
Many of us with TOU donāt have a single 24/7 table. And some of us even have tiering within multiple TOU tables. Hereās a summary of the number of US plans that have one vs. more than 1 TOU tables for the top 25 utilities with the most total rate plans.
2 Likes
I am also interested in this feature! Surprised to see it has been discussed since 2018 and still doesnāt exist, even in a basic form. Thank you for continuing to consider implementing it.
Hey folks,
This isnāt a replacement for a built-in ToU calculation, but this web app I constructed does let you look at any Sense month or billing period. It uses a simple ToU pricing table that everyone seems to think is good enough. It runs directly off a Sense exported hourly CSV for any month or billing period you provide it.
https://pgstats.shinyapps.io/SenseToUCalculator/
To use it, you all have to fill in and supply a ToU pricing table that tells the price across all 24 hours in a day for each month. A sample table, that has 4 different ToU periods, off-peak and peak, for both summer and winter, is below.
PriceTable.csv (2.4 KB)
The columns show the cost of each day, with the different colors representing different ToU prices. As you can see, I have solar, so there are some days that have ToU periods with negative pricing, which reduces my bill.
Try it and enjoy ! And have a happy and safe 4th !
3 Likes