Earth Notes: EGC: HaaS Lite WP1 D13 Technical Research

Summary and introduction

Deliverable 13, part of Work Package 1.

Summarise existing retail real-time billing-system integration schemes especially those that involve some energy-savings element; and examine existing legal, operational and technical environments.

We looked at the entities and data-flows likely needed to support a number of HaaS Lite (or similar) scheme variations.

We also took some account of areas where the regulatory framework may alter the set of allowed interactions and constraints. Eg district heat networks vs gas/electricity supply.

We looked at related schemes already in the (consumer) market. We looked for gaps where products such as HaaS could be but are not, from a technical point of view.

Partial Abstract from HaaS WP1 D12 Technical Architecture Report

The current heating market offers little incentive for fuel providers to reduce carbon emissions. Additionally, end-users face significant barriers to improving their heating efficiency.

By switching to selling heating instead of fuel, fuel usage becomes a cost and utilities are encouraged to provide the heating efficiency technologies that the users cannot afford. The model has been proven to work in other markets such as lighting, with Philips' flagship "Pay-per-Lux" scheme. OpenTRV hopes to leverage the improved and in-home data available from the smart meter rollout and the IoT boom to provide a way of accurately calculating and sharing savings between the utility and the end-user. [PayPerLux]

Schemes for Further Investigation

Our current intention is to investigate up to three variants from the technical, customer and financial point of view, though this may change as the project progresses:

• pre-HaaS shared-savings
• two HaaS with different regulatory positions

Some of the Data and Flows Required

Given that all of our approaches generate energy savings, it will at least be necessary to measure these savings to manage them. It will also be necessary to give appropriate feedback to the participants including the end-user and the fuel/heat and finance providers, in real time (with granularity depending on the exact scheme).

Given OpenTRV's relatively simple Environmental Technical Verification protocol [OTETV] that still implies the need for at least the following data, in real time:

• local climate/weather data
• heating fuel consumption
• an indication of when devices are in control or normal mode
• possibly the past history of heating fuel usage against weather

Also, depending on the scheme, there may be real-time interaction with the user such as to adjust settings and receive feedback and predictions.

Other scheme-dependent data and flows may include:

• fuel/heating provider metering/telemetry
• fuel/heating provider billing interactions
• retailer billing flows
• shared-savings calculations and flows with end user
• shared-savings calculations and flows with fuel/heating provider
• shared-savings calculations and flows with retailer
• shared-savings calculations and flows with equipment providers
• aggregator data flows
• regulatory data flows
• other authority data flows

Regulatory Considerations

There are very different regulatory environments for (say) working as an agent of or alongside a licensed gas or electricity retailer, from being such a retailer, and from being a district heat provider.

These differences need not stand in the way of feasibility studies. But schemes that have the potential to go live quickly without special regulatory support such as waivers, or even changes in the law, are preferred.

End-user Considerations

It is abundantly clear from the Customer Research [EGCWP1D13] that the nature of interactions with users, for example to have savings persist, has to be finely tuned.

Even showing savings in numerically smaller units may reduce effectiveness [TEDCtech].

Public Findings

Some of our initial findings are not public at this stage.