An IoT-Based Solution for Monitoring and Controlling Battery Energy Storage Systems at Residential and Commercial Levels

Abstract

Today, increasing numbers of batteries are installed in residential and commercial buildings; by coordinating their operation, it is possible to favor both the exploitation of renewable sources and the safe operation of electricity grids. However, how can this multitude of battery storage systems be coordinated? Using the Application Programming Interfaces of the storage systems’ manufacturers is a feasible solution, but it has a huge limitation: communication to and from storage systems must necessarily pass through the manufacturers’ cloud infrastructure. Therefore, this article presents an IoT-based solution which allows monitoring/controlling battery storage systems, independently from the manufacturers’ cloud infrastructure. More specifically, a home gateway locally controls the battery storage using local APIs via Wi-Fi on the condition that the manufacturer enables them. If not, an auxiliary device allows the home gateway to establish a wired communication with the battery storage via the SunSpec protocol. Validations tests demonstrate the effectiveness of the proposed IoT solution in monitoring and controlling ABB, Sonnen and SolarEdge storage systems.

1. Introduction

Conventional thermal generators—with high ramp capacities or very short start-up times—have always guaranteed the stability of electrical systems. The mission of these generators has never been easy and today, this mission is further complicated by the growing penetration of non-programmable renewable sources. In fact, sun and wind cause significant uncertainties in power generation and push the entire power system towards a low inertia [1,2,3].

Energy storage systems can contribute to power system stability, providing ancillary services without CO₂ emissions, even in the presence of a high penetration of non-programmable renewable sources [4,5]. Batteries are the most used storage technology for this purpose and several contributions in the literature show interesting applications of large power/capacity batteries in transmission grids. For example, [6] investigates the impact of the size of an energy storage system in the range 0.5–1.0 MW to the economic efficiency of a virtual power plant, which also includes a hydropower plant and a photovoltaic system. A two-step algorithm is proposed in [7] to control a grid-connected 560 kWh/720 kVA lithium titanate BESS, in order to simultaneously dispatch the active power flow and provide primary frequency regulation to the grid. Similarly, the algorithm proposed in [8] controls a 2 MW/1 MWh lithium-titanate BESS for primary frequency regulation in the wider transmission network in the United Kingdom. On the contrary, the battery storage in [9] serves the grid operator to ensure the buses voltage compliance. Other contributions in the literature report on social cost–benefit analysis [10] and assessing storage systems value and projects viability [11].

Rather than transmission grids, the major interest of researchers and market operators is in the integration of battery storage systems with active distribution grids [12,13]; this integration is strategic because it is directly related to the proliferation of prosumagers and renewable energy communities (see Figure 1).

Indeed, today, ever-increasing numbers of batteries are installed at residential and commercial levels, in combination with photovoltaic systems and modern electronic DC-AC converters that regulate the power flow between the prosumager and the electricity grid. Therefore, although the main purpose of these battery storage systems is to increase prosumers’ self-consumption rates, it is possible to coordinate the operation of batteries to provide ancillary services to the distribution grid.

Coordinating the operation of distributed battery storage systems is not an easy task. As the number of batteries increases, the data exchange grows very quickly [14]; in addition, modern technologies such as 5G [15], smart contracts and blockchain [16] and cloud platforms [17,18,19] are spreading rapidly. In this context, the relevance of monitoring and control systems [20,21], and the importance of data visualization [22] in facilitating both the optimization and analysis of smart grids necessarily increases.

In this sophisticated framework of communication/control devices and systems [23], the use of the Internet of Things (IoT) is, today, a rapidly growing trend [24,25]. In fact, the integration of IoT into power systems significantly contributes to the improvement of remote monitoring and efficient energy management [26]. Recent IoT open-source applications highlight the versatility, applicability, usability and cost-effectiveness of IoT in supporting smart grids [27], especially in measurement, communication, data processing and command [28].

1.1. Battery Energy Storage Systems in Renewabe Energy Communities: Related Works

