Open Domestic Energy Controller

To help combat climate change and lower energy bills, more and more households are installing domestic renewable energy systems and using electricity as their primary fuel. But they soon discover that the lack of interoperability between equipment means it doesn’t work as effectively as it should.

Yet working efficiently as a single integrated system is just a software upgrade away.

This document proposes a policy-driven Open Domestic Energy Controller (ODEC) to manage domestic energy generation and usage. It would enable equipment from different manufacturers to work together seamlessly, allow all stakeholders (householders, national grid, suppliers, …) to optimise usage together, and provide open privacy-preserving infrastructure on which anyone can build innovative products, services and apps.

Table of contents

Motivation

An early adopter of domestic green energy technology will use equipment from various manufacturers in their house, for example:

For maximum efficiency, each piece of domestic green energy equipment needs to take into account every other piece of equipment installed in the home. Unfortunately, equipment from different manufacturers will not talk to each other, so cannot act as a single effective system.

Domestic household

This means end users don’t get the full benefits of their investment, and rely on the grid more than necessary. Moreover, devices are unable to work effectively if they can’t communicate between themselves. For example, the combination of a DC-coupled battery and EV charger which tries to only use excess power from the solar panels does not work, resulting in workarounds which limit the capability of the technology and work inefficiently.

National Grid

The end user of all this technology is not the only stakeholder. The Grid would prefer that the maximum power ever consumed by a house was as predictable and as low as possible to reduce the peak capacity which needs to be available. If an induction hob, car charger, and air source heat pump were used at the same time, a house could consume almost 20kW, but if the individual pieces of equipment worked together to avoid drawing power at the same time, the load could be halved without inconveniencing the end user or affecting their energy bills. If stakeholders other than the end user had a way of requesting certain behaviours, costs and environmental impact could be reduced further.

Manufacturers

Manufacturers want to sell equipment which works well and has minimal support costs. While some manufacturers produce ranges of products that are well integrated, no manufacturer produces the full range of domestic green energy equipment now available, and all manufacturers would want to sell equipment to end users who already have equipment from their competitors.

Environmental impact

While the greatest environmental benefits will result from more efficient operation of equipment and making green domestic systems cheaper and more compelling, improved interoperability would reduce the financial and environmental impact of manufacturing unnecessary equipment.

Both the Battery and the EV charger use a “CT clamp” with a wireless interface to monitor the electricity being exported to the grid. Yet the smart meter knows the exact value, and broadcasts it over a wireless network. If devices could use this information, the clamps would not have to be manufactured, let alone be installed.

Outline solution

A pure-software Open Domestic Energy Controller (ODEC) delivered as:

In the vast majority of cases, the end user would not have to buy anything to use the ODEC system.

Policy based control

The usual approach of describing how a system should be controlled is to write write explicit instructions about how specific pieces of equipment should operate together, usually through a configuration interface. This has limitations: the capabilities are restricted to what was designed by the manufacturer, only a few models of equipment can be controlled, there’s no way for other stakeholders to request better use of energy, and it’s a closed system which locks out people trying to innovate and improve how we use energy.

Instead, the proposed ODEC runs many small bits of software, and combines their behaviours into efficient control of the equipment. Each of these bits of software describes one Policy: How one aspect of the system should behave. Some example policies are listed in the appendix.

An ODEC is configured with a prioritised list of policies, which can come from different stakeholders (end users, installer, equipment manufacturer, energy supplier, national grid…). These run in order of priority, and set properties like “desired power level” on equipment.

So the Policies can control any equipment of a particular kind, simple Adaptors are written by the manufacturers, or third parties where legacy interfaces are available, which read the state and adjust the behaviour of each device.

Each device would be presented as a generic interface for a kind of equipment. An interface for a solar panel inverter may provide statistics on the power available. A smart meter measures the import/export power. A house or EV battery may provide charge level, maximum discharge power output, desired charging power, and desired discharge power. Given all this information, a Policy can then divide solar power between the batteries to use all the solar power.

Works with existing equipment

Ideally, a software upgrade to the Smart meter’s In Home Display would run the core ODEC software, and Adaptors for all the equipment would be available in a central repository to control all the equipment in the home.

This would enable the full benefits for all equipment, old and new, and avoid the financial and environmental impact of manufacturing new equipment.

