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 service 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 profileId
s or providerProfileId
s, 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 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", and "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 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 Arcadia-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. |
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 in any number of ways, including changing 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 rises 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 | An 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 lifetime 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, and 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, is 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
{
"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:
{
"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"
forrateInflation
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 useprofileId
too.- In this case, we are passing in a Solar Lease (rate input of type
"FIXED_PRICE"
). Here it's $295. Also, thePropertyInput
rateInflation
for"after,solar"
denotes that this lease will escalate annually at 1.9%.
{
"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).
{
"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 providing us with 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.
{
"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
} ]
} ]
}