The key role of battery storage systems in renewable energy communities has been extensively explored in the literature. The renewable energy communities were introduced into the European regulatory framework—Directive 2018/2001/EU—with the strategic aim [29] of helping the European Union in the current energy transition [30]. These communities are a modern reorganization of local energy systems to integrate distributed energy resources [31] and involve citizens in current energy transition [32,33]; for the latter, institutional preconditions [34], social acceptability [35] and the potential of citizens to co-finance community initiatives on renewable energy [36] have been studied. The benefits for citizens include consumer empowerment and environmentally friendly exploitation of renewable energy resources [37], but also economic benefits that derive from participating in electricity markets when energy communities commercialize their flexibility. In the electricity market within the community (e.g., the internal market), flexibility enables peer-to-peer exchange or trading [38,39,40] and increases collective self-consumption and self-sufficiency [40], thus reducing costs for energy purchased on external markets. In the electricity market outside the community (e.g., the external market), flexibility is load shifting and the ancillary services provisioning to grids operators, thus determining a profit for the community itself.

The key role of storage systems in ancillary services provisioning has been also extensively explored in the literature. For example, the model proposed in [41] determines the operation of battery storage systems, installed at both residential and grid levels, for frequency regulation and peak shaving. Other models provide manual frequency reserve by operating centralized vanadium redox flow battery and electric vehicles [42], or by operating residential/commercial battery storage systems [43]. In [44], batteries and heat pumps are coordinated with each other for participating in the German automatic frequency recovery reserve market. In multi-energy communities discussed in [45,46,47], battery storage systems are combined with thermal storage systems and gas boilers for participating in the joint energy and ancillary services markets. In [48], batteries are the main tool that enables the energy communities to mitigate the load ramp rate of the national power system. In addition, battery storage systems can facilitate the exploitation of flexibility provided by air conditioners, reducing demand during peak hours [49,50] without compromising thermal comfort [51,52]. To this scope, it can be implemented predictive controls and pre-cooling techniques [53] or on-off preset cycles during peak hours [54].

1.2. IoT Solutions in Battery Energy Storage Monitoring and Control: Related Works

The integration of the IoT in power systems is rapidly growing today as IoT supports measurement, communication, data processing and command implementation in smart grids. However, the literature is not very generous with contributions on IoT applications in battery storage systems monitoring and control, at residential and commercial levels.

Table 1. Comparison of main features of previous works.

Ref.	SoC	Alert	HW	SW	Comm.	Battery Type	Type	Year
[53]	yes	Yes	Rpi	GR	TCP-IP	5 kW-100 Ah	Jnl	2022
[54]	Yes	No	IBM servers	Node red	MQTT	2.5 Ah	Jnl	2021
[55]	Yes	No	Rpi	GR	TCP/IP	5 kW-100 Ah	Jnl	2021
[56]	Yes	No	Rpi	-	TCP/IP	12 V-26 Ah (Lead acid)	Cnf	2018
[57]	Yes	No	Rpi	PHP	TCP/IP	48 V-200 Ah	Cnf	2017
[58]	No	No	Rpi	GR	MQTT	192× (3.6 V-3350 mAh)	Cnf	2021
[59]	No	Yes	Arduino	-	TCP/IP	4× (3.6 V-3350 mAh)	Cnf	2021
-	Yes	Yes	Rpi	GR	MQTT	3 kW-12 kWh ABB 4 kW-4 Wh Sonnen 3 kW-4 Wh SolarEdge	Jnl	2023

summarizes the main features of the literature contributions where State-of- Charge (SoC) indicates the estimation/calculation of the state of charge of the batteries, Alert indicates the functionality for sending alarms and messages (e.g., batteries temperatures), HardWare (HW) is the device used to execute software (e.g., Rpi stands for Raspberry Pi), SoftWare (SW) is the software environment to visualize the data (e.g., GRF stands for Grafana), Communication is the link type used to collect the data to display, Battery Type specifies the battery storage system tested by the reference, Type indicates whether the reference is an article (Jnl) or a conference contribution (Cnf), Year is the year of publication.

Table 1 shows that not all contributions in the literature provide the calculation/estimation of the state of charge of the batteries, although this is essential for an adequate control of the storage system. Alert’s features are also extremely underapplied. Raspberry Pi is the most popular device to run IoT system software while Grafana (GRF) is the most used software environment to visualize data. The most common communication protocol is TCP/IP while MQTT is, unexpectedly, used only once.

