The Architecture for Testing Central Heating Control Algorithms with Feedback from Wireless Temperature Sensors

Abstract

The energy consumption of buildings is a significant contributor to overall energy consumption in developed countries. Therefore, there is great demand for intelligent buildings in which energy consumption is optimized. Online control is a crucial aspect of such optimization. The implementation of modern algorithms that take advantage of developments in information technology, artificial intelligence, machine learning, sensors, and the Internet of Things (IoT) is used in this context. In this paper, an architecture for testing central heating control algorithms as well as the control algorithms of the heating system of the building is presented. In particular, evaluation metrics, the method for seamless integration, and the mechanism for real-time performance monitoring and control are put forward. The proposed tools have been successfully tested in a residential building, and the conducted tests confirmed the efficiency of the proposed solution.

1. Introduction

Heating, ventilation, and air conditioning (HVAC) systems are responsible for thermal comfort and air quality. In the European Union, buildings consume around 40% of total energy [1,2]. The member states must ensure that new buildings, and also some existing buildings, will meet certain energy requirements [3]. This is one of the reasons for switching to renewable energy sources [4] and for the development of clean energy generation [5]. Moreover, rising energy prices and global discussions regarding the state of the environment are driving more interest in adapting central heating control systems in residential and office buildings to improve energy efficiency while maintaining the thermal comfort of their occupants. This modernization usually requires the replacement of actuators, sensors, and the local controller (the latter with one that has extended features and capabilities). Observation that every closed loop control system—including central heating systems—has a feedback mechanism led us to the conclusion that this can be exploited to pass some additional information to the existing control system, with minimum modifications. Improved control algorithms can be executed on a separate computing unit, exchanging only corrections of the parameters computed by a legacy local controller. This modular approach reduces the cost of the installation and also simplifies the evaluation of the modified system performance. Comparing the updated system with the legacy one involves turning off corrections provided by optimization algorithms. New algorithms, requiring more computing capabilities, access to external services like a weather forecast, and the capability to retrieve information from wireless temperature sensors installed in a building, can be further improved with the developments in information technology, artificial intelligence, and machine learning.

There are many challenges regarding the architecture of a test environment for the evaluation of various HVAC control algorithms [6,7] that go beyond computer simulation [8,9]. Despite the fact that full repeatability can be provided only in simulations, at this moment they cannot totally mimic the behavior of a physical building. On the other hand, executing various HVAC control algorithms in the real world requires a way to ensure the comparability of the algorithms’ performance. External environmental factors (insolation, outdoor temperature, etc.) as well as the thermal comfort of inhabitants and changes in the hydraulic and automation subsystems may influence the results. Local (low-level) HVAC controllers deployed in the field might be managed by a high-level (remote) controller or building management system (BMS). It is a challenge to embed sophisticated control algorithms into local HVAC controllers [10]. Our contribution will show experimentally how to seamlessly enhance legacy heating control systems with optimization algorithms and will provide metrics to evaluate their performance.

The article is organized as follows: In Section 2, we present a literature review regarding HVAC automatic control algorithms in both the context of the Internet of Things and maintaining thermal comfort. Section 3 contains a description of the equipment used in the case study and a description of the heating control system of the building where the tests were performed. In Section 4, we present the control hierarchy and metrics used for performance evaluation. In Section 5, we show the results of our experiments, followed by a discussion in Section 6. In Section 7, we conclude our work.

2. Literature Review

In the literature, many control methods have been proposed and developed for HVAC systems. These methods can be divided into classical control, hard control, soft control, hybrid control, and other control techniques. Details of these methods are compared and discussed in [11,12]. These methods can also be divided into traditional, advanced, and intelligent [12]. In [13,14], an overview of the advanced control strategies for HVAC is presented. A comprehensive review discussing computational intelligence techniques for HVAC systems is presented in [2]. It is worth mentioning that classical control methods, including on–off (bang-bang) and proportional–integral–derivative (PID), are still used in many HVAC systems because of their simplicity and low cost [11,12].

