Retrofitting Photovoltaics: A Service-Class-Based Management Approach ^†

Abstract

With the increasing popularity of photovoltaic (PV) equipment in residential and commercial buildings, there is a pressing need for systems that maximize energy efficiency and self-consumption. This paper introduces an integrated management framework for retrofitting existing infrastructures, enabling high photovoltaic (PV) self-consumption in residential buildings through a rule-based control strategy. The framework supports three service classes—defined by user-level Quality of Service (QoS) parameters—and monitors battery voltage along with grid power exchange to coordinate heat pumps, batteries, and hot water cylinders. Experimental deployment in a residential testbed achieved up to 89% PV self-consumption while keeping daily grid usage below 0.5 kWh. Ablation experiments on battery size further demonstrated the approach’s robustness to reduced storage capacities. The use of Commercial-Off-The-Shelf (COTS) components underscores the minimal intrusiveness of this solution, highlighting its potential for seamlessly integrating diverse, vendor-specific equipment into a coordinated control system.

1. Introduction

Photovoltaic (PV) systems for residential and commercial buildings are gaining popularity in Europe, the USA, and other developed countries, as they are an effective means of mitigating climate change and increasing the energy efficiency of existing and new buildings. It represents an important step toward achieving the ambitious goal set by the European Union to reach carbon neutrality by 2050 [1]. According to projections in [2], growth in the buildings sector’s energy consumption is expected, partly due to the population increase. Notice that space heating, cooling, and water heating account for 59% of total buildings’ site energy consumption [2]. Unfortunately, installing energy-efficient equipment like PV panels, batteries, heat pumps, and smart thermostats does not necessarily translate to the anticipated degree of energy savings. In many cases, devices operate independently rather than as an integrated ecosystem, yielding suboptimal results in practice.

Example. For instance, it is worth noting that the battery charging/discharging policy of a PV inverter is completely decoupled from the heat pump power demand and expected PV production during a self-consumption cycle. Logically, an inverter gives precedence to recharging the batteries before any spare power can be measured outside the inverter–battery sub-system. A simplified schematic of the monitored and actuated single-phase setup is shown in Figure 1. During a PV self-consumption cycle, such behavior can delay the heat pump activation until the batteries are nearly full (sequential activation), thus losing the opportunity to absorb future spare power. A smarter approach would be to charge batteries at a slower rate while signaling the heat pump to run in parallel with the charging cycle (concurrent activation). In this way, the battery remains ready to absorb more spare power during the entire self-consumption cycle.

The ability to activate loads concurrently is particularly beneficial around midday, when PV production peaks and fully self-consuming the generated power can be challenging. In situations where the PV subsystem and the heat pump subsystem are inherently independent—either due to diverse vendors, lacking interconnectivity, or compatibility issues—our proposed framework provides a solution by monitoring the battery voltage in real time and using it as a trigger for heat pump operation. Section 4 delves further into the crucial role of the battery voltage sensor in maximizing PV self-consumption.

Maximizing PV self-consumption is particularly advantageous in countries where the grid does not provide virtual energy storage capability (i.e., surplus electricity sent to the grid is not freely retrievable later). Depending on local electricity trading schemes, customers benefit from minimizing grid usage after sunset. The proposed management framework was deployed in Italy, where no virtual energy storage is offered. In other countries with different grid policies, maximizing self-consumption might be less critical.

In this work, we propose an integrated management framework that achieves a high degree of PV self-consumption in residential buildings. A key novelty lies in its ability to retrofit existing multi-vendor systems with minimal intrusiveness: instead of requiring vendor-specific APIs or specialized hardware modifications, our approach uses off-the-shelf sensors and actuators to coordinate batteries, heat pumps, and hot water systems. This framework has been implemented and tested in a residential building with 200 m² of living area and equipped with a 12 kW heat pump, 8 kW (peak power) PV panels, 25 kWh Li-ion batteries, and a $200 \mathcal{\ell }$ hot water cylinder (HWC).

Three practical pain points motivate this work: (1) Multi-vendor device incompatibility—proprietary interfaces hinder integration of PV inverters, batteries, and heat pumps from different manufacturers; (2) Siloed device operation—batteries charge sequentially before loads are served, wasting spare PV power during peak production hours; (3) High cost and complexity of existing solutions—MPC requires accurate per-building thermal models, while DRL lacks the interpretability and stability guarantees needed for mass-market deployment. These pain points expose three research gaps that the present work addresses: (i) a lack of low-intrusive frameworks that avoid hardware or firmware modifications for legacy devices; (ii) insufficient attention to user-centric service differentiation that balances energy efficiency with thermal comfort in PV self-consumption management; and (iii) limited studies on maintaining high self-consumption under varying battery capacities, a key practical constraint for homeowners.

The highlights of this work include:

• An automated self-consumption strategy that supports three service classes: (1) Low, (2) Medium, and (3) High Quality of Service (QoS). These classes, respectively, provide low-power heating, domestic hot water (DHW (Domestic hot water includes a 50 °C setting for power-efficient production and a 65 °C high-temperature setting for thermal disinfection.)), and high-power heating and DHW up to 65 °C;
• A management framework that can be retrofitted to existing buildings and PV systems by augmenting photovoltaic and heat pump systems (plus hot water cylinders) with straightforward sensor-actuator modules;
• A low-cost testbed realized with Commercial-Off-The-Shelf (COTS) equipment consisting of PV panels, an inverter, batteries, a heat pump, and a hot water cylinder with resistive heating. Each component was originally designed for standalone operation, yet our approach integrates them without significant hardware or firmware modifications. Experiments show that the proposed management framework can achieve up to 89% PV self-consumption while keeping daily power grid consumption below 0.5 kWh.

The use of COTS components is generally challenging as each vendor proposes its proprietary interfaces and features, often not compatible with those of other brands. Such restrictions typically hinder the tight integration of a multi-brand system. By contrast, our approach demonstrates multi-brand compatibility through universal sensor readings (battery voltage, water temperature, spare power) and simple relay-based actuation.

Prior Work. A preliminary version of this framework, with early partial results, appeared in [3], focusing on the conceptual approach but lacking the comprehensive experimental validation. This paper substantially expands upon that by offering an in-depth analysis of system performance under different automation regimes and battery sizes.

The remainder of this paper is organized as follows. Section 2 reviews related work. Section 3 clarifies terminology and assumptions. Section 4 introduces our service classes for PV self-consumption. Section 5 describes the proposed management framework for automation. Section 6 presents experimental results, and Section 7 concludes the paper with future directions.

2. Related Work

The decarbonization of the global building stock has transitioned from an aspirational goal to an operational imperative, driven by regulatory frameworks such as the EPBD and the need to retrofit legacy structures characterized by poor thermal envelopes [4]. Consequently, the integration of Distributed Energy Resources (DERs)—specifically PV, batteries, and heat pumps—has exposed a critical “integration gap”, where high-performance components operate as isolated silos due to fragmented control logic [5]. The following subsections synthesize the recent literature regarding control strategies, interoperability, and service-oriented management.

2.1. Evolution of Control Strategies: From Heuristics to Edge AI

The optimization of PV self-consumption has matured significantly, revealing a tripartite contention in control methodologies: the robustness of Rule-Based Control (RBC), the theoretical optimality of Model Predictive Control (MPC), and the adaptability of Deep Reinforcement Learning (DRL).

