Thanks for taking a look @dmitrysml777,
I do the grid chart the same way the OpenEI database does it, with hours represented by their start time, so the hour from 4pm to 5pm, is marked as 4pm or 16:00. Grid tables need to have an index associated with every hour, not referenced as the hour between 3pm and 4pm. In time programming, that is really 3pm to 3:59:59.999999pm.
If the hours 13:00 to 16:00 are covered, that’s 1pm-5pm
If hours 17:00 to 19:00 are covered, that’s 5pm-8pm ( yes, 5-8pm interval is only 2 hours long, unlike Jan-Mar, which is 3 months long).
If the hours from 20:00 to 09:00, that’s 8pm to 10pm
Sorry that that’s a bit confusing, but I think the chart matches the high-peak, low-peak, and base hours for weekdays. As I noted earlier, I had to combine a couple of high-peak, low-peak pairs that have the same price in Jan-Mar, and Apr-May, plus combined all the base periods throughout the year, to fit into the existing 6 TOU table.
More Insight into Electricity Cost Calculations
For those of you interested, I have been analyzing the database of US electric rates to learn all the possible cost calculation variants. To build a robust calculator, and one that can do comparisons, it’s important to build a single set of data structures that support all the possible calculations rather than doing 10 different variants of data structures for each flavor of calculation. That said, the sheer number of rate plans makes it hard to divine all the possible flavors of calculation and screen out non-existent combinations. I have finally spend some time unpacking/unrolling the pricing rate structure in the OpenEI database.
Here’s a glossary of the cost equation parameters.
rate - the $ cost per “unit” for electricity. Every time-of-use period and tier within a time-of-use period has a rate and a unit (almost). Residential rates in the database ranges from 0 to 0.81045 (81 cents).
unit - the measure that is priced. In most rates the unit is kWh, though my forensic analysis reveals units of “kWh Daily”, “kWh/kW”, “kWh” NA, and no units whatsoever. The “kWh Daily” has special meaning - it means that tiering thresholds are based on total daily usage, not per billing period like most.
adj - adjustments - a rate typically subtracted or added to the pricing ‘rate’. Adjustments range from -0.4624 to 0.342713
sell - sell is the rate that the utility pays you back for energy you produce. Rates with adjustments are applied to the “from grid” hourly data. Sell pricing is applied to “to grid” hourly data. Just to be clear, each hour can only have either a “from grid” or “to grid” net, not both. So the price used in the hourly calculation is different based on the sign of net energy usage. Sell rates range from 0 to 0.17244
ToU - Time-of-use period - this value isn’t directly in the database, but implicit in it’s structure. The database has a list of ToU periods, each with their own entries, which can be a simple rate or a set of tiers. Every rate in the database has at least one ToU. simple non-time-varying rates are just a single ToU. The number of ToU periods ranges from 1 to 9.
tier - tier level - this value isn’t directly in the database, but implicit in it’s structure. Tiers are implied if a pricing table in a specific ToU entry has more than one row. A tier will have pricing info (“rate”, “unit”, possibly also “adj” and “sell”). Tiers will also have a “max” that defines up to what energy usage, per day or per billing period based on the unit, that price is applicable. Above that max, pricing moves to the next tier. Rate tiers range from 1 (basic rate, no max) to 5.
max - is the usage threshold to move to the next rate tier for calculation. ‘max’ is compared against the running total for the day or billing period for that specific ToU period.
Of the 832 rate plans I’m working with in the OpenEI database, the distribution of combinations of parameters available are below. I’m suspect of a few of them.
Given that I’m going to need to reorganize the pricing tables to make them more editable, my plan is fill in all the parameters in the database and just apply the single “most complex” calculation. That means that I need to:
Convert all cases of non-tiered pricing to a single tier with a very large max
Fill in every row without an adjustment value with an adjustment of 0
Fill in every row without a sell price with a sell price of (rate - adj), because no sell price means that the sell price is really the same as the buy price.
Once I do that I can use a single calculation for all rates.
Why can’t Sense just use the same databases as Chargepoint? I just select my utility and plan and it knows exactly how much my energy costs going into my EV depending on the day/time.
My guess is $$$, but I hope the Sense team has at least tried to reach out to them…
@bretkeller,
That’s an interesting idea. Chargepoint has both the scale (50M$ in revenue, 700 employees) and direct business need to be able to price/cost energy flowing through their shared and home charging stations. I’m note sure that their shared charging stations have to rely on an outside database because utility metering infrastructure also delivering pricing information - my smart meter knows the instantaneous pricing via the same networking that the utility uses to read my meter every few seconds.
But it appears that I haven’t been clear enough with my explanations - The database is just a list of utilities and rates with an associated structured bunch of numbers. The data is pretty worthless without
the secret decoder that relates the data to the pricing calculation - the data implies specific calculations, but they are not built into the database.
regular updates to the database
support to handle issues when the price doesn’t match the bill
Not as simple as just buying a “pricing database”
BTW - I can’t see how Chargepoint would be anywhere near accurate for a home charging station using tiered electrical pricing. It would have no way to know your home’s total consumption to date vs. the tier thresholds, to select the correct price.
Good day!
I love this feature. I am lucky (I suppose?) to be in an area that doesn’t have peak and off peak prices.
Sense does not seem to have an option to add prices for peak time costs. Would it be possible to add this to the sense electricity cost page? This would allow users to view how much something costs during peak vs off peak and/or an overall cost that would be more accurate than a single price.
Sense does track energy useage by the hour in the Power meter page so perhaps and option for Labeled Peak Price From {start-time}to{end-time}
This is great and in my mind this seems like such a simple option to add to Sense programming so that we can simply listed cost based on time. At least 2-3 tiers and we can just enter the times and rates. I feel like many of these simple options that improve functionality for folks are never implemented.
If you are interested and want to play with TOU, I have done a web app that reads in a Sense Hourly download data file for a single billing period and calculates your usage or costs separated by TOU period or by device. Data on the TOU pricing comes from a national database. I haven’t implemented tiers because there are several different flavors of how tier breakpoints are calculated. I’ll be the first to say that TOU and tiering is not as simple as most people imagine.
Having the ability to enter time of use pricing would be a huge help to calculating my energy costs.
I’m here in California with an EV so my electricity ranges from 9c/kwh to 52c/kwh.
I hope this counts as an up vote to integrate cost/kwh based on time.
Thanks!
@bvinick,
Which utility are you using ? Not that it’s a replacement for a built-in TOU calculation in Sense, but this web app I built should do the TOU calculations for you using the downloaded Sense hourly data for one billing period. I use it for my PG&E EV TOU tariff that sounds a lot like yours.
Hey @tasmindomine - this is a product wishlist thread, meaning that folks who want to see a specific feature added to Sense can “like” it here so we can gauge popularity amongst our users. We’re aware of how important this feature is to Sense users with Time of Use plans, and will keep the Community up-to-date on relevant updates.
Time of Use compatibility has been added as part of V34 (iOS/Android).
As one of the most popular product wishlist posts from Community members, we’re excited to roll this out. We are also hoping to add additional functionalities to this feature in the future.