Nowadays, the concept of the Internet of Things is often used to improve control of HVAC systems. The term Internet of Things was first proposed by Kevin Ashton in [15] as a network of physical objects embedded with electronics, circuits, software, sensors, and network connectivity that enables these objects to collect and exchange data. This has found many applications in the control of the state of systems for which the state is dependent on many variables [16]. One of the applications of IoT is the identification of human thermal comfort, which can be approximated by the Predicted Mean Vote [17]. Environmental variables (temperature, air velocity, and relative humidity) are measured by sensors (within a greater system) that are able to determine what thermal sensations a person experiences. The calculated indicator can be used to automatically control air conditioning. This system can improve comfort and reduce the energy consumption at the same time [7].

While the Predictive Mean Vote approach relies on an aggregated comfort model, other models consider distinct preferences between unique individuals [18]. Data collected by a set of sensors, occupants’ feedback from wearables, an online survey that gathered occupant-related information about age, gender, and clothing level, allows for the development of personal comfort models. Personalized thermal comfort models are able to capture the distinct preferences of each individual to enable a better understanding of the specific comfort requirements inside a building. Occupant behavior, especially interactions with building systems like HVAC, impact the building energy performance [19]. Wireless technologies like Wi-Fi or Bluetooth, image recognition, sound detection, passive infrared detection systems, and sensor fusion might capture behavior patterns and provide information about thermal-zone-level occupant localization. Occupancy-based HVAC control strategies can be classified as either user-defined schedules or occupancy-based mechanisms. In the former, occupants use manual or programmable thermostats or other means of scheduled control. In the latter, occupancy detection and monitoring systems provide input to reactive or predictive control, which can either be defined by a set of rules or driven by optimal control algorithms [20,21]. Control algorithms can be divided into [22]: local control, responsible for adjusting actuators of the system according to the predefined set points (e.g., on-off, PID), and high-level control, where an additional layer of control determines set points of the local control (e.g., predictive control, machine learning, and other artificial intelligence algorithms). Development of IoT data-driven closed-loop control systems in residential buildings faces many challenges related to data acquisition, transfer, storage, aggregation, and processing to deliver useful information for an HVAC system [10].

In [23], metrics and examples of testing environments for HVAC systems are presented. In laboratory conditions, it is possible to simulate the test environment using an electrical circuit composed of resistors and capacitors, which corresponds to the resistance and heat capacity of elements of a room (mainly air and walls) [24]. In such a model, the change of natural conditions can be reproduced on demand. It means that the unpredictability of environmental conditions can be emulated and recreated when needed. The impact of weather changes and the human factor led to the invention of the feed-forward method, which changes its state based on prediction disturbances [25].

In [26], an IoT system was adopted to monitor an HVAC system for a Smart Factory. The system was based on temperature and humidity sensors and the energy meter of the air conditioning. However, Wi-Fi communication ruled out the use of battery power supply for sensors and therefore significantly limited the ability to collect data from multiple rooms with a single access point.

In [27], the architecture of a real-time control system for heating energy management is described, which combines a field-programmable gate array (FPGA) controller and a cloud backend. In [28], a central heating system with feedback from temperature measurements is described. In this paper, we propose a similar solution to one of the aforementioned examples that takes into account data from several sensors and is suitable for larger buildings, such as multi-family buildings, hotels, schools, offices, etc.