Hereafter, the contributions of Table 1 are commented. The authors of [55] present a lithium-ion battery management unit. A Raspberry Pi acts as a web server and also as a Modbus TCP/IP client; the open source Grafana suite implements the interfaces that allows the user to online continuous monitoring the storage system status (voltage, current, power, temperature and SoC). In [56], a low-cost open-source battery management system (BMS) is proposed; it monitors voltage, current, temperature and SoC. The peculiarity of the proposed BSM is its ability to adapt to different battery technologies, namely, lithium-ion and sodium nickel chloride batteries. In [57], the battery storage system is part of a microgrid that also includes a photovoltaic system, loads and a hydrogen-based storage system. For that microgrid, the authors proposed an innovative multi-layered architecture to deploy heterogeneous automation and monitoring systems. A Controller Area Network (CAN) bus was used to interconnect the battery management unit with a central controller which acts as a data and command exchanger. Modbus TCP over an Ethernet network served as a physical means to implement the network integration layer, whereas the open-source Grafana suite implements the supervisory monitoring and interaction layer. In [58], the voltage and current of a set of batteries are measured using low-cost sensors; the data measured by the sensors are collected and processed by Arduino, then sent to a data server (mounted on Raspberry Pi), which sends them back to a cloud database. A web application was developed in HTML to display the measured voltage and current values. Unfortunately, in the setup of the laboratory prototype, the authors used lead–acid batteries instead of lithium-ion batteries. In [59], the proposed IoT battery monitoring system is a Raspberry Pi Model 2, which receives voltage, temperature, and current measurements from the storage system inverter, via TCP/IP and an open communication protocol. The data collected by the IoT system are sent to a cloud database and visualized using the ExtJS/HTML5 framework. The authors of [60] present a modular solution, capable of handling a set of 18650B-type lithium-ion batteries that form—hypothetically—the battery of an electric vehicle. A Raspberry Pi hosts the IoT server which receives current and temperature measurements from sensors via MQTT. The measurements are transferred to an InfluxDB time series database via the NodeRed tool. Open source Grafana was used to monitor battery parameters. The authors of [61] also present a modular solution for managing a set of Li-ion batteries for electric vehicles. The proposed solution, tested in the laboratory using very common and cheap devices, unfortunately only considers the battery voltage. The last row of Table 1 refers to the present article.

1.3. Motivation and Original Contribution of This Article

Section 1.1 described the importance of monitoring and controlling battery storage systems to unlock the enormous benefits of energy communities including: increasing the exploitation of renewable sources for the energy transition and contributing to the safe operation of electricity grids. Section 1.2 reported the current consolidated opinion according to which IoT technology is an extremely valid tool for realizing devices for real-time monitoring and control of distributed battery storage systems. However, such IoT devices are still absent in the current market and the literature is still scarce. The few scientific articles in this field propose solutions and prototypes that are still far from becoming devices ready for the market.

Having said that, the following question arises: how are the monitoring and control of battery storage systems, in residential and commercial levels, implemented today? Currently, it is possible to monitor and control only latest generation battery storage systems; manufacturers have created a communication channel between these storage systems and their own cloud infrastructure over Internet. Access to this communication channel is denied; access to data stored in manufacturers’ cloud infrastructure databases is also prohibited.

So how can the manager of a renewable energy community, made up of a multitude of prosumagers, monitor and control the distributed storage systems that fall into the community? The manager must necessarily sign a—commercial—agreement with all the manufacturers of battery storage systems that fall within the community. Under this agreement, the manufacturers will allow the manager to use their Application Programming Interfaces (APIs) so that the manager can receive/send data to storage systems. The use of manufacturers’ APIs is a viable solution but has obvious limitations, as better explained in Section 2 of this article.

This article proposes an IoT solution that overcomes the limitations of the current solution (i.e., the manufactures’ APIs). The proposed IoT solution consists of a cloud infrastructure and a home gateway to create a direct communication channel between the energy community’s cloud infrastructure and the battery storage systems that fall within it, avoiding the use of cloud infrastructures of battery storage systems manufacturers.

Thus, the contribution of this paper is summed up as follows:

• The proposed IoT solution is the combination of a cloud infrastructure and a home gateway; this combination creates a direct communication channel between the cloud infrastructure and distributed battery storage systems;
• The proposed solution is independent of the cloud infrastructures of distributed storage systems manufacturers;
• The home gateway has high interoperability requirements, as well as ease of installation and implementation, is compatible with a variety of storage systems from different manufacturers already on the market, and does not use closed communication protocols;
• The home gateway, installed at a residential or commercial levels, communicates directly via Wi-Fi with the battery storage system on condition that the manufacturer of the battery storage system grants the necessary authorization;
• When the manufacturer does not grant this authorization, the prototype of an auxiliary device—called SunSpec adapter—allows the home gateway to communicate with the battery storage system via the SunSpec protocol.

