You are currently viewing a new version of our website. To view the old version click .
MDPIMDPI
Search all articles
Sensors
Download PDF
  • Article
  • Open Access

24 December 2022

Design and Implementation of a Cloud-IoT-Based Home Energy Management System

,
,
,
and
1
Department of Electronic Engineering, Universidad Técnica Federico Santa María, Valparaíso 2390123, Chile
2
Electrical Engineering Department, Faculty of Engineering, Mansoura University, Mansoura 35516, Egypt
3
Sustainable Energy Technologies Center, King Saud University, Riyadh 11421, Saudi Arabia
4
Department of Computer Engineering, Jeonbuk National University, Jeonju 561-756, Republic of Korea
Sensors2023, 23(1), 176;https://doi.org/10.3390/s23010176
This article belongs to the Special Issue Smart IoT System for Renewable Energy Resource
Version Notes
Order Reprints

Abstract

The advances in the Internet of Things (IoT) and cloud computing opened new opportunities for developing various smart grid applications and services. The rapidly increasing adoption of IoT devices has enabled the development of applications and solutions to manage energy consumption efficiently. This work presents the design and implementation of a home energy management system (HEMS), which allows collecting and storing energy consumption data from appliances and the main load of the home. Two scenarios are designed and implemented: a local HEMS isolated from the Internet and relies on its processing and storage duties using an edge device and a Cloud HEMS using AWS IoT Core to manage incoming data messages and provide data-driven services and applications. A testbed was carried out in a real house in the city of Valparaiso, Chile, over a one-year period, where four appliances were used to collect energy consumption using smart plugs, as well as collecting the main energy load of the house through a data logger acting as a smart meter. To the best of our knowledge, this is the first electrical energy dataset with a 10-second sampling rate from a real household in Valparaiso, Chile. Results show that both implementations perform the baseline tasks (collecting, storing, and controlling) for a HEMS. This work contributes by providing a detailed technical implementation of HEMS that enables researchers and engineers to develop and implement HEMS solutions to support different smart home applications.

1. Introduction

Nowadays, the applications of the Internet of Things (IoT) are appearing in different domains, such as transportation [], healthcare [], agriculture [], and power systems []. These IoT solutions aim to monitor and control various elements and devices in different scenarios that will ease tasks and provide useful applications for daily living []. In the electric power system, energy plays a central role in powering our homes and appliances. However, the metering process for estimating the consumption of a house is widely dependent on an electromechanical energy meter, which implies that utility companies have to employ personnel to perform the metering tasks monthly in order to bill their customers []. As for the appliance consumption within a house, residents may not be aware of individual power consumption for each appliance, therefore facing inefficient energy usage without even knowing. In this regard, Chile has set a goal to have around 6.5 million smart meters installed by 2025 []. This goal focuses mainly on using smart meters to lower energy demand by providing more detailed energy billing and interfaces of energy consumption through web interfaces and applications, as well as implementing new tariff systems.
IoT will play a key role in enabling several energy efficiency mechanisms, such as the Internet of Energy, smart grids, and smart homes. This is possible by using digital sensors and communication devices that enable a home energy management system (HEMS), which allows continuous consumption monitoring and appliance control, as well as supporting the communication between the utility and the power grid []. Data are collected using IoT devices and later transferred to the cloud-based system infrastructure from where it is stored and processed []. Data-driven applications, databases, and file storage systems are key features that can be designed and deployed in cloud-based infrastructure to support the IoT cloud-based requirement for several energy Internet applications.
The design and implementation of a proper architecture are the main challenges for enabling applications based on IoT-collected data on a global level. Several works have proposed HEMS-IoT architectures to solve these challenges. The common criterion used to define an architecture is the data processing and storage location. Three layers are found in the literature where data processing and storage can occur: edge, fog, and cloud.
In this paper, an overview of the HEMS-related work is presented, focusing on key elements, such as the design of a HEMS architecture enabled by IoT devices and the usage of local and cloud computing for data storage and processing. We propose a Cloud-IoT based home energy management system, which helps residents, landlords, researchers, and administrators manage the energy consumption within a house. The proposed HEMS implements a four-layer architecture, which is capable of collecting and storing energy consumption data. Consumption data are obtained from two kinds of devices: smart meters and smart plugs. The smart meter units are able to collect the energy consumption of the entire house, while smart plugs are capable of collecting energy consumption and controlling the power supplied to a single appliance. Two implementations were carried out following two different approaches. In one approach, a local HEMS was isolated from the Internet with a central processing unit. In the other approach, a cloud-based implementation used the cloud for data storage and processing. Both systems provide baseline features, such as collecting measurements from the devices, storing them in a database or performing load control actions, such as turning on/off a device manually or by scheduling. Results show the capability of both systems to perform the collection and storing features for energy consumption and to control the appliances by using smart plugs. The main contributions of this work can be summarized as follows:
  • Design and implementation of a four-layer HEMS architecture that allows collecting and storing energy consumption data from appliances and the main load of the home.
  • Two scenarios are designed and implemented: a local HEMS isolated from the Internet that relies on its processing and storage duties using an edge device and a Cloud HEMS using AWS IoT.
  • To the best of the authors knowledge, this work is the first electrical energy dataset with a 10-second sampling rate from a real household in the city of Valparaiso, Chile, over a one-year period.
  • Detailed technical implementation of HEMS will enable researchers and engineers to develop and implement HEMS solutions to support different smart home applications.
