Run a Savings Analysis

What is a Savings Analysis?

The Savings Analysis endpoint provides you with a calculator to project the potential future costs and savings of a change in energy use or rates. You can run a savings analysis to determine the potential savings from installing a solar system and optionally switching a rate plan (we are adding more projects from installing on site storage to buying an EV). The Savings Analysis calculator is somewhat similar to the Cost Calculator. The big difference is that instead of running just one services bill(s), this calculator runs at least two bills (called scenarios) and then reports back not only the costs for each scenario, but the differences (savings) between them.

Passing in your Property Inputs

Just like the Cost Calculator, the Savings Calculator accepts propertyInputs that you use to pass in basic inputs. Usage data is provided by passing in one or more profileIds or providerProfileIds, as is solar production. Tariffs can be set on the account or explicitly passed in via a masterTariffId. Other assumptions like expected future rate inflation can also be passed in this way. Each property in the list needs to be tagged with which scenario or scenarios that it applies to. For instance, if you wish to use the same profileId for both the “before” and “after” scenarios you would tag that property with "scenarios":"before,after". Think of a scenario as one service that your customer pays for (like electricity that they pay the utility for or solar that they pay a lease or PPA on). A scenario therefore needs a tariff (rate plan) too. You need at least two scenarios otherwise there wouldn’t be anything to compare to get savings.

Getting the results - Data Series

The response from calling the Savings Analysis endpoint comes back with an array of data points (SeriesMeasure) in the seriesData property. Examples of series are “First Year Monthly numbers before going solar”, “Annual Solar Numbers for the next 20 years”, “Savings numbers over the lifetime of the project”. More specifically, each series has a time granularity (e.g. monthly or annual), a time frame (for example the first year only or the entire project), and what scenarios it’s computed from (e.g. the “before, the “after”, the “solar” or the “series”). Each data series is identified by a unique ID (an integer). The series property on the response is an array of the series that were included in the response, giving you the meta-data about the series available. Then the seriesData property holds all the actual data points for all series. Each data point holds a cost, a quantity and a rate for a time interval of its corresponding data series.

Data Definition

Savings Analysis Request

The savings analysis endpoint is very flexible. From this single endpoint, you can configure your analysis in thousands of different ways. You can change your account’s tariff to a different one in the “after” scenario, you can change how quickly electricity rates go up each year, or you can use an entirely different solar power system than the one that you proposed. To enable all of that flexibility, you have a lot of different parameters to choose from. They are split into three groups: top level parameters that set the stage for the entire analysis, property inputs that define the parameters of each scenario, and rate inputs that let you specify entirely new rates to apply to your analysis. Before we get into the parameters, though, we need to talk about the idea of a scenario.

Scenarios - Building Blocks of Savings Analysis

At the most basic level, savings is how much the customer would have paid for energy without solar versus how much they actually did pay after solar was installed. To capture this, the Savings Analysis endpoint uses the notion of a scenario. There are three scenarios:

The before scenario represents how much the customer would pay to their utility if they never installed solar.
The solar scenario represents the cost of solar energy only.
The after scenario represents how much the customer will pay to their utility after solar is installed.

These three scenarios are defined independently of each other. In general, specifying one input (say, a rate escalator) for a particular scenario will not cause that same input to be applied to the other two. A typical savings analysis will use the customer’s pre-solar electricity consumption in both the before and after scenarios and will specify solar production in both the solar and after scenarios.

Top Level Parameters

The top level parameters set the stage for the entire analysis. At a minimum, you’ll need to provide a fromDateTime and an accountId or providerAccountId. Everything else is optional.