Model Predictive Control (MPC) remains the academic gold standard for maximizing energy efficiency, leveraging mathematical models of thermal dynamics to optimize actions over a receding horizon [6]. Recent advances in stochastic and scenario-based MPC have successfully addressed the uncertainty of PV generation [7]. However, widespread adoption in residential retrofits is hindered by the “modeling bottleneck”: constructing accurate white-box or grey-box thermal models for individual legacy homes is economically nonviable and computationally expensive for low-cost embedded controllers [8].

Deep Reinforcement Learning (DRL) has emerged as a model-free alternative, capable of learning optimal policies through trial-and-error without explicit physical models [9]. While DRL agents can outperform traditional baselines by 15–30% [10], they suffer from a lack of interpretability (the “black box” problem) and stability concerns during the training phase; even at deployment time (after extensive training), they can be a source of safety concerns due to unpredictable behaviors. Recent breakthroughs in Rule Extraction (RE) suggest that the utility of DRL may lie in offline policy generation, where complex agents are distilled into interpretable decision trees for deployment [11], validating the architectural relevance of deterministic rule sets.

Several recent studies have specifically targeted PV-battery-heat pump coordination in retrofitted buildings. However, existing retrofitting frameworks typically rely on vendor-specific APIs or require modifications to inverter firmware to access real-time battery state-of-charge data [12,13], limiting their applicability to heterogeneous multi-brand installations. In contrast, the present work achieves coordination through universal physical measurements (battery voltage, water temperature, grid power exchange), requiring no vendor cooperation.

Modernized Rule-Based Control (RBC). Despite the proliferation of advanced solvers, RBC remains the dominant strategy for mass-market retrofitting due to its transparency and low computational overhead [14]. Recent studies rigorously validate “lightweight” algorithms that prioritize execution speed on edge devices (e.g., Raspberry Pi) over absolute mathematical optimality. For instance, Banaei et al. [15] demonstrated that while RBC yielded costs approximately 3.9% higher than complex MPC, it reduced runtime by three orders of magnitude. Furthermore, the emergence of Machine Learning-Enhanced RBC (ML-RBC) allows for static thresholds to be dynamically tuned by local forecasting models, bridging the gap between simplicity and adaptability [16].

2.2. Interoperability and the “Matter” Paradigm

The main barrier to effective retrofitting (as identified in early literature) was the lack of interconnectivity among multi-vendor devices [17]. The 2023–2025 period witnessed a paradigm shift with the maturation of the Matter protocol and Web of Things (WoT) architectures.

Matter eliminates the proprietary interface silos by defining a unified, IP-based application layer, allowing Commercial-Off-The-Shelf (COTS) components to be controlled by a central Home Energy Management System (HEMS) without custom APIs [18]. Crucially, the Matter 1.4 specification introduced standardized clusters for device energy management, enabling HEMS to query generic battery states or command heat pumps regardless of manufacturer [19]. The W3C Web of Things (WoT) Architecture formalizes this via the “Gateway Pattern”, where a local servient virtualizes legacy assets into standardized web entities. Recent implementations have demonstrated how this allows disparate devices (heat pumps, batteries) to be integrated [20]. This confirms that the future of retrofitting lies in standardized software layers rather than invasive hardware modifications.

2.3. Service-Oriented Management and QoS

The concept of categorizing loads into service classes has evolved into formalized Quality of Service (QoS) frameworks. In modern HEMS literature, QoS is quantified not merely by availability, but by multidimensional metrics of user satisfaction and task completion [21]. Thermal Comfort as QoS: Recent studies map “High QoS” to strict adherence to Predicted Mean Vote (PMV) indices, while “Low QoS” permits wider temperature deadbands to maximize self-consumption [22]. Task-Based QoS: For deferrable loads like EVs, QoS is defined by the timely completion of charging cycles, prioritizing user convenience over energy cost when necessary [23]. This differentiation aligns with emerging Energy-as-a-Service (EaaS) business models, where providers manage retrofitted assets to meet Service Level Agreements (SLA) rather than selling raw energy [24]. In this work, QoS classes are designed offline to meet increasing levels of user comfort while the photovoltaic production ramps up, guaranteeing minimal energy consumption from the grid. The QoS classes can be further fine-tuned at run-time and even new classes can be integrated, making the QoS control highly configurable.

2.4. Beyond the Single Home

While this work focuses on single-building optimization, the proposed service-class framework is extensible to Community Energy Storage (CES) and Peer-to-Peer (P2P) trading. Shared storage systems benefit from load diversity, potentially reducing required capacity by 13–30% compared to individual batteries [25]. In such scenarios, service classes can define storage tiers, prioritizing “High QoS” community members during peak demand.

2.5. Gap Analysis

Despite these advancements, a gap remains in effectively and affordably orchestrating standard heating, cooling, and battery systems in non-homogeneous setups without relying on expensive industrial-grade solvers. While DRL and MPC offer theoretical optimality, their computational and modeling costs bar them from mass-market retrofit scenarios. This work addresses the need for a predictable, lightweight, and interoperable management framework that leverages the robustness of rule-based control with service classes to achieve high self-consumption with minimal hardware intrusiveness. The proposed technology focuses on existing buildings that already have installed equipment; hence, retrofitting an Internet of Things (IoT) based management framework is the mass-market solution that we propose to significantly improve the energy efficiency of buildings. Finally, Section 5 discusses a real system implementation to demonstrate how the proposed management framework is a flexible and low-cost solution that can be deployed on IoT devices commonly used for building automation.

3. Terminology and Assumptions

This work focuses on residential buildings equipped with PV panels, batteries, a heat pump, and a hot water cylinder (HWC) for the production of domestic hot water (DHW). To achieve high levels of energy efficiency, the heat pump is used both to heat/cool the building and produce domestic hot water. It is assumed that the hot water cylinder has a resistive heat element and it has two temperature sensors: (a) $T_{hwc}^{up}$ on top of HWC, and (b) $T_{hwc}^{down}$ at the bottom of HWC. A thermostat is used to control the temperature of the building, the voltage $V_b$ of the batteries and the power $P_{spare}$ returned (a negative value of $P_{spare}$ means that the system is consuming power from the grid) to the power grid are monitored in real-time to promptly adapt the self-consumption strategy to the instantaneous PV production.

The activation of a self-consumption load can be subject to a precedence constraint with a transition condition; for instance, the expression ${\mathbf{service}}_{\mathbf{1}}\stackrel{T_{HWC}^{down} \ge 50 °\mathrm{C}}{\Rightarrow }{\mathbf{service}}_{\mathbf{2}}$ means that $servic{e}_2$ is activated after the activation of $servic{e}_1$ if the bottom temperature of HWC has reached 50 °C. Priority-based activation rules use the $V_b$ sensor and they use following notation: $V_b\ge 52.2\mathrm{V}\stackrel{\left(30\mathrm{s}\right)}{\to }\mathbf{low}\mathbf{QoS}$ that is, low QoS service is activated when $V_b$ is greater than or equal to 52.2 V for at least 30 s. Deactivation rules use the $V_b$ sensor and they use following notation: $\mathbf{high}\mathbf{QoS}\stackrel{\left(1\min \right)}{\to }{V}_b\le 52.4\mathrm{V}$ that is, high QoS service is deactivated when $V_b$ is less than or equal to 52.4 V for at least 1 min. Finally, background-based activation rules use the $P_{spare}$ sensor and they use following notation: $P_{spare}\ge 1.9\mathrm{kW}\stackrel{\left(30\mathrm{s}\right)}{\to }\mathbf{high}\mathbf{QoS}$ that is, high QoS service is activated when $P_{spare}$ is greater than or equal to 1.9 kW for at least 30 s. The background deactivation guard works in a similar way, but normally it uses a negative threshold for $P_{spare}$ to detect when power is taken from the grid.