The rest of the paper is structured as follows: In Section 2, related work for HEMS is explained. Section 3 presents the proposed HEMS architecture. Section 4, presents two case studies: a local HEMS, and a Cloud HEMS. Section 5 elaborates on the technical details for the implementation of both systems. Section 6 discusses the results from the case studies and the future challenges for HEMS implementations. Finally, Section 7 concludes the paper.

3. Cloud-IoT Home Energy Management System

Figure 1 shows the proposed Cloud-IoT HEMS architecture. It consists of four layers: perception layer, communication layer, middleware layer, and application layer.
Figure 1. Cloud-IoT HEMS architecture.

3.1. Perception Layer

The perception layer enables data collection through sensors, as well as data storage and data processing tasks through edge devices. This layer considers several physical devices, such as sensors, smart meters, and smart plugs, which are often referred to as “things”. Edge devices enable tasks, such as data storage, data processing, and performing actions, on things that are located in the edge sub-layer. The perception layer is a key element in the proposed architecture, working as the first step in the energy data collecting process and as the last step in the appliance controlling process.
  • Things Layer: The things layer is composed of sensors and actuators. Sensors are used to collect information on important measurements of the smart home. Sensors, such as temperature, humidity, and light detection, among others, are used for comfort purposes. Regarding appliances’ power consumption, two devices are introduced: smart meters and smart plugs. A smart meter is able to collect energy consumption information of the main loads of the smart home. It utilizes a current transformer (CT) and a voltage sensor to compute the power consumption. Smart plugs (SP) work as a middleware between the power line of the house and the appliance plug. The purpose of SPs is to collect energy consumption data from a specific appliance while also being able to control the energy delivered to the appliance using a relay.
  • Edge Layer: The edge is the closest to the sensors and actuators. It provides the capability to collect data and perform command operations over “things”. The edge layer considers a low latency but limited data storage and processing capabilities as available resources. From a HEMS perspective, the edge layer is found at the house level, where it is able to use this layer as a perception layer to collect the data of interest.

3.2. Communication Layer

This layer allows the connection of the perception layer with the middleware layer. Several communications technologies could be used to perform this task, among them WiFi, Zigbee, LoRa, Fiber, and mobile networks such as 4G and 5G. The election of the technology has various attributes, such as effective range (short range and long range), cost, coverage, and availability of a given communication system. An important role of the network layer is providing a home area network (HAN) for perception layer devices to join. The HAN allows communication between devices, also known as machine-to-machine (M2M) communication, which allows routing the data from the things to the edge or from the edge to the middleware layer.

3.3. Middleware Layer

The middleware layer is related to cloud-based services that rely on the received data to perform some tasks. The most common functions of a HEMS consider storing measurements in a database, performing data processing tasks through microservices, and providing an application programming interface (API) for managing data requests. These services can be implemented by using a public cloud, such as Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure (Azure). Given the functionality, the middleware layer is similar to the edge layer but provides a scalable infrastructure to serve higher traffic and more demanding processing and storage tasks. Several technology stacks are available for developers to carry out the required implementation to achieve the abovementioned tasks. Some challenges and decisions that need to be addressed in order to provide a robust system consider database election, designing and deploying the required cloud architecture, programming language, and/or framework election. The middleware in this architecture serves as a bridge between the data perspective provided by the “things” and the intended smart home features or applications identified in the application layer.