Name	Type	Description
accountId	String	The Genability-generated ID of the account for which you want to do the savings analysis.
providerAccountId	String	The alternative ID of the account for which you want to do the savings analysis.
fromDateTime	DateTime	Indicates the start of your analysis and should align with when you expect the system to interconnect (1-6 months in the future, typically). This setting affects the version of the account’s tariffs that are in effect during the first year of the analysis. The fromDateTime must be set to the first day of the month in order to return 12 monthly values for the first year series.
~~toDateTime~~	DateTime	DEPRECATED. To make the analysis span 25 years instead of the default of 20, use projectDuration, not `toDateTime`.
propertyInputs	Array of PropertyData	The parameters for the analysis. There are many different options available. We discuss them below.
rateInputs	Array of TariffRate	Custom tariffs for this analysis. You can use this to define lease rates, PPA rates, or special tax rates. Make sure to set the `scenario` property so that your rate is applied correctly.
populateCosts	Boolean	If set to `true`, your results will contain an even more detailed breakdown of the first year of results for this calculation.
tariffEffectiveOn	DateTime	(Optional) This field enables doing a calculation with a single, specified version of a given tariff. For example, if the user specifies that they want to use the 2016-01-01 version of PG&E’s E-1 tariff, any calculation, whether it’s for 2013, 2015, or 2016, would use the rate data from that version and only that version of the tariff.
autoBaseline	Boolean	(Optional, Default=true) Use this field to disable intelligent baselining in the usual case where you don’t want it.
useIntelligentBaselining	Boolean	This field works in conjunction with autoBaseline (above) and determines how to interpolate and extrapolate usage data when that is set to true. Read intelligent baselining for details.

Property Inputs

For customizing a savings analysis, the propertyInputs collection is where the action is at. With these inputs, you can customize your analysis any number of ways, including change tariffs, changing usage data, and changing your solar system. Each input can apply to more than one scenario, so make sure to set its scenario property.

Name	PropertyData Type	Scenarios	Description
profileId	String	before, after, solar	The ID of the usage profile that you want to use for this scenario. Can be set for `before`, `solar`, and `after`. If nothing is set for `before` or `after`, the default behavior is to use the account’s default profile. You can add more than one profile per scenario and combine them using the `operator` property on this input. The `operator` can be `+` or `-`, which indicates whether you want to add or subtract the indicated profile’s values from the other ones for that scenario.
providerProfileId	String	before, after, solar	The alternative ID for the profile that you want to add to the analysis.
baselineType	String	before, after, solar	If you want to use a typical baseline for the usage in a particular scenario, set a data value of `typicalElectricity` for this property. For solar, use `typicalSolarPv`. You can use this if you don’t have usage or solar data for the account and you just want to do a quick analysis.
masterTariffId	Integer	before, after	The tariff that will be used for this scenario. If this is not set, it defaults to whatever is currently set as the `masterTariffId` on the account.
rateInflation	Decimal	before, after, solar	The rate at which the cost of energy raises for every year of the analysis. Use a `dataValue` of `3.5` to use 3.5%, for example.
solarDegradation	Decimal	solar, after	The rate at which energy production from the solar system degrades. If your degradation rate is 0.5% per year, use a value of `0.5` here.
projectDuration	Integer	before, after, solar	You can make the project last however long you want. The default is 20 years.
solarPvLoadOffset	Integer	solar, after	If you don’t have an existing solar profile, you can use `solarPvLoadOffset` to specify a percentage of the customer’s existing load to offset with a PV system. The system will be a south facing and tilted at 30 degrees. By default (if you just set `baselineType` to `SOLAR_PV` for the `solar` scenario), this will be set to 80%. If you want to specify the solar production in kWh rather than as a percentage of the load, you can do so by entering annual solar production as the `dataValue` and “kWh” as the `unit`.
loadOffset	Integer	solar, after	Alternative name for `solarPvLoadOffset`.
loadSize	Integer	before, after	If you don’t have an existing usage profile, use this option in conjunction with a `baselineType` of `TYPICAL` to size your customer’s annual usage. It will use a typical profile from our database and scale it up or down to the annual value that you specify.

Rate Inputs

Rate inputs are simply a collection of TariffRate objects with one new property: scenario. Use that parameter to specify which scenario you want this custom rate to apply to. This field can be used for things like setting the first-year PPA or lease rate and setting a custom tax rate.

Savings Analysis Response

The data that you get back from the savings analysis represents a complete description of the results of your calculation.

Summary Fields