For the sake of simplicity, it is assumed that batteries are always in a charging, discharging, or depleted mode; hence, batteries are never in standby mode (disconnected from load and PV panels) to avoid over-charging. Standby mode of the battery is supported by the Management Framework, but it requires handling some corner cases whose description would lower the readability of this article. However, a hint to this problem and its solution will be discussed when necessary.

Table 1. Framework Notation.

Symbol	Description
SCR	self consumption rate
LMI	load matching index
DHW	domestic hot water
HWC	hot water cylinder
$T_{hwc}^{up}$	temperature of water at top of HWC
$T_{hwc}^{down}$	temperature of water at bottom of HWC
$V_b$	voltage of battery
$P_{spare}$	spare power (kW) returned to the grid
$V_{stdby}$	voltage of battery when it is in standby mode
$V_l^{on}$	activation voltage for low QoS
$V_l^{off}$	deactivation voltage for low QoS
$V_m^{on}$	activation voltage for medium QoS
$V_m^{off}$	deactivation voltage for medium QoS
$V_h^{off}$	deactivation voltage for high QoS
$sr{v}_1\stackrel{T_{hwc}^{down} \ge x °\mathrm{C}}{\Rightarrow }sr{v}_2$	precedence constraint with transition condition
$V_b\ge x\stackrel{\left(y\mathrm{s}\right)}{\to }service$	activation guard: service is started if $V_b\ge x$ for y seconds
$service\stackrel{\left(y\min \right)}{\to }{V}_b\le x$	deactivation guard: service is stopped if $V_b\le x$ for y minutes
$P_{spare}\ge x\stackrel{\left(y\mathrm{s}\right)}{\to }srv$	background activation guard: srv is started if $P_{spare}\ge x$ for y seconds
$srv\stackrel{\left(y\min \right)}{\to }{P}_{spare}\le x$	background deactivation guard: srv is stopped if $P_{spare}\le x$ for y seconds

summarizes the notation used throughout this work.

4. Service Classes for PV Self-Consumption

Priority and background-based activation rules provide the means to define distinct service classes for photovoltaic self-consumption. The $V_b$ sensor, enabling concurrent activation of loads, allows the heat pump to operate alongside the battery charging cycle. Moreover, it facilitates real-time identification of battery charging and discharging cycles within the proposed Management Framework. Monitoring $V_b$ allows to prioritize the activation of loads so that the produced PV power can be shared among the charging of batteries and the self-consumption loads. Finally, monitoring $P_{spare}$ allows for activating loads in the background; that is, a load is activated only when spare power $P_{spare}$ is returned to the grid for some time.

The proposed management framework of photovoltaic self-consumption introduces three service classes: (1) Low, (2) Medium and (3) High Quality of Service (QoS). These classes are described below and summarized in

Table 2. Service Classes Currently Implemented In The Management Framework.

Service Classes	Power (kW)	Type of Service	Implementation
High QoS background srv	1.7 kW heating element plus heat pump load (high power mode)	medium QoS $\stackrel{T_{HWC}^{down}\ge 50 °\mathrm{C}}{\Rightarrow }$ DHW at 65 °C (heating with heat pump)	heating element + heat pump (background activation of heating element)
Medium QoS low priority	Adaptive load, high power mode [1.5–4 kW]	DHW at 50 °C $\stackrel{T_{HWC}^{down}\ge 50 °\mathrm{C}}{\Rightarrow }$ High Power Heating	heat pump: compressor is power limited at kW (priority-based activation)
Low QoS high priority	Constant load, low power mode ∼1.5–2 kW	Low Power Heating	heat pump: controlled by fixed value of water flow temp (35–40 °C) (priority-based activation)

.

• Low Quality of Service (QoS): This service class delivers low power heating (∼1.5–2 kW in the experimental testbed). The low QoS operates on a priority-based activation, and its power consumption can be tuned by setting the water flow temperature of the heat pump at 35–40 °C;
• Medium Quality of Service (QoS): This service class initially produces DHW at 50 °C. During this phase, the heat pump’s power consumption increases (from 1.5 kW up to 4 kW) as DHW temperature raises. Once the DHW reaches the target temperature, the heat pump switches to deliver high power heating (∼4 kW). The medium QoS also operates on a priority-based activation, and its power consumption is limited to a fixed value (4 kW in the experimental testbed) by setting the maximum power consumption of the heat pump compressor;
• High Quality of Service (QoS): This service class produces DHW at 65 °C and operates on a background-based activation ($P_{spare}\ge 1.9\mathrm{kW}\stackrel{\left(30\mathrm{s}\right)}{\to }\mathit{high}\mathit{QoS}$ in the experimental testbed). This service is subject to a precedence constraint ($\mathit{medium}\mathit{QoS}\stackrel{T_{hwc}^{down} \ge 50 °\mathrm{C}}{\Rightarrow }\mathit{high}\mathit{QoS}$) and it is stopped by a deactivation guard that uses the battery voltage as threshold ($\mathit{high}\mathit{QoS}\stackrel{\left(1\min \right)}{\to }{V}_b\le 52.4$ V in the experimental testbed).

Figure 2 shows an example of a PV production curve obtained from our testbed in May: it had a peak power of 5.56 kW and a daily production of 31.22 kWh. Note that photovoltaic production has fast dynamics (order of seconds) while a heat pump is slow to react to service requests (order of minutes). This discrepancy makes it challenging to fully exploit a photovoltaic system’s production profile (kW). To better align the automated self-consumption load (used for building heating and domestic hot water provision) with the PV production curve, this work proposes the use of different service classes.

While the proposed management framework can be used for heating and cooling needs in residential buildings, this paper focuses on heating due to its demand during the most challenging months for PV production (September to April for our testbed located in northern Italy). In fact, during these eight months, our testbed’s PV production ranged from a minimum of 1–5 kWh/day to a maximum of 30–40 kWh/day. This significant production variance makes PV self-consumption challenging, and the proposed service classes effectively address this issue.

The tri-service-class design works well in the deployed testbed; however, the proposed framework is highly configurable. As such, the type and number of service classes, as well as their activation priority, can be modified. The management framework described in Section 5 provides key primitives necessary to integrate multiple actuators and sensors and presents them to the user as an organized group of prioritized service classes. See the following Section for a detailed discussion about the “Management Framework”.

5. Management Framework

The support of service classes to efficiently manage PV self-consumption loads is based on five key primitives:

• “Precedence constraint with transition condition”: a service is activated only after the activation of another service if a transition condition is satisfied;
• “Priority activation guard”: a service is activated only if the voltage of the battery is above a threshold for y amount of time;
• “Background activation guard”: a service is activated only if the spare power returned to the grid is above a threshold for y amount of time;
• “Deactivation guard”: a service is deactivated if the voltage of the battery is below a threshold for y amount of time;
• “Background deactivation guard”: a service is deactivated if the spare power (A negative value of $P_{spare}$ can be set as threshold meaning that the system is consuming power from the grid) returned to the grid is below a threshold for y amount of time.