3.4. Application Layer

A HEMS aims to provide data to several domains, such as Energy Internet, smart grids, and smart homes. Some data-driven applications for HEMS are, for example, demand response, P2P energy trading, and monitoring energy consumption for user awareness. These applications serve as the last layer in the proposed architecture which is the closest to the end user.

4. Home Energy Management System Design

Two case studies are proposed to compare different approaches for HEMS: a local HEMS and a cloud-based HEMS. On the one hand, a local HEMS system uses a central computing unit to handle data storage and processing tasks. On the other hand, a cloud-based system collects the data through a gateway and is able to enable several solutions and applications.
Both systems are designed to meet the following tasks, which enable HEMS to perform some features of a smart home:
  • Monitoring of the energy consumption: HEMS should store data about the power consumption of the appliances monitored by the smart plugs and the main load of the smart home.
  • Appliance control: HEMS should allow a resident to interact with the appliances connected to smart plugs to supply or deny energy.
In this work, the smart home includes some features that are present on both systems as a requirement. We recognize two categories that are common ground for the implementation of such systems:
  • The things: Both case studies utilize the same end devices: smart plugs and smart meters. The task of the smart meter is to collect the total power consumption reading of the house. On the other hand, a smart plug is able to collect the power consumption and control the supplied power of a single appliance.
  • Networking and communications: From a communication perspective, we considered that the smart home has WiFi capabilities, enabling devices to interact within a home area network (HAN). Devices such as smart plugs and smart meters have the capability to join the HAN using WiFi technology. An Internet Protocol (IP) address is assigned to each device that joins the network. The things have the capability to periodically send measurements of the energy consumption telemetry to the destination. Direct energy consumption requests can also be performed, following the messaging protocol that each device supports. The things send the collected data using MQTT, a popular Pub/Sub (publisher/subscriber) messaging protocol, where each device sends data over a unique topic.
Figure 2 shows a schematic diagram for HEMS design. On the left side, the system is composed of home appliances, a smart meter, smart plugs, and a computing unit serving as the local HEMS. This approach considers a solution that relies solely on monitoring and managing house appliance consumption in a local scenario. Such solution presents benefits from a privacy perspective, given that it is isolated from the Internet. The main drawback of this kind of approach is the limited computational and storage capacity of the HEMS, which is directly related to the provisioned on-premise hardware. From the Edge perspective, the devices such as smart plugs and smart meters are intended to collect energy measurements based on the energy consumption of certain appliances and the total energy consumption of the main home, respectively.
Figure 2. Schematic diagram for HEMS. Left: Local HEMS design, Right: Cloud HEMS design.
The design of the Cloud-IoT HEMS is presented on the right side of Figure 2, where the energy and data interactions are shown. Smart meters and smart plugs allow the collection of energy-related data. The main objective is to send the energy consumption data to the cloud. For this purpose, the things send information to a gateway, which allows bridging the data into the cloud.
These data are stored and processed by databases and cloud microservices. Several data-driven HEMS applications can be designed and implemented. One benefit of using public cloud services is the infinite scaling opportunity, which allows applications to scale as needed. Cloud providers manage the hardware and configurations required to enable any architecture to function appropriately, easing the development experience. This allows for cheaper costs when comparing cloud-based implementations to on-premise implementations for a scalable system.

5. Implementation