The Savings Analysis summary contains a number of fields that describe the basic results for a Savings Analysis. These fields include things like preTotalCost, postTotalKWh, and netAvoidedCost.

Pre-Solar Summary Fields

These fields summarize values for how things would have been in the first year without solar.

Name	Description
preTotalCost	The first year, pre-solar cost of energy. It is the highest of the `preTotalNonMinCost`, `preTotalMinCost` and `preTotalNonBypassableCost`.
preTotalKWh	The first year, pre-solar amount of energy used.
preTotalKWhCost	The first year, pre-solar cost of kWh only. Does not include minimum costs.
preTotalKWhRate	The first year, pre-solar rate for kWh only. Does not include minimum costs.
preTotalMinCost	The first year minimum bill for the customer.
preTotalNonBypassableCost	The first year non-passable costs for the customer.
preTotalNonMinCost	The first year bill for the customer. Will almost always be the same as preTotalCost.
preTotalRate	Pre-solar blended kWh rate. Equal to (`preTotalCost`/`preTotalkWh`)

Post-Solar Summary Fields

These fields represent the first year after solar. Not all of these values will show up in every situation. For example, netAvoidedRate won’t show up if you haven’t included a solar profile, as there’s no “avoided” rate to calculate. For a standard solar analysis, though, these values will always be available.

Name	Description
postTotalCost	The first year, post-solar cost of energy from the utility only (i.e. not including the cost of solar). It is the highest of the `postTotalNonMinCost`, `postTotalMinCost` and `postTotalNonBypassableCost`.
postTotalKWh	The amount of energy still consumed from the utility in the first year after solar.
postTotalKWhCost	The first year post-solar cost for kWh only. Does not include minimum costs.
postTotalKWhRate	The first-year post-solar rate for energy from the utility only. Equal to (`postTotalKWhCost`/`postTotalKWh`).
postTotalMinCost	The minimum bill for the first year.
postTotalNonBypassableCost	The minimum bill for the first year, calculated using NonBypassable Charges (NBCs). Non-Bypassable charges cannot be offset by other NEM credits, creating a second minimum charge for solar customers.
postTotalNonMinCost	The customer’s new utility bill, without accounting for any minimum charges.
postTotalRate	The post-solar blended kWh rate for energy still purchased from the utility. Equal to (`postTotalCost`/`postTotalKWh`).

“Net” Summary Fields

Net fields represent the difference between the pre- and post- solar values.

Name	Description
netAvoidedCost	The cost of energy that is no longer being purchased from the utility in the first year post-solar. Equal to (`preTotalCost` - `postTotalCost`).
netAvoidedCostPctOffset	The percentage of first year cost from the utility offset by solar. Equal to (`netAvoidedCost`/`preTotalCost`).
netAvoidedKWh	The amount of kWh generated by the solar power system. Equal to (`preTotalkWh` - `postTotalkWh`).
netAvoidedKWhPctOffset	The percentage of first year kWh offset by solar. Equal to (`netAvoidedkWh`/`preTotalkWh`).
netAvoidedRate	The average value of an avoided kWh. Equal to (`netAvoidedCost`/`netAvoidedKWh`)

Lifetime Summary Fields

Lifetime values represent totals over the life of the project.

Name	Description
lifetimeSolarCost	The cost of solar energy over the life of the project.
lifeTimeUtilityAvoidedRate	ACP over the life of the project.
lifetimeWithoutCost	The life time cost of energy without a solar system.
lifetimeAvoidedCost	Customer savings over the life of the project. Equal to (`lifetimeWithoutCost` - [`lifetimeSolarCost` + `lifeTimeUtilityAfterCost`]).
lifeTimeUtilityAfterCost	The amount still paid to the utility after solar over the life of the project.

Account Analysis

The Account Savings Analysis call returns an AccountAnalysis object when you run a calculation. It has the following data structure.