This article is structured as follows: Section 2 describes the proposed IoT solution for monitoring and controlling distributed battery storage systems, Section 3 discusses validations tests, a discussion closes this article.

2. Proposed IoT Solution for Monitoring and Controlling Battery Storage Systems

Modern residential and commercial battery storage systems, especially if combined with photovoltaic systems, are fitted with communication modules for connection to the Internet via the local home Wi-Fi network. In so doing, manufacturers create a communication channel between these storage systems and their own cloud infrastructure for monitoring battery operation. A local controller—also called battery management system—periodically sends measurements of batteries’ voltages, currents and state of charge to the manufacturer’s cloud infrastructure. These data can be shared with the customer through Apps or specific web dashboards, developed by the manufacturers themselves. In addition to monitoring, it is also possible to regulate for the operation of the battery storage system. In fact, manufacturers can send set points to the AC-DC converter of the storage system to regulate the charge and discharge of the batteries to desired values. As it is easy to intuit, access to these communication channels and the related cloud infrastructures is denied.

Let us suppose that the manager of a renewable energy community needs to know and modify the functioning of the battery storage systems that fall within the community; the manager’s goal is to regulate all prosumagers’ power so that the aggregated power equals a desired value. The only way the manager has to achieve his goal is to sign an agreement—typically a commercial type—with all the storage system manufacturers that fall within the community. This way, the manager’s cloud infrastructure will communicate to the manufacturers’ ones via APIs and, consequently, with battery storage systems. Therefore, to adjust the power $P_i$ that the ith prosumager of Figure 2 exchanges with the grid at the reference value $P_i^{ref}$, the manager needs to implement a feedback control.

The difference between the reference and measured value returns the error $e=P_i^{ref}-P_i$ which the manager uses to update the battery power, i.e., $P_{Batt,i}=P_{Batt,i}+e$. The critical points of this simple feedback process are many and, among these, the three most relevant are:

-

$P_{Batt,i}$ e $P_i$: the community manager must necessarily ask the storage system manufacturer for these values via the appropriate APIs (i.e., read request);

-

$P_{Batt,i}+e$: to update the battery power, the community manager must necessarily ask the storage system manufacturer via the appropriate APIs of the manufacture to send the new value to the storage system (i.e., write request);

-

response time: assuming a multitude of prosumagers, the overall time to (a) receive current values, (b) perform the calculations, (c) send new values and (d) verify that the new values have been correctly implemented may not be compatible with the dynamics of the system under control.

In addition to the list above, it is also necessary to consider that storage system manufacturers are not obliged to provide API’s to the energy community manager; and if the manufacturers decide to do so, they will ask for money to be paid for the provided service.

That said, the need for a solution for monitoring and controlling distributed battery storage systems clearly emerges, a solution which does not subject an energy community manager to the constraints and costs illustrated above. This solution should be compatible with the largest number of storage systems, even if from different manufacturers; it should ease the installation at residential and commercial levels, avoid the use of closed protocols, and be highly interoperability. As far as the authors know, such a solution does not exist in the current market; this lack motivated the design and development of the IoT solution proposed in this article.

The proposed IoT solution consists of a cloud infrastructure and a home gateway (see Figure 3); the latter is installed at the prosumager and creates a direct communication channel between the cloud infrastructure and the prosumager’s storage system. The home gateway communicates to the battery storage system directly and via Wi-Fi (as both are connected to the same local area network), on condition that the storage system manufacturer provides the home gateway with the necessary authorization. In the absence of such authorization (or if the cost for this authorization is too expensive), this article proposes an auxiliary device—named SunSpec adapter—that allows the home gateway to communicate with the storage system using the SunSpec protocol.

2.1. The Cloud Infrastructure of the Proposed IoT Solution

The cloud infrastructure of the proposed IoT solution has a microservices architecture, is developed on Google Cloud Platform, is modular and scalable; each microservice has high specificity and its own interface based on representational state transfer (REST) methods.

The cloud infrastructure microservices are shown in Figure 4 and are described as follows:

-