To simplify the evaluation of an HVAC system, some authors [6] limit measurements to a single room. This minimizes the number of controlled HVAC devices and allows for easily repeatable conditions. Some researchers assert that indoor changes are cyclical and that only user experience feedback should be used to determine the performance of the tested control strategy. If the satisfaction level is unchanged, the energy consumed by the HVAC equipment is used as a metric for evaluation [29]. When people feel discomfort, they override automatic settings and the energy consumption of the HVAC system increases. The satisfaction level could be related to the level of thermal discomfort. It is equal to zero if the temperature is within the limits, but out of the limits its value is equal to the quadratic function of temperature deviations. In the same article, the authors emphasize the importance of considering the relation to the outdoor temperature. The heating degree days (HDD) metric can be used for that purpose [30], optionally in combination with metered energy use [31]. Using only HDD is not sufficient to estimate user comfort [32]. However, it is very useful in combination with information of the energy consumed by an HVAC system and information about indoor temperature. Other performance criteria might be used as optimization goals in different HVAC control strategies, including energy consumption, thermal comfort, HVAC runtime, fossil fuel consumption, peak, cost, and CO₂ emission [20].

3. Materials and Methods

The high-level design of the proposed architecture involves modification of a computer program run by a local heating controller. The modification involves adjusting the set point of central heating hot water temperature. It can be achieved by either running an optimization sub-procedure on a local low-level controller or with a remote procedure call—for sophisticated algorithms, using data sources such as temperature measurements inside thermal zones or weather forecast services. In this section, we explain in detail how the proposed architecture is applied to a study building to demonstrate its feasibility.

3.1. Integration with the Legacy Heating Control System

To verify the robustness of the proposed solution, we implemented it in a multi-family building located in Warsaw, Poland. The legacy control system schematic is shown in Figure 1. The system has central heating (CH) and domestic hot water (DHW) circuits. The output temperature (measured at TCR/08) of the CH circuit is managed by a PID controller acting on a TVR/04 valve. The output temperature (measured at TCR/020) of the DHW circuit is managed by another PID controller acting on a TVR/05 valve. Both tasks are performed by a local controller: Honeywell Excel Web Ethernet-based, freely-programmable building automation controller. The local controller was configured to automatically connect to a Message Queuing Telemetry Transport (MQTT, ISO/IEC 20922 [33]) broker and to subscribe to a topic where the data coming from optimization algorithms is published. The publisher is a computer program running on the edge router presented in Section 3.4. It aggregates the data received from wireless temperature sensors described in the next subsection. The hardware on which it is running is a custom built extension board for Raspberry Pi Compute Module, with Ethernet interface and LoRa radio interface. The interior of the control room, where the local controller and the edge router were installed, as well as all the hydraulics and controls, are shown in Figure 2.

The local controller has access to the following data sources shown in Figure 1:

TCR07 

Outdoor temperature sensor

TCR13 

Temperature of water returning from the central heating heat exchanger

TCR08 

Temperature of central heating circuit supply water

TCR09 

Temperature of central heating circuit return water

TCR011 

Temperature of supply water from heat plant

TCR013 

Temperature of return water to heat plant

TCR016 

Inlet temperature of domestic hot water after mixing with recirculation line

TCR017 

Temperature of domestic hot water recirculation system

TCR015 

Temperature of tap water flowing into the domestic hot water circuit

TCR020 

Domestic hot water heat exchanger outlet temperature

TCR021 

Temperature of supply domestic hot water

PCR01 

Central heating system pressure

PCR02 

Domestic hot water system pressure

PTR01 

Pressure of supply water from heat plant

PTR02 

Pressure of return water to heat plant

QFR06 

Heat consumed by central heating and domestic hot water

QFR022 

Heat consumed by central heating

FCR017 

Domestic hot water flow meter

FFR01 

Supply water injected into heating circuit water meter

FFR06 

Heat plant return water flow meter

FFR03 

Domestic hot water circulation water meter

FFR022 

Heat plant return water flow meter for central heating circuit

The local controller controls the following elements shown in Figure 1:

NC018 

Speed of the domestic hot water recirculation pump

FR010 

Speed of the central heating circulation pump

PVR03 

Valve controlling pressure difference between supply and return water

TVR04 

Valve controlling the central heating heat exchanger circuit

TVR05 

Valve controlling the domestic hot water heat exchanger

TVR06 

Valve controlling supply water injection into heating circuit

3.2. Process Monitoring