Name	Type	Description
designId	String	This is `null` for Account Analysis (so ignore it). It is used in Project Analysis (different endpoint).
dataStatus	Integer	Represents the status of the underlying data (profiles) that the analysis ran on. 2 means all the underlying data is up to date. 1 means it’s still processing, and you should run the analysis again once the profile is done (this is very unusual).
scenarios	Array of Scenario	Each scenario in the analysis. For a solar PV analysis there will be a “before” for without solar electric bill, “after” for the with solar electric bill, “solar” for the solar system, and “savings” for net savings with solar (before - after + solar). See below for the data structure of the `Scenario` object.
series	Array of Series	A list of `Series` objects, each one describing the data points (`SeriesMeasure`) it contains. The `Series` object is documented in further detail below.
seriesData	Array list of Series Measures	This list holds the actual data points, each of type `SeriesMeasure` (described below). Each ties to a particular series (above) using a unique integer value. Each `SeriesMeasure` holds a rate, quantity, and cost.
seriesCosts	Map of Integer to Calculated Cost	If `populateCosts` is set to `true`, this field is populated with `CalculatedCost` objects corresponding to each series. They are indexed by `seriesId`, which you can find from the `series` collection.

Scenario

A Savings Analysis has at least two Scenario objects in its response. For a solar PV analysis there are 4. You only need to worry about sending this in a request to the Savings Calculator when running a generic analysis type. Scenario has the following data structure.

Name	Type	Description
id	String	This is not used for Account Analysis (it’s used for Project Analysis). Will be null. Ignore it.
name	String	The unique name (key) of this scenario. Solar PV has “before”, “after”, “solar” and “savings”.
serviceType	String of ServiceType	The type of service for this scenario. `"ELECTRICITY"` or `"SOLAR_PV"`
inputs	List of PropertyData	The important inputs that were used in this scenario’s calculation. This defines the usage data profiles, the rate plan and plan arguments and other parameters for the calc. See examples below.
rates	List of TariffRate	Used to pass the site’s specific contracted electricity rates (only needed if they are in a deregulated market), their tax rates (if you want us to calculate post tax numbers), and possibly their solar offers PPA or lease rate. See examples below.

Series

The Series object denotes the scenario, time frame, granularity of each data series in the results. It has the following data structure.

Name	Type	Description
seriesId	Integer	All the series measures (below) for this series have this identifier. It is a unique integer within the response. You should not assume the integer will be the same for the same series between responses. Instead look at the series’ `period`, `duration`, and `scenario` fields to find the `seriesId` you need.
fromDateTime	DateTime	The start date of the series.
toDateTime	DateTime	The end date of the series.
scenario	String	Mathematical formula of scenarios that produced this series.
displayLabel	String	The display label for this series.
seriesPeriod	String	The series period/term. Possible values are: `"YEAR"`, `"MONTH"`, `"DAY"`, and `"HOUR"`.
seriesDuration	Integer	The duration of the series with respect to the `seriesPeriod`. e.g. if this is 20 and `seriesPeriod` is `"YEAR"`, this series’ data covers 20 years.
designId	String	Not populated for Account Analysis.
key	String	For future use.
rate	Decimal	Average rate over the entire duration of this series.
qty	Decimal	Total quantity over the entire duration of this series.
cost	Decimal	Total cost over the entire duration of this series.

There are several common series that you’ll get back in most Savings Analysis calls:

Before Solar Utility
After Solar Utility
Solar
Total Savings

Each series will be returned with three granularities: monthly for the first year, annual for the life of the project, and the total over the life of the project. This means that for a standard solar savings analysis, you will get back twelve Series items.

SeriesMeasure

The SeriesMeasure object holds one data point, such as before solar electricity in the first year. It has the following data structure.

Name	Type	Description
seriesId	Integer	The identifier of the series that this data point belongs to (See Series above).
fromDateTime	DateTime	Start date and time of this data point.
toDateTime	DateTime	End date and time of this data point.
rate	Decimal	The average rate of charge for this timeframe, denominated in the major currency applicable. For instance, in USD this would be 0.12 for 12 cents.
qty	Decimal	Quantity for this timeframe (usage or production, etc. typically in kWh).
cost	Decimal	Cost (or savings) of this timeframe

Put it all together

