This How-To is for Signal customers and provides strategies for modeling usage when you have less than a year’s worth of bills or require hourly usage data. With the help of Genability’s Typical Baseline API, you can turn one or more bills into twelve, with just two calls and a little bit of code.

Switch and Conduct customers have a simpler approach! They can take advantage of our Inteligent Baselining capabilities, and should stop here and read our Inteligent Baselining How To instead.

Problem: Not Enough Data

It’s common to run into potential customers who don’t know how much electricity they use. Sometimes, these customers have access to their utility’s online bill service or keep a good record of their bills, and you can use that data to develop a usage model for their site. Other times, this isn’t possible: your customer’s utility may not offer access to detailed usage data, or maybe the customer throws out their bills as soon as they pay them. Either way, a lack of usage data can be a major impediment to doing an accurate savings analysis.

Based on how many bills you have access to, and the level of bill detail, we have some strategies in this page to estimate a full year of usage data.

Primer on Typical Baselines

We will use our Typical Baselines quite heavily in this How To, so it’s worth taking a detour and getting up to speed with that API before we go too much further. The typical baseline service provides a collection of building usage profiles from around the country, organized by location, customer type, and building type. They’ve been developed by taking reputable building usage models (such as RECS, CBECS and CEUS), as well as dynamic profiles published by some utilities, and calibrating them with actual data from thousands of analyses that have been done with the Genability API.

Get the best Typical Baseline

So lets take a look at a typical baseline for a hypothetical customer. Lets assume we are working with a residential customer living in San Francisco, with zip code 94123. We get a baseline for this customer with the following request:

GET /rest/v1/typicals/baselines/best?addressString=94123&buildingType=RESIDENTIAL&excludeMeasures=false&groupBy=MONTH&measureUnit=proportion

This request returns a baseline profile with a couple of special options. First, we’ve grouped the result by month. You can also choose to group by hour, but month is good enough for this scenario, since our customer is on PG&E’s E1 tariff (a non-TOU tariff), which doesn’t require hourly usage. We’ve also specified that results be returned as proportions rather than absolute consumption, which is the default. This will make scaling our usage data a little more straightforward, when we do that later.

Among other things, this request will return a series of measurements:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
"measures": [
{
    "i": 1,
    "v": 8.84306292
},
{
    "i": 2,
    "v": 7.72489182
},
{
    "i": 3,
    "v": 8.47541736
},
{
    "i": 4,
    "v": 8.01065365
},

/* edited for length */

{
    "i": 12,
    "v": 8.81430209
}]

Each measurement is indexed by the month of the year that it corresponds to, with 1 representing January, 2 representing February, and so on. Since we chose to have the results returned as proportions, each value represents the proportion of a typical customer’s annual usage that is used in that month. So, in this example, a typical customer in zip code 94123 uses 8.84% of their annual total in January.

If you want to know more about Typical Baselines, like the different building types available, take a look at the API Reference page.

Now you know enough about Typical Baselines to be dangerous, so lets get back to the problem at hand!

Case 1 : I don’t have ANY bills!

If you don’t have access to any bills, you can use the typical baseline by itself without having to do any scaling, to estimate monthly electric usage and costs. Use the buildingId property key to specify the building type of the typical to be used. Available building types are described on the API Reference page. In contrast to the previous typical baseline call, absolute usage instead of proportions are used.

Here’s how you request an on-demand calc, using a RESIDENTIAL typical baseline for usage:

POST /rest/v1/ondemand/calculate
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
  "fromDateTime" : "2018-01-01",
  "toDateTime" : "2019-01-01",
  "tariffEffectiveOn" : "2017-10-01",
  "masterTariffId" : 522,
  "detailLevel" : "CHARGE_TYPE",
  "groupBy" : "MONTH",
  "tariffInputs" : [ {
    "keyName" : "baselineType",
    "dataValue" : "typicalElectricity",
    "operator" : "+",
    "dataFactor" : 1
  },{
    "keyName" : "buildingId",
    "dataValue" : "RESIDENTIAL"
  }]
}

