Introduction
The Sustainable Community Energy Networks (SCENe) project aims to accelerate the adoption of community energy schemes through research and development of the necessary technological platforms and associated business models. It is centred on a new low-carbon housing development in the Trent Basin area of Nottingham, UK that will result in several hundred new homes as part of a wider regeneration initiative (). Integral to this development are the components necessary to facilitate community energy. A 2.1 MWh Tesla battery has been installed that will be charged in part through solar photovoltaic panels that are installed on the roof tops of participating homes and an urban solar farm. This battery will allow participation in grid services that help balance the UK’s National Grid while generating revenue for the scheme. In future phases of the project it will also be used for the direct benefit of the community to power a heat network, electric vehicles and potentially homes through behind the meter services such as demand response ().
To optimise the use of these assets it is important to understand the energy demands within the community so that decisions can be made as to when to import from the grid, export to the grid or consume generated electricity within the community. In addition, it is important for participants to understand their own energy behaviour, its impact on the overall operation of the scheme and any behavioural changes they may be able to make to enhance their energy efficiency. For these reasons, each participating home was equipped with a range of monitoring equipment to help measure and predict electricity usage, indoor environmental conditions and demands for space and water heating.
The paper firstly describes the devices that were deployed in each home to facilitate the monitoring and then shows how these devices were brought together in a system architecture. Sample data is then provided before the challenges encountered and lessons learned are discussed and conclusions drawn.
Monitoring Devices
A key requirement of the monitoring equipment was the ability for it to be installed and maintained in properties that were already built and occupied. It was important therefore that it could be retrofitted as unobtrusively as possible and with a minimum of disruption. The equipment deployed falls into 3 categories; indoor environment, electricity consumption, heating and thermal energy as detailed below.
Indoor Environment
Indoor environmental conditions were monitored using a range of EnOcean sensors. This technology utilises low bandwidth and low power wireless transmissions from sensors that are typically designed to harvest their energy requirements from the environment in the form of solar energy, thermal differentials or kinetic energy for example (). This feature reduced the need for battery replacements and hence maintenance visits to the properties.
Indoor temperature and relative humidity were measured using batteryless sensors with small solar panels that could be easily wall-mounted as shown in Figure 1. Sensors were installed in the main bedroom and the landing of another floor within the property. Data was sent whenever the temperature changed by at least 0.5 degrees, the relative humidity changed by at least 2% or otherwise every 15 minutes. This data provided an historical view of how warm the participants maintain their property and therefore the likely energy required to satisfy this demand. It also provides the opportunity to present feedback to the user as to how their heating requirements relate to others in the community and the likely impact of any changes they may wish to make.
An EnOcean temperature and relative humidity sensor installed in one of the properties. A magnified view is shown in the inset image.
Changes in internal CO2 concentration are primarily the result of human activity i.e. breathing out, and without adequate ventilation CO2 can rise to unhealthy levels, which in extreme circumstances can result in symptoms such as drowsiness and headaches. It is important to understand therefore whether energy efficiency measures taken to reduce heat loss in energy efficient homes such as those on the Trent Basin development are at the expense of internal air quality. As internal CO2 concentration is correlated with human activity, together with other data it can also help us develop a view of occupancy patterns within a property and across the community. This data can in turn help to predict likely energy demand. A single sensor, powered by ambient light with a battery backup, was thus installed in the main living area as shown in Figure 2. CO2 concentration together with temperature and relative humidity was measured and transmitted at least every 15 minutes.
An EnOcean carbon dioxide sensor, that also measures temperature and relative humidity, installed in one of the properties.
Although CO2 concentration in the main living area provides some insight into occupancy patterns, more data was required to enhance the ability to measure and predict occupancy given its importance to likely energy demand. A more direct measure was also introduced therefore using a motion sensor installed on the ceiling of the main hallway. This EnOcean sensor was powered by a small battery that was specified to last for at least the 2-year duration of the project. It transmitted a signal whenever motion was detected with a minimum interval of 1 minute.
Electricity Consumption
As part of the UK’s rollout of smart meters, the Trent Basin properties were equipped with first generation smart meters that promise to provide consumers with near real-time information on their energy use. However, access to this data is limited to the energy provider and the consumers own in-home display. It was not possible therefore to interface with the meters for the purposes of the project. The specification of second generation UK smart meters provides for a Consumer Access Device () that allows more flexibility with data access, however these meters were not available in the project timescales. In addition, smart meters only provide data on overall household consumption and do not support finer-grained categorisation that allows energy use to be disaggregated into potential areas of interest such as lighting or cooking.
For these reasons electricity was monitored at the consumer unit, which receives the main incoming supply and distributes this to individual circuits within the property. Although there was variance in the specific wiring of each property, a typical pattern was for the electrical sockets to be separated in to 2 to 3 circuits, lighting separated in to a further 2–3 circuits and the electric cooker and electric hob to have their own individual circuits. These were all monitored therefore together with the main incoming supply. To facilitate retrofitting, PowerTag technology () was selected that allows circuits to be easily and accurately monitored without the need for any rewiring. A small single-pole Schneider PowerTag was attached to each circuit of interest that transmitted power data to a concentrator, which due to space constraints was installed externally but close to the consumer unit.
Heating and Thermal Energy
Space and water heating accounts for around 80% of the energy consumed in a typical UK property (). It therefore plays a dominant role in the energy demands of the community and, following introduction of the heat network, operation of the community energy scheme. This also presents an opportunity for better understanding heating behaviour with a view to providing residents with actionable information to make potentially significant reductions in their usage.
To help develop this understanding and provide residents with more control of their heating, each participating property was equipped with a Honeywell Evohome system (). By controlling each radiator separately this system allows temperature control of individual rooms helping to ensure that rooms are only heated when necessary. This zonal control provides greater scope for energy saving over more traditional single zone thermostats. Evohome is also a connected thermostat allowing access and control through a website or smartphone app, which provides further opportunities for residents to better control their heating. This connectivity allows data to be collected on the temperatures of each zone and a richer picture of the house temperature to be developed. In addition, data can be collected on heating behaviour such as choice of target temperatures, schedule use and overrides.
Boilers within participating properties were equipped with OpenTherm technology (), which is an open standard for communication between a boiler and a thermostat. This technology allows the modulation rate of a boiler to be controlled to more precisely satisfy heating demand and can be more efficient than simple on/off controls. It also provides access to a rich dataset from the boiler including boiler on times, calls for hot water, water temperatures and fault conditions.
Given the dominance of thermal energy in a typical domestic property, it was important to develop a richer understanding of this demand to help specify future developments of the scheme such as the heat network and to highlight opportunities for optimisation and behaviour change. In initial phases of the development, space and water heating demand was satisfied by a gas fired combination boiler. As this was the only gas using appliance in a property, gas meter data therefore provides a picture of total thermal energy demand. However, this data does not provide disaggregated data for space and water heating. In addition, it was not possible to directly interface with the first-generation UK smart meters installed in the properties.
For these reasons, heat meters were installed where possible to measure specific energy use for both space and water heating. For central heating, these meters measured flow and return temperatures together with flow rate to provide an accurate calculation of energy consumption. Hot water was heated on demand using an independent water circuit within the boiler and energy consumption was therefore measured using the temperature differential between the cold water inlet and hot water outlet together with flow rate.
System Architecture
There are two key aspects to the system architecture; the in-home monitoring system that generated the data and the cloud infrastructure that received, processed and exposed this data for consumption by other services. These are detailed in the remainder of this section.
Monitoring Equipment Architecture
The architecture of the in-home equipment is shown in Figure 3. EnOcean telegrams transmitted by the indoor environment sensors were received by a gateway device specifically developed for the project. This gateway was based on a Raspberry Pi 3 Model B+ with an EnOcean Pi board that provided a radio and serial interface for interacting with EnOcean sensors in the property.
Architecture of the in-home monitoring equipment and cloud connections. Data leaves the property over the public Internet via the router’s broadband connection or wirelessly for the heat meters. Dashed lines show wireless connections and solid lines physical connections.
Schneider PowerTag sensors transmitted power data using proprietary wireless communications to the associated Schneider concentrator, which also calculated energy consumption for each monitored circuit. This device was connected to the Project SCENe gateway using a wired Ethernet connection and the power and energy for each tagged circuit were read every 15 seconds using the Modbus TCP/IP protocol. The gateway was connected to the Internet using a Wi-Fi connection to the participants existing wireless router and broadband connection.
The Honeywell Evohome heating controller used proprietary wireless communications to interact with the controllers installed on each radiator within the property and with an OpenTherm bridge that in turn was wired to the OpenTherm controls within the boiler. The heating controller was also connected to the Internet using the participants existing Wi-Fi router and broadband connection allowing remote control and data storage and access from the Honeywell cloud.
Heat meters were equipped with Wireless M-Bus, which is a European standard that specifies the communication between utility meters and gateways and has a range of up to several kilometres in urban areas. The meters were installed close to the boiler and wirelessly transmitted data to an external receiver that was installed in a community energy centre, which also housed the community battery and other control equipment. This receiver transmitted data to the University of Nottingham’s cloud using General Packet Radio Service (GPRS) on the mobile network.
Cloud Architecture
The University of Nottingham’s cloud was built on top of Microsoft Azure and provided the hub for data storage and access while laying the foundation for subsequent data analysis. Message Queue Telemetry Transport (MQTT) was chosen to send data from the SCENe gateway to the cloud (). This is a standardised Internet of Things connectivity protocol designed to be very lightweight. It therefore places minimal data requirements on the participant’s broadband connection. It uses a publish/subscribe pattern in which received messages are published to a central broker, which in turn sends the message on to all relevant subscribers. In this case an Azure Internet of Things (IoT) Hub was used as the broker, which accepts messages from any registered device over a connection secured using Transport Layer Security. JavaScript Object Notation (JSON) was adopted as a lightweight format for sensor data interchange and each received message triggered a function app on Azure, which was responsible for persisting the data. Such stateless functions that are quickly started on a defined trigger are an example of a serverless architecture sometimes known as Functions as a Service (FaaS). Data was stored using Azure Cosmos DB, a document-based NoSQL database that is scalable and responsive and does not require a fixed schema.
It was not possible to interface directly with the Evohome heating data as this was sent directly to Honeywell’s own cloud infrastructure, which was also based on Microsoft Azure. However, it was possible to retrieve data from participants who had granted access through cloud-to-cloud interaction in two ways. Firstly, a Representational State Transfer (REST) Application Programming Interface (API) provided access to in-home temperature data, target temperatures, heating schedules and boiler data collected through the OpenTherm interface. Secondly, an Azure Event Hub was used to provide a publish/subscribe capability for all heating data. A serverless function app running in the cloud was again triggered that parsed the data into JSON documents, which were stored in the same Cosmos DB instance. Boiler monitoring data was not available through the Event Hub and could only be accessed using the REST API.
Heat meter data was sent from the Wireless M-Bus receiver over the mobile network using GPRS. Data files were transferred using HTTP to Azure where another serverless function app was used to parse the data into JSON documents and store in Cosmos DB. All monitoring data was therefore stored in this database, which facilitated subsequent analysis using other services. A REST API was also developed that provided access to anonymous data to research partners. This made use of Azure API Management to provide a front-end that could be managed and secured. This service used another serverless function app to query Cosmos DB for the requested data. Key elements of the resulting architecture are shown in Figure 4.
Key elements of the cloud service architecture. Services shown within the dotted area are part of the University of Nottingham’s cloud infrastructure hosted on Microsoft Azure. The heating data Event Hub is part of the Honeywell cloud infrastructure, which is also hosted on Microsoft Azure. Data is stored and retrieved as documents using serverless functions or Functions as a Service (FaaS).
Results
A sample of the data collected from the system described above is illustrated in this section using a single winter weekday’s data for an anonymous sample of 21 properties across the community. Total power demand for all properties over the 24-hour period can be seen in Figure 5.
Total power demand for a sample of 21 properties in the community over a 24-hour period.
Spikes in power demand of approximately 15.5 kW at around 7:30 am and 19 kW at around 7:30 pm were noticeable as part of more general trends of increased demand during the morning as many residents awake and in the evening as residents return home for the evening. Of particular note was an overnight spike in demand at 1am, which was the result of a single 7 kW electric vehicle (EV) charge cycle lasting approximately 2 hours. This event highlights the degree to which vehicle battery charging will dominate community electricity demand as EV adoption accelerates. This point is further emphasised in Figure 6, which shows electricity consumption in each of the 21 properties disaggregated into sockets, lighting, cooking, EV and other over the same 24-hour period.
Disaggregated electricity consumption for each of the 21 sample properties over the same 24-hour period.
The figure shows that consumption for the majority of properties is well below the national average, which is to be expected given the nature of the housing development and the emphasis on energy efficiency. Low power lighting was also used throughout the development, which is highlighted by the relatively low contribution of lighting to overall consumption. However, there are several notable deviations from this general pattern. In addition to property 16’s EV charging event, properties 17 and 19 show substantial consumption outside of the main categories. The power profiles of these properties reveal that there is a significant baseline demand of the order of 0.5kW in both cases, which is an order of magnitude greater than many neighbouring properties. This is an example of the type of information that would be useful to feedback to residents so that they can investigate the underlying cause and possibly take action to reduce their consumption.
There are also significant differences between the consumption of individual properties, which is driven by a number of factors including the number of residents, demographics and occupancy. To illustrate this point Figure 7 shows motion and carbon dioxide data for properties 2 and 11, which are one of the highest and lowest consuming properties respectively. Together this data can provide a good approximation to occupancy.
Motion (shaded areas) and carbon dioxide (right axis) for properties 2 and 11.
As the motion sensor was installed in the main hallway, it was triggered when residents enter and leave the property, visit the kitchen or more generally move around the property. The carbon dioxide sensor was installed in the main living area and therefore elevated levels are expected when that area is occupied for extended periods. The strong correlation between occupancy and energy consumption on this day is clear from the data. Motion was evident throughout the day in property 2 and elevated carbon dioxide levels are typically apparent during periods of reduced motion. This suggests that the property was occupied for the majority of the day. Carbon dioxide concentrations reached a maximum of over 1800 ppm in the evening, which also suggests multiple occupants were present. In contrast, limited motion was seen in property 11 around 8am and 6pm and carbon dioxide levels do not rise above baseline levels. This suggests the property was empty for the majority of the day.
Example heating data is provided in Figure 8, which shows the average, minimum and maximum temperatures over the sample 24-hour period for each property. This data was collected from both the Evohome heating system and the EnOcean temperature sensors, which together provide a rich picture of the temperature for each room in the home.
Average, minimum and maximum temperatures for each property over the example 24-hour period.
The data shows that the average temperature for most properties fell within a comfortable temperature range of around 18 to 21 degrees Celsius with the notable exception of property 15 that had an average temperature of below 16 degrees. However, inspection of motion data suggests this property was entirely unoccupied during this period. The average temperature of property 8 also fell below 18 degrees, which is a consequence of much lower than usual overnight temperatures due to a heating set point of 10 degrees in the majority of the home. The maximum temperatures reveal that there is evidence of overheating in all properties. However, this was not always the result of normal heating behaviour. Property 4 for example reached nearly 29 degrees in a room with a heating set point of only 21 degrees. In many cases however there was a potential correlation between heating set points and overheating. Nine of the properties used set points in excess of 21 degrees at times and as high as 28 degrees in one case. There is thus an opportunity to influence residents heating behaviour by feeding back this data with a view to reducing overheating and associated energy consumption.
Discussion
It is clear from the previous sections that a broad range of technologies and protocols were required to implement the monitoring architecture described in this paper. This is consistent with the fragmented nature of the Internet of Things technology space at the time of writing. Although some consolidation is likely given the initiatives of the large technology companies such as Google and Apple, this fragmentation is likely to persist for the foreseeable future and a successful architecture will thus need to be flexible to a range of different technologies.
However, such diversity at the device and protocol level can be consolidated at the cloud level. Data generated can be ingested using a common structure in such a way that the complexity of the underlying system can be made invisible to services that consume this data. In this work, JSON documents with a common core of objects were used for storage in a document-based NoSQL database. Data retrieved from the API by consuming services could therefore work with this common structure independently of the underlying technology. To reach this point however a number of challenges and learnings were encountered that will be discussed in the remainder of this section.
EnOcean technology was chosen for monitoring of the indoor environment. The key feature of this technology is the ability for devices to harvest the energy they need for data transmission from their environment. In this project ambient light was used to power devices via embedded photovoltaic cells thus alleviating the need for batteries. The attraction of this approach from a maintenance perspective is clear as in theory devices can be installed and left to run for long periods without further intervention. However, in practice batteryless devices used in this work were sometimes unable to generate and store enough power for consistent data transmission even in relatively well-lit rooms. In some cases, this resulted in no data transmissions during the night and therefore any maintenance advantages were overshadowed by data quality issues. Other EnOcean devices with a battery backup proved more reliable and thus the advantage of this technology was to extend battery life rather than remove the need for them. It should be noted however that these findings are specific to the sensors used in this work and therefore should not necessarily be generalised across all EnOcean devices.
As previously highlighted, it was not possible to interface with the smart meters installed in the Trent Basin properties and sub-metering was therefore necessary. This proved impractical in a retrofit scenario for gas meters however electricity sub-metering was achieved using PowerTags installed in the consumer unit. Such use of wireless sensors has the potential to be problematic where the consumer units are metal-clad, which is now a requirement for new properties in the UK for example, and the receiver is externally installed. In this scenario, as was the case in this work, wireless data transmissions must penetrate the metal-clad box. However, consumer units typically have holes designed for cable connections that can be exposed to create a more radio friendly environment. Very few packet errors were therefore registered when the receiver was installed close to the consumer unit in this way.
The power sensors also allowed monitoring of individual circuits such as lighting and cooking. Such disaggregated data is of potential value in helping to build a finer-grained understanding of energy consumption. It was however limited in several ways. Firstly, circuits within individual homes were not consistent and therefore it was not always possible to directly compare consumption of a given circuit across the community, which may have been useful for analysis and feedback for residents. This will always be the case in a retrofit scenario but for future developments specification of consistent circuit wiring across properties of the same type would be useful to facilitate subsequent monitoring and analysis. Secondly, it was not typically possible to directly monitor the consumption of individual appliances such as the washing machine or tumble dryer as these were not powered by individual circuits. However, circuit power sensors provide more focussed data on an area of interest such as kitchen sockets, which is likely to increase the efficacy of any subsequent algorithmic analysis to identify specific devices (). Over time this issue is likely to become redundant as smart appliances are adopted that report their own energy consumption.
The OpenTherm connection to the boiler provided access to a range of data that allowed monitoring of boiler performance. This dataset included modulation rate expressed as a percentage of maximum firing rate, flame-on times and whether the boiler was firing due to a call for heating or hot water. In theory therefore, this data could be used in conjunction with the capacity of the boiler to estimate energy consumed for heating and hot water individually. However, there are several issues with this approach. Firstly, modulation rate is an optional OpenTherm parameter and cannot therefore be relied on across all boiler types. Secondly, the resolution of the data may not be sufficient to make accurate calculations. With the Evohome thermostat used in this work, the maximum resolution of data was every minute and thus the data was not fully representative of actual boiler operation. This approach may be possible however using other thermostats that more frequently poll for boiler data.
Thermal energy consumption can also be calculated using flow rate, flow temperature and return temperatures. However, only 2 of these data points were available via OpenTherm. For central heating, flow and return temperatures were provided but not flow rate. For hot water in a combination boiler, flow rate and flow temperature are provided but not inlet water temperature. In both cases therefore it was not possible to calculate energy consumption thus necessitating the use of heat meters.
Although providing accurate data, heat meters are far more difficult to retrofit often requiring draining of the entire central heating system. In addition, in some properties installation was difficult due to space constraints and length of exposed pipe work. However, to alleviate these difficulties, certified compact ultrasonic heat meters were used that can be used in scenarios with limited upstream and downstream piping, which in some cases can adversely impact the accuracy of this type of meter.
A key issue in the design of a monitoring system is access to data. It was important therefore to choose protocols that provide open access to data. EnOcean telegrams conform to a publicly available specification and can thus be interpreted and used by any compatible receiver. Power and energy data was available via Modbus TCP/IP, which is another open protocol. Similarly, the wireless M-Bus data transmissions used by the heat meters could be received and used without restriction.
However, although the availability of connected home products is proliferating, data from such products is often not available either through an open interface or a negotiated commercial agreement. This is the case for many smart thermostats and it was important therefore to ensure that any such products used also provided access to the associated data. In general, this issue limited the option of utilising off-the-shelf connected products.
Another important issue to consider was data transfer from a monitored home to the backend cloud infrastructure. There were several possibilities considered including use of the mobile network however an advantage of the advent of the connected home is that consumers are becoming more accustomed to the use of their existing Internet connection for these products. A similar approach for this project was thus adopted and in keeping with this general market trend.
This approach does however require consent for the use of an existing Internet connection and introduce the risk of data acquisition failing due to changes in the homes Internet connectivity that are not visible or directly controllable. This is a key advantage of technologies such as Wireless M-Bus and other Low-Power Wide-Area Network (LPWAN) technologies (). These technologies are designed to facilitate low-power, long range data transmission so that communal receivers can be used removing the need for individual receivers in each property. This architecture is a good fit for geographically constrained areas such as community energy projects and a fruitful area of investigation for subsequent projects.
The advent of managed cloud services from the major technology companies is a great asset in the development of IoT systems. It is now possible to more easily create scalable, robust services with high availability. In this project a number of such services were used including serverless functions that performed many important roles within the system. These functions are spun-up on demand following a defined trigger and have the significant advantage of not requiring a dedicated server. In many cases, this architecture served its purpose well. However, in cases where rapid response was required it was found to be problematic due to the inherent delays in the spin-up process. This was particularly apparent when a rapid response from the API was required to answer a user request for data for example. On first execution of the function significant delays were often apparent that were detrimental to the user experience. Careful consideration should thus be made before employing serverless functions for scenarios in which functions may not be used for some time but require rapid response on first use.
Conclusions
In this paper we have described a technology platform for monitoring homes in a community energy scheme. The monitoring includes indoor environmental conditions, electric power, thermal energy and heating. A diverse range of technologies and protocols were required to implement this system, which given the fragmented nature of Internet of Things technology, is likely to be commonplace for the foreseeable future. However, consolidation was possible in the cloud to provide a consistent data structure for other services that consume the data. Sample data was presented that demonstrated its potential for understanding and influencing energy demand in the community.
Much of the technology deployed used short range wireless sensors that require a local gateway to receive, process and transmit the data to the backend cloud services. These sensors were easy to install and retrofit but placed a requirement on network connectivity in each individual home. Heat meters however used the low-power, long-range Wireless M-Bus protocol thus alleviating the need for a receiver in each home. This technology is an example of a Low Power Wide Area Network of which there are several examples including LoRa and NB-IoT (). These technologies are designed for IoT applications that typically require low power consumption and low data rates but long range. They are thus a natural fit for community energy schemes and as more devices utilising these technologies emerge provide a fruitful area of focus for associated monitoring.