Here’s an example of a response back, in JSON, with all the parts above

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
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
{
   "status": "success",
   "count": 1,
   "type": "AccountAnalysis",
   "results": [
      {
         "designId": null,
         "dataStatus": 2,
         "summary": {
            "preTotalCost": 1552.74,
            "preTotalKWh": 7079.3096,
            "netAvoidedCost": 1043.46,
            "postTotalCost": 509.28,
            "lifetimeSolarCost": 39564.18,
            "lifeTimeUtilityAvoidedRate": 0.411,
            "lifetimeWithoutCost": 43910.76,
            "postTotalMinCost": 53.9616,
            "postTotalNonBypassableCost": 0,
            "netAvoidedCostPctOffset": 0.672,
            "netAvoidedKWh": 3792.5,
            "netAvoidedKWhPctOffset": 0.5357,
            "postTotalKWh": 3286.8096,
            "preTotalRate": 0.21933495,
            "postTotalNonMinCost": 509.27982,
            "lifetimeAvoidedCost": -14342.92,
            "postTotalRate": 0.15494661,
            "netAvoidedRate": 0.275138,
            "lifeTimeUtilityAfterCost": 16816.861,
            "preTotalNonMinCost": 1552.7365,
            "preTotalMinCost": 53.9616
            "preTotalNonBypassableCost": 0,
         },
         "scenarios": [
            {
               "id": null,
               "name": "before",
               "serviceType": "ELECTRICITY",
               "inputs": [
                  {
                     "keyName": "lseId",
                     "displayName": "Pacific Gas & Electric Co",
                     "dataType": "STRING",
                     "fromDateTime": "2013-06-01T00:00:00+00:00",
                     "toDateTime": "2014-06-01T00:00:00+00:00",
                     "dataValue": "734",
                     "scenarios": "before,after"
                  },
                  {
                     "keyName": "masterTariffId",
                     "displayName": "Residential",
                     "dataType": "INTEGER",
                     "fromDateTime": "2013-06-01T00:00:00+00:00",
                     "toDateTime": "2014-06-01T00:00:00+00:00",
                     "dataValue": "522",
                     "scenarios": "before,after"
                  },
                  {
                     "keyName": "profileId",
                     "displayName": "2012 CA Electricity Residential Profile",
                     "dataType": "STRING",
                     "fromDateTime": "2013-06-01T00:00:00+00:00",
                     "toDateTime": "2014-06-01T00:00:00+00:00",
                     "dataValue": "5350801df203671e925d49c8",
                     "scenarios": "before,after"
                  },
                  {
                     "keyName": "territoryId",
                     "displayName": "Territory",
                     "description": "Territory where tariff is operational",
                     "dataType": "INTEGER",
                     "fromDateTime": "2013-06-01T00:00:00+00:00",
                     "toDateTime": "2014-06-01T00:00:00+00:00",
                     "dataValue": "3538",
                     "scenarios": "before,after"
                  },
                  {
                     "keyName": "rateInflation",
                     "dataType": "STRING",
                     "fromDateTime": "2013-06-01T00:00:00+00:00",
                     "toDateTime": "2014-06-01T00:00:00+00:00",
                     "dataValue": "3.5",
                     "scenarios": "before,after"
                  },
                  {
                     "keyName": "tariffCode",
                     "displayName": "E-1",
                     "dataType": "STRING",
                     "fromDateTime": "2013-06-01T00:00:00+00:00",
                     "toDateTime": "2014-06-01T00:00:00+00:00",
                     "dataValue": "E-1",
                     "scenarios": "before,after"
                  }
               ]
            },

			/* inputs for other Scenarios */

         "series": [
            {
               "seriesId": 1,
               "fromDateTime": "2013-06-01T00:00:00-07:00",
               "toDateTime": "2014-06-01T00:00:00-07:00",
               "scenario": "before",
               "displayLabel": "Before Solar Utility (Mo/Year 1)",
               "seriesPeriod": "MONTH",
               "seriesDuration": 12,
               "designId": null,
               "key": null,
               "rate": 0.21933495,
               "qty": 7079.3096,
               "cost": 1552.74
            },

			/* metadata about the other series */

         ],
         "seriesData": [
            {
               "seriesId": 1,
               "fromDateTime": "2013-06-01T00:00:00-07:00",
               "toDateTime": "2013-07-01T00:00:00-07:00",
               "rate": 0.21295582,
               "qty": 499.97726,
               "cost": 106.47307
            },

			/* more series data */
         ]
      }
   ]
}

Calculate Savings Analysis for Solar PV

The Solar PV analysis type allows you to calculate the savings from your customer going solar. The standard scenarios ran for an analysis of this type are 1) “before” which is what the electricity bill would be in the future without solar (sometimes called the “do nothing” scenario), 2) “solar” which denotes what the solar system being considered would produce and cost, 3) “after” which is the electricity costs and usage given the system is installed (so electricity usage is reduced by what the system produces), and 4) “savings” which are the net savings (“before” minus “after” plus “solar”).