… and when you do this you get back the following (note the typical baseline has been projected into the future)…

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
{
    "status": "success",
    "count": 1,
    "type": "CalculatedCost",
    "requestId": "36f86e22-4575-4ee1-9614-1133d9faf071",
    "results": [
        {
            "calculatedCostId": "ade01e6b-b067-401c-ac61-3a98437614f1",
            "masterTariffId": 522,
            "tariffName": "Residential",
            "totalCost": 1500.01,
            "fromDateTime": "2018-01-01T00:00:00-08:00",
            "toDateTime": "2019-01-01T00:00:00-08:00",
            "currency": "USD",
            "summary": {
                "subTotalCost": 1500.01,
                "taxCost": 0,
                "totalCost": 1500.01,
                "adjustedTotalCost": 1467.17,
                "kWh": 6749.83,
                "kW": 2.01
            },
            "accuracy": 100,
            "items": [
                {
                    "fromDateTime": "2018-01-01T00:00:00-08:00",
                    "toDateTime": "2018-02-01T00:00:00-08:00",
                    "quantityKey": "fixed",
                    "rateAmount": 0,
                    "itemQuantity": 0,
                    "cost": 0,
                    "chargeType": "FIXED_PRICE"
                },
                {
                    "fromDateTime": "2018-01-01T00:00:00-08:00",
                    "toDateTime": "2018-02-01T00:00:00-08:00",
                    "quantityKey": "consumption",
                    "rateAmount": 0.22060799,
                    "itemQuantity": 521.569558,
                    "cost": 115.06241184,
                    "chargeType": "CONSUMPTION_BASED"
                },
                {
                    "fromDateTime": "2018-02-01T00:00:00-08:00",
                    "toDateTime": "2018-03-01T00:00:00-08:00",
                    "quantityKey": "fixed",
                    "rateAmount": 0,
                    "itemQuantity": 0,
                    "cost": 0,
                    "chargeType": "FIXED_PRICE"
                },
                {
                    "fromDateTime": "2018-02-01T00:00:00-08:00",
                    "toDateTime": "2018-03-01T00:00:00-08:00",
                    "quantityKey": "consumption",
                    "rateAmount": 0.22041558,
                    "itemQuantity": 469.476287,
                    "cost": 103.4798881,
                    "chargeType": "CONSUMPTION_BASED"
                },
                
/* edited for length */

                {
                    "fromDateTime": "2018-12-01T00:00:00-08:00",
                    "toDateTime": "2019-01-01T00:00:00-08:00",
                    "quantityKey": "fixed",
                    "rateAmount": 0,
                    "itemQuantity": 0,
                    "cost": 0,
                    "chargeType": "FIXED_PRICE"
                },
                {
                    "fromDateTime": "2018-12-01T00:00:00-08:00",
                    "toDateTime": "2019-01-01T00:00:00-08:00",
                    "quantityKey": "consumption",
                    "rateAmount": 0.22073111,
                    "itemQuantity": 522.72286,
                    "cost": 115.38119711,
                    "chargeType": "CONSUMPTION_BASED"
                }
            ],
            "assumptions": [...]
        }
    ]
}

Case 2 : I have one simple bill

If you have one recent bill with a single usage (kWh) value on it, then we recommend simply scaling the typical baseline up or down to the size of the usage on the bill. Lets walk through how to do this, assuming we have a bill for 500 kWh from 10/15/2017 to 11/15/2017.

  • First, get the best typical baseline, making sure to request the intervals for the date range of your bill.
GET /rest/v1/typicals/baselines/best?postCode=94123&country=US&buildingType=RESIDENTIAL&excludeMeasures=false&intervalFromDateTime=2017-10-15&intervalToDateTime=2017-11-15&groupBy=DAY

Here’s a snippet of the daily usage intervals returned. Note that intervals can also be returned by HOUR, MONTH and YEAR.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
                
            "intervals": [
                {
                    "fromDateTime": "2017-10-15T00:00:00+00:00",
                    "toDateTime": "2017-10-16T00:00:00+00:00",
                    "duration": 86400000,
                    "kWh": {
                        "quantityAmount": 17.860065,
                        "rateAmount": 0
                    },
                    "kW": {
                        "quantityAmount": 1.21726,
                        "rateAmount": 0
                    }
                },
                {
                    "fromDateTime": "2017-10-16T00:00:00+00:00",
                    "toDateTime": "2017-10-17T00:00:00+00:00",
                    "duration": 86400000,
                    "kWh": {
                        "quantityAmount": 19.524914,
                        "rateAmount": 0
                    },
                    "kW": {
                        "quantityAmount": 1.33904,
                        "rateAmount": 0
                    }
                },
                
/* edited for length */

                {
                    "fromDateTime": "2017-11-14T00:00:00+00:00",
                    "toDateTime": "2017-11-15T00:00:00+00:00",
                    "duration": 86400000,
                    "kWh": {
                        "quantityAmount": 18.938971,
                        "rateAmount": 0
                    },
                    "kW": {
                        "quantityAmount": 1.23953,
                        "rateAmount": 0
                    }
                }
            ]
  • Next, determine a scale factor by dividing the usage on the bill by the sum of the kWh intervals returned in the first step. The sum of these intervals is found in the intervalConsumption field of the response. So, scale factor = bill kWh / typical kWh = 500 / 577 = 0.866551.

  • Lastly, pass the scale factor into the calculation via the dataFactor property. This scales the typical baseline down to our bill’s usage.