These key primitives have been used in our testbed to realize the three service classes of Table 2. Figure 3 shows a state machine representation of our PV self-consumption management process. The visual representation incorporates all precedence constraints, voltage and power thresholds, priority and background activation guards with respective time parameters, as well as all essential deactivation guards employed in our testbed. The transition conditions, explicitly and implicitly stated in the system, are all accurately captured by the state machine, allowing for a comprehensive and faithful depiction of the system’s operational logic. An example of such implicit precedence is the requirement for the heating element to be deactivated before the transition from Medium QoS to Low QoS can occur. This is due to the voltage deactivation threshold of the background service being higher than the one for the Medium QoS deactivation. The background deactivation guard was not used in this implementation, but could be included to increase system robustness and to handle any faulty condition that causes the system to consume an excessive amount of power from the grid.

Note that the PV inverter disconnects the batteries and puts them in standby mode when they are fully charged and they are not used by any load. In such a case, $V_b=V_{stdby}$ cannot be used to infer the charging or discharging rate of the battery and a background activation guard needs to be used to activate a service. It is important that the deactivation guard of the same service uses a voltage threshold $x<V_{stdby}$; otherwise, the two rules (activation and deactivation) are executed at the same time with undefined behavior. In case the PV system does not have any batteries, both priority-based activation guard and deactivation guard will not be available to manage the self-consumption loads. This limitation, together with the lack of local energy storage, greatly limits the overall efficiency of a photovoltaic system.

5.1. Framework Implementation

This implementation aims primarily at demonstrating how a multi-brand testbed, consisting of existing equipment lacking smart grid functionalities, can be retrofitted and augmented with advanced home automation features. The goal is to prove that any existing residential building equipped with a PV system can improve its energy efficiency substantially by maximizing self-consumption capability. In countries like Italy, where the grid does not offer any virtual energy storage capability, it is crucial that consumers maximize their PV self-consumption rate to reduce their monthly electric bill. Ultimately, we aim to demonstrate that affordable solutions exist to transform any existing residential building into a “smart house” that supports advanced “self-consumption technology” and can take full advantage of an installed PV system.

5.1.1. System Architecture