Resource URL

POST /rest/v1/accounts/analysis

Request Parameters

Along with the required security parameters, this endpoint requires you to post a particular JSON structure in the body of the request. Here’s an example:

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
{
  "providerAccountId" : "api-eg-01",
  "fromDateTime" : "2013-06-01",
  "propertyInputs" : [ {
    "scenarios" : "before",
    "keyName" : "masterTariffId",
    "dataValue" : "522"
  }, {
    "scenarios" : "after",
    "keyName" : "masterTariffId",
    "dataValue" : "522"
  }, {
    "scenarios" : "before,after",
    "keyName" : "rateInflation",
    "dataValue" : "3.5"
  }, {
    "scenarios" : "solar",
    "keyName" : "rateInflation",
    "dataValue" : "1.9"
  }, {
    "scenarios" : "after,solar",
    "keyName" : "solarDegradation",
    "dataValue" : "1.5"
  }, {
    "scenarios" : "after, solar",
    "keyName" : "providerProfileId",
    "dataValue" : "PVWATTS_RESIDENTIAL_CA_2012"
  } ],
  "rateInputs" : [ {
    "scenarios" : "solar",
    "chargeType" : "FIXED_PRICE",
    "rateBands" : [ {
      "rateAmount" : 137.05
    } ]
  } ]
}

You can read more about all of the available parameters and options up above. When calculating solar savings for your customer, you need to pass in these scenarios:

the do nothing or “before” electricity Scenario. That is, what your customer will pay for electricity without going solar.
the “solar” Scenario, or how much the system produces and what that costs. In other words, what the Account will pay for solar (e.g. the PPA or lease)
the “after” installing solar electricity Scenario. In other words your customer’s electricity bill given solar. This should be lower than the “before” scenario because less power is bought from the grid.

Example : Solar PV Analysis for Lease

The following is a common scenario. The providerAccountId denotes the account to run this against. By passing this in, the current tariff and default electricity profile are used without having to explicitly state them. The tariff is used for both before and after scenarios. The other parameters are passed in via property and rate inputs:

PropertyInput "before" for rateInflation denotes the expected rate at which electricity will increase in the future. 3.5 is 3.5%
PropertyInput solarDegradation for "after,solar" denotes how much less the solar system will production each year. 0.5 is 0.5%.
PropertyInput providerProfileId for "after,solar" denotes the solar model profile (in this case a PV Watts one). You can use profileId too.
In this case, we are passing in a Solar Lease (rate input of type "FIXED_PRICE"). here it’s $295. Also, the PropertyInput rateInflation for "after,solar" denotes that this lease will escalate annually at 1.9%.

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
{
  "providerAccountId" : "api-example-01",
  "fromDateTime" : "2013-02-01",
  "propertyInputs" : [ {
    "scenarios" : "before",
    "keyName" : "rateInflation",
    "dataValue" : "3.5"
  }, {
    "scenarios" : "solar",
    "keyName" : "rateInflation",
    "dataValue" : "1.9"
  }, {
    "scenarios" : "after,solar",
    "keyName" : "solarDegradation",
    "dataValue" : "0.5"
  }, {
    "scenarios" : "after,solar",
    "keyName" : "providerProfileId",
    "dataValue" : "solar-1"
  } ],
  "rateInputs" : [ {
    "scenarios" : "solar",
    "chargeType" : "FIXED_PRICE",
    "rateBands" : [ {
      "rateAmount" : 295.00
    } ]
  } ]
}