Kubernetes: Google service for configuring and automating services, and managing workloads;

-

Kiki: sends the commands for charging/discharging the batteries to the home gateway that translates the commands and forwards them to the storage system;

-

EnergyFlow: receives the measurements sent by the storage systems through the home gateway;

-

Cloud Storage: service for archiving objects in Google Cloud;

-

TimescaleDB: open-source database server for time-series data, optimized for fast data entry and complex queries;

-

MySQL: open-source and well-known structured query language (SQL) relational database;

-

Conflet: manages basic configurations of all microservices.

Below is the list of microservices that belong to the cloud infrastructure and that will be implemented soon:

-

MongoDB: noSql (non-relational) document-based database, particularly useful for the development of mobile applications;

-

Kubeflow: open source machine learning toolkit for Kubernetes for running machine learning algorithms;

-

Aurora/omoi: receives data from field devices that do not communicate with the home gateway, consists of a data warehouse (bigQuery) and REST API interfaces released on Kubernetes;

-

Mirai: runs a set of machine learning algorithms for forecasting end-user generation and demand;

-

Okane: provides the electricity markets prices (wholesale, spot, and ancillary service markets);

-

Merchant: performs an algorithm for calculating offers for the ancillary services electricity market;

-

Censor: runs a machine learning algorithm to calculate the level of reliability of a battery energy storage system using historical series (e.g., number of failures, number of disconnections, etc.);

-

Taiyo: collects historical weather data (e.g., irradiation, temperature);

-

Simu: runs an algorithm that creates load and generation profiles for prosumagers, useful for numerical simulations and tests;

-

Rieki: calculates revenues, costs and profits for a renewable energy community.

All the microservices available on Kubernetes (Kiki, Conflet, Okane, Taiyo, Simu, Rieki) are autoscaling services, so capable of scaling upwards as the processing load increases or downwards vice versa.

2.2. The Home Gateway

The home gateway proposed in this article is a Raspberry Pi 3 model B Version 1.2, shown in Figure 5. with a Linux based operating system.

The software, developed with Node.js, includes an MQTT client for communication between the cloud infrastructure (broker server) and the prosumagers battery storage system. The home gateway operating system integrates the ZeroConf application protocol, therefore the home gateway can be identified within a local area network (LAN) by hostname. In this way, all the devices installed at the prosumager’s level can easily initiate a communication with the home gateway—and, therefore, with the cloud infrastructure—knowing the hostname and ignoring the IP address. The operating system also integrates procedures or functions provided by the storage system manufacturer to enable direct communication via local APIs.

The data flow for sending commands from the cloud infrastructure to the storage system to check battery operation is shown in Figure 6.

The operator’s command is forwarded from the cloud infrastructure to the broker and then dispatched to the home gateway via MQTT protocol. The home gateway translates the operator’s command, sends it to the storage system, and waits for a response to be returned to the broker. Each response returned to the broker is saved in a database; in doing so, procedures for checking and diagnosing the processes for sending/executing commands are periodically activated. The database also contains late responses as the cloud infrastructure uses the broker asynchronously. The data flow for data requests to monitor battery operation is shown in Figure 7.

The home gateway sends data requests autonomously and at regular time intervals (cron task); the data provided by the storage system are returned to the broker and stored in a data warehouse.

2.3. The Sun Spec Adapter

In the absence of an agreement with the storage system manufacturer, the home gateway can neither directly monitor nor control the operation of the storage system as shown in the previous Section 2.2. As a result, a prototype of a device named SunSpec adapter was created; the prototype’s printed circuit boards are shown in Figure 8.

The SunSpec adapter acts as an interface between the home gateway and the storage system; it uses a wireless connection with the home gateway (using the ZeroConf protocol) and a wired connection with the storage system (RS485 serial port).

The data flow for monitoring and controlling a storage system in the presence of the SunSpec adapter are modified as shown in Figure 9 and Figure 10.

The SunSpec protocol, developed by the SunSpec Alliance, was chosen for developing such an adapter because all the major manufacturers of battery storage systems (but also of photovoltaic inverters and industrial measurement devices) are members of the SunSpec Alliance. Therefore, power converters allow of battery storage allows third parties to read/write the microcontroller registers via the SunSpec protocol.