To monitor the behavior of the system, a virtual 3D representation was created. The model has been built in a way that reflects the physical appearance and layout of the equipment in the control room, as shown in Figure 3. Thanks to that, it is relatively easy to read. Every element of the system is represented by a miniature 3D model with an associated label showing its present value. For example, the variable speed pumps are shown as animated fans with speed indicators providing information about their revolutions per minute. All the data are provided in real time by the local controller using the MQTT protocol. The visualization was built with a Unity game engine and compiled with Web Graphics Library (WebGL), so it can be accessed via any modern web browser. It is possible to use a virtual reality set to explore the virtual control room and to inspect all sensors. In case of abnormal operation, a visual notification is shown so a technician can intervene and fix the potential issue.

3.3. Indoor Temperature Measurements

The legacy system lacked equipment to measure indoor temperature in thermal zones. We wanted optimization algorithms to make use of this information, so we installed wireless temperature sensors. The reason for wanting this was that apart from changes in outdoor temperature, insolation, wind speed and direction, humidity, etc., disturbances in heat flux may also be caused by other, less obvious sources, including [34]:

• Temperature of hot water supplied from district heating;
• Temperature of water supplied from renewable energy systems;
• Inhabitants’ heat (60–80 W of heat power per person);
• Power dissipation from electrical receivers installed in the building.

Disturbances in heat flux can be tracked by measuring the amount of heat transferred to the building. This approach is used in the legacy installation described in this case study. Additional information can be collected by temperature sensors placed in different heat zones inside the building. This gives quick and precise information regarding places where the temperature is changing. The optimization algorithms gain access to new data sources which respond quicker to disturbances in heat flux. With additional information from a weather forecast service, it opens new possibilities for heating-energy optimization algorithms.

3.4. Wireless Temperature Sensors

To track temperature changes, we used custom-built wireless temperature sensors installed in selected places inside the building. Each sensor has the following subsystems [35]: sensing (temperature measurement), computing (data processing), communication (long-range radio communication), and power (providing system supply voltage). Temperature is measured by a Sensirion temperature sensor [36] which digitalizes readouts and transmits them using an Inter-Integrated Circuit (I²C) interface to a microcontroller. The selected microcontroller responsible for data processing belongs to the STM32L1 family of ultra-low-power System-On-Chips (SOC), which has the following features [37]:

• Ultra-low-power 32-bit Arm-based Cortex-M0+;
• 10 KB RAM, 32 KB Flash, 4 KB of data EEPROM;
• $-40$ °C to $85$ °C operating temperature range;
• Supply current 1.2 $\mathsf{\mu }$A in stop mode with a real-time clock;
• 1.65 V to 3.6 V supply voltage;
• USB peripheral communication interface.

Communication is provided by a long-range (LoRa) radio module from Semtech [38] that operates in the 433 MHz band. The device is powered by a lithium battery. The detailed documentation of the devices, including schematics, PCBs, and source codes, is described in [39]. Several versions of the devices have been constructed and tested before installation in the building—one of them is shown in Figure 4.

The effort related to design and implementation of dedicated temperature sensors was justified by the ease of configuration of measurement intervals, full control over encryption mechanisms securing data transmission, and flexibility in adjusting radio transmission power.

3.5. Temperature Information Collection

Temperature data from wireless sensors are wirelessly transmitted to the edge router using LoRa radio. We installed nine wireless sensors in the selected building. We were able to use only a single edge router due to an excellent radio link budget offered by LoRa radio working in the 433 MHz band. The edge router transmits the data to a Message Queuing Telemetry Transport (MQTT, ISO/IEC 20922) broker. The communication may be optionally encrypted by transport layer security (TLS). The data are then retrieved by a web application written in C# that stores them in a relational database, provides an application programming interface (API) to retrieve historical data, and provides a graphical user interface to read current values. The optimization algorithm described in the next part of this paper also receives the most up-to-date data from the MQTT broker to process it. The information flow is shown in Figure 5.

