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
    } ]
  } ]
}