The wired communication between the SunSpec adapter and the storage system uses the Modbus TCP protocol. The protocol, as is well known, is an application-level communication protocol, positioned at level 7 of the ISO/OSI model which establishes the formatting of messages (framing), and the mode of transmission of data and control functions between devices that communicate according to the client/server paradigm through different types of bus or on heterogeneous networks.

For wireless communication between the SunSpec adapter and the home gateway, the SunSpec adapter is visible on the LAN via mDNS protocol, even in the absence of a DNS server within the same LAN. The mDNS service has the following characteristics: Name: hostname [mac_address], Type: _smqtt._tcp, Port: 8883. The home gateway connects to the MQTT broker mounted on the SunSpec adapter and subscribes to specific MQTT topics to send read and write commands to the storage system. Messages exchanged via MQTT protocol are encrypted with Transport Layer Security (TLS v1.2) protocol. Furthermore, the configuration of the SunSpec adapter to communicate with the storage system is via MQTT. The MQTT configuration message payload contains the following information: Timestamps (Unix timestamps); Name (or identifier) associated with the storage system (device); the storage model (device model); storage connection parameters (e.g., IP address).

The SunSpec adapter MQTT topics and read/write requests are reported in

Table 2. List of MQTT topics.

MQTT Topics	Description
/sunadp/configuration	The device receives the configuration of the storage system to check.
/sunadp/command	The device receives commands to forward to the storage system.
/sunadp/monitoring	The device sends monitoring data to the storage system at equal intervals.

,

Table 3. List of read requests.

	Syntax and Description
Frequency	{“read”: “Frequency”} The frequency (in Hz), measured at the point of common coupling between the battery storage and the electric grid.
Line-to-phase voltages	{“read”: “Phase voltage”} The line to phase voltages (in V).
Line current	{“read”: “Line current”} The line current (in A).
Active power	{“read”: “Active power”} The absorbed/delivered active power (in W).
Reactive power	{“read”: “Reactive power”} The absorbed/delivered reactive power (in VAr).
State of charge	{“read”: “State of charge”} The state of charge of batteries (in %).

and

Table 4. List of write requests.

	Syntax and Description
Charge	{“write”: “charge”, “power”: 50, [%] “interval”: 60 [min]} The batteries charge at 50% of the rated power for 60 min
Discharge	{“write”: “discharge”, “power”: 80, [%] “interval”: 60 [min]} The batteries discharge at 80% of the rated power for 60 min
Set profile	{“write”: “profile”: “self-consumption”, “backup”: 20 [%]} The batteries operate according to a preset profile, e.g., maximize self-consumption, and the state of charge cannot be lower than 20%.
Stop	{“write”: “stop”} The batteries stop charge/discharge and remain in standby mode.

.

Every 15 s the home gateway sends the reading requests of Table 3 to the storage system, calculates the minimum, maximum and average of the received values and publishes them on the specific topic. The MQTT message payload contains the following information:

• Timestamp (Unix timestamp);
• Monitored device (meter or storage);
• Any details of the monitored device (meter consumption or meter production);
• Monitored quantity (voltage, current, apparent energy, active power, etc.);
• Type of monitored variable (absorbed or delivered);
• Four values (min, max, avg, last value).

All data are wrapped in a JSON object.

3. Validation Tests

This section shows the validations tests to demonstrate the effectiveness of the proposed IoT solution. Following this, Section 3.1 illustrates the home gateway in combination with an ABB storage system while Section 3.2 and Section 3.3 illustrate the home gateway in combination with the SunSpec adapter and two storage systems produced by SolarEdge and Sonnen, respectively.

3.1. Test 1: Home Gateway and ABB React2

The test consists of sending a command from the cloud infrastructure to a 3 kW–12 kWh battery energy storage system, model React2, producer ABB and illustrated in Figure 11.

In particular, the storage system is asked to charge the batteries at 100% power rated for 30 min. The command sent from the cloud infrastructure to the home gateway, via MQTT Broker, is the following JSON:

• {;
• “storage_id”: “000000001”;
• “CMDMode”: “charge”;
• “timeout”: 1800000;
• “percSetpoint”: 100;
• }.

where storage_id is the storage system identifier. The home gateway receives this command, translates it into a POST statement:

POST [IP_REACT2]/v1/ess/poc/config/

which adds the following JSON:

• {;
• “timeout”: 1800000;
• “setpoint_percent”: 100;
• }.