There would be a number of levels of support. These vary from availability of a description of how to interface with a device, to being able to run the ODEC software.

User experience

A user will need at least one device which supports running the ODEC software. This could be the In Home Display for the smart meter, or equipment which has enough spare processing power.

To set up a system, or add more equipment to an existing system, where all have been updated with support for the ODEC system, a user:

Where some equipment pre-dates the ODEC, but an Adaptor is provided by the manufacturer or a third party, it will need to be added manually. Some devices may be able to be discovered and configured automatically by scanning the network.

Once all the devices are joined, default policies will provide efficient behaviour. Just joining all the equipment as a controlled system is sufficient to operate efficiently.

Using a web interface or an app, the installer or user can add additional policies as required, and adjust the configuration to meet the user’s preferences.

Implementation

The ODEC downloads and runs small bits of software from the internet. These provide instructions for Adaptors, which connect equipment to the ODEC system, and Policies, which describe how the overall system should work.

For security, all the downloaded software is run inside a “sandboxed runtime” which constrains the software so that it can only perform an allowed list of operations. Being able to run software from many different sources in a way that is safe and won’t negatively affect other software enables the controller to be open, as it removes the concern that other parties can run software that will negatively affect the system or cause equipment to operate unsafely.

All the downloaded software is digitally signed for authenticity, so the end user can be assured that it comes from the right organisation and can be updated securely. If an end-user wants to run their own software, they can upload it through a web interface without signing it, as access to the web interface proves their ownership.

All equipment uses an Adaptor to translate the way it communicates to something the ODEC understands. The ODEC implements the well established standard protocols for talking to equipment, such as Modbus and web REST APIs, and downloaded Adaptors use these to interface with specific devices. In addition, for newer devices which have the ODEC software embedded, a Generic Adaptor can discover the equipment and communicate with it without the need for a device specific Adaptor to be written.

Inside the ODEC, the system is represented as a collection of “Objects”, each of which represents something in the overall system. These are set up by the equipment and Adaptors. Then, every few seconds:

This continuously adjusts the overall system to work optimally, following the Policies set by the various stakeholders.

Design criteria

Behaviour specified through multiple policies
Multiple stakeholders can request behaviour by publishing Policies which are independent of the actual equipment installed, enabling an open ecosystem of vendors, power grids, supplies, end users, experimenters, and startups.
End user is in control
The ODEC does not stop the end user from using their equipment as they wish.
Runs on the local network
Everything is controlled locally, without the need to use cloud servers. No vendor has sufficiently reliable cloud servers, and it would be too expensive for them to provide the very frequent data updates needed.
Distributed
ODEC logic can run on any device in the network, so a device can have the hardware it needs, and participate in the ODEC system. Higher powered devices can run the policies and direct other devices.
Safe and fault tolerant
Each device treats instructions from the ODEC as a desired state, and uses its own logic to control the equipment accordingly and use sensible defaults when the ODEC is not online. This approach makes sure that ODEC errors can’t make the equipment do something unsafe, or operate in a manner which is not allowed by the regulators. If part of the system breaks and is unavailable, the policies are generic so will adapt to the equipment now available.
Secure
The ODEC is secure against intrusion from the local network, the internet, devices being controlled, and authors of policies and adaptors.
Easy to extend
For someone to implement a new behaviour, they do not need to know any of the specifics of what is being controlled, or re-implement behaviours already implemented by someone else.
Privacy by default
The ODEC doesn’t need to send data to vendors to operate. Users need to opt in to data collection, enforced by the ODEC runtime.
Sandboxed
All software is run in an environment which is tightly controlled, so each stakeholder is confident that they cannot be negatively affected by someone else’s code. This is a key enabler of an open ecosystem, by avoiding the need for gatekeepers.
Can’t be bricked
There is no way for a vendor to decide they no longer want to support a product and stop it from working.

Deliverables

For this this to succeed, it must be easier and cheaper for manufacturers to participate in the open ecosystem than to develop their own solution, yet still allow them to differentiate their products. Therefore, any software must be open source under a liberal license, and specifications licensed for no cost.

Specifications

The specification documents will describe how to interface a device to the ODEC, how to implement a ODEC controller, and how to write and publish policies and adaptors.