The testbed was carried out in a real house located in the city of Valparaiso, Chile. A wireless local area network (WLAN) was set up by a router that provides WiFi connectivity for all devices located in the house. The energy consumption data was acquired starting from July 2021 up to September 2022. Four appliances were used: a kettle, a washing machine, a refrigerator, and a microwave.
The selected smart plugs were the Sonoff POW R2, which were modified to fit inside a small electrical box, as seen in Figure 3a. This configuration provides one outlet for connecting the appliance and one plug for connecting the unit to the power outlet of the home. Each appliance was connected to a smart plug, as seen in Figure 3b. These devices were configured using the open-source firmware Tasmota. This firmware allows for an easier development experience enabling easier management of the configurations of smart plugs. The web interface was used to set up the WiFi connection with the HAN.
Figure 3. Sonoff POW R2 as smart plug, overview, usage, and configuration. (a) Smart plug unit; (b) Two smart plug units connected to a kettle (left) and a microwave (right); (c) MQTT configuration on Tasmota web interface.
On the smart plugs, MQTT was set using the web user interface (UI) by specifying the required connection parameters, as seen in Figure 3c. Each smart plug uses a unique MQTT topic to publish and/or subscribe to messages. The Sonoff devices were configured to send one measurement every 10 s using the telemetry feature within Tasmota. Message data were transmitted using JavaScript Object Notation (JSON) structure. The topic structure for smart plugs is “tele/device-ID/sensor”, which represents the telemetry event sent by a specific device informing its sensors data collection.
For the smart meter, the eGauge EG4115 unit was selected, as seen in Figure 4a. This device uses current transformer (CT) sensors, as seen in Figure 4b, and voltage sensors to compute the energy consumption of the house with frequencies of one measurement per second. This device was connected via Ethernet to the router, joining the local area network (LAN) and obtaining an IP address. This device comes with XML API within its firmware, which enables any device in the network to request measurements of the unit.
Figure 4. eGauge EG4115 data logger used as smart meter to collect energy consumption data from the main load of the house.(a) eGauge data logger unit showing instant power consumption; (b) CT Sensor (blue device) used to collect the current of the main load of the house.
Messages sent by smart plugs and the smart meter are composed of several attributes that compose the payload of the message. Table 2 presents the data structured object provided on the event emission by the smart plug and the smart meter. These messages are structured in a data object based on a key-value pair structure. The attribute column in the table references the key of the data object, while the type column provides the data type of the value associated with the attribute. The description and measuring unit are provided for all attributes on the smart plug and the smart meter.
Table 2. The things, smart plug, and smart meter energy data collection attributes on messages.

5.1. HEMS Local Implementation

The local implementation was carried out using a Raspberry Pi as the local HEMS, as shown in Figure 5. A Raspberry Pi was configured with Raspberry Pi OS-Lite, which is a Linux distribution developed to serve as the suggested operating system (OS).
Figure 5. Schematic diagram for local HEMS implementation.
Several services were configured in the Raspberry Pi to allow this unit to establish MQTT communication, provide a database to store measurements, and perform lightweight processing tasks. Mosquitto is an open-source MQTT broker, which was used in the Raspberry Pi to participate in a publish–subscribe messaging scheme with the things. The MQTT broker was set up on port 1883.
MongoDB is a non-relational database that allows storing data in a JSON structure. A single MongoDB instance was set up on the Raspberry Pi on port 27017. Python is a high-level scripting language that was used to automatize the process of storing a document in the database for each measurement received. Three scripts were developed: the first one for collecting the measurements of the smart plugs, the second one to collect measurements of the smart meter, and the last one to handle appliance control commands. The first script uses the paho MQTT client, which connects to the MQTT broker and subscribes to each smart plug MQTT topic. PyMongo, a MongoDB client, is used to perform operations in the database. For each message received by the broker, the content of the message is saved into the database.
For collecting the smart meter measurements, the second Python script uses requests, an HTTP client for Python, to request the last four hours of energy consumption recorded by the eGauge unit. This request is fulfilled by a CSV file that contains the requested data. The file is saved in local storage within the Raspberry Pi. This script is scheduled to be performed every four hours using a cron job. Please note that the time of “4 h” could be adjusted based on application requirements. The last script provides the capability to send commands to a specific appliance topic for turning the relay of the smart plugs ON or OFF.

5.2. HEMS Cloud-Based Implementation

The Cloud HEMS system was implemented following the structure presented in Figure 6. A Raspberry Pi was configured as an MQTT broker using mosquitto. This broker was used as a host by the things to send the telemetry events using MQTT on individual topics. The MQTT broker was set up in a bridge mode, allowing it to route the inbound data to a new destination provided by the cloud provider.
Figure 6. Schematic diagram for Cloud HEMS implementation.
AWS IoT Core was set up using the AWS console. The IoT Core provides an MQTT broker, which is able to manage MQTT connections from smart homes. IoT Core also allows setting up triggers for executing events when data is received. The implemented triggers and actions are presented in Figure 7.
Figure 7. AWS IoT Core implemented rules and actions.
Two rules are set in order to perform some actions. The first one considers that all the incoming messages that match the topic structure “tele/+/sensor” will be logged into AWS CloudWatch. The plus sign “+” is an MQTT single-level wildcard on AWS IoT Core rules that matches any value in that position; in this case, it represents the device ID from the smart plug unit. The rest of the actions are executed only when the second rule is met, which implies that the power consumption informed by the received message is greater than zero. This rule was set to optimize the storage and costs of the implemented system. When the rules are not matched by the incoming MQTT messages, these are discarded. Regarding the actions, the Cloud HEMS stores the data using DynamoDB, where smart plug data are stored in a JSON object using the schema and attributes presented in the data payload in Table 2. For storing the smart meter data, an S3 bucket is used to handle the CSV files provided by the unit over MQTT. Kinesis Firehouse is used to ingest the received MQTT message into a data stream enabling further processing, data events, and real-time-based applications.