and sends it to the storage system. Shortly thereafter, the home gateway sends the storage system a GET request to verify that the command was successful:

GET [IP_REACT2]/livedata

The storage system responds with a long list of data. From this list, the home gateway extracts the value under examination and sends it to the cloud infrastructure, via MQTT broker and in JSON format:

• {;
•   “consumption”: {;
•   “powerActive”: {;
•   “discharge”: 0;
•   “charge”: 2949;
•   “measure_unit”: “W”;
• }.

The correct execution of the command is also verified through the dashboard provided by the storage system manufacturer; in Figure 12, batteries are charging at 2.9 kW.

3.2. Test 2: Home Gateway, SunSpec Adapter and 4 kW-4 kWh SolarEdge Battery Storage

The 4 kW-4 kWh SolarEdge battery storage under study is shown in Figure 13.

Firstly, a JSON is used to configure the SunSpec to communicate with

• {;
•   “storage”: “ solardge “;
•   “model”: “ Storedge 4”;
•   “address”: [ SolaredgeIP];
•   “crate “: {;
•   “max”: 4000;
•   };
•   “ soc “: {;
•   “mins”: 5;
•   };
•   }.

The SolarEdge service that allows the control of the charge/discharge of the batteries is named Grid Service API. The upload/download command is sent via a POST method on the commands/schedule-der-event endpoint. For example, the following POST charges the batteries to 35% rated power from startTime up to endTime:

• {;
•   “derId”: “90e8dcc3-c70d-4725-a348-01a33b5f0612”;
•   “commandUri”: “ chargeStorage “;
•   “startTime”: “2022-11-06T16:52:00.268Z”;
•   “endTime”: “2022-11-06T17:00:00.724Z”;
•   “priority”: “1”;
•   “parameters”: {;
•   “chargePowerPercent”: “35”;
•   };
• }.

The command priority, i.e., priority: “1”, implies that this command overrides any previous command. The storage system replies with a confirmation of receipt:

• {;
•   “id”: “ca2d8cb3-12ab-45e0-9dde-54f12ab77848”;
•   “derType”: “storage”;
•   “derSerial”: “73170C77-0D-STORAGE”;
•   “commandUri”: “chargeStorage”;
•   “createdOn”: “2022-11-06T16:51:44.786Z”;
•   “startTime”: “2022-11-06T16:52:00.268Z”;
•   “endTime”: “2022-11-06T17:00:00.268Z”;
•   “status”: “Delivered”;
•   “statusMessage”: null;
•   “statusTime”: “2022-11-06T16:51:44.883Z”;
•   “parameters”: { “ chargePowerPercent “: “35” };
• }.

The confirmation also contains an identification code which can be used to modify this command at a later time.

The SolarEdge’s dashboard shown in Figure 14 confirms that batteries are charging at the desired value. For discharging the batteries, the line “commandUri”: “ chargeStorage” is replaced with “commandUri”: “dischargeStorage”.

3.3. Test 3: Home Gateway, SunSpec Adapter and 3 kW-4 kWh Sonnen Battery Storage

Firstly, a JSON is used to configure the SunSpec to communicate with the 3 kW-4 kWh Sonnen battery storage:

• {;
•   “storage”:   “sonnen”;
•   “model”:   “Ecobatteries 8.2”;
•   “address”: [;
•   <SonneIP>;
•   ];
•   “crate”: {;
•   “max”: 3000;
•   };
•   “soc”: {;
•   “mins”: 5;
•   };
• }.

To charge and discharge the battery, the operation mode of the storage system is changed from Self Consumption (which is the default program) to Manual, by the following GET method:

http://{{SONNEN_IP}}:8080/api/setting?OperatingMode=1

Then, the following PUT method:

http://{{SONNEN_IP}}:8080/api/v1/setpoint/charge/{{40}}

which is used to charge batteries at 40% rated power.

The Sonnen’s dashboard shown in Figure 15 confirms that batteries are charging at the desired value. For discharging the batteries, the steps to be performed are similar to those just above; for example, using the GET method:

http://{{SONNEN_IP}}:8080/api/v1/setpoint/discharge/{{50}}

The batteries discharge at 50% rated power.

4. Discussion

This article first recalled the key role of battery storage systems in renewable energy communities; these storage systems offer flexibility on the demand side and can significantly contribute to the electricity market within the community; for example, by enabling peer-to-peer exchange and trading, increasing collective self-consumption and energy self-sufficiency, and reducing overall purchase costs of electricity, but also to the electricity market outside the community (providing ancillary services to electricity grid operators).

This article then recalled the key role of the IoT in providing devices for remote monitoring and control of battery storage systems, highlighting, however, that such devices are absent from the current market and that the literature is far from proposing viable and robust solutions.

That said, how is it possible today to monitor and control the operation of a multitude of battery storage systems, installed in a renewable energy community or, more generally, at residential and commercial levels?

This article explained that the manager of the energy community must necessarily sign a commercial agreement with all the manufacturers of battery storage systems that fall within the community; thanks to this agreement, the manager can use the Application Programming Interfaces (APIs) of the manufacturers’ cloud infrastructures and monitor/control the batteries accordingly. The use of the APIs is a viable solution but has a strong limitation as well as a cost: the communication to and from the storage systems must necessarily pass through the manufacturers’ cloud infrastructure.

The next question then is: how is it possible to create a direct communication channel between the cloud infrastructure of the energy community and the storage systems present in the community?

This article answered this question by presenting an IoT-based solution that is a combination of a cloud infrastructure and a home gateway. The proposed solution is independent from the cloud infrastructures of distributed storage system manufacturers; it eases the installation/implementation; it is compatible with a variety of commercial storage systems from different manufacturers; and it does not use closed communication protocols. The home gateway, installed at a residential or commercial level, communicates directly via Wi-Fi with the battery storage, provided that the storage system manufacturer grants the necessary authorization. In the absence of this authorization, this article has proposed the prototype of an auxiliary device, named the SunSpec adapter, which allows the home gateway to communicate with the storage system, via the SunSpec protocol.

To demonstrate the effectiveness of the proposed IoT solution, this article showed three validations tests. A first test illustrated the direct—wireless—communication between the proposed home gateway and a 3 kW-12 kWh storage system, React2 model produced by ABB. A second and a third test illustrated the communication between the proposed home gateway and two storage systems (a 4 kW-4Wh Sonnen and a 3 kW-4 Wh SolarEdge) through the SunSpec adapter.

To conclude, designing and implementing a—practical and economical—solution for coordinating battery storage systems, distributed in a cluster of prosumagers at a residential and commercial level, is possible today. However, manufacturers of battery storages must enable local APIs, free of charge and without agreement.

In the absence of free APIs, the adoption of the SunSpec protocol is a valid option, but SunSpec alliance members (Tesla, General Electric, Jinko, LG, SMA, Sonnen, Solax Power, to name a few) must define a standard for the messages’ bodies, sent via the SunSpec protocol.

The future development of this work is to test the simultaneous coordination of a hundred residential and commercial battery storage systems.

5. Conclusions

This article recalled the key role of battery storage systems installed at residential and commercial levels and the key role of the Internet of Things in providing devices for remote monitoring and controlling battery storage systems.

This article also discussed the use of the Application Programming Interfaces (APIs) of the battery storage systems manufacturers’ cloud infrastructures. Using such APIs is a feasible solution, but it typically requires signing a commercial agreement and paying for the API services. In addition, the communication to and from the storage systems must necessarily pass through the manufacturers’ cloud infrastructure.

This article proposed an IoT- based solution as the combination of a cloud infrastructure and a home gateway; the proposed solution creates a direct communication channel to battery storage systems because it uses local APIs instead of the manufacturers’ cloud APIs.

The home gateway directly communicates via Wi-Fi with the battery storage system, provided that the storage system manufacturer grants the necessary authorization. In the absence of this authorization, this article proposed an auxiliary device, named the SunSpec adapter, which allows the home gateway to establish wired communication with the storage system via the SunSpec protocol.

To demonstrate the effectiveness of the proposed IoT solution, this paper showed three validation tests using a 3 kW-12 kWh ABB storage system, a 4 kW-4 Wh Sonnen storage system and a 3 kW-4 Wh SolarEdge storage system.

The authors concluded that designing and implementing a—practical and economical—solution for coordinating a multitude of battery storage systems, distributed at a residential and commercial level, is possible today, but manufacturers must enable local APIs.

In the absence of local APIs, the adoption of the SunSpec protocol is a valid option, but SunSpec alliance members must define a standard for the message bodies sent via the SunSpec protocol.