POST /rest/v1/ondemand/calculate
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
  "fromDateTime" : "2018-01-01",
  "toDateTime" : "2019-01-01",
  "tariffEffectiveOn" : "2017-10-01",
  "masterTariffId" : 522,
  "detailLevel" : "CHARGE_TYPE",
  "groupBy" : "MONTH",
  "tariffInputs" : [ {
    "keyName" : "baselineType",
    "dataValue" : "typicalElectricity",
    "operator" : "+",
    "dataFactor" : 0.866551
  },{
    "keyName" : "buidlingId",
    "dataValue" : "RESIDENTIAL"
  }]
}

In the example above we’ve estimated monthly usage and costs for PG&E’s E1 tariff, which like most flat and tiered tariffs, only requires monthly usage to determine costs. It’s worth mentioning that since the granularity of our typical baselines is hourly, we’ve essentially used a sinlge bill’s usage to estimate hourly usage for the entire year. This becomes especially helpful if your customer is on or considering a TOU tariff, where the cost of energy varies by time of day.

Case 3 : I have a bill with usage and demand

Suppose your bill is a bit more complicated and includes both usage (kWh) and peak demand (kW) values on it. This is more common for commercial customers, although some residential tariffs do have demand charges. Just as in the previous case, we recommend scaling the typical baseline to the usage on the bill, but instead of passing a scale factor on the typical, we’ll explicitly pass usage data via the dataSeries property. This allows us to scale our load to both the usage and demand on the bill.

Lets assume we have a Commonwealth Edison commercial bill for their Medium Load Hourly Pricing tariff, with 233,443 kWh and a peak demand of 583 kW from 9/20/2017 to 10/19/2017.

  • Get the best typical baseline, making sure to request intervals by HOUR for the date range of your bill.
GET /rest/v1/typicals/baselines/best?addressString=60601&buildingType=MEDIUM_COMMERCIAL&excludeMeasures=false&intervalFromDateTime=2017-09-20&intervalToDateTime=2017-10-19&groupBy=HOUR
  • Determine a scale factor by dividing the usage on the bill by the sum of the intervals returned in the first step (note that total interval consumption is returned in intervalConsumption field). In this case, scale factor = bill kWh / typical kWh = 233,443 / 88,934 = 2.624902.

  • Multiply the hourly kWh intervals returned in the first step by the scale factor. Then pass the scaled usage values to the calculation using the dataSeries property, along with the peak demand.