5.3. Case Study 1: Local HEMS Results

For the local HEMS, results show the capability of the system to store the energy consumption data of the appliances and from the main load of the house. Figure 8 shows a snapshot of the MongoDB collection that contains the measurements from the appliances collected by the smart plugs.
Figure 8. Database record of smart plug measurement of the kettle.
Each document contains the energy-related parameters for each telemetry event. The document contains one parameter that allows for appliance identification. By using the ID of the smart plug, it is labeled as the correct appliance with the same name attribute in the database document. This parameter is configured in the collection as an index, which allows for faster queries when used as a filter parameter. The records collected by the smart meter are shown in Figure A1, where they are stored as CSV files in a directory.

5.4. Case Study 2: Cloud HEMS Results

Cloud HEMS was deployed starting in July 2021, during which data were collected and stored in the cloud. The AWS S3 web panel allows checking the individual files stored by the system for the smart meter measurements, as seen in Figure A2. Each file is around 3MB, and it contains a four-hour window of measurements taken by the smart meter every second. These files follow the structured data provided by the eGauge unit.
Batch processes can be scheduled to perform analytics operations over the stored data. Figure 9 shows a pie chart for the energy consumption per appliance for the first week of August 2022. This information intends to serve the residents as feedback on their behavior regarding the energy consumption of each appliance.
Figure 9. Energy consumption per appliance for resident awareness.
One feature that benefits from data analysis services provided by AWS in the cloud is shown in Figure A3, where an email notification alerts when the system has not detected any writing activity in the database. This enables the residents to be aware of appliance malfunction, energy blackouts, connectivity issues, or any other problem regarding the energy consumption in the home.
Figure 10 shows the data availability of the system regarding the collected data from the devices. The x-axis presents the available time period since the system started recording data from July 2021 up to the end of the study (grouped by months). The four appliances and the main load of the home are shown on the Y-axis. The values shown for each device and the month represent the percentage number of messages received from each device during a certain month over the total amount of messages that could be received considering the sample rate for each device. This graph shows that in some periods, such as August 2022, there were some constraints on receiving data from the house. This happened due to a system malfunction, blackouts, or scheduled maintenance from the power utility provider.
Figure 10. Analysis of system availability for the collected data.
Regarding data visualization, Figure 11 shows the main load of the house collected by the eGauge unit. The period shows the regular power consumption over the month of August with a gap of data. In Figure 12, a window of two hours shows the specific energy consumption for the kettle, refrigerator, microwave, washing machine, and the main load of the house on 2 August 2022. A slice of the data collected from our real house implementation with some instructions regarding the implementation of the HEMS can be found at our repository of the project https://github.com/pipegreyback/EViG-Server, (accessed on 1 October 2022).
Figure 11. Total power consumption of the main load of the house using the eGauge unit during the period of July, August, and September 2022.
Figure 12. Power consumption data from the four appliances using smart plugs and the main load of the house.

6. Discussion

Data-driven applications provide an enormous benefit in various fields. In distribution power systems, the new applications of the Energy Internet, smart grids, and smart homes will allow, for example, disaggregated consumption per appliance using the total power consumption of the home. Some other applications allow load scheduling for appliances. These applications require reliable architecture and implementation that allow the collection, storage, and processing of such data. Such a challenge has been discussed widely, but there is no one standardized architecture that fits all solutions, thus the architects and developers need to identify the requirements of the system in order to design a reliable architecture that allows the system to function properly. Some of the considerations will enforce the data storage and processing to be deployed locally at the edge or remotely in the cloud. Nevertheless, a system such as the proposed HEMS could present different requirements when multiple houses implement the system. There are other constraints, such as a massive amount of data sent to the cloud from individual houses, which could result in high latency and degradation of the service. Thus, solutions that use a fog layer as data concentrators within a neighborhood, such as Neighborhood Area Network (NAN) should be considered when looking to deploy a HEMS in various houses within a neighborhood.
New tools such as AWS Cloud Development Kit (CDK) for speeding the provisioning process of services appear as an interesting alternative to provisioning infrastructure through web interfaces, such as the AWS console. AWS CDK follows the paradigm of Infrastructure as Code (IaaC) which enables the developers to write code in several programming languages such as Typescript, Python, and Go. The code represents the required services to be provisioned, with the respective configurations which are then synthesized and deployed into AWS through cloud formation.