The self-consumption management framework was implemented on a cloud service offered by Shelly (https://home.shelly.cloud/; accessed on 27 January 2026). An overview of the deployed hardware setup is shown in Figure 4. Shelly’s smart home automation devices were selected as sensors and actuators because of their affordability, robust software stack based on Mongoose-OS, and intuitive programming interface that uses time triggers, event triggers, and actions.

5.1.2. Testbed Hardware Setup

The testbed consisted of the following components:

• A PV system with a ZCS Azzurro single-phase inverter (Zucchetti Centro Sistemi S.p.A., Terranuova Bracciolini, Italy) and five WECO 4k4 PRO battery modules (WECO S.r.l., San Bonifacio, Italy);
• A Ferroli OMNIA 12 kW heat pump (Ferroli S.p.A., San Bonifacio, Italy);
• Seven Daikin Altherma HPC heat pump convectors (Daikin Europe N.V., Ostend, Belgium);
• A 200 L hot water cylinder for domestic hot water (manufacturer: Cordivari S.r.l., Morro d’Oro, Italy), which can be heated both by the heat pump and a resistive heating element.

To monitor and control these components, we used various sensors and actuators. For instance, an energy meter (Shelly EM) was used to measure returned or consumed energy. Two temperature probes (the top sensor is useful for the user to read the actual temperature of DHW, while the bottom sensor is used by the automation) (Shelly 1) monitored the hot water cylinder’s temperature, and a voltage meter (Shelly Uni) measured the batteries’ voltage (the voltage of WECO batteries is in the range of 49.5–55 V while the analog-to-digital converter (adc) of Shelly Uni has a maximum input voltage of 30 V. In order to use the Shelly Uni as a voltage meter for the battery, a 10 kΩ voltage divider was added to the adc input circuit so that the Shelly Uni reads $1/2V_b$). It was decided to acquire only the battery voltage without its state of charge, since it is an electric parameter that can be easily read. The batteries (WECO) have two dry contacts that can be set as output ports to signal two levels of state of charge; moreover, the heat pump (Ferroli) has a “smart grid” function. We decided to ignore both features since they seemed rather rudimentary and unsuited for the purpose of adaptability and portability. As highlighted in Section 6, the deployed sensors were very effective at implementing the self-consumption policy based on service classes. Finally, as actuators, the heat pump is turned ON/OFF by using a smart switch (Shelly 25); its two power levels (low and high power) are implemented by operating a three-way motorized valve with a “Shelly 1” and forcing the heat pump water flow to the convectors’ circuit while the heat pump is still prioritizing (This is a customization since the heat pump does not support two power levels of operation; it only allows to set statically the water flow temperature) DHW. Moreover, each Daikin heat pump convector can be activated or put on standby by operating its “presence input contact” with a “Shelly 25”. Finally, the resistive heating element is controlled (ON/OFF) by using the contactor control of a Shelly EM. The IoT-based implementation of the proposed management framework had an approximate cost of 250 euro.

5.1.3. Testbed Location and Annual Energy Profile

The testbed is a two-storey masonry residential building (200 m² living area) located in coastal Northern Italy (Massa Carrara province, climate zone D, 1525 heating degree-days). Annual energy data recorded over the full calendar year 2025 are summarized in

Table 3. Annual energy balance of the testbed building (calendar year 2025).

Parameter	Value
Total PV production	8381 kWh (41.9 kWh/m2 yr)
Total consumption	8207 kWh (41.0 kWh/m2 yr)
Heat pump (total)	3801 kWh (46.3%)
Space heating	2172 kWh
DHW (heat pump)	731 kWh
Cooling	750 kWh
Standby/other	148 kWh
DHW resistive element	1100 kWh
Other loads	3306 kWh
Grid feed-in	1600 kWh
Grid draw	2322 kWh
Annual self-consumption rate	81.4%

. The building’s specific annual consumption of 41.0 kWh/m² yr is consistent with a partially retrofitted masonry envelope served by a heat pump; the near-unity PV-to-load ratio (8381/8207 ≈ 1.02) confirms that the PV installation is well-matched to the building’s needs. The measured annual self-consumption rate of 81.4% validates the effectiveness of the proposed framework over the full seasonal cycle, including spring and autumn shoulder months where PV production and load demand are roughly balanced.

5.1.4. Software and Rules Implementation

The system used both time-triggered tasks (periodically activated by a timer) and event-triggered tasks (e.g., $P_{spare}$ > 1900W for 30 s) to control the components. These rules needed to be carefully designed and tested to avoid any conflicts, which could result in rapid and continuous triggering of a relay and potential damage to the equipment. A programming environment with proper debugging, verification, and simulation tools would facilitate this process to test the correctness and safety of implemented rules before deployment in a physical system; in fact, this will be part of our future work.

5.1.5. Safety Considerations

In the interest of safety, the combined maximum power of all the automated loads was limited to 5.7 kW, and the power of the heat pump compressor was capped at 4 kW. Also, each smart relay should implement a safety mechanism based on watchdog timers, allowing devices to converge to a preset safe state in a distributed manner in case of faults. As part of our future work, we will focus on a verification tool for the IoT management framework, such that the correct design of safe states for faulty configurations will be verifiable.

5.1.6. Security

Even though security, robustness, and fault tolerance were not the primary focus of this investigation, they were integral aspects for system deployment.

In the current IoT system implementation, Shelly devices run a local HTTP server on port 80, potentially exploitable if an attacker gains access to the local network. To counter this, the local network was protected by using an Internet firewall and standard security measures. The newer “Generation two” of Shelly (Shelly Plus and Shelly Pro series) offers better security with HTTPS actions support, but was not used in the existing testbed.

5.1.7. Fault-Tolerance and Recovery

Certain shortcomings were identified in the current implementation: the Shelly devices support a default state at the time of reboot but lack a safety mechanism for converging to a distributed and safe state during instances of Internet connectivity loss or device crashes. In such cases, the Shelly relays maintain their current (ON/OFF) state.

To address this, the local network was enhanced with “Home Assistant Operating System” (https://www.home-assistant.io/; accessed on 27 January 2026) installed on a Raspberry Pi4. This setup allowed all Shelly devices to be controlled both remotely (using the Shelly cloud) and locally through the Home Assistant interface in case of Internet connectivity loss. The local Home Assistant server served as a backup when the connection to the cloud was lost. It was observed that many random software faults that would otherwise halt the cloud automation could be resolved by locally rebooting the affected device with Home Assistant.

5.1.8. Usability

It is worth mentioning that the deployed testbed was initially operated only by expert users. Further studies are needed to focus attention on human–computer interaction, usability, and testing with novice users; such research should be performed to develop a new generation of user-friendly and energy-aware solutions for residential automation. To this purpose, the testbed has been recently extended with a Graphical User Interface (GUI) based on the “Home Assistant Operating System”. We realized that the integration of the management framework with a GUI that displays in real-time all the electric power parameters and DHW temperature significantly improves system usability.

6. Experimental Results

The proposed automation framework, as implemented on the testbed, was tested over several months and proved to offer adequate robustness and reliability for an affordable and versatile home automation solution. The software stack had a Mean Time Between Failures (MTBF) ranging from weeks to a few months, comparable to the MTBF observed in the software of Internet routers. Occasionally, a reboot of all Shelly components and Internet routers was necessary to restore all automation functionalities and recover from random crashes of a few Shelly devices.

The performance of the proposed management framework is demonstrated through both experimental and simulated results. These results showcase PV production, battery charge, and self-consumption patterns for three sample days. Furthermore, SCR and LMI are calculated for each day to measure the effectiveness of the proposed self-consumption strategy.

LMI is a performance metric that quantifies the degree of alignment between power generation from the PV system and the power consumption by all loads, including batteries. It is defined as the ratio between consumed power and PV-produced power. During a self-consumption cycle, an LMI close to one indicates that all PV-produced power is self-consumed, either by charging the battery or by powering service loads such as Domestic Hot Water (DHW) production and heating/cooling of the building. An LMI below one indicates that part of the PV-produced power is not used by the building and is returned to the grid, which could signify a poorly designed self-consumption scheme, an oversized PV system, or undersized battery capacity.

Lastly, SCR provides an indication of how much of the generated PV power is consumed by self-consumption service loads without charging the battery. While a high LMI value is desirable to avoid returning power to the grid, a high SCR value may suggest that the PV system is likely undersized or the self-consumption scheme is poorly designed. In such cases, the PV system provides power for daily heating/cooling and domestic hot water but may not accumulate enough energy for nightly usage.

The formal definitions are given by the following:

$$\begin{array}{ccc}\mathrm{LMI}\hfill & =& {\displaystyle \frac{P_{\mathrm{consumed}}}{P_{\mathrm{PV}}}}\hfill \end{array}$$

(1)

$$\begin{array}{ccc}\mathrm{SCR}\hfill & =& {\displaystyle \frac{P_{\mathrm{service}\mathrm{loads}}}{P_{\mathrm{PV}}}}\hfill \end{array}$$

(2)

where $P_{\mathrm{consumed}}$ is the total power consumed by the building, including both battery charging and service loads; $P_{\mathrm{PV}}$ is the total power produced by the PV system; $P_{\mathrm{service}\mathrm{loads}}$ is the power consumed by self-consumption service loads only (such as DHW, heating, and cooling), excluding battery charging.

6.1. PV Production, Battery Charge, and Self-Consumption

Figure 5 depicts PV production, battery charge, and self-consumption for three sample days. The correlation between PV production and self-consumption is evident, demonstrating the effectiveness of the proposed management framework. Additionally, it is worth noting that the LMI values were consistently around $80\%$ in the experimental setup, signifying an efficient match between PV production and load consumption.

In the implemented testbed, the battery absorbs any residual PV power not used by the self-consumption cycle. Since experimental data were recorded with limited nightly load and limited nightly battery consumption, the battery was recharged quickly in the first phase of the experiments and this experimental pattern limited the value of LMI (∼80%). However, what matters more than the absolute value of achieved LMI (greatly affected by the ratio of PV production to battery capacity) is the evidence that the designed service classes enable the self-consumption load to follow reasonably well the daily PV power production. To highlight the maximum efficiency that the prototype can achieve when the battery is also discharged during the night, a larger battery charging process was simulated to measure the ability of the PV system to accumulate energy for night consumption. The simulation assumes that any residual PV power is stored in the battery. The maximum simulated battery charging power was capped at the measured maximum LMI to maintain a minimal amount of power returned to the grid. This is necessary to keep the voltage at the grid interface stable and avoid unwanted grid utilization. Additionally, instantaneous charging power is always limited to 3 kW by the inverter to avoid overheating the battery.

Table 4. Battery Simulation For Three Sample Days.

Day	SCR	Actual Battery Charged (Wh)	Maximum Battery Charge (Wh)
28 March 2023	68%	6526 Wh	11,793 Wh
6 April 2023	66%	6671 Wh	13,306 Wh
7 April 2023	62%	6594 Wh	11,595 Wh

illustrates the maximum battery charge (Wh) in our testbed that was equipped with a battery sufficiently large to absorb all surplus production. The simulated results show that we can achieve $LMI\sim$ 98% while satisfying the battery’s maximum charging power. This simulation was repeated to extrapolate the necessary increase in PV production in order to accumulate enough energy for a night consumption at, respectively, 5, 7.5, 10, 12.5, 15, 17.5 and 20 kWh of load.

To preserve consistency in the simulation results, it was assumed that the self-consumption load remains equal. This means that the self-consumption was kept the same independently of simulated PV power production, while it can happen that given more PV power, self-consumption would possibly be higher and only stop when DHW is fully heated up and rooms reach thermostat temperature. This change can partially offset the consumption, but keeping the self-consumption load stable allows us to focus on the PV system and isolate the impact of PV power production and battery size on the overall system performance. Finally, Figure 6 shows a scatter plot of the projected required sizing of the PV system for three test days. Notice that the required sizing is scaled from the actual production, under the assumption that self-consumption remains constant and all extra production is accumulated in a battery (that is, $LMI\sim$ 98%).

6.2. Ablation Experiments on Battery Size

Further experiments were carried out over multiple days between 12 March 2024 and 20 March 2024. On some days, the automated control system (proposed management framework) was disabled, allowing the thermostat and legacy DHW controller to manage the system. The thermostat was set at the average maintained temperature during the corresponding automation test. This provided a baseline for comparison against the fully automated system. On one day, the battery was detached, while on the other days, the battery spare capacity was set at approximately 5 kWh and 15 kWh, to assess the influence of battery capacity on system efficiency under both control regimes.

LMI and SCR for the various scenarios are shown in

Table 5. Experimental results for SCR, LMI, and battery charge.

Configuration	Battery Capacity (kWh)	SCR	LMI	Battery Charge (Wh)	Production (Wh)
Automation	15	0.45	0.89	15,287	31,480
Baseline	15	0.33	0.68	13,922	27,390
Automation	5	0.69	0.86	5780	28,630
Automation	5	0.59	0.88	6801	21,010
Baseline	5	0.52	0.62	5341	33,000
Baseline	0	0.64	0.64	59	29,590

. Given the same battery capacity, the proposed automation (run on 12, 14, 17 March) achieved higher SCR and LMI values compared to days when the baseline system was used (13, 20 March).

As observed in Table 5, on 12 March, with 15 kWh of available battery capacity, the automation achieved an SCR of 0.45 and an LMI of 0.89. Conversely, when the system was operated in baseline mode on 13 March, the SCR dropped to 0.33, and the LMI dropped to 0.68, indicating reduced efficiency.

On 14 and 17 March, the battery had a spare capacity of 5 kWh, and the automation focused on charging the battery until it reached a high state of charge. Despite the limited battery capacity, the automation achieved a significant SCR of 0.69 and an LMI of 0.86 on 14 March. Similarly, on 17 March, the system achieved an SCR of 0.59 and an LMI of 0.88, demonstrating efficient energy utilization even with reduced battery capacity. On 19 March, the battery was disconnected before starting the experiment, and the system was operated in baseline mode. While the SCR remained at 0.64, the LMI dropped to 0.64, reflecting the inefficiency of the system when running in baseline mode.

6.3. Impact of Automation on System Efficiency

Figure 7 shows the system’s behavior under different conditions, including days with automation enabled (12, 14, 17 March) and days with baseline control (13, 19, 20 March). The automation consistently demonstrated improved system performance compared to the baseline, especially in maintaining higher battery charge levels and maximizing PV self-consumption. Across all experiments, the proposed system achieved a performance (LMI) increase of over $20\%$ compared to the corresponding baseline configuration.

On days where automation was enabled, the system was able to maintain a higher state of charge for the battery, allowing for efficient use of PV energy. By comparison, on days like 13 March and 20 March, when the thermostat and legacy DHW controller were in control, the system demonstrated lower SCR and LMI values, indicating reduced efficiency in balancing PV production and consumption.

The automation also effectively adjusted charging behavior based on the battery’s state of charge. For example, on 14 March, the system prioritized battery charging until it reached a higher voltage, maintaining the battery in an optimal state for future PV energy storage.

6.4. Comparative Simulation Against Alternative Strategies

6.4.1. Design Priorities

The comparative strategies are evaluated against three priorities, listed in decreasing order of precedence: P1 Minimize grid usage (in the absence of virtual energy storage, every kWh exchanged with the grid is a financial loss); P2 Preserve inverter and battery longevity (favor smooth, sustained load activation over rapid on/off cycling that increases switching losses and cell degradation); P3 Maximize occupant comfort (subject to P1 and P2, deliver as much thermal energy as possible during PV hours). The two reference strategies bracket the proposed framework. Sequential RBC reproduces the default policy of non-integrated systems without a feedback loop: the inverter charges the battery at full rate while the thermostat-driven heat pump operates independently on the same fixed demand profile, drawing from the grid whenever battery charging has consumed the available PV. It trivially satisfies P2 (smooth, sustained charging) but sacrifices P1 (unnecessary grid exchange) and P3 (delayed heating). The Oracle Greedy maximizes P1 and P3 through predictive load redistribution, but at the expense of P2 and of requiring perfect foresight. The proposed framework targets a practical balance among all three priorities.

6.4.2. Strategies Compared

We compare the proposed framework against two reference controllers simulated on the same experimental data:

1.

Sequential RBC. Models the default behavior of a standard PV inverter: the battery is charged at maximum rate (up to the 3 kW inverter limit) before any surplus power is made available to self-consumption loads. This is the “sequential activation” pattern described in Section 1. It trivially satisfies P2 (the inverter runs in a single sustained charging mode) but sacrifices both P1 and P3 by delaying load activation and returning surplus PV energy to the grid.

2.

Oracle Greedy. An offline oracle with perfect knowledge of the day’s PV production curve that redistributes the thermal load to absorb as much surplus PV power as physically possible. At every timestep the oracle: (i) satisfies the base load demand; (ii) charges the battery from remaining PV (up to 3 kW); (iii) activates additional heat-pump heating (up to 4 kW electrical, subject to an indoor temperature ceiling of 25 °C enforced by the same thermal model of Section 6.5) and DHW resistive heating (up to 1.7 kW, cumulative energy capped at 3480 Wh corresponding to a 200 L cylinder heated from 50 to 65 °C). Because it can shift thermal demand into periods of surplus PV, the oracle represents a theoretical upper bound on self-consumption with respect to P1. Note that the oracle charges the battery greedily rather than deferring charge to high-PV periods: given the measured production profiles and the available thermal sinks (building mass and DHW cylinder), the greedy policy already absorbs all surplus at every timestep, so look-ahead battery scheduling yields no additional benefit. This greedy optimality is contingent on the PV-to-load ratio observed in our testbed; with higher PV capacity or larger batteries, the thermal sinks would saturate, and a fully predictive policy would be required to schedule battery deferral—violating P2 (frequent load switching driven by forecast updates) and risking P1 (grid draw if PV falls below forecast). Under the present conditions, however, the greedy oracle represents a tight upper bound on achievable self-consumption.

Both simulations use the same measured PV production profile and the base self-consumption load demand recorded in each experiment day. Battery capacity is set to the actual energy charged on the corresponding day. All strategies observe the 3 kW inverter charging constraint and the power balance $P_{\mathrm{PV}}=P_{\mathrm{battery}}+P_{\mathrm{loads}}+P_{\mathrm{grid},\mathrm{out}}$ at every five-minute timestep.

Table 6. Comparative simulation of three control strategies on the automation-experiment days. Spare and Grid columns are in Wh. The Proposed column reflects the actual measured data recorded while the framework was active; baseline days are excluded because the proposed control policy was not running. The Oracle redistributes thermal load to absorb surplus PV power (Section 6.4), hence its higher SCR.

		Sequential RBC				Proposed			Oracle Greedy
Day	Batt.	SCR	LMI	Grid	Spare	SCR	LMI	Spare	SCR	LMI	Spare
	(kWh)			(Wh)	(Wh)			(Wh)			(Wh)
12 Mar	15	0.39	0.78	1756	3435	0.45	0.89	1678	0.50	1.00	0
14 Mar	5	0.56	0.70	3638	6634	0.69	0.86	2996	0.79	1.00	0
17 Mar	5	0.43	0.64	3253	4827	0.59	0.88	1579	0.66	1.00	0
Avg.		0.46	0.71	2882	4965	0.57	0.88	2084	0.65	1.00	0

reports SCR, LMI, daily energy drawn from the grid (Grid), and daily surplus PV energy returned to the grid (Spare) for each strategy across the three automation-experiment days.

Two findings emerge from Table 6:

• Proposed vs. Sequential RBC. The concurrent-activation strategy raises SCR by 24% and LMI by 24% on average. The proposed framework achieves zero PV-window grid draw, whereas Sequential RBC forces an average of 2.9 kWh/day from the grid because battery-first charging starves the self-consumption loads during early PV hours, confirming the inefficiency highlighted in Section 1. Sequential RBC also returns more than twice as much surplus PV energy to the grid (5.0 vs. 2.1 kWh/day).
• Proposed vs. Oracle Greedy. The oracle achieves LMI = 1.00 and SCR = 0.65 on average by redistributing thermal demand into periods of surplus PV power; the proposed framework reaches SCR = 0.57 and LMI = 0.88. The gap (SCR + 14%, LMI + 14%) quantifies the additional self-consumption attainable through predictive load shifting—at the cost of requiring a full thermal model, perfect PV forecasts, and MPC-level optimization complexity. Moreover, such a policy ignores inverter activation and deactivation transients that prevent rapid load switching in practice, and disregards the long-term effects of frequent cycling on heat-pump compressor wear and battery cell degradation. Closing this gap with data-driven extensions to the current rule set, while respecting these hardware constraints, is an explicit target for future work.

Table 7. Qualitative comparison of the proposed framework against alternative control paradigms. Proposed system in bold.

	MPC	DRL	Vendor RBC	Proposed
Deployment cost	High	Medium	Low	Low
Computational overhead	High	High (training)	Negligible	Negligible
Transparency	Medium	Low	High	High
Multi-vendor compat.	Low	Low	None	High
Per-building modeling	Required	Required (training)	None	None
Comfort-aware QoS	Yes	Possible	No	Yes
Optimality guarantee	Theoretical	Asymptotic	None	88% of oracle LMI *
* See Table 6; closing the gap requires predictive load shifting.

positions the proposed framework against the main control paradigms discussed in Section 2, highlighting the parameters that each approach optimizes or sacrifices.

6.5. Thermal Comfort Implications

Having established the proposed framework’s P1 performance (88% of oracle LMI) and P2 compliance (smooth, threshold-based switching), we now evaluate P3: the impact on occupant thermal comfort. Because the three control strategies allocate different amounts of PV power to the heat-pump-driven self-consumption loads during the PV production window, they produce different indoor temperature trajectories and, consequently, different levels of occupant comfort. To quantify this effect, we apply a first-order lumped-capacitance thermal model of the testbed building (a two-storey masonry house in Northern Italy) and evaluate the resulting temperature profiles against the EN 16798-1 standard [26].

6.5.1. Thermal Model

The building is modeled as a single thermal zone with parameters derived from the Italian energy code (DM 26/06/2015, climate zone D) and standard construction practice for partially retrofitted masonry buildings:

• Total heat-loss coefficient $UA=295$ W/K (envelope 221 W/K including thermal bridges + ventilation 73 W/K at 0.5 ACH).
• Effective thermal mass $C=$ 13,000 Wh/K, giving a time constant $\tau =C/UA\approx 44$ h.
• Heat-pump COP $=3.0$ for space heating at a supply temperature of 35 °C.
• Approximately 40% of total self-consumed PV energy drives the heat pump for space heating; the remainder serves DHW (resistive element, COP $=1$) and other loads.
• Passive solar gains through ≈20 m² of glazing (peak ≈ 1200 W at noon on the south-facing facade) and internal gains of 350 W.
• Outdoor temperature follows a sinusoidal diurnal profile with a mean of 11 °C and amplitude 3.5 °C, representative of mid-March conditions in coastal Northern Italy.

At each five-minute timestep, the indoor temperature is updated as

$$T_{t+1}=T_t+{\displaystyle \frac{\left(Q_{\mathrm{heat}}+Q_{\mathrm{solar}}+Q_{\mathrm{int}}-UA(T_t-T_{\mathrm{out}})\right)\mathrm{\Delta }t}{C}},$$

(3)

where $Q_{\mathrm{heat}}=P_{self-consumed}\times 0.4\times \mathrm{COP}$ is the heat delivered to the zone. The initial temperature at midnight is calibrated so that the simulated profile matches the earliest available room-temperature measurement (typically at $07:00$).

For days where measured upper-floor temperatures are available, the model achieves an RMSE of 0.2–0.3 °C, which is adequate for a comparative assessment.

6.5.2. Comfort Evaluation

We assess comfort during occupied hours (07:00–22:00) against EN 16798-1 Category II (20–25 °C operative temperature, recommended for new and renovated residential buildings) and Category III (18–25 °C, acceptable for existing buildings). In addition to the percentage of occupied time within each comfort band, we report the cumulative degree-hours of discomfort (DH), defined as $\sum max(20-T_t,0)\mathrm{\Delta }t$, which penalizes both the duration and severity of under-heating.

Table 8. Simulated thermal comfort for the three control strategies. $\overline{T}$ and $T_{min}$ are the average and minimum occupied-period temperatures, Cat. II% and Cat. III% the fraction of occupied hours (07:00–22:00) within the EN 16798-1 20–25 °C and 18–25 °C bands, respectively, and DH the degree-hours of discomfort below 20 °C.

		Sequential RBC					Proposed					Oracle Greedy
Day	Batt.	$\overline{T}$	$T_{\min }$	II	III	DH	$\overline{T}$	$T_{\min }$	II	III	DH	$\overline{T}$	$T_{\min }$	II	III	DH
12 Mar	15	18.5	17.9	0%	87%	22.3	18.6	18.0	0%	91%	20.8	18.7	18.0	0%	94%	19.4
14 Mar	5	19.9	19.2	44%	100%	3.8	20.1	19.4	58%	100%	2.4	20.3	19.4	65%	100%	2.3
17 Mar	5	19.2	18.9	0%	100%	11.8	19.4	18.9	0%	100%	9.7	19.5	18.9	8%	100%	7.6
Avg.		19.2	18.7	15%	96%	12.6	19.4	18.8	19%	97%	11.0	19.5	18.8	24%	98%	9.8

summarizes the results.

Two observations emerge:

• The proposed framework raises the average occupied-period temperature by 0.2 °C and increases Category II compliance from 15% to 19% compared to Sequential RBC. Degree-hours of discomfort decrease by 13% ($12.6\to 11.0$ DH). The Oracle Greedy strategy extends this trend further, reaching 24% Category II and 9.8 DH by redirecting all surplus PV power into space heating and DHW. The modest Category II percentages reflect the substantial thermal losses of the two-storey masonry envelope ($UA=295$ W/K); nevertheless, Category III compliance (18–25 °C) remains above 96% for all three strategies, confirming that the building stays within acceptable limits for existing residential stock.
• On 14 March, the proposed framework achieves 58% Category II compliance; the Oracle reaches 65%, confirming that both concurrent and predictive load activation deliver meaningful comfort benefits alongside self-consumption gains.

These results show that the concurrent activation of self-consumption loads, besides improving P1 (self-consumption) and P2 (smooth operation), also delivers measurable gains on P3 (comfort). Sequential battery-first control delays the delivery of heat to the building, causing longer under-heating periods in the morning and early afternoon. The oracle demonstrates that further self-consumption gains are physically achievable through predictive load shifting, but at the cost of requiring a thermal model and PV forecasting—complexity that the proposed framework deliberately avoids. By contrast, a conventional thermostat-driven system could, in principle, maintain constant comfort by freely drawing from the grid, but at the expense of P1 (high grid usage) and P2 (frequent inverter cycling between grid-import and PV-export modes). The proposed framework demonstrates that these three objectives need not conflict: voltage-based concurrent activation captures 88% of the oracle’s load-matching performance while simultaneously improving thermal comfort relative to the sequential baseline.

6.6. Discussion

The presented results demonstrate the successful operation of the proposed management framework. The close alignment of PV production and self-consumption ensures that the generated power is utilized effectively. The high values of LMI indicate a good match between the produced and consumed energy, leading to a reduced reliance on the grid and improved overall efficiency of the PV system.

Moreover, the ablation experiments on battery sizes (Section 6) clearly highlight the role of storage capacity in self-consumption performance. Reducing the battery’s usable capacity from 15 kWh to 5 kWh allowed us to investigate how the system copes with limited storage. Even with less available capacity, the proposed automation outperformed the baseline approach by maintaining higher levels of SCR and LMI. This highlights the adaptability of the rule-based framework: although a larger battery provides more room for energy shifting and higher overall autonomy, the automated control strategy still demonstrates tangible improvements with a smaller battery.

These experiments also underscore the trade-off between capital investment in battery capacity and gains in self-consumption. While a larger battery may yield higher LMI and enable smoother load matching, it increases upfront costs and requires more physical space. By showing that our automation achieves a 20% or greater improvement over baseline even with modest storage, we offer a cost-effective path for existing buildings that cannot justify an expensive battery setup. Such incremental upgrades—where partial battery capacity is retrofitted alongside rule-based automation—can still deliver significant reductions in peak grid usage and overall electricity bills.

6.6.1. Theoretical Implications

The results expand the applicability of rule-based control (RBC) in PV retrofitting by demonstrating that a priority-ordered service-class abstraction captures 88% of the load-matching performance of an omniscient oracle (LMI 0.88 vs. 1.00) without model identification, PV forecasting, or computationally expensive optimization. The remaining 12% gap is attributable to predictive thermal load shifting—redistributing heat-pump and DHW demand into periods of surplus PV power—which requires a full building thermal model and perfect foresight. This quantification establishes a clear target for future data-driven extensions. The concurrent activation pattern—coordinating battery charging and self-consumption loads via a single voltage threshold—constitutes a general design primitive that is transferable to other Distributed Energy Resource (DER) coordination problems. Furthermore, the thermal comfort evaluation (Section 6.5) formalizes the link between control strategy and occupant well-being, integrating EN 16798-1 comfort bands as a QoS metric within a rule-based framework.

6.6.2. Practical Implications

For homeowners and installers, the framework offers a cost-effective retrofit path: the entire IoT automation layer costs approximately EUR 250 (Section 5) and requires no vendor cooperation or firmware modifications. The ablation experiments confirm that meaningful self-consumption gains (≥20% improvement over baseline) are achievable even with modest 5 kWh storage, lowering the capital barrier for adoption. The observed MTBF of several weeks to months is adequate for residential deployment, though improving software reliability remains an engineering priority (Section 7).

6.6.3. Safety and Security

Safety and security are addressed at both the design and implementation levels. At the design level, the combined maximum power of all automated loads is capped at 5.7 kW, and the heat pump compressor is limited to 4 kW, preventing overload of the electrical installation. The battery management system (BMS) embedded in the inverter independently enforces over-charge and over-discharge limits, so the automation framework cannot damage the storage subsystem. At the implementation level, the IoT controller operates exclusively on the local network; sensor readings (voltage, temperature, power) are physical signals that cannot be spoofed remotely. A local Home Assistant instance provides an additional control path that remains operational during Internet outages. Section 5 provides further details on watchdog timers, fault recovery, and network security measures.

6.6.4. Economic Considerations

The automation layer (Shelly IoT devices, relays, sensors) costs approximately EUR 250, while the PV panels, inverter, batteries, and heat pump are assumed to be pre-existing equipment. During the experimental period, the automated system consumed less than 0.5 kWh/day from the grid, compared to an estimated 3–5 kWh/day under baseline (thermostat plus legacy DHW) operation. At the 2024 Italian residential electricity tariff of approximately EUR 0.25/kWh, the daily saving is EUR 0.6–EUR 1.1. Over an eight-month heating season (≈240 days), the cumulative saving of EUR 150–EUR 260 implies a payback period of one to two heating seasons for the IoT hardware investment. The annual energy balance of the testbed (Table 3) confirms a grid draw of 2322 kWh/yr (11.6 kWh/m² yr), an annual self-consumption rate of 81.4%, and a near-unity PV-to-load ratio, indicating that the system sizing is well-matched to the building’s needs. A full economic analysis across different building types and climates is beyond the scope of a single-testbed study and is left as future work.

The proposed management framework is rule-based and specifically designed for retrofitting existing systems (seen as “black-box”) with limited or no support for modern smart building features such as real-time monitoring of inverter parameters and smart grid functions for automatic load balancing. The activation of the described service classes is subject to the daily production of the PV system, with the goal of maximizing self-consumption under a zero-carbon footprint principle. For user comfort, we plan to extend the framework with user localization capabilities, allowing it to optimize comfort for current occupants or automatically limit the building to solar-only operations when users are away. Finally, as future work, we aim to integrate learning algorithms that predict PV production and user comfort preferences on daily or weekly timescales, thereby refining the self-consumption policy in a data-driven manner.

7. Conclusions

In this paper, we presented a management framework for optimizing the integration of photovoltaic (PV) systems with self-consumption loads in residential buildings. The proposed approach demonstrated effective coordination among batteries, heat pumps, and other loads, achieving a close alignment between PV production and consumption. Experimental results showed a high load matching index (LMI), indicating efficient utilization of generated power, reduced reliance on the grid, and improved overall energy performance of the PV system.

Additionally, ablation experiments on battery sizes revealed that even with reduced storage capacity, the automation strategy outperforms a baseline system. While a larger battery can naturally support higher autonomy and smoother peak shifting, our rule-based control still yields substantial improvements in self-consumption and load matching for more modest battery capacities.

A key advantage of this solution is its minimal intrusiveness when retrofitting heterogeneous multi-vendor systems. Rather than requiring custom firmware or proprietary communication protocols, it leverages off-the-shelf IoT sensors and actuators to coordinate legacy equipment that was never intended for integrated control. As a result, building owners can cost-effectively upgrade existing infrastructures without performing major hardware overhauls.

The simulation and sizing estimations further highlight the potential of the framework for balancing PV installation costs, battery sizing, and reliance on the grid. Nevertheless, additional long-term data collected year-round are needed to better capture seasonal variations in load behavior and weather conditions. Such comprehensive datasets would enable robust statistical models of consumption patterns and more precise assessments of the impact of different battery sizes on nighttime autonomy and annual self-consumption rates. Gathering data from multiple, geographically distributed installations would also yield more generalized guidelines for system sizing.

Limitations and Applicability Boundaries. The following constraints should be considered when interpreting the results: Seasonal and geographic scope. The experiments were conducted in mid-March in Northern Italy (climate zone D, heating-dominated). Summer operation was not investigated since PV power generation is at its peak during that season and residential energy demand is trivially met during most of the days. In higher-latitude regions with shorter winter PV windows, achievable self-consumption will be lower; conversely, locations with higher annual irradiance may benefit even more. Single testbed. All results derive from a single 200 m² residential building. Generalizing to different building typologies (apartments, commercial premises, poorly insulated stock) requires additional deployments. Safety and fault tolerance. The heat pump retains its own thermal protection limits and the battery management system (BMS) of the inverter independently prevents over-charge and over-discharge. The IoT actuators (Shelly relays) maintain their last state on controller failure or network outage rather than reverting to a safe default; a local Home Assistant instance mitigates this by providing a secondary control path, but systematic fault-injection testing has not been performed. The current MTBF (weeks to months) indicates room for improvement in software reliability.

Looking ahead, we plan to design a verification tool for the IoT management framework so that, in the long term, the proposed framework can be used as a verified control firmware and integrated with data-driven extensions to the current rule-based logic, incorporating factors such as weather forecasts, seasonal occupancy, and user comfort preferences. We aim to integrate electric vehicle (EV) charging policies into the same framework, allowing for further load coordination and peak shaving. Finally, we intend to investigate security and fault-tolerance concerns associated with IoT-based automation, ensuring that large-scale deployments maintain the reliability and safety required for modern energy ecosystems.