Published:
October 22, 2021
Last updated:

The XENON integration guide

As the decentralized energy space expands, we at gridX are continually extending the compatibility of our platform by integrating additional DERs. To ensure the efficient and timely delivery of new integrations, we have developed a three-step process.

Step 1: Can we integrate it?

Before starting any implementation work, we check whether the device provides an interface that delivers the necessary data points. These include general measurements, as well as measurements that differ according to device type i.e. we require different data points from a battery than from an EV charging station (EVCS).

Generally the device must provide the following data points:

  • A unique identifier
  • Power measurements
  • Voltage
  • Current
  • Apparent power

Depending on the device type, we then require additional data points to be able to manage the device, rather than simply monitoring it – for simplicity reasons we’ll focus on EVCS and batteries or strictly speaking the inverters of the batteries here:

EVCS

  • Plug state
  • Charging station state, e.g. ready, authorized, charging error
  • Max. Charge/Discharge power

Battery

  • State of Charge
  • Minimum charge power
  • Maximum charge power
  • Capacity
  • State of health

If the device ticks both the general and device-dependent boxes, we proceed with the integration. 
For monitoring only, the general requirements are sufficient.

Step 2: The actual integration

Once we have confirmed that a device provides the necessary interfaces and information, the actual integration begins.

Step 2.1: Scanner implementation

The goal here is to detect and identify the device in a network and forward its ID and device type to our backend. For the scanner, we rely on a range of discovery protocols like ARP and SEMP. The scanner is considered done once we are able to detect and identify the appliance in a network.

Step 2.2: Monitoring implementation

This step enables us to read values from an appliance and normalize them so that they can be reported to the backend in a standardized format.

We apply a standardized data format for each appliance type. Units and data types, however, may vary by manufacturer and model. Therefore, data often needs to be converted to comply with our format. 

Once the data is converted and it complies with our format, all values are written into a protobuf measurement that corresponds to the appliance type. Each type of protobuf measurement is associated with a corresponding appliance type i.e. an EV charging station measurement is associated with an EV charging station.

To verify measurements are correct and complete, we perform one of the following checks:

  • Plausibility check – Simply speaking, we check whether all expected values have been transmitted. These vary by the type of appliance – a battery, for example, requires different data points than an EV charging station.
  • Validity check – The appliance is set up in a test stand in our laboratory. There, we can compare the data reported by the connected meter to the data received in the backend.

Step 2.3: Controller implementation

This step is only relevant for appliances we want to control in addition to monitoring. The aim here is to map abstract control commands to specific appliance commands. In other words, protocols and commands vary from device to device. To provide an abstraction layer that removes this variation, we build an adapter. This would ensure, for example, that the command to discharge a battery is the same regardless of the actual battery and the protocol it employs.

The set of commands that we map here depends on the appliance type: whereas a battery requires both a discharge and a charge command, an EV charging station only requires a charge command (unless it supports bi-directional charging).

Once all the commands have been mapped and implemented, we move on to testing and documenting the integration.

Step 3: Testing and documentation

In the last step of the integration, we ensure everything works as expected and we document the integration and setup process.

Step 3.1: Visualization test

Arguably there’s a lot more to an integration than meets the eye. But visualizing measurements goes a long way in ensuring that values “make sense”. Therefore, we set up the appliance in our lab and operate it for at least 24h.

After this, the measurements are visualized and inspected for plausibility and anomalies.

Step 3.2: Characterization test

This step – surprise – aims to characterize the appliance. To do this, we measure two things: accuracy and reaction time.

  • Accuracy – The accuracy with which appliances report data and – in the case of controlling – adhere to commands varies from appliance to appliance. While one appliance may only regulate in steps of 100 Watts, another may do so in steps of 10 Watts.
  • Reaction time – This measures the lag between the time a command is sent and the time it is actually put into action. This is critical for the stability of energy management systems.

The graph above shows a visual representation of a test for accuracy and reaction time of a recently integrated charging station. The set point (petrol) indicates the command; the measured power is represented by the blue line; and the red line represents the deviation. Two things can be observed here. Accuracy-wise, the charging station only adjusts loads in multiples of 230 Watts (there are some slight deviations due to inaccuracies)  and rounds commands to the nearest multiple. When ordered to charge 1,380 Watts, for example, it will charge 1,436 Watts. 

With regards to reaction time, the frequency of the vertical shifts of the purple line show that the charging station adjusts its load every 20 seconds and that there is a lag of around 10 to 20 seconds between sending the signal and its execution.

Step 3.3: Documentation

As Damian Conway once said, “documentation is a love letter that you write to your future self.” And in this spirit, we finish the integration by documenting the entire process. This serves mainly two purposes. 

Firstly, in case changes are required in the future, it is much easier for any engineer to comprehend and amend the previous work. 

Secondly, installers will need to know how the appliance must be installed and configured to function with XENON as intended.

Once all this is successfully completed, the device is added to our list of supported appliances and made available to our customers.

Get the report!
Like what you read?
Sign up for our newsletter and get the next post delivered directly to your inbox.
Thanks for signing up!
Your submission was successful!
Oops! Something went wrong while submitting the form.