Any resident of a flat in which a sensor was installed could freely access the readouts by scanning a quick-response code (QR code) placed on the cover of the device. A list containing information about all installed sensors was also available via a web browser. Both screens are shown in Figure 6.

4. Methodology

4.1. Control Hierarchy

We designed a two-layer algorithm for heating energy control inside a residential building. The topology of the proposed solution is shown in Figure 7. The basic control algorithm remains almost unchanged. It is executed on a Honeywell Excel Web Ethernet-based programmable building automation controller. It takes information from the outdoor temperature sensor, and using PID algorithms, controls appropriate valves in the building control room. The local controller is connected via MQTT protocol with the edge router (which publishes adjustments to the desired temperature of central heating circuit supply water (TCR/08)) computed by the local controller. In other words, the CH temperature set point computed by the algorithms executed on the legacy hardware is changed according to the value computed by the optimization layer, which also has access to measurements from wireless temperature sensors installed in the building and a weather forecast service.

4.2. Metric

To evaluate the performance of optimization algorithms, we measured the energy consumed by the central heating (CH) installation adjusted with outside temperature. For normalization, a degree days metric—the integral of a function of time that varies with outdoor temperature [40]—can be used (more specifically, heating degree day (HDD), which is designed to quantify the demand for energy required to heat a building [41]). In this study, we use more fine-grained metrics that make use of outdoor temperature measured every hour instead of a daily average. All temperature measurements were made by TCR/07 outdoor temperature sensors. Central heating energy consumption was measured by QFR022 energy meter. Having these values meant we were able to make a measurement and verification (M&V) report [42]. The main advantage of M&V is that it isolates the energy effect after modernization, which is often disturbed by other processes occurring in the facility.

We used the following equation to quantify CH energy consumption:

$$E_1\left({\left\{t_i\right\}}_{i=1}^n\right)=\frac{{\sum }_{i=1}^{n}Q\left(t_i\right)}{{\sum }_{i=1}^{n}T\left(t_i\right)}$$

(1)

where ${\left\{t_i\right\}}_{i=1}^n$ denotes sequence of length n when the measurements took place. In other words, every element of this sequence is the time of measurement. $Q\left(t\right)$ is heating power used by CH installation at time t. $T\left(t\right)$ is defined as follows, similarly to definitions in [40,41]:

