The XENON integration guide

As the energy space becomes more and more decentralized, gridX is continually extending the compatibility of our platform. We do this by integrating additional distributed energy resources (DERs) to help our partners scale, focusing on the most future-proof original equipment manufacturers (OEMs), and the most relevant models within their portfolio. For this to happen, different assets and OEMs must be “integrated” with our XENON platform. 

There are two ways to get the integration ball rolling. The first is when partners approach us with a request for a particular OEM with selected models. The second is when we find an OEM or asset that we determine to have great potential in the market or will bring synergies for multiple partners. Once one of these options is set in motion, the integration process gets under way.

Integrating towards singularity

Step 1: Evaluation

Step 1.1: Is it a priority? 

When first faced with a new OEM or asset, our integration team asks themselves a series of questions to determine whether the integration makes sense on a business level – both financial and operational – for ourselves and our customers.

Typical questions are:

• What is the potential impact of this new asset in terms of revenue for both ourselves and our partners?
• What timeline do our partners expect for the rollout?
• What are the technical expectations? 
• What’s the reputation of the product?
• Does the asset align to our energy management system’s (EMS’s) overall strategy?

Step 1.2: Can we integrate it?

After our team has assessed whether we want to integrate an asset, the next step is: can we?

The answer to this question comes down to data. We start with a general evaluation of all assets from the OEM to get an overview if all of the information and technical documentation we require is available. If it is, our team members then determine the technical feasibility of the integration based on these data points. 

It’s important to note that these points include general measurements, as well as measurements that differ according to device type. For example, we require the following of all devices:

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

Then, depending on the device type, we require additional data points to be able to manage it, rather than simply monitoring it. For this example, we’ll focus only on EV charging stations (EVCS) and battery inverters.

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

Once these assessments are made, there is a further evaluation into the outlook of the OEM’s cooperation, validating their documentation and verifying if there is a plan for testing the integration. If all of these boxes are checked, we align with our partners and the OEM to greenlight the project, have the assets sent to our Test Lab and begin the integration process.

Step 2: The actual integration

We start the integration with initial tests in our Test Lab to confirm whether or not the device provides the necessary interfaces and information. If it does, the integration process continues.

Step 2.1: Benchmarking

For quality assurance, all assets go through a benchmark process. Integrated assets are measured in a predefined series of tests to rate response times, delays and accuracy of the interface. Assets that do not meet our quality standards (e.g. delayed response times, insufficient data accuracy, etc.) fail this phase and the integration process is stopped. 

To start the benchmarking process, our team develops software that allows the gridBox to “speak” to the asset (in this case, think of the gridBox as a polyglot that can speak multiple languages in order to communicate with different assets).

Step 2.2: Scanner implementation

The scanner is the software that detects and identifies the device in a network and forwards 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.

Once the scanner has been implemented, our team must create the code for the “driver”: a piece of software that connects the gridBox to the asset. This is needed to monitor and, if possible, control the asset.

Step 2.3: 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. Because units and data types may vary by manufacturer and model, the data often needs to be converted to comply with our format (again, much in the same way language localization takes place when translating a text from something like English to Spanish, Dutch to Portuguese, etc.).

Step 2.4: Controller implementation

This step is relevant for assets we want to control in addition to monitoring. The aim here is to map abstract control commands to specific asset 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 because although 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 of the commands have been mapped and implemented, and the scanner and driver allow the asset and gridBox to speak the same language, we move on to final end-to-end testing and documenting the integration.

Step 3: Testing and documentation

The last step of the integration is testing. Our development team is highly skilled, and part of what makes them so skilled is their process of testing assets, products and features in order to debug and ensure the highest functionality. During the integration testing stage, we also document the setup process in order to keep quality consistent.

Step 3.1: Practice (testing) makes perfect

We test each integration from end-to-end to ensure optimal performance between the asset and the different XENON modules (e.g., the Tariff Timer, Energy Optimizer, Peak Shaver, etc.). Depending on the asset we’re integrating and the needs of our partner, we run tests in our lab, in the field or both. 

During the testing stage, our backend team takes control over the asset and attempts to manage it remotely in order to verify that everything is working as it should. We have several tests that cover different use cases and touch on all of the features of our drivers. Some tests can be executed independently, while others require actions, such as plugging in an EV for testing an EVCS. All tests are done in our lab.

The general criteria for testing is scanning to find the asset from the frontend and monitoring it. If necessary, our developers will also test whether it can be controlled, too. Tests differ according to asset type, such as:

• Meters
• Inverters
• EVCS
• Heat pumps
• IO devices

Tests for each focus on the asset’s individual functionalities. For example, batteries that are controllable are tested for inverters, and EVCS is tested if we can do a PV surplus charge. Specific tests can also be requested, such as the capabilities for advanced uses like in time-of-use optimization.

Step 3.2: Rollout

After successful testing for monitoring and controllability with the EMS, the implementation follows the software rollout of gridX via weekly and stable releases. It is first pushed to the alpha stage. As it matures, it moves to beta and then stable.

If requested or deemed sensible by/with the customer, we can also add extended field testing. For 4 to 6 weeks, we do end-to-end testing together with other devices at a customer location. If desired, this will be done after the software release (i.e., alpha stage).

Step 3.3: Documentation

As computer scientist 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. 

Documentation typically covers the commissioning of the appliance. In this state, the asset always starts from the gridBox’s default setting. Each step and change made thereafter are documented thoroughly. Screenshots are required. As the developer testing the asset moves through the steps, they add all changes and findings to the commissioning documents. This serves two purposes: first, if changes are required in the future, extensive documentation makes it easier for any engineer to comprehend and amend the previous work. Second, installers will need to know how the appliance must be installed and configured to function with XENON.

Once all steps are successfully completed, it is made available to our customers.

Energy management is nothing without integration

In addition to saying that integration is what makes XENON’s hands and eyes work, Gomes Makohin also adds: “Providing high quality integrations is fundamental to get the correct data and, later, to properly steer assets toward the optimal operation point, especially from an economical and environmental perspective. Put simply: if we can't reach the assets, nothing can be done at all.” 

Integration doesn’t just open the door for new assets and OEMs; it is the very doorknob that has to be turned. Without it – or without it done correctly – decentralized clean assets that are the foundation to the energy transition will work against each other, rather than in harmony, rendering the energy transition a failure. Part of what sets XENON apart from other home energy management systems is our close cooperation with OEMs. We don’t just rely on certain APIs from different OEMs; we work together with them. 

The efforts of our integration team stand as a testament of our commitment to driving innovation and progress within the energy ecosystem. By meticulously integrating the most crucial and relevant OEMs and models for our partners, we not only accelerate their growth but also propel the entire industry forward. We empower our partners to scale faster than the market, ushering in a new era of integration (pardon the pun), efficiency and sustainability. As we continue to forge ahead, our mission remains clear: to revolutionize the energy landscape and shape a future defined by collaboration, ingenuity and boundless potential.

Watch the video below to get an even closer look at gridX's integration process.

Click here if you want to know which OEMs and protocols we have already integrated or get in touch with us.