The DER API – Developing Energy
We are opening our XENON platform to third-party developers. This allows anyone to develop energy management applications from scratch in no time. There is no need to build and maintain integrations for individual manufacturers or devices – just one single RESTful API.
Definition: Before we dive into the details: Let’s clarify what we are talking about when we say DER. A DER is a Distributed Energy Resource. We use this term for all devices that consume, store or produce energy and provide an interface for third-parties.
More manufacturers. More devices. More protocols.
In recent years, more and more manufacturers have entered the market and introduced their own DERs. And while most modern devices offer some interface for third-party applications, no dominant protocol has emerged so far. Consequently, most devices require custom integrations. This means that developers are often forced to weigh up the effort of developing and maintaining an integration against the broad support of their application. Thus, every integration potentially blocks resources that could have been used on the development of the actual application.
One API to rule them all.
For this reason, we have developed the DER API to give every developer access to the perks of XENON. It is a simple RESTful API that provides one data structure per device type – independent of the device’s manufacturer and actual protocol. This abstraction enables developers to focus their efforts on the development of their actual applications. To this date, XENON already supports 27 of the most common OEMs and we are extending the support on a monthly basis.
An API like any other – just for energy
Ever worked with an API? Well, lucky for you, our DER API works just like most other modern APIs.
Let’s start with the data models:
- Account – This model maps to an account that is registered to use the DER API. Each account can be associated with any number of clusters. An account can exercise control over all associated clusters.
- Clusters – Clusters map to gateways. Each cluster is a grouping of devices, has a unique cluster ID and is associated with one account.
- Devices – Each device is associated to one cluster. Moreover, each device features a set of properties including the type of device (inverter, meter, battery etc.), the device manufacturer, model name, serial number and firmware version.
- Flexibilities – Each device features flexibilities. These detail the current state of the flexibilities, i.e. the load on each phase, the total load on all phases and – in the case of a battery – the state of charge.
- Constraints – Constraints apply to a device. Constraints determine the charge/discharge of a device. They feature a timestamp at which they are valid and a timestamp at which they become invalid. To forego conflicts between constraints they are assigned a priority and only the one with the highest priority is applied.
The API offers three types of endpoints, which all serve a different purpose:
- Inventory – The inventory allows you to retrieve all clusters associated with an account and, if given a cluster ID, all DERs associated with each cluster.
- Flexibility – If given a cluster and device ID, this endpoint returns the current state of a device including power measurements, state of charge as well as the current state (i.e. ready, error).
- Constraints – This endpoint requires a cluster and device ID and supports three operations. A GET request returns a list of all the constraints applied to a device. A POST request adds a new constraint to the list. A DEL request requires a constraint ID as an additional parameter and deletes the specified constraint.
Simple. Flexible. Powerful.
The described data models and endpoints provide simple and flexible access to any DER that you own. If the cluster and device IDs are given, you can control any of your devices. This allows you to realize a simple solar charging system with just 40 lines of code:
This snippet highlights the two key advantages of the DER API:
- It is joyfully simple. The abstraction layer handles all the bits and pieces of the actual implementation. You can focus on the logic of your code rather than worrying whether it complies with the specific protocol of the given device.
- It is manufacturer independent. Theoretically, you could use this code in any other cluster that features a meter, a PV system and an EV charging station.
Save your spot
We have been developing XENON for years but we are just starting to onboard third-party users. We want to ensure a quality product and a timely response to any query. Therefore, it will take some time to get everyone on board. But when it is your turn, you can be sure you will have our full attention.
Watch our DER API webinar to learn more.