POST /rest/v1/ondemand/calculate
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
{
  "fromDateTime": "2017-09-20T00:00:00-05:00",
  "toDateTime": "2017-10-19T00:00:00-05:00",
  "masterTariffId": 85097,
  "groupBy": "YEAR",
  "detailLevel": "CHARGE_TYPE",
  "billingPeriod": "true",
  "expected": {
    "totalCost": 17818.21,
    "adjustedTotalCost": 17818.21,
    "kWh": 233443
  },
  "propertyInputs" : [
  {
    "keyName": "consumption",
    "fromDateTime": "2017-09-20T00:00:00-05:00",
    "duration": 3600000,
    "dataSeries": [ 179.77, 169.33, 177.38, 203.24, 229.62, 327.97, 402.25, 480.49, 493.95, 484.76, 482.85, 481.81, 490.36, 485.81, 490.36, 492.63, 471.55, 398.56, 416.9, 376.97, 294.23, 208.05, 200.31, 174.53, 177.33, 166.86, 174.15, 199.34, 228.99, 340.08, 407.32, 479.62, 496.14, 485.39, 493.42, 483.04, 498.33, 496.8, 496.61, 500.15, 475.29, 400.22, 426.93, 395.93, 307.06, 217.16, 208.94, 180.9, 185.57,	174.74,	179.49,	195.77,	208.88,	293.34,	386.8,	452.88,	475.67,	468.29,	490.77,	486.67,	481.07,	484.64,	451.22,	445.37,	416.24,	374.97,	389.71,	353.54,	266.38,	215.67,	193.04,	182.58,	167.97,	171.34,	160.23,	171.4,	165.55,	235.8,	213.24,	302.6,	299.77,	309.64,	315.48,	326.48,	310.68,	303.5,	297.58,	299.62,	269.39,	274.75,	274.18,	279.3,	241.61,	218.18,	188.04,	189.76,	180.62,	180.83,	168.28,	200.83,	224.36,	288.63,	313.33,	357.56,	354.28,	357.44,	364.14,	359.55,	374.08,	367.86,	361.46,	363.01,	349.13,	297.68,	314.19,	292.36,	257.42,	201.33,	197.17,	171.46,	173.96,	163.34,	170.86,	193.99,	223.43,	346.19,	406.08,	473.29,	499.82,	498.63,	513.64,	510.12,	526.37,	528.51,	525.73,	528.92,	500.91,	405.13,	408.37,	370.21,	288.92,	205.58,	197,	170.15,	173.21,	162.32,	168.63,	197.14,	224.88,	340.93,	400.51,	483.9,	516.04,	526.74,	559.75,	566.64,	589.54,	604.23,	613.69,	620.17,	582.46,	486.02,	495.36,	459.1,	341.85,	239.64,	230.56,	201.23,	204.45,	189.32,	195.12,	231.84,	256.43,	365.04,	444.5,	549.18,	585.57,	592.58,	600.14,	598.78,	635.06,	647.61,	659.53,	670.99,	626.7,	505.27,	500.91,	450.27,	326.72,	234.55,	227.6,	190.96,	190.4,	177.42,	182.42,	212.71,	233.55,	341.9,	422.23,	531.12,	565.94,	560.24,	599.59,	608.29,	631.47,	629.69,	630.31,	627.6,	587.69,	494.43,	490.55,	441.74,	336.46,	239.2,	232.11,	202.04,	211.18,	196.6,	201.59,	218.66,	230.71,	301.73,	375.15,	454.1,	481.09,	474.34,	475.13,	460.48,	467.85,	463.81,	448.79,	457.85,	424.51,	386.12,	399.14,	363.9,	279.26,	226.63,	194.29,	184.85,	167.54,	169.95,	161.05,	171.79,	167.73,	231.17,	209.79,	286.9,	277.49,	279.74,	287.43,	291.74,	287.93,	278.35,	267.96,	264.06,	230.14,	261.04,	247.09,	257.09,	232.84,	207.36,	186.2,	176.01,	175.15,	175.89,	172.38,	207.61,	244.23,	308.48,	313.38,	331.71,	318.04,	321.88,	330.4,	326.94,	330.98,	332.88,	332.04,	336.24,	333.32,	300.69,	314.65,	297.16,	267.76,	208.46,	209.85,	188.94,	201.79,	193.25,	208.36,	241.64,	280.21,	446.75,	464.44,	512.32,	507.45,	486.2,	495.63,	482.82,	481.25,	474.24,	468.33,	474.25,	456.7,	408.32,	423.2,	396.94,	319.7,	206.76,	203.68,	182.34,	192.99,	186.77,	196.31,	224.76,	263.22,	424.06,	446.2,	489.72,	481.25,	464.66,	480.58,	476.46,	486.45,	487.14,	488.06,	493.07,	470.58,	411.32,	422.95,	391.74,	305.64,	212.02,	206.49,	177.5,	181.45,	167.97,	178.56,	203.83,	230.61,	361.2,	413.04,	478.08,	485.54,	482.84,	513.64,	525.71,	554.89,	566.51,	573.8,	574.48,	541.02,	459.84,	460.63,	421.25,	322.11,	225.7,	213.46,	183.1,	180.01,	171.15,	175.83,	206.1,	231.07,	344.06,	408.04,	494.96,	521.12,	524.28,	550.87,	553.71,	571.54,	577.06,	568.25,	563.97,	538.74,	463.68,	465.14,	428.19,	328.87,	233.26,	218.3,	193.48,	194.38,	182.21,	187.79,	202.94,	213.87,	302.41,	384.5,	456.94,	481.13,	470.12,	481.2,	471.43,	451.38,	430.48,	397.09,	403.71,	377.72,	356.86,	366.56,	344.62,	280.58,	205.17,	200.83,	171.72,	177.41,	171.63,	182.41,	176.41,	188.3,	269.63,	247.19,	300.23,	297.66,	276.2,	288.81,	270.29,	276.94,	248.57,	259.05,	238.35,	244.86,	247.41,	256.83,	251.48,	245.81,	207.75,	200.45,	176.82,	191.25,	183.87,	193.18,	190.51,	201.49,	217.06,	207.6,	236.07,	215.38,	209.77,	231.78,	236.43,	241.61,	225.95,	240.12,	218.94,	204.48,	256.91,	257.01,	267.58,	242.01,	208.16,	187.67,	180.5,	173.47,	172.41,	164.79,	197.94,	232.8,	308.52,	309.94,	336.06,	323.86,	324.37,	331.26,	321.72,	324.79,	323.28,	321.31,	328.63,	319.76,	294.88,	300.29,	281.15,	254.33,	197.42,	196.98,	173.72,	176.09,	174.33,	187.59,	208.77,	248.76,	432.76,	446.51,	493.59,	491.67,	481.26,	506.4,	515.53,	523.56,	523.15,	523.29,	523.26,	494.24,	419.96,	411.86,	377.09,	300.57,	206.19,	199.55,	172.27,	176.23,	164.07,	170.78,	192.64,	222.21,	363.27,	409.55,	484.24,	510.13,	502.45,	520.81,	527.26,	545.78,	540.55,	541.38,	543.42,	513.1,	450.59,	459.78,	419.6,	327.68,	224.63,	211.47,	184.93,	188.97,	183.59,	189.61,	212.9,	238.25,	374.62,	437.83,	520.44,	504.66,	464.48,	467.91,	453.54,	457.82,	453.31,	451.35,	458.38,	441.88,	396.28,	403.65,	374.43,	294.76,	202.63,	195.62,	170.5,	175,	165.49,	173.6,	188.41,	202.72,	307.27,	384.32,	444.5,	457.78,	443.96,	455.16,	446.98,	444.7,	438.84,	408.47,	412.66,	389.37,	387.55,	401.64,	379.92,	296.79,	235.56,	210.26,	203.82,	183.71,	186.69,	166.63,	183.51,	170.56,	249.03,	215.52,	293.83,	282.06,	286.36,	287.76,	291.41,	279.69,	268.31,	253.74,	248.7,	233.96,	265.69,	243.62,	255.79,	234.8,	213.3,	193.54,	180.05,	178.76,	179.76,	179.1,	206.07,	247.29,	317.77,	316.76,	331.36,	315.7,	315.42,	323.32,	319.99,	323.58,	326.85,	326.92,	329.21,	320.66,	306.69,	304.23,	284.88,	255.79,	197.57,	197.51,	173.32,	175.07,	164.98,	178.41,	206.54,	241.91,	413.94,	440.04,	486.6,	484.75,	473.7,	492.96,	489.2,	496.66,	496.03,	495.04,	495.83,	468.87,	411.34,	405.97,	378.85,	299.76,	205.12,	199.58,	172.13,	175.96,	164.52,	172.37,	201.22,	230.91,	370.08,	412.17,	474.99,	492.98,	488.12,	506.55,	499.91,	506.88,	479.99,	460.88,	455.08,	436.98,	401.15,	402.76,	375.8,	302.69,	203.94,	196.46,	169.86,	173.44,	162.27,	168.7,	190.78,	225.06,	366.57,	415.96,	475.84,	479.51,	459.37,	465.1,	452.32,	453.34,	450.54,	452.9,	461.25,	445.44,	407.11,	410.25,	382.64,	308.94,	206.39,	198.24,	175.96 ],
  "unit":"kWh"
  },
  {
    "keyName": "demand",
    "dataValue": 582.83
  },
  {
    "keyName": "capacityObligation2241",
    "dataValue": 695.22
  }]
}

Case 4 : I have multiple bills with TOU usage

When you have more than one usage value, such as if you have a split bill, a TOU bill, or more than one bill, then the computation gets a little more involved. What we are suggesting here is just one way of doing things.

  1. For each bill you have, run a bill matching calculation. This will break the TOU usage inputs into specific “frames” (date and time intervals with pro-rated usage). If you use a detailLevel of CHARGE_TYPE and groupBy of ALL you will get results back that are suitable for the next step.
  2. For each “frame” above, perform the scale factor logic similar to Case #2, but just over the hours of the frame.
  3. Take the sum of all the factored frames, and use it to determine what needs to be used to factor all the remaining hours that you have not yet touched.

Contact us for more details!