$$T\left(t\right)=\left\{\begin{array}{cc}0\hfill & \mathrm{for}\mathrm{temperature}x\mathrm{in}°\mathrm{C}\mathrm{at}\mathrm{time}t\mathrm{such}\mathrm{as}x>18 °\mathrm{C}\hfill \\ 18-x\hfill & \mathrm{for}\mathrm{temperature}x\mathrm{in}°\mathrm{C}\mathrm{at}\mathrm{time}t\mathrm{such}\mathrm{as}\mathrm{x}\le 18 °\mathrm{C}\hfill \end{array}\right.$$

The metric defined by (1) quantifies the ratio of total energy consumption during a specific period to the difference between the temperature outside and 18 $°\mathrm{C}$ (for all hours when the temperature was lower than 18 $°\mathrm{C}$), summed over the same time period. A lower value of the metric means more effective usage of the thermal energy. The reference temperature of 18 $°\mathrm{C}$ is the base temperature for European countries [43,44,45]. As a secondary metric, we used the following equation to quantify thermal discomfort related to underheating:

$$E_2\left({\left\{t_i\right\}}_{i=1}^n\right)=\frac{1}{n}\sum _{i=1}^{n}D\left(t_i\right)$$

(2)

where ${\left\{t_i\right\}}_{i=1}^n$ denotes sequence of length n when the measurements took place. In other words, every element of this sequence is the time of measurement. $D\left(t\right)$ is thermal discomfort at time t. $D\left(t\right)$ is defined as follows, similarly to the definition in [29]:

$$D\left(t\right)=\left\{\begin{array}{cc}0\hfill & \mathrm{for}\mathrm{temperature}x\mathrm{in}°\mathrm{C}\mathrm{at}\mathrm{time}t\mathrm{such}\mathrm{as}x>21 °\mathrm{C}\hfill \\ {(21-x)}^2\hfill & \mathrm{for}\mathrm{temperature}x\mathrm{in}°\mathrm{C}\mathrm{at}\mathrm{time}t\mathrm{such}\mathrm{as}x\le 21 °\mathrm{C}\hfill \end{array}\right.$$

The reference temperature of 21 $°\mathrm{C}$ is the recommended indoor temperature in living spaces of a residential building [40]. As a tertiary metric, we used the following equation to quantify overheating:

$$E_3\left({\left\{t_i\right\}}_{i=1}^n\right)=\frac{1}{n}\sum _{i=1}^{n}O\left(t_i\right)$$

(3)

where ${\left\{t_i\right\}}_{i=1}^n$ denotes sequence of length n when the measurements took place, providing that on the day of the measurement the outdoor temperature was less than 21 $°\mathrm{C}$. In other words, every element of this sequence is the time of measurement. $O\left(t\right)$ is overheating at time t. $O\left(t\right)$ is defined as follows:

$$O\left(t\right)=\left\{\begin{array}{cc}x-21\hfill & \mathrm{for}\mathrm{temperature}x\mathrm{in}°\mathrm{C}\mathrm{at}\mathrm{time}t\mathrm{such}\mathrm{as}x>21 °\mathrm{C}\hfill \\ 0\hfill & \mathrm{for}\mathrm{temperature}x\mathrm{in}°\mathrm{C}\mathrm{at}\mathrm{time}t\mathrm{such}\mathrm{as}x\le 21 °\mathrm{C}\hfill \end{array}\right.$$

The reference temperature of 21 $°\mathrm{C}$ is the recommended indoor temperature in living spaces of a residential building [40]. When the HVAC system causes the indoor temperature to exceed this threshold, it means that it works ineffectively.

4.3. Measurements

The measurements were made from April, 2021 to May, 2022. The data are publicly available in a form of comma-separated values (CSV) files [46]. We used R environment for statistical computing [47] to create a M&V report and calculate energy efficiency (1), as well as underheating (2) and overheating (3) indices for different optimization algorithms.

The control loop of the legacy local controller is presented in a simplified form as Algorithm 1. In an infinite loop, the outdoor temperature and the temperature of central heating circuit supply water are used to derive the set point of central heating circuit supply water (line 3). In the legacy system, it is immediately followed by the execution of control logic code responsible for setting valves and pumps in order to reach that set point (as shown in line 5). However, in the proposed solution, before execution, the value of the set point could be modified by a selected optimization algorithm (in line 4). From the software engineering point of view, it resembles a Strategy behavioral design pattern [48]. It simplifies the definition of a family of algorithms and makes them interchangeable. This way, the complexity and details of the optimization function are separated from the legacy system.

The performance of the new implementation was tested with different optimization algorithms, e.g., the function call in line 4 of Algorithm 1 was referring to various algorithms that were altering the set point of TCR08.

Algorithm 1 Central heating control loop

$\begin{array}{cc}\mathbf{Input}\mathbf{:} \mathrm{TCR07}\hfill & \hfill ▹\mathrm{Outdoor}\mathrm{temperature}\\ \mathbf{Input}\mathbf{:} \mathrm{TCR08}\hfill & \hfill \hspace{1em}\hspace{1em}▹\mathrm{Present}\mathrm{value}\mathrm{of}\mathrm{temperature}\mathrm{of}\mathrm{central}\mathrm{heating}\mathrm{circuit}\mathrm{supply}\mathrm{water}\\ 1:\mathbf{while}\mathbf{true}\mathbf{do}\hfill & \\ 2:\hspace{1em}\mathrm{Update}\mathrm{values}\mathrm{of}\mathrm{TCR07}\mathrm{and}\mathrm{TCR08}\hfill & \hfill \hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em} ▹\mathrm{Communicates}\mathrm{with}\mathrm{sensors}\mathrm{to}\mathrm{read}\mathrm{present}\mathrm{values}\\ 3:\hspace{1em} \mathrm{spTCR08}\leftarrow \mathrm{COMPUTE}(\mathrm{TCR07},\mathrm{TCR08})\hfill & \hfill \hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}▹\mathrm{Computes}\mathrm{the}\mathrm{set}\mathrm{point}\mathrm{using}\mathrm{the}\mathrm{legacy}\mathrm{algorithm}\\ 4:\hspace{1em} \mathrm{spTCR08}\leftarrow \mathrm{OPTIMIZE}\left(\mathrm{spTCR08}\right)\hfill & \hfill ▹\mathrm{Adjusts}\mathrm{set}\mathrm{point}\mathrm{of}\mathrm{temperature}\mathrm{of}\mathrm{central}\mathrm{heating}\mathrm{circuit}\mathrm{supply}\mathrm{water}\\ 5:\hspace{1em}\mathrm{EXECUTE}\left(\mathrm{spTCR08}\right)\hfill & \hfill ▹\mathrm{Executes}\mathrm{control}\mathrm{logic}\mathrm{to}\mathrm{set}\mathrm{valves}\mathrm{and}\mathrm{pumps}\mathrm{in}\mathrm{order}\mathrm{to}\mathrm{reach}\mathrm{spTCR08}.\\ 6:\mathbf{end}\mathbf{while}\hfill & \end{array}$

Optimization algorithms do not control any specific actuators shown in Figure 1. They modify only the set point of TCR08—the temperature of central heating circuit supply water. For that reason, we were able to measure differences in their performance and directly compare them. Low-level control mechanisms, including control over all the valves and pumps, were preserved as the source code of the local controller and were left unchanged.

5. Results

Comparison of energy consumption of the central heating system controlled by different optimization algorithms is shown in

Table 1. Changes in energy consumption in the test building with different optimization algorithms. $T\left(t\right)$ denotes degree-hours.

Month	Samples	Energy [kWh]	$\mathit{T}\left(\mathit{t}\right)$	E1 (1)	Algorithm
April, 2021	398	3565	3759	0.948	I
May, 2021	495	7021	7069	0.993	I
October, 2021	485	4373	4158	1.052	II
November, 2021	385	5509	4818	1.143	II
December, 2021	727	16,540	13,653	1.211	III
January, 2022	744	15,145	12,638	1.198	III
February, 2022	672	11,416	9789	1.166	III
March, 2022	742	11,868	10,276	1.154	III
April, 2022	720	7815	7105	1.100	Various
May, 2022	743	2479	2645	0.937	Various
April–May, 2021	893	10,586	10,828	0.978	I
October–November, 2021	870	9883	8976	1.101	II
December–March, 2022	2885	54971	46,357	1.186	III

. The recorded measurement data clearly show variations in the performance of the different algorithms. By calculating the ratio of consumed thermal energy to the degree-hours in a period when a specific optimization algorithm was running, we can directly compare them. We see that Algorithm I outperforms Algorithms II and III in terms of energy consumption. The proposed method of normalization of energy consumption in relation to the outdoor temperature seems to be working, because values computed by (1) provide consistent results for each algorithm independently from the time of the year when the test took place. In the last two months, various algorithms were tested, so we did not assign data from this period to any algorithm. Comparison of underheating and overheating indices for different algorithms is shown in

Table 2. Underheating and overheating indices in the test building during the test period.

Month	Samples	$\mathit{t}<21$	E2 (2)	$\mathit{t}>21$	E3 (3)	Algorithm
April, 2021	576	0	0	576	1.78	I
May, 2021	456	31	0.02	425	1.19	I
October, 2021	422	0	0	422	2.45	II
November, 2021	133	0	0	133	1.38	II
December, 2021	672	17	0	654	1.48	III
January, 2022	696	0	0	696	1.79	III
Febuary, 2022	633	107	0.07	525	1.5	III
March, 2022	671	0	0	671	1.69	III
April–May, 2021	516	15	0.01	501	1.52	I
October–November, 2021	278	0	0	278	2.19	II
December–March, 2022	668	30	0.02	638	1.62	III

. The lower the values of $E_2$ and $E_3$, the better. Algorithms II and III are comparable. However, Algorithm II obviously overheats the building. The description of Algorithms I–III is a trade secret. For legal reasons, we cannot provide their description, nor can we provide the baseline energy consumption, i.e., what the performance of Algorithm 1 is, without adjusting the set point of the temperature of the central heating circuit supply water.

Apart from implementation details regarding computations made by optimization algorithms, we see that they indeed influence energy consumption while the system is still under supervision of the legacy controller, ensuring proper functioning of low-level mechanisms. The measurements show that there are differences in the algorithms’ performance. However, determining what difference is considered to be significant, and then deciding which algorithm is better, requires additional research.

6. Discussion

The presented results demonstrate that it is possible to significantly influence the performance of the legacy heating control system by algorithms that only adjust the set point of temperature of central heating circuit supply water. Details regarding the optimization algorithms’ implementation are outside the scope of this article, but the performance metric clearly shows differences in their effectiveness.

The main implication of the presented results for legacy central heating installations is that optimization algorithms using data from external sources (like wireless temperature sensors) can be seamlessly added, even if the legacy controller has no proper communication interfaces to establish direct communication. Existing communication protocols like TCP, or more specifically, MQTT, can be used to exchange the data with an external processing unit that carries out the necessary computations and is equipped with appropriate communication interfaces.

The split between the legacy controller specialized in orchestrating valves, pumps, etc., and the optimization unit responsible for adjusting the set point of the temperature of central heating circuit supply water is clearly defined. Another advantage of that solution is that software engineers can operate on a platform of their choice (in our case it was an edge router with Raspberry Pi Compute Module, shown in Figure 4), instead of learning the nuances of the legacy platform designed to perform much simpler operations without the capability of running, for example, Python or Matlab code. More advanced solutions involving artificial intelligence and machine learning can also be introduced in a similar way. In particular, we want to apply a reinforcement learning training method by rewarding central heating control strategies that minimize $E_1$, $E_2$, and $E_3$ indices. The learning agent should be able to find improved adjustments of the TCR08 set point by learning through trial and error.

The main disadvantage of the proposed solution is that it requires some modifications of the legacy controller control logic. The effect of scale is hard to achieve, as every modification of the existing CH installation requires spending time and resources on learning the legacy controller. For old installations, source codes might not be available, making modifications painful and time-consuming. Deeper analysis is required to learn when performance improvement, time and material costs, and system complexity justify modifications of the existing system instead of simply replacing it. The proposed architecture is very scalable—it can be used in any central heating system with a local controller capable of running injected programming code to communicate with an external optimization algorithm. Thus, it can be used in a single-family or a multi-family building as well as in an office. Algorithms can run either on local machines or in the cloud, which further increases system scalability and reliability.

7. Conclusions and Future Work

This paper presents the architecture for the evaluation of central heating control algorithms that enhance the local control layer with optimization algorithms that have access to additional information. This method lowers requirements regarding connectivity and computing capabilities of the local central heating control unit while offering a framework to implement and evaluate modern control algorithms. The optimization layer is affecting only a single control variable—the desired temperature of central heating circuit supply water. The communication between layers is provided by ISO-recommended MQTT protocol. It means that optimization algorithms, which have additional information from wireless indoor temperature sensors, a weather forecast service, or from other data sources, can run on either a locally installed edge router or on a powerful cloud-based backend, depending on memory and computational requirements. The empirical verification of the proposed architecture was carried out and successfully tested in a residential building in Warsaw, Poland.

In the future, we want to use the method described in this paper to evaluate a set of machine learning control algorithms and compare the obtained results with simulations provided by the whole-building energy modeling engine EnergyPlus and the Transient System Simulation Tool.