6.1. Technology Adoption

The acquisition of dedicated sensors and actuators with Internet capabilities and IoT devices provide multiple benefits for different data-driven applications, but it comes with the challenge of technology adoption. In [,], the authors investigated the user perception on acceptance of monitoring energy consumption devices such as smart meters. In [], the authors reviewed consumer beliefs regarding smart meters using behavioral decision research. Results showed that consumers are positively predisposed toward smart meters; however, the authors proposed recommendations for electric utilities in order to address misconceptions about smart meters’ benefits and concerns over risks. Even though the use of smart energy management systems in the residential context provided energy savings, increasing user acceptance has been a challenge over field implementations []. The authors identified seven high-level categories based on a mixed-method approach providing a more holistic understanding of users’ perception of smart energy management system adoption.

6.2. Implications of the Proposed Solution and Future Directions

The design of HEMS still entails a degree of uncertainty, given that developers and architects might propose different approaches on how to carry out such a system. This is due to multiple factors, such as the variety of IoT-enabled devices, networking and communication protocols, and data resolution requirements. The usage of IoT devices such as smart plugs, a common component of both implementations, provides the benefit of enabling existing households to benefit from smart grid applications without interventions of the property. Our implementation was able to perform a set of features available in HEMS for a real house in Valparaiso, Chile. However, another direction is the integration of other communication protocols such as Zigbee or LoRa. Such solutions will enable our system to support heterogeneous IoT systems, which provide flexibility while choosing IoT end devices such as smart meters and smart plugs.

7. Conclusions

In this paper, we designed and implemented two HEMS solutions that are able to store power consumption and control appliances by using edge (local) devices or the cloud. The proposed architecture consists of four layers: perception layer, communication network layer, middleware layer, and application layer. The local HEMS is isolated from the Internet and utilizes an edge device to serve as the main processing unit. The cloud-based HEMS utilizes a gateway to send the data to the cloud. Both implementations are driven by IoT devices to send data measurements or receive control signals. We reviewed, designed, and implemented the most common approaches on state-of-the art edge (local) HEMS and cloud-based HEMS. Both systems have some common features of HEMS; however, they differ in terms of privacy and scalability. In this regard, new challenges appear when multiple HEMSs need to be deployed in a community or a neighborhood area network. A hybrid approach could enable a more reliable and integral solution than using edge devices or the cloud as individual systems. Our ongoing work considers extending the developed HEMS to support different applications, such as energy disaggregation, anomaly detection, demand response, and peer-to-peer energy trading, further extending the system capabilities to enable real-time data processing applications through data streams.

Author Contributions

Conceptualization, M.A.A., J.M.M. and F.C.; methodology, M.A.A., J.M.M., F.C., A.M.E. and Y.-C.K.; software, F.C.; validation, M.A.A., J.M.M. and F.C.; formal analysis, M.A.A., J.M.M., F.C., A.M.E. and Y.-C.K.; investigation, M.A.A., J.M.M., F.C., A.M.E. and Y.-C.K.; writing—original draft preparation, F.C. and M.A.A.; writing—review and editing, M.A.A., J.M.M., F.C., A.M.E. and Y.-C.K.; funding acquisition, M.A.A. and Y.-C.K. All authors have read and agreed to the published version of the manuscript.

Funding

This work was supported in part by the Agencia Nacional de Investigación y Desarrollo (ANID) through the Proyecto Fondecyt de Iniciación en Investigación 2020 under Project ID11200178, DGIIP-UTFSM Chile, and in part by the National Research Foundation of Korea (NSF) Grant through the Korean Government under Grant (2021R1I1A305872911).

Institutional Review Board Statement

Not applicable.

Data Availability Statement