Protocols
Describes how the devices and controllers communicate across the network, using new protocols and older established protocols.
Language and bytecode
How the Adaptor and Policies are written, and the device independent bytecode which is run by the ODEC. Ideally this should use existing languages, such as Java or WASM.
ODEC programming model
How the ODEC represents the devices in the system so that the downloadable software can read and control the devices.
Services
How the Adaptors and Policies are published and updated on internet servers.

Test suite

Alongside the specifications, a test suite allows any manufacturer to verify that their products will work with the ODECs. A pass from the test suite will show that it will work with any other device in the ecosystem.

Reference implementations

While a manufacturer could implement the protocols and run the test suite, this is more work than is needed. It also makes it harder to ensure that all implementations are compatible, and risks manufacturers only supporting the absolute minimal features.

Therefore, reference implementations should be provided for devices and controllers. These should be implementations that are easy to integrate, and sufficiently lightweight that they will fit in the storage and processing capacity of existing equipment.

Funding model

There is unlikely to be a business in creating and maintaining the open controller protocols and reference implementations, as it is infrastructure work which enables collaboration across the industry. Any attempt to create a business which “owns” the ODEC is likely to deter adoption.

Funding is likely to come from:

Taking an open source approach to specifications and implementations will allow manufacturers to contribute changes they need, although the project maintainers should ensure quality and the right architectural direction.

Incorporating the project as a non-profit or charity may be helpful with engagement and when seeking funding.

Next steps

Develop and run a prototype to demonstrate policy based control
This prototype will be specific to a small set of equipment, and not be extensible. However, it will have the architecture of the proposed ODEC, and behaviours will be described using policies. By running it in a small number of homes, monitoring the behaviour carefully, the concept can be proven.
Draft specifications and prototype reference implementation
Building on the lessons learned from the prototype, draft specifications can be written and a reference implementation prototyped. The goal is to demonstrate practicality of interfacing with existing equipment, and implementing ODECs with a software upgrade to existing devices.
Engagement with manufacturers & stakeholders
When there is something concrete to demonstrate, talk to manufacturers and other stakeholders to establish the level of interest, and their requirements for adoption and functionality. Adjust specifications accordingly.
Final specifications and production version
After feedback from stakeholders, finalise the first version of the specification and deliver production quality reference implementations.

The main challenge in the first step is obtaining information about how to integrate with devices which have no public documentation, where manufacturers may be reluctant to provide documentation. Obtaining a grant and support from a well-known institution may help in convincing them.

Appendices

Levels of support

The ODEC will work with equipment of any age and capability, as long as it has a network interface. Some manufacturers offer “dongles” to add network interfaces, and these do not need to specifically support the new system.

Four levels of support for the new system are defined, for wide compatibility, avoidance of modifications to existing equipment, and to support devices with limited processing power.

Level 0: Manual setup without equipment upgrades
Adaptor software is published which uses the existing capabilities of the equipment to interface to the ODEC. The equipment would not need modifying or a firmware update.
Level 1: Automatic configuration
The device implements enough of the new protocols so that it can automatically be added to a ODEC with the correct Adaptor and configuration.
Level 2: Controller capable
These devices are capable of running the ODEC controller software which executes the Adaptors and Policies. One level 2 or above device is elected as the controller.
A Configuration API is provided by the ODEC, and the configuration is replicated to all level 2 devices.
Level 3: Computing power
More demanding applications may require more processing power than can be provided by an embedded processor in equipment. A larger device can be added to the system to provide more computing power and storage.
Configuration UI
The configuration UI is a separate component, and not integrated into the ODEC. A web interface, or an app on a mobile device, uses the configuration API to set up the system.

Example policies

Batteries and EVs