Example : Multi-Array Solar PV Analysis for PPA with Rate Switch

The following is similar to the example above, but this has a 15.5¢ solar PPA rather than a lease ("CONSUMPTION_BASED"). It also switches tariffs “after” solar to a more solar friendly tariff. Finally, we pass in 2 solar model profiles (e.g. one for south roof, one for west).

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
{
  "providerAccountId" : "api-example-01",
  "fromDateTime" : "2013-02-01",
  "propertyInputs" : [ {
    "scenarios" : "after",
    "keyName" : "masterTariffId",
    "dataValue" : "3250619"
  }, {
    "scenarios" : "before",
    "keyName" : "rateInflation",
    "dataValue" : "3.5"
  }, {
    "scenarios" : "solar",
    "keyName" : "rateInflation",
    "dataValue" : "1.9"
  }, {
    "scenarios" : "after,solar",
    "keyName" : "solarDegradation",
    "dataValue" : "0.5"
  }, {
    "scenarios" : "after,solar",
    "keyName" : "providerProfileId",
    "dataValue" : "solar-1"
   }, {
    "scenarios" : "after,solar",
    "keyName" : "providerProfileId",
    "dataValue" : "solar-2"
  } ],
  "rateInputs" : [ {
    "scenarios" : "solar",
    "chargeType" : "CONSUMPTION_BASED",
    "rateBands" : [ {
      "rateAmount" : 0.155
    } ]
  } ]
}

Example : Solar PV Analysis without Intelligent Baselining

Our IB feature is used in the two previous examples above. However, if you would like to run a Savings Analysis without Intelligent Baselining, you will need usage data to cover the first year of your analysis. If you are running a Savings Analysis in the future (e.g. January 1, 2019), you will need to load usage data for the future 12 months (e.g. January 1, 2019 to January 1, 2020). If you are running a Savings Analysis in the past (e.g. January 1, 2015), you will need the past 12 months of usage data (e.g. January 1, 2015 to January 1, 2016).

If you load monthly readings for your electricity profile, each hour of the month will be prorated as a flat amount. This is fine for a flat charge rate plan but does not work well for time of use tariffs or rate plans that have different rates for import and export. In a case like that, we recommend doing your own Intelligent Baselining and provide us hourly data for the year.

If you have historical usage data but would like to use the current version of a tariff, you will use the tariffEffectiveOn property. Here is an example where the fromDateTime is in the past (e.g. 2015-01-01 since usage data is for January 1, 2015 to January 1, 2016) and the tariffEffectiveOn date is set to a more recent date (e.g. 2017-11-01) so the current version of the tariff will be used to calculate the whole year’s costs. This makes for a more accurate projection 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
{
  "providerAccountId" : "api-example-01",
  "fromDateTime" : "2015-01-01",
  "autoBaseline" : false,
  "useIntelligentBaselining": false,
  "tariffEffectiveOn": "2017-11-01",
  "propertyInputs" : [ {
    "scenarios" : "before",
    "keyName" : "masterTariffId",
    "dataValue" : "522"
  }, {
    "scenarios" : "before",
    "keyName" : "rateInflation",
    "dataValue" : "3.5"
  }, {
    "scenarios" : "solar",
    "keyName" : "rateInflation",
    "dataValue" : "1.9"
  }, {
    "scenarios" : "after,solar",
    "keyName" : "solarDegradation",
    "dataValue" : "0.5"
  }, {
    "scenarios" : "after,solar",
    "keyName" : "providerProfileId",
    "dataValue" : "solar-1"
   }],
  "rateInputs" : [ {
    "scenarios" : "solar",
    "chargeType" : "CONSUMPTION_BASED",
    "rateBands" : [ {
      "rateAmount" : 0.155
    } ]
  } ]
}