Not applicable.

Acknowledgments

The authors would like to acknowledge Proyecto Fondecyt de Iniciacion en Investigacion 2020 under Project ID11200178, DGIIP-UTFSM Chile, and National Research Foundation of Korea (NSF) Grant through the Korean Government under Grant (2021R1I1A305872911).

Conflicts of Interest

The authors declare no conflict of interest.

Appendix A

Sensors 23 00176 g0a1
Figure A1. Smart Meter energy records from eGauge unit.
Sensors 23 00176 g0a2
Figure A2. AWS S3 bucket with energy consumption records from smart meter.
Sensors 23 00176 g0a3
Figure A3. Email notification when a smart plug has not write into the database in a fixed period of time.

References

  1. Luo, X.G.; Zhang, H.B.; Zhang, Z.L.; Yu, Y.; Li, K. A New Framework of Intelligent Public Transportation System Based on the Internet of Things. IEEE Access 2019, 7, 55290–55304. [Google Scholar] [CrossRef]
  2. Bhuiyan, M.N.; Rahman, M.M.; Billah, M.M.; Saha, D. Internet of Things (IoT): A Review of Its Enabling Technologies in Healthcare Applications, Standards Protocols, Security, and Market Opportunities. IEEE Internet Things J. 2021, 8, 10474–10498. [Google Scholar] [CrossRef]
  3. Friha, O.; Ferrag, M.A.; Shu, L.; Maglaras, L.; Wang, X. Internet of Things for the Future of Smart Agriculture: A Comprehensive Survey of Emerging Technologies. IEEE/CAA J. Autom. Sin. 2021, 8, 718–752. [Google Scholar] [CrossRef]
  4. Ratasich, D.; Khalid, F.; Geissler, F.; Grosu, R.; Shafique, M.; Bartocci, E. A Roadmap Toward the Resilient Internet of Things for Cyber-Physical Systems. IEEE Access 2019, 7, 13260–13283. [Google Scholar] [CrossRef]
  5. Bellini, P.; Nesi, P.; Pantaleo, G. IoT-Enabled Smart Cities: A Review of Concepts, Frameworks and Key Technologies. Appl. Sci. 2022, 12, 1607. [Google Scholar] [CrossRef]
  6. Avancini, D.B.; Rodrigues, J.J.; Martins, S.G.; Rabêlo, R.A.; Al-Muhtadi, J.; Solic, P. Energy meters evolution in smart grids: A review. J. Clean. Prod. 2019, 217, 702–715. [Google Scholar] [CrossRef]
  7. Biblioteca del Congreso Nacional de Chile. Experiencia Comparada Instalación de Medidores Inteligentes. 2019. Available online: https://obtienearchivo.bcn.cl/obtienearchivo?id=repositorio/10221/27088/1/BCN___Experiencia_comparada_medidores_inteligentes_25Marzo_edPM.pdf (accessed on 10 January 2022).
  8. Leitão, J.; Gil, P.; Ribeiro, B.; Cardoso, A. A Survey on Home Energy Management. IEEE Access 2020, 8, 5699–5722. [Google Scholar] [CrossRef]
  9. Ahmad, T.; Zhang, D. Using the Internet of things in smart energy systems and networks. Sustain. Cities Soc. 2021, 68, 102783. [Google Scholar] [CrossRef]
  10. Zhang, C.; Wu, J.; Zhou, Y.; Cheng, M.; Long, C. Peer-to-Peer energy trading in a Microgrid. Appl. Energy 2018, 220, 1–12. [Google Scholar] [CrossRef]
  11. Luo, Y.; Itaya, S.; Nakamura, S.; Davis, P. Autonomous cooperative energy trading between prosumers for microgrid systems. In Proceedings of the 39th Annual IEEE Conference on Local Computer Networks Workshops, Edmonton, AB, Canada, 8–11 September 2014; pp. 693–696. [Google Scholar]
  12. Kabalci, Y.; Kabalci, E.; Padmanaban, S.; Holm-Nielsen, J.B.; Blaabjerg, F. Internet of Things Applications as Energy Internet in Smart Grids and Smart Environments. Electronics 2019, 8, 972. [Google Scholar] [CrossRef]
  13. Li, W.; Yigitcanlar, T.; Erol, I.; Liu, A. Motivations, barriers and risks of smart home adoption: From systematic literature review to conceptual framework. Energy Res. Soc. Sci. 2021, 80, 102211. [Google Scholar] [CrossRef]
  14. Shakerighadi, B.; Anvari-Moghaddam, A.; Vasquez, J.C.; Guerrero, J.M. Internet of Things for Modern Energy Systems: State-of-the-Art, Challenges, and Open Issues. Energies 2018, 11, 1252. [Google Scholar] [CrossRef]
  15. Singh, S.; Roy, A.; Selvan, M. Smart Load Node for Nonsmart Load Under Smart Grid Paradigm: A New Home Energy Management System. IEEE Consum. Electron. Mag. 2019, 8, 22–27. [Google Scholar] [CrossRef]
  16. Mahapatra, B.; Nayyar, A. Home energy management system (HEMS): Concept, architecture, infrastructure, challenges and energy management schemes. Energy Syst. 2022, 13, 643–669. [Google Scholar] [CrossRef]
  17. Pierleoni, P.; Concetti, R.; Belli, A.; Palma, L. Amazon, Google and Microsoft Solutions for IoT: Architectures and a Performance Comparison. IEEE Access 2020, 8, 5455–5470. [Google Scholar] [CrossRef]
  18. Veloso, A.F.d.S.; de Moura, M.C.L.; Mendes, D.L.d.S.; Junior, J.V.R.; Rabêlo, R.A.L.; Rodrigues, J.J.P.C. Towards Sustainability using an Edge-Fog-Cloud Architecture for Demand-Side Management. In Proceedings of the 2021 IEEE International Conference on Systems, Man, and Cybernetics (SMC), Melbourne, Australia, 17–20 October 2021; pp. 1731–1736. [Google Scholar] [CrossRef]
  19. Palacios-Garcia, E.J.; Arbab-Zavar, B.; Vasquez, J.C.; Guerrero, J.M. Open IoT Infrastructures for In-Home Energy Management and Control. In Proceedings of the 2019 IEEE 9th International Conference on Consumer Electronics (ICCE-Berlin), Berlin, Germany, 8–11 September 2019; pp. 376–379. [Google Scholar] [CrossRef]
  20. Van Cutsem, O.; Bayram, I.S.; Maher, K.; Fosse, J.C. Demonstration of a Smart Villa Energy Monitoring Platform in Qatar. In Proceedings of the 2019 UK/ China Emerging Technologies (UCET), Glasgow, UK, 21–22 August 2019; pp. 1–4. [Google Scholar] [CrossRef]
  21. Pipattanasomporn, M.; Chitalia, G.; Songsiri, J.; Aswakul, C.; Pora, W.; Suwankawin, S.; Audomvongseree, K.; Hoonchareon, N. CU-BEMS, smart building electricity consumption and indoor environmental sensor datasets. Sci. Data 2020, 7, 241. [Google Scholar] [CrossRef] [PubMed]
  22. Rashid, H.; Singh, P.; Singh, A. I-BLEND, a campus-scale commercial and residential buildings electrical energy dataset. Sci. Data 2019, 6, 190015. [Google Scholar] [CrossRef] [PubMed]
  23. Tekler, Z.D.; Low, R.; Yuen, C.; Blessing, L. Plug-Mate: An IoT-based occupancy-driven plug load management system in smart buildings. Build. Environ. 2022, 223, 109472. [Google Scholar] [CrossRef]
  24. Krishnamurti, T.; Schwartz, D.; Davis, A.; Fischhoff, B.; de Bruin, W.B.; Lave, L.; Wang, J. Preparing for smart grid technologies: A behavioral decision research approach to understanding consumer expectations about smart meters. Energy Policy 2012, 41, 790–797. [Google Scholar] [CrossRef]
  25. Tekler, Z.D.; Low, R.; Blessing, L. User perceptions on the adoption of smart energy management systems in the workplace: Design and policy implications. Energy Res. Soc. Sci. 2022, 88, 102505. [Google Scholar] [CrossRef]
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Article Metrics

Citations

Article Access Statistics

Journal Statistics
Multiple requests from the same IP address are counted as one view.
Download PDF
Abdominal Aortic Thrombus Segmentation in Postoperative Computed Tomography Angiography Images Using Bi-Directional Convolutional Long Short-Term Memory Architecture
Previous
Evaluation of Doppler Effect Error Affecting the Radio Altimeter Altitude Measurements
Next