Any spare electricity from the PV should charge the house battery, then the EV.
This simple sounding policy solves the problem with DC coupled house batteries and EV solar chargers. Because the ODEC has visibility into the power available and battery capacity, it can prioritise the batteries accordingly, and ensure that the charging levels never import power from the grid, or discharge the house battery to charge the EV.
A more sophisticated version would always charge the EV when the power available was over 1.4kW, the minimum needed to charge an EV, as long as the house battery would be full by the end of the day.
Charge the house battery so it has the same amount used overnight as yesterday, then let other equipment take priority.
Since it’s reasonably likely that the overnight power will be the same (unless the weather is dramatically different which affects the heat pump), there’s not a huge amount of point in charging the battery to full if something else in the house could use the power.
Make sure the EV is at least 50% charged at all times, and 75% by the weekend.
While some cars and chargers can cooperate to achieve this, implementing this as a policy would make this functionality available to all EVs.
Don’t charge the EV with energy from the house battery in the summer.
If there is plenty of solar power (generation over last few days is high) then it’s worth avoiding wear on the house battery by an unnecessary discharge cycle.
Use an EV tariff effectively.
Some suppliers offer a tariff for EV owners where electricity during the day is slightly more expensive, but in the early hours of the morning when demand is low, a much lower price. When this is available, use pricing data from the smart meter to find this period, then charge the EV to the required charge level, and the house battery if it is unlikely there will be much solar power available during the day.

End user control

Some policies could be triggered by end user request, either on the In Home Display or an app.

When requested, charge EV to 80% as soon as possible.
A high priority policy, when triggered by the user, would charge the car on full power until it reached a given charge level.

Grid load management

It’s costly to provide capacity that isn’t used, to the extent that the National Grid sometimes pays consumers to reduce their electricity consumption at peak times when there is forecast to be low generation from renewables.

These policies do not directly or immediately benefit the consumer, and show how a policy based approach to energy management can balance the needs to multiple stakeholders. Here, the grid can be provided more cost effectively and at lower risk, eventually benefiting the consumer through lower prices and increased reliability.

Reduce peak load on grid
Except in exceptional circumstances, the consumer is not paid to reduce their load at peak times, and most tariffs are not variable. But there are opportunities to shift usage away from peak hours. EVs don’t need to be charged in the late afternoon, and electric heating could be moved to before and after the peak time with little impact on comfort in a well-insulated house.
Temporarily reduce load during predicted spikes in demand.
Spikes in demand are predictable, such as large numbers of kettles boiling during breaks in sporting events. By downloading a list of predictions, the controller can reduce load on the grid for this short period by pausing energy use, potentially avoiding the expense of having generators on standby.
If power from the grid costs 0p or less, charge all the batteries (house and EVs) as quickly as possible.
Smart meters know the current cost of electricity. Pricing signals could be used to inform decisions about how to use power.
When the Demand Flexibility Service is activated, ensure the house battery is charged before the session.
When the National Grid provides advance notice of an energy saving session, ensure the house battery has sufficient charge to meet predicted power usage in the session. As a high priority policy, it would charge from the grid if necessary (overriding PV only charging), and always discharge the battery during the session (overriding discharge cycle management policies).
This policy would minimise the energy used during the session, meeting the National Grid’s objective, and maximising the bonus paid to the consumer.
If there’s a power outage, cooperate with surrounding houses to delay starting up heat pumps, prioritised on occupants and temperature levels.
Air source heat pumps are usually on 24 hours a day. After a power outage, they will all need to increase the temperature of the circulating water, causing a spike in load when the power comes back on. If they were to coordinate start times, this peak could be reduced.

Enable innovation

Currently, because of the lack of standards and extensible controllers, new ideas require a lot of work to interface with all the installed equipment. An open and extensible controller eliminates unnecessary work, allowing anyone to build innovative products and services on top.

Here’s an example of a startup which is producing a product which only works with a subset of equipment, and is having to make a large and unnecessary investment in integration with each individual device. If the ODEC was available, they would only need to deliver the innovative part of their product, as all the integration work would be provided as part of the ODEC.

Startup with idea of scheduling car charging
EV charging is a balancing act to ensure you always have enough range, but using the lowest cost source of electricity. Policies could expose data on equipment and use external data sources such as calendars to use machine learning to optimise charging.
Startup developing a new energy app
Manufacturers provide apps which interface with their hardware, and are limited to the functionality imagined by the manufacturer. This may not be what the individual consumer wants. By opening up data and control, anyone can develop a new app to interface to any domestic equipment.
University researchers experimenting and gathering data
Researchers could try out new control algorithms across a wide variety of equipment. The equipment interfaces would ensure that this remains safe operation. The information provided by every part of the house’s system could be uploaded for analysis.
Use collected data from sensors
Sensor manufacturers, for example, weather monitoring systems, can provide information to the system which can be used by other policies to make better decisions.