A low-cost, flexible system for energy monitoring in buildings

POLITECNICO DI MILANO

Dipartimento di Elettronica, Informazione e Bioingegneria

Laurea Magistrale-Ingegneria delle Telecomunicazioni

A LOW-COST, FLEXIBLE SYSTEM FOR ENERGY

MONITORING IN BUILDINGS

Relatore:

Prof. Matteo Cesana

Tesi di laurea di:

ARMAND HUQI

Matr. 835191

The ubiquitous nature of Internet of Things (IoT) has led to its applications in various domains like logistics, healthcare, industries, autonomous transport along with several others. Among these applications of IoT, we illustrate the use of IoT in smart buildings for Energy Monitoring. A smart building comprises a building equipped with sensors, information appliances, network communications and automation equipment, that pro-vide a comfortable, safe, green and convenient living environment. Furthermore, the re-cent advances in technologies encompassing sensors, micro-motor systems and wireless communication has facilitated the intercommunication among the embedded systems in a smart home environment.

Utility bills display the amount of energy being used – if they are analyzed, however they do not reveal when, where or how that energy is consumed. Detailed measurement of energy usage in real time can provide an awareness of the patterns of energy usage throughout a building. The knowledge could help decision support systems and orga-nization management in the consideration of the energy usage of process structures and components in a building.

Studies [1] have suggested that more energy can be saved in buildings with direct real-time energy consumption feedback as compared to those with indirect feedback like monthly bills. We have developed a low-cost interactive energy management system that permits the residents understand their electricity usage patterns and adapt their behaviour to reduce their energy footprint. Furthermore, such a system can also be linked with generation estimates and monitoring systems to further optimize the building level con-sumption [2].

While the costs of sensors and data storage have become cheaper, the cost of complete monitoring system on the other hand remains high for large-scale deployment. This has been a major factor that has kept these system from being used in a larger scale.

The work in this thesis aims at building a low-cost energy monitoring platform that can help drop the initial deployment cost. A literature survey on the existing solutions have revealed that the primary cost of a generic IoT system is the one regarding the deployment [3]. We investigated methods that permitted to deploy the same system with lower costs and deduced that our primary area of focus were the sensors and the gateway. With the development in the area of MEMS and sensing technologies, the prices of sensors has dropped [4], however the costs of a gateway remains still high. Through the scope of this work, we developed a suitable IoT gateway that could be used in conjunction with already in place architectures. We illustrate the challenges involved in building such a gateway, the steps involved and the improvements we achieved with the deployment of the gateway in a smart building.

Abstract IT

La versatilit`a del Internet of Things (IoT) ha portato a un suo utilizzo in vari settori come logistica, sanit`a, industrie, trasporto autonomo etc. Tra queste applicazioni IoT, noi illustriamo l’uso dell’Internet of Things in edifici intelligenti per il monitoraggio en-ergetico. Un edificio intelligente `e un edificio dotato di sensori, dispositivi informatici, comunicazioni di rete e dispositivi automatici, che offrono un ambiente confortevole, si-curo, verde e conveniente. Inoltre, i progressi nelle tecnologie recenti dei sensori, sistemi micro-motore e comunicazione wireless ha facilitato l’intercomunicazione tra i sistemi embedded in un ambiente domestico intelligente. Le bollette mostrano la quantit`a di ener-gia utilizzata se sono analizzate, tuttavia esse non rivelano quando, dove e come l’enerener-gia viene consumata. La misura dettagliata del consumo di energia in tempo reale in grado di fornire una consapevolezza dei modelli di consumo di energia all’interno di un edifi-cio. Gli studi hanno suggerito che pi`u energia pu`o essere salvata in edifici con feedback in tempo reale rispetto a quelli con feedback indiretto come le bollette mensili. Abbiamo sviluppato un sistema di gestione dell’energia interattivo a basso costo che permette ai res-identi a capire i loro modelli di utilizzo dell’energia elettrica e migliorare le loro abitudini per ridurre il loro consumo energetico. Inoltre, questo sistema pu`o anche essere collegato con sistemi di controllo per ottimizzare ulteriormente il livello consumo dell’edificio

Mentre i costi di sensori e di memorizzazione dei dati sono diminuiti, il costo del sistema di monitoraggio completo invece rimane alto per la distribuzione su larga scala. Questo `e stato un fattore importante che no ha permesso a questi sistemi di essere uti-lizzati in larga scala. Il lavoro di tesi mira a costruire una piattaforma di monitoraggio energetico a basso costo che pu`o aiutare ad abbassare il costo dell’installazione iniziale. Un’indagine fatta sulle soluzioni esistenti ha rivelato che il costo principale di un sistema IoT generico `e quello relativo al gateway. Abbiamo studiato i metodi che ci hanno per-messo di implementare lo stesso sistema con costi inferiori e dedotto che ci dovevamo focalizzare su i sensori e il gateway. Con lo sviluppo nel settore delle tecnologie di rileva-mento MEMS, il prezzo dei sensori `e sceso, tuttavia il costo di un gateway rimane ancora elevato. Attraverso questo lavoro abbiamo sviluppato un gateway IoT che potrebbe essere utilizzato con architetture gi`a esistenti. Illustriamo le sfide affrontante nella costruzione di un tale gateway, le varie fasi e i miglioramenti che abbiamo ottenuto con una prova del gateway in un prototipo.

1 Introduction 1

1.1 State of the Art . . . 3

2 Components 6 2.1 The Gateway . . . 7 2.1.1 HLK-RM04 . . . 8 2.2 Sensors . . . 9 2.3 Actuators . . . 12 2.4 Transport-MQTT . . . 13 2.5 Data Storage . . . 14 2.6 Data Visualization . . . 15 3 Implementation 17 3.1 Gateway and Sensors . . . 18

3.1.1 OpenWRT Build Environment . . . 18

3.1.2 Installing Linux on the HLK-RM04 . . . 20

3.1.3 Sensor Wiring . . . 20 3.1.4 Software . . . 21 3.2 Server Side . . . 24 3.2.1 The MQTT Broker . . . 24 3.2.2 Database . . . 25 3.2.3 Grafana . . . 26 4 Testing 29 4.1 Desirable Features . . . 29

4.2 Design and Implementation . . . 31

4.3 Test Enviroment . . . 33

4.3.1 Broker Reconnection Test . . . 34

4.3.2 Accuracy Testing . . . 35

5 Observations 37

Appendices 39

LIST OF FIGURES

3.2 OpenWRT Build System . . . 19

3.3 Developement Kit . . . 20 3.4 Wiring . . . 21 3.5 Terminal screenshot . . . 23 3.6 Broker Overview . . . 25 3.7 Grafana . . . 27 3.8 Wiring . . . 28 4.1 3G Connection . . . 32

Chapter 1 Introduction

Chapter 1

Introduction

The work on this thesis is focused on IoT applications to smart buildings. In the traditional building scenario, the tenants of the building use the appliances and receive the bills to be paid periodically. It has been documented that when the user is aware of the energy being consumed, the user tends to be thrifty with the energy consumption. IoT makes the use of sensors and embedded systems to monitor the usage of energy and provide the user with periodic updates on the energy consumptions. However, the prices of the end to end system is on the higher side due to the high costs of deploying the system [5]. The aim of our work was to fill in this gap and to build an end to end system for a smart building while reducing the overall costs and not compromising on the features of the system. The most costly component for an initial deployment of an energy monitoring system remains the IoT gateway. Indeed, while the cost of sensors and data storage have become cheaper, the cost of complete monitoring system remain high for everyone to use. This has been a major factor that has kept these systems from being used in a larger scale, with the cheapest commercial system for energy monitoring starting at 100 euros.

We developed a low-cost real-time energy measurement and actuating system by us-ing a cheap and yet very powerful router board as our IoT Gateway. The system developed in the context of this thesis, is an end-to-end system involving accumulation of the data from the end devices equipped with sensors to storage and processing of the data. The fundamental features that were taken in consideration were: security, a backup trans-mission medium for outbound data, an efficient medium for communication, possibility

of remote updates, tolerability of power conditions, preparation for intermittent and dy-namic connectivity issues. The system board chosen is selected for its computation and communication abilities as well as it’s relatively low cost and ease of programming and operation. The system we have designed and developed has a price of about 20 euros. The cost can be brought further down when the system goes to mass production. We found out that router architecture is actually very good for use as an IoT gateway. Using OpenWRT makes this implementation very flexible, as we can add different types of radio connec-tions to this board. We can add for example a GPRS/UMTS or Zigbee connection. This is made very simple by OpenWRT. For this project we used a cheap Router Board. How-ever, there are many more advanced routers with lots of processing power and network speed to fulfill more and more local processing and faster transfer rates at the same time. We implemented a possible framework for building intelligent systems using hardware we already have in our houses. To showcase our work in a real life scenario, we presented a prototype of our product at a symposium in Milan. Furthermore, we conducted a series of tests on the system which helped us better understand the behavior of the system under different conditions. Indeed we evaluated the performance of the gateway in terms of the features and requirements of a standard IoT gateway and have concluded that our gateway fulfills all of these requirements, while also minimizing the overall deployment costs.

The primary scope of this work was to link and bridge the gap between energy con-sumption and the physical operations consuming that energy. We reviewed the existing technologies and the state of the art to conclude that the costs of deployment were high in these kinds of systems. Our work was aimed to design and develop a system that would reduce the costs without compromising the functionality of the existing systems. While researching on the cost of a system, we found out that the most costly piece was in the form of the IOT gateway . We managed to built a cheaper gateway and this led to an overall cheaper system. The system that we built managed to deliver very good reliability during the tests we conducted on it. In the future, the system could be further developed to get more insights on energy usage profiles. By learning the habits of the consumers, in the near future it could also be possible to give hints on how to individualize energy utiliza-tion, or when possible, the system could automatically take action by remotely powering

Chapter 1 Introduction on or off devices. Another aspect that could be further enhanced is the use of a better voltage and current sensor. This could further help fine tune the profiles for every build-ing. Finally, building a mobile app for android and IOS nowadays is the norm, as it would make the system more appealing to new customers.

1.1

State of the Art

The Internet of Things (IoT) is a novel concept connecting physical objects to the Inter-net, changing the way we look at our surroundings and the way we are interacting with objects around us. Internet is moving from connecting people with people to connecting people with things and things with things as well. The IoT is playing a major role in this transformation of the internet. IoT can be defined as a network of objects which have the following properties; these objects should be able to connect to the internet and these objects should be uniquely addressable in the internet. For example, the oven in the house can be such an object or ‘thing’ connected to the internet. The oven can let the user know, that he left it on even after he left the house. The user can receive the message over the internet and may also choose to turn off the oven remotely leveraging the services offered by IoT. With the simplicity, utility and pervasiveness that IoT has brought with it, IoT has found applications in various domains ranging from building automation, smart transport systems and industrial automation to healthcare, disaster management and emergency re-sponse services.

Energy Monitoring: Among the various domains of IoT applications, the work on this thesis is focused on the area of applying IoT to smart buildings. In the traditional building scenario, the tenants of the building use the appliances and receive the bills to be paid periodically. This results in a gap between the user and the knowledge of the amount of energy the user consumes. This gap can be fulfilled with the help of the Internet of Things by deploying an energy monitoring system which makes the use of sensors and embedded systems to monitor the usage of energy and provide the user with periodic

up-dates on the energy consumptions. Studies have suggested that when the user is aware of the energy being consumed, the user tends to be thrifty with the energy consumption [2]. Thus, energy is saved in the process. The architecture of a smart building involves the use of embedded sensors in the building to gather data on energy consumption and push the data to a gateway [6]. However, the prices of the end to end system is on the higher side due to the high costs of deploying the system. Our work is aimed at filling this gap to build an end to end system for a smart building while reducing the overall costs and not compromising on the features of the system.

Volume of Energy Monitoring Data: When the server requests measurement informa-tion from a house, the gateway returns the requested informainforma-tion as a 64-byte response comprised of the meter identifier, current time, device type/ address, (temperature, humid-ity) instantaneous and cumulative power consumption. It is worth noting that since the size of the packet payload is small (64 bytes), this does not place any significant burden on the communication technology required to transport this information. We observed that, for the most aggressive data collection regime (once every sec), close to 5.4 megabytes (MB) of data is logged per day, per building at the data collection server. For example, this translates to 1944MB per year. In terms of monetary costs for the storage required, it is estimated to be roughly 10 Euros. This is miniscule in comparison to some of the other costs, notably the ones related to deployment. While the cost of sensors and data storage have become cheaper, the cost of complete monitoring system on the other hand remain high for everyone to use. This has been a major factor that has kept these systems from being used in a larger scale [5]. The most costly component for an initial deployment of an energy monitoring system remains the IoT gateway. The cheapest commercial systems for an energy monitoring starts at 100 euros.

IoT Gateway: IoT gateways are devices positioned between edge systems and the cloud. They perform functions such as protocol translation, data processing/storage/filtering along with device [7]. Modern IoT gateways also play an increasingly important role in helping to provide edge analytics so that only the most important information and alerts are sent up to the cloud to be acted upon. IoT Gateways close the gap between devices in the field and the Cloud, where data is collected, stored and manipulated by business

appli-Chapter 1 Introduction cations, facilitates the seamless integration of wireless sensor networks and mobile com-munication networks or Internet, and the management and control with wireless sensor networks. [8] In this scenario, various common home appliances, such as TV set, washer, lights, camera, which are embedded with sensor and wireless communication modules, can construct several ad- hoc in-home wireless networks. The in-building IoT Gateway integrates several common ad-hoc network protocols and supports the intercommunica-tion among the equipments with different network protocols. The users can control the in-home smart equipments through the IoT Gateway. Moreover, high-end gateways offer local processing and storage capabilities to provide off-line services and almost real time control over the devices in the field. In this work, a low-cost real-time energy measure-ment and actuating system is developed by using a cheap and yet very powerful router board as our IoT Gateway. The system board chosen is selected for its computation and communication abilities as well as it’s relatively low cost and ease of programming and operation. Its ability to communicate with a wide variety of modern and legacy systems facilitating the gathering of data to a central location for analysis. By using the Open-WRT linux firmware we dramatically enhanced the capabilities of this board. Adding IoT gateway capabilities resulted in a natural transformation of it. OpenWRT is a linux system specific for routers, it means that it has better routing capabilities than most of the vendor specific firmwares and, what is more important, it is built with strong security in mind. We ended up with a very secure IoT gateway that we can program to do many things in a very simple and intuitive way. For example, adding different types of wireless connectivity resulted to be a straightforward operation. We tested the board with Wifi, Zigbee, 6LOWPAN and RF and deduced that it is quite simple and stable. The system we have designed and developed has a price of about 20 euros. The cost can be brought further down when the system goes to mass production. We evaluated the performance of the gateway in terms of the features and requirements of a standard IoT gateway and have concluded that our gateway fulfills all of these requirements, while also minimizing the overall deployment costs.

Chapter 2

Components

One of the primary applications of the IoT lies in monitoring of various types. Among these applications, energy monitoring has been a key aspect to monitor and optimize the use of resources in energy consumption. Even though a lot of research has been already performed in this area, there is still a lack of a viable and penetrative low-cost solution. We try to address this issue in our work by offering a working proof of concept of an economic, yet powerful energy monitoring system.

The system developed in the context of this thesis, is an end-to-end system involving accumulation of the data from the end devices equipped with sensors to storage and pro-cessing of the data. In this chapter, we discuss the optimization of costs in terms of the choice of components at each layer of the architecture of our system to build an overall optimized proof of concept.

Chapter 2 Components

Figure 2.1: System Overview

2.1

The Gateway

Gateways are emerging as a key element of bringing legacy and next-gen devices to the IoT. They integrate protocols for networking, help manage storage and edge analytics on the data, and facilitate data flow securely between edge devices and the cloud. The first thought of a local gateway for the initial development stages brings to mind the widely used ones: Rasperry Pi, BeagleBone to name a few. These systems are usually very good for this purpose. They can use a Linux distribution and have multiple I/O ports. However, they are still a bit too costly in terms of scalability. Nowadays there are more and more SoC (System on Chip) capable of doing the same things and cost sensibly less. What we needed is a small SoC capable of running linux equipped with multiple I/O ports.

The Ralink RT5350F is a Wi-Fi System-On-Chip (WiSoC), typically used in access point and router platforms. It has many Input/Output ports and, is one of the few devices with two on-board UART interfaces. Most of the end-device in use today are using the UART interface directly or through wireless access to communicate with the gateway.

The SoC alone costs as low as 2 dollars. With commercial solution using the same chip already available for just 8-9 dollars. One of these commercial solution is the

HLK-Figure 2.2: RT5350F

RM04 board produced by a HLK-Tech based in Shenzen, China. Using it with the ven-dor’s firmware is insufficient for a gateway since its functionality is very limited. We want to install on it a Tailored Linux distribution called OpenWRT. OpenWRT is a Linux Distribution specific for these types of embedded devices.

2.1.1

HLK-RM04

HLK-RM04 is primarily a small router produced by HLK-Tech that is equipped with [9]: 2 uart ports, 1 I2C port, 1 I2S port, Up to 12 GPIOs, 2 ethernet ports, 1 usb 2.0 port. There are two commercial versions available:

1. 4MB onboard flash storage and 16MB Ram 2. 8MB onboard flash storage and 32MB Ram

The cost is almost the same, but for the purpose of installing OpenWRT on it, is better to use the second option. This gives the possibility to run more programs on the same board. With more ram available it is possible to install many more packages. By having more ram it also allows to use a web interface called LUCI that makes interacting with this gateway

Chapter 2 Components

Figure 2.3: HLK-RM04

2.2

Sensors

In order to measure electricity, a Voltage and Current measurement sensor is needed. SD3004 is a Energy Measurement SoC from SDIC Microelectronics Co LTD that has thefollowing properties:

• High precision energy measurement

• Provides RMS voltage and RMS current Calculates active power and power factor Calculates AC frequency

• Calculates total energy usage over time

• 24 seg × 4 com LCD drivers, can be switched to become I/O ports • Supports LED driving

• Real time clock, can output second signal • UART and I2C interfaces

It greatly simplifies circuit designs and reduces production costs for energy meter, metering socket and similar products. The most interesting feature alongside the cost and functions, is the presence of the UART and I2C ports. This means it can be connected

to the Gateway in various forms, including Wired, Wi-fi, RF or ZigBee [10]. A commer-cial product based on SD3004 [11] is the PZEM-004T, a power meter that is made by PeaceFair Electronics [12].

Figure 2.4: PZEM-004T PZEM-004T communication protocol

1. Set the communication address: 192.168.1.1

Send command: B4 C0 A8 01 01 00 1E Reply data: A4 00 00 00 00 00 A4 Note: The above example illustrates that setting the communication address as 192.168.1.1 (the user can set their own address based on their preferences and needs).

2. Set the power alarm threshold:20 KW

Send command: B5 C0 A8 01 01 14 33 Reply data: A5 00 00 00 00 00 A5

Note: 14 in the sending command is the alarm value (14 is a hexadecimal data representation, which converted to decimal is 20). What you should note is the power alarm value of this module is based on KW units, which means the minimum alarm value is 1KW, the maximum value is 22KW.

3. Read the current voltage

Chapter 2 Components Note: Reply voltage data is D1D2D3 = 00 E6 02, 00 E6 represent the integer-bit of the voltage, 02 represent the decimal of the voltage, the decimal is one digit, converts 00 E6 to decimal is 230; converts 02 to decimal is 2, so the current voltage value is 230.2V.

4. Read the current current

Send command: B1 C0 A8 01 01 00 1B Reply data: A1 00 11 20 00 00 D2

Note: Reply current data is D2D3 = 11 20, 11 represent the integer-bit of the cur-rent, 20 represent the decimal of the curcur-rent, the current decimal is two digits, converts 11 to decimal is 17; converts 20 to decimal is 32, so the current current value is 17.32 A.

5. Read the current power

Send command: B2 C0 A8 01 01 00 1C Reply data: A2 08 98 00 00 00 42

Note: Reply power data is D1D2 = 08 98, converts 08 98 to decimal is 2200, so the current voltage value is 2200W.

6. Read the energy

Send command: B3 C0 A8 01 01 00 1D Reply data: A3 01 86 9F 00 00 C9

Note: Reply energy data is D1D2D3 = 01 86 9F, converts 01 86 9F to decimal is 99999, so the accumulated power is 99999Wh.

Sending commands and replying data are done automatically as shown above, the data are expressed in hexadecimals; the last byte of the sending and replying data are 1E and A4, belong to cumulative sum. At sending commands: B4 + C0 + A8 + 01 + 01 + 00 = 21E (use the hexadecimal addition), the cumulative sum data is 21E, take the last two bytes 1E to be used the cumulative sum data in sending commands; data in reply: A4 + 00 + 00 + 00 + 00 + 00 = A4 (use the hexadecimal addition),the cumulative sum data is A4,which is the cumulative sum data in reply.

2.3

Actuators

Here we mostly use relays to control turning on and off different appliances. A relay is an electrically operated switch. Many relays use an electromagnet to mechanically operate a switch, but other operating principles are also used, such as solid-state relays. Relays are used where it is necessary to control a circuit by a separate low-power signal, or where several circuits must be controlled by one signal There mainly two types of relays used.

• Voltage controlled with high or low level control • UART controlled relay.

We prefer to use the latest as it gives more options, and can control many appliances with just three wires. We use ICStation UART Control [13] 5V 4-Channel Relay Module

Figure 2.5: ICS Relay Relay Uart Control The protocol is very simple. 1. Send 0x50 command to see if the device is alive 2. Wait for reply that should be 0xAB

Chapter 2 Components 4. After 0x51 command each bit we send controls a relay.

Example 1111 all relays are on 1011 second relay off and so on.

2.4

Transport-MQTT

MQTT stands for MQ Telemetry Transport. It is a publish/subscribe, extremely simple and lightweight messaging protocol, designed for constrained devices and low-bandwidth, high-latency or unreliable networks. The MQTT protocol is based on the principle of publishing messages and subscribing to topics, or ”pub/sub”. Multiple clients connect to a broker and subscribe to topics that they are interested in. Clients also connect to the broker and publish messages to topics. Many clients may subscribe to the same topics and do with the information as they please. The broker and MQTT act as a simple, common interface for everything to connect to. This means that you if you have clients that dump subscribed messages to a database, to Twitter, Cosm or even a simple text file, then it becomes very simple to add new sensors or other data input to a database, Twitter or so on [14] [15].

Messages in MQTT are published on topics. There is no need to configure a topic, publishing on it suffices. Topics are treated as a hierarchy, using a slash (/) as a separator. This allows sensible arrangement of common themes to be created, much in the same way as a filesystem. For example, multiple computers may all publish their hard drive temperature information on the following topic, with their own computer and hard drive name being replaced as appropriate:

sensors/COMPUTERNAME/temperature/HARDDRIVENAME

Clients can receive messages by creating subscriptions. A subscription may be to an explicit topic, in which case only messages to that topic will be received, or it may include wildcards, that is subscring to all topics available on the broker.

Figure 2.6: MQTT Overview

2.5

Data Storage

InfluxDB is a time series database built from the ground up to handle high write and query loads. InfluxDB is meant to be used as a backing store for any use case involving large amounts of timestamped data, including DevOps monitoring, application metrics, IoT sensor data, and real-time analytics [16] .

Here are some of the features that InfluxDB currently supports that make it a great choice for working with time series data.

• Custom high performance datastore written specifically for time series data. The TSM engine allows for high ingest speed and data compression.

• Written entirely in Go. It compiles into a single binary with no external dependen-cies.

• Simple, high performing write and query HTTP(S) APIs.

• Plugins support for other data ingestion protocols such as Graphite, collectd, and OpenTSDB.

Chapter 2 Components • Expressive SQL-like query language tailored to easily query aggregated data. • Tags allow series to be indexed for fast and efficient queries.

• Retention policies efficiently auto-expire stale data.

• Continuous queries automatically compute aggregate data to make frequent queries more efficient.

• Built in web admin interface.

InfluxDB uses a host‘s local time in UTC to assign timestamps to data and for coordi-nation purposes. Use the Network Time Protocol (NTP) to synchronize time between hosts; if hosts‘ clocks aren’t synchronized with NTP, the timestamps on the data written to InfluxDB can be inaccurate [17].

Telegraf — Time Series Data Collection Telegraf is a plugin-driven server agent for collecting and reporting metrics. It has plugins or integrations to source a variety of metrics directly from the system it is running on, pull metrics from third party APIs, or even listen for metrics via a statsd and Kafka consumer services. It also has output plugins to send metrics to a variety of other datastores, services, and message queues, including InfluxDB, Graphite, OpenTSDB, Datadog, Librato, Kafka, MQTT, NSQ, and many others. We use it here to collect MQTT messages and write them to the influxDB [17].

2.6

Data Visualization

Grafana allows you to query, visualize, alert on and understand your metrics no matter where they are stored. Create, explore, and share dashboards with your team and foster a data driven culture [18].

Visualize: Fast and flexible client side graphs with a multitude of options. Panel plugins for many different way to visualize metrics and logs.

Alerting: Visually define alert rules for your most important metrics. Grafana will continuously evaluate them and can send notifications.

Notifications: When an alert changes state it sends out notifications. Receive email notifications or get them from Slack, PagerDuty, VictorOps, OpsGenie, or via webhook.

Dynamic Dashboards: Create dynamic and resuable dashboards with template vari-ables that appear as dropdowns at the top of the dashboard.

Built-in InfluxDB Support: Rich query editor with measurement, tag and tag value completion Automatic handling of group by time Templating queries for generic dash-boards. Ad hoc filters for exploration dashboards

Chapter 3 Implementation

Chapter 3

Implementation

This chapter is an explanation of the work we have done to put the pieces together in order to have a fully working IoT system, and it is divided in two parts.

1. Gateway and Sensors: This part illustrates the requirements for having a working gateway, capable of interacting with sensors and actuators.

2. Server-Side : This part includes the steps and software we used on the server for gathering, visualizing and analyzing the data from the gateway

3.1

Gateway and Sensors

3.1.1

OpenWRT Build Environment

OpenWrt is a highly extensible GNU/Linux distribution for embedded devices. It is built from the ground up to be a full-featured, easily modifiable operating system for small net-work devices [19]. OpenWrt provides features similar to a modern package-based Linux distribution: a built-in web server with CGI support, an SSH server and most impor-tantly, a package management tool, ipkg. Using ipkg, new applications, tools and kernel drivers can be added and removed at runtime, without requiring a reboot. OpenWrt is loaded onto the prospective router by using the standard firmware upgrade mechanism provided by the router. However, in the sense that it does not provide a complete desk-top experience, it still provides much of the functionality expected from a modern Linux distribution [20]. Instead of trying to create a single, static firmware, OpenWrt provides a fully writable filesystem with package management. This allows the user to customize the device through the use of packages to suit any application. The OpenWrt build system is a set of Makefiles and patches that allows users to easily generate both a cross-compilation toolchain and a root filesystem for embedded systems. Embedded systems use a different processor and require a cross-compilation toolchain - a compilation toolchain that runs on a host system but that generates code for a target system (and target processor’s in-struction set architecture (ISA)). For example, if the host system uses x86 and the target system uses MIPS32 (our case), the regular compilation toolchain of the host runs on x86 and generates code for x86, while the cross-compilation toolchain runs on x86 and generates code for MIPS32 [19].

While it is possible to manually configure and compile your own software, OpenWrt’s build system automates this process to work on the instruction set architecture of most embedded systems. For implementing a build system for OpenWrt a Linux OS host is needed, in this case a Ubuntu 14.04 on a VirtualBox was used. Using the Build System you can select the specific properties for the used board.

Chapter 3 Implementation

Figure 3.2: OpenWRT Build System For our SoC :

1. Target System (Ralink RT288x/RT3xxx) 2. Subtarget (RT3x5x/RT5350 based boards) 3. Target Profile (HLK-RM04)

Moreover luci-https web interface and libmosquitto packages are selected for built-in installation. Luci is a web interface that will allow us to interact with the gateway from a web browser. Libmosquitto is an MQTT lightweight and compact Library. With the right options chosen its time to compile the firmware. Usually the first time it will take about 2-3 hours to compile. After that, the next times it will be considerably faster. If the compilation process is successful it will produce a compiled Linux image, specific for the board in the bin directory of the OpenWRT buildroot.

3.1.2

Installing Linux on the HLK-RM04

Installing linux on this board can be hard the first time. However once the right procedure is understood and mastered, the process becomes straightforward. We make use of the development board that comes with it. It adds two Ethernet ports and pin-outs for the other ports. It also comes with a usb to uart adapter, and Lan cable. We use two small programs to install the firmware: TFTP server and a Serial monitor program (putty).

Figure 3.3: Developement Kit

TFTP Server allows a client to get a file from a remote host. One of its primary uses is in the early stages of nodes booting from a local area network. In most routers its purpose is mostly firmware remote flashing. The serial monitor is used to interact with the board on initial stage of the boot process. This is done pressing number 2 on the keyboard. This tells the bootloader to install the firmware that is located on the TFTP server. After that it will reboot in two minutes and on the next reboot we will have a fully functional gateway with Linux on top of it.

3.1.3

Sensor Wiring

Since the chosen energy meter has a UART interface, we used that to connect and interact with the gateway. This can be done in various ways. The simplest way of doing it is by connecting it directly through one of two UART ports on the gateway. Another option is

Chapter 3 Implementation even RF. We have tried Wired, Bluetooth and RF and it works really well.

Figure 3.4: Wiring

3.1.4

Software

With all the previous steps already done, we started to focus on the control software for the gateway. The first things was to make sure that we were are able to communicate with the sensor. With the sensor properly connected we started to think on how to make a small program that reads the measurements and sends the values to the server through MQTT protocol. The PZEM-004T needs to be told what measures we want. It gives readings for, Voltage, Current, Instantaneous power and accumulated energy.

The software basically consists of 5 parts: 1. It opens the serial port

2. Sends the reading commands as specified in PZEM-004T communication protocol 3. Reads the data from the sensor

4. Closes the serial port

5. Puts the readings into variables that can be used later to send them in various pro-tocols

6. Finally we send the reading using the MQTT protocol to the server’s address The code is organized such that each reading has its own topic.There are four reading with four topics: ”volt”, ”ampere”, ”watt” and ”Wh”. This way we can subscribe at the

broker and get the reading we want. At first some tests were done using a local Linux-PC connected directly to the Energy Meter through a ”USB to UART” adapter . The reason for this is to make things faster to debug. In order for the gateway to be able to run the code, the code should be cross-compiled for the MIPS architecture. After some testings we finally had a working program. Once there was a working copy of the code, the program was ready to be cross-compiled. The code can be found in Appendix.

Here is the debug output for every reading we get from the meter. It shows every byte of each reading. According to the protocol these readings are converted as below. volt=225.6 ampere=0.15 watt=61.0 whour=77

1. result[0]=160 a0 result[1]=0 00 result[2]=225 e1 result[3]=6 06 result[4]=0 00 result[5]=0 00 result[6]=135 87 Using the 2nd and third byte we get 225.6. In the results it is shown the hexadecimal and decimal value. Normally from the Uart port of the meter the reading are in hexadecimal, and we need to convert them one by one and combine the bytes together in order to have a proper reading of the result 2. result[0]=161 a1 result[1]=0 00 result[2]=0 00 result[3]=15 2c result[4]=0 00

re-sult[5]=0 00 result[6]=205 cd

3. result[0]=162 a2 result[1]=0 00 result[2]=61 40 result[3]=0 00 result[4]=0 00 re-sult[5]=0 00 result[6]=226 e2

4. result[0]=163 a3 result[1]=0 00 result[2]=0 00 result[3]=77 4d result[4]=0 00 re-sult[5]=0 00 result[6]=240 f0

The cross compilation process is not trivial and should be done using the OpenWrt BuildRoot. This however can only be done after we have previously compiled the Linux image for our board/gateway. We encountered an issue while trying to run the compiled software on the gateway. It looked like it was properly working but the data we were receiving were completely wrong. The problem we found out later, was that the uart interface is used as a console normally. If you try to use it just like it is configured the data you will get will be mixed with console output messages. So in order to make it work

Chapter 3 Implementation

Figure 3.5: Terminal screenshot

properly, the console needs to be terminated. This was done by commenting the console start on the initial startup scripts found in /etc/inittab

::sysinit:/etc/init.d/rcS S boot

::shutdown:/etc/init.d/rcS K shutdown

#::askconsole:/usr/libexec/login.sh //we commented this line out Now that the port was free for us to use, we tried the program and it worked the same

as it previously did in the Linux-pc we were using for the tests. Another small program that we had to write, was the relay control software. Being that the communication is quite simple, writing it after the Meter program was slightly faster. We used the same logic for communicating to the UART port.

At this point we were confident for the gateway and sensors/actuators working to-gether, and the next step was the server-side for the system.

3.2

Server Side

The server can be a local machine running Linux or it can be a cloud platform like Amazon AWS, Microsoft Azure etc. We started out by building a server on a local computer, and only after we had a good working server, it was deployed on the cloud.

3.2.1

The MQTT Broker

The gateway can read the energy values and publish them as topics using the MQTT protocol. It needs to connect to an MQTT broker on the server. Today there are many choices on which broker to use, some of them being, Mosquitto, RabbittMQ, HiveMQ etc.

Mosquitto is open source and is written in C. It fully supports MQTT 3.1 and MQTT 3.1.1. Its binary is very small and mosquitto also works well on constrained devices. For cloud deployments with tens of thousands of concurrent connections, the single-threaded nature could become a challenge, so you should do some test deployments ini-tially. Mosquitto is a suitable choice in terms of stability [21].

RabbitMQ is a software which supports multiple protocols out-of-the-box. Its MQTT support is implemented as an adapter which translates to AMQP and does not implement all MQTT core features. It’s highly scalable and reliable and there are many deployments using AMQP. It’s written in Erlang and should be trivial to install on most systems [22].

For our test, we used Mosquitto as it is user-friendly to install and use. On the cloud however we used RabbitMQ because we could use MQTT alongside other protocols like STOMP. Once the broker is up and running, the clients can publish or subscribe to topics. In this case the Gateway will publish the readings with specific topics for each.

Chapter 3 Implementation

Figure 3.6: Broker Overview

3.2.2

Database

The influxDB is a very fast time-series DB, it is simple and can be queried using its own web interface. Using the web interface, it is very straightforward to create Databases, users, roles etc. By default, InfluxDB uses the following network ports:

• TCP port 8086 is used for client-server communication over InfluxDB’s HTTP API • TCP port 8088 is used for the RPC service for backup and restore

In addition to the ports above, InfluxDB also offers multiple plugins that may require custom ports. All port mappings can be modified through the configuration file, which is located at /etc/influxdb/influxdb.conf for default installations. By writing influx on the terminal gives access to influx daemon. Here we added an admin user and a Database called Grafana where we will store the data.

However you can’t write topics directy to the database. This is when Telegraf in comes in handy. Telegraph has many plugins, one of them being the MQTT subscriber plugin. Once installed and configured this plugin will subscribe to the desired topics on the Broker and will write the values on the Database [17]. This is done preserving the topic names, that are used as fields in the database.

We were having some problems when trying to write data from the broker to the database using Telegraf. The problem was the correct syntax of the MQTT published data. We found out that the value topics had to be JSON format. This meant we had to

go back to the gateway code and modify the mqtt publish line. After some more tests everything was working good. We write on the DB 4 values from 4 topics namely, Volt, Ampere, Watt, Joule.

3.2.3

Grafana

Grafana is a powerful visualization tool, that allows the use a great variety of databases as visualization sources. It is very intuitive, and it is possible to create multiple dashboards, with each of them showing different measurements at the same time. This can also be done with various types of formulas like instantaneous value, mean value, previous history etc.

The Grafana GUI is accessible using a web browser that points to http://server-ip:3000 The first step is to add the InfluxDB as the source, by pointing to the right address and port (localhost:8086 in this case) and also where influx is installed. Once the source is properly installed and configured there are many ways of visualizing the data.

We have created four dashboards, one for each measure we got from the meter. The dashboards have different type of visualization options. Many mathematical functions can be implemented on the data and visualize directly the output (median, mean, derivate etc..).

With dashboards we can have insights on the Energy usage on a building. Historical data can be used as well to get the usage patterns and possibly correct them for better energy efficient management. Using alerts on the dashboards we can create specific rules that will notify or take action as programmed [18]. For example, you can put a maximum energy usage during certain times of the day, and turn on or off appliances. This is done using the relays.

Another option could be adding temperature sensors and regulating the air conditioning of the building or specific room accordingly.

Chapter 3 Implementation

Figure 3.7: Grafana

Proof Of Concept To showcase our work in a real life scenario, we presented a pro-totype of our product at a symposium in Milan. The idea of presenting the proof of concept was simple. We simulated a building, where the sensors, actuators and gateway are present along with a remote server that runs the software used for this project. As a server we can use any type of computer powerful enough to run a full-fledged Linux Dis-tribution. For this prototype a Raspberry pi acted as the server. This means installing and configuring the server software on it. The gateway was connected using wireless directly to the server (Raspberry) or through Internet.

To make it more portable, a direct wifi connection was set between the gateway and the Raspberry. This means that the raspberry acts also as a wifi Access point for the gateway to connect to. Being that we now had a wifi network, it was easy to connect to it directly from any device and to have access to the Grafana web-interface. This way all of the potential partecipants could have a quick glance of the measurements in real time.

A script on the server managed to start all the pieces of the software at the system boot. RabbitMQ was used as the MQTT broker, Telegraf then subscribes to all the topics and write them on the Influx database. The data this way is directly accessible using grafana web interface from any device connected to the same network. We used small fan that

Figure 3.8: Wiring

was attached to the meter for the measures. A simple routine would turn off the fan once it reached 100Wh of consumed energy. When this happens the routine resets the board memory and restarts the showcase.

Chapter 4 Testing

Chapter 4

Testing

IoT is definitely getting traction, but behind this flowery picture is the force driving this whole IoT era, THE NETWORK. Robust and secure networking is the single most im-portant need for IoT and that’s where IoT gateways play an imim-portant role as it is the most complex piece of the hardware of the system.

With networked IoT devices comes the need for a robust and secure medium of infor-mation exchange. IoT gateways not only abstract the medium of communication but also provide the secure channel required for the transmission of this data. Gateways usually run real-time operation systems (RTOS) or a form of Linux to drive their systems like we are. Hardware and software level encryption is built right into the gateway to provide a secure channel for communication [?] .

Each of the above steps may appear easy individually, but it’s actually quite difficult to achieve. In order to illustrate this, we can break this function down into the some impor-tant things every IoT system needs to do in order to perform its primary functions.

4.1

Desirable Features

Be Secure Security is a clich´ed term nowadays, however, network security is only as strong as the weakest link. Security should be provided to both the communicating

channel and encryption/decryption of the IoT payload being transmitted [8] [6].

Provide a Backup Transmission Medium for Outbound Data It is natural for a transmission medium to fail in critical conditions. Nowadays data has become invaluable. Connectivity via mediums like SMS, satellite links, etc. should be provided as a backup plan to communicate the data during the loss of the primary channel.

Provide an Efficient Medium for Communication Data is money, but sadly so is the channel of communication. When networks provide enough bandwidth and low cut-down time, the picture is all rosy and beautiful. The gateway should plan for when you have a low bitrate connection and/or are being charged big bucks for every byte that passes between your gateway and the cloud. Highly efficient protocols like CoAP or MQTT should be used when possible, and also protocols such as UDP instead of TCP.

Enable Remote Updates It’s imperative for the underlying firmware to be updat-able to their latest releases to provide feature sets, bug fixes, security patches, etc. Op-erating systems like Linux provide the necessary infrastructure to support these kind of over-the-air (OTA) updates.

Tolerate Power Conditions Power is an important factor to be taken into consid-eration for the gateway and constrained devices in general. You never know when the devices will get buzzed with a shock or run out of juice. Every IoT gateway must survive unpredictable power cycles and be able to restore itself to at least a minimum functional level afterwards. At bare minimum, they need to be able to talk to the cloud to convey status and accept basic commands to restore.

Prepare for Intermittent and Dynamic Connectivity Issues You will never be able to predict or control the conditions of your Internet connection. Sometimes, if you are on a cellular connection, it will disappear altogether. In all cases, the software in the

Chapter 4 Testing gateway needs to be able to re-establish the connection without intervention. Also, gate-ways should prepare themselves in cases where the connection may be down for extended periods. Here caching and queuing of data would help the gateways provide loss-less transmission of mission critical data after connectivity is re-established.

4.2

Design and Implementation

In our system we use MQTT for the transport of the data. As we know, MQTT stands for MQ Telemetry Transport. It is a publish/subscribe, extremely simple and lightweight messaging protocol, designed for constrained devices and low-bandwidth, high-latency or unreliable networks. When using MQTT the payload of our transmission is just 64 bytes for message, and this way it is very economical when we store data on the cloud. MQTT also provides username password authentication as part of the protocol. Use the password file option to define the valid usernames and passwords.We have to be sure to use network encryption while using this option otherwise the username and password will be vulnerable to interception. When using certificate based encryption there are two op-tions that affect authentication. The first is requirecertificate, which may be set to true or false. If false, the SSL/TLS component of the client will verify the server but there is no requirement for the client to provide anything for the server: authentication is limited to the MQTT built in username password. If require-certificate is true, the client must pro-vide a valid certificate in order to connect successfully [21]. We use username/password for authentication to the local server and a certificate based authentication for the bridge between the two brokers. This should make the transmission between the brokers very secure.

OpenWRT is an open-source project, this means that the security glitches will get fixed as soon as there is a known vulnerability. In contrast to static firmware from vendors, our gateway will get the updates as soon as they are released [19].

Using OpenWRT gives us the possibility to update our gateway or to even turn on the automatic updates from remote locations. We point the software repository address to a

channel where we usually store the latest updates of the firmware and packages. Using automatic updates on the gateway, it will update itself as soon as it sees a new package or firmware.

This gateway is very flexible thanks to the OpenWRT firmware. Adding different connectivity options is straitforward. We even tried using a 3g usb modem as a backup trasmission medium and it worked really well. All we had to do was download a package called luci-proto-3g and add a new wireless interface. When testing the new interface, we turned off a couple of times the wifi. The transmission recovered completely through the 3G connection within 10 seconds from the initial wireless fault.

Figure 4.1: 3G Connection

Our system can be powered with 5V and Current consumption is about 140mA for wifi and UART enabled at the same time. This makes it easy in case we need to just use a small battery for events of short power outages. If no connection is available, we will store the data locally and publish them later. This is done using mosquitto persistence option [21]. The power meter also has an onboard memory where it stores the accumulated power usage. Even in case of catastrophic failure of the system, we would still be able to get the overall power consumption for the time the system was not online. We use an AC to DC

Chapter 4 Testing Finally, on a theoretical level, the system seems to be very robust. In the next part we illustrate how the system behaved as a whole and we study about the measurement accuracy.

4.3

Test Enviroment

We conducted a series of tests on the system which helped us better understand the be-haviour of the system under different conditions. For the test we used a prototype that we made earlier. The prototype consisted of two parts. Sensors and gateway that did the measuring and transmission, and the server part where the data was sent, stored, analyzed and visualized. For the server part a local machine with all the software (RabbitMQ, Tele-graph, InfluxDB, Grafana) installed on it was used. Both the gateway and the server were connected to a local wifi network. The gateway published the data as soon as they came from the power meter. During the test we discovered that, in an event of disconnection, it took about a minute for the MQTT client to connect back to the Broker. This meant that we needed something to store the data locally for that amount of time.

In order to avoid the message loss in case of Internet connectivity issues between the gateway and the server, we used the persistence mode in the mosquitto broker. That is, when a durable client connects (clean session is set to 0), the broker will maintain information about that client after it disconnects. This means the subscriptions for that client and possible messages ready for delivery when it reconnects (using the same client id!)

For the persistence mode to work , we need a local and remote broker to be connected in bridge. That is a bridge between a local broker installed on the gateway, and the broker installed on the server. This way the data is stored locally by the first broker in case of a disconnection.

By default, and according to the MQTT spec, messages are only queued for a discon-nected durable client if both the subscription and the message use a QoS of greater than 0. Mosquitto offers the ability to queue all messages.

persistent_client_expiration duration

This option allows persistent clients (those with clean session set to false) to be re-moved if they do not reconnect within a certain time frame. This is a non-standard option. As far as the MQTT spec is concerned, persistent clients persist forever.

Badly designed clients may set clean session to false whilst using a randomly gener-ated client id. This leads to persistent clients that will never reconnect. This option allows these clients to be removed.

The expiration period should be an integer followed by one of h d w m y for hour, day, week, month and year respectively. For example in our case we use:

persistent_client_expiration 10m

4.3.1

Broker Reconnection Test

A testing for the ability of the gateway to reconnect to the network and consequently to the MQTT broker was conducted. We wrote a script that would periodically turn off and on the wireless interface periodically. This was simply done by using crontabs to execute two commands every 15 minutes (wifi down adn wifi up). This meant that there were 4 recconection attempts per hour, 96/day and in total there were 672 attempts to reconnect. During one week of testings, the gateway was able to reconnect to the correct broker on the server almost all the times. We measured the number of failed reconnections in three time intervals. This was done to properly set the persistence time, that is the time we need to store the data in case of connectivity issues. Most of the time the reconnection was successful within 2 minutes of the disconnection. But still, sometimes it didn’t reconnect within 2 or 5 minutes. On the other hand, it connected almost 99.85 percent of the time within 10 minutes (Table 4.1). We then ended up using 10 minutes as the persistent client expiration. Eventually, the gateway will always reconnect in some time. The broker will store the messages for 10 minutes waiting for the client to reconnect.

Chapter 4 Testing Table 4.1: Failed reconnections within 2, 5 and 10 minutes.

Days Failed Reconnects: 2min Failed Reconnects: 5min Failed Reconnects: 10min

1 6 2 0 2 5 2 0 3 5 2 0 4 4 3 1 5 3 1 0 6 6 2 0 7 4 3 0

4.3.2

Accuracy Testing

Having conducted tests on the connectivity part, we wanted to have a clear view on the accuracy of the measurements we were getting. For this we needed a proved high preci-sion voltage and current meter as a target to confront with our meter. We used a Fluke Calibration 8845A 6.5 digit precision multimeter. This multimeter can handle 100 mV to 750 V AC with maximum resolution of a 100nV. We used this Multimeter to measure voltage and current at the same time that our system was doing measurements. Figure 4.1 shows a range of the measurements from the multimeter and our system.

Figure 4.2: Meter Voltage accuracy

In the specifications, our meter has an average of 1 percent of accuracy error. In the real world, during our tests, it showed that it was even less than that, with a 0.3 percent of offset Wrt to the fluke multimeter for the voltage measures and about 0.6 percent for the current measures. For the cost of this meter the result was surprisingly very good.

Chapter 5 Observations

Chapter 5

Observations

The primary scope of this work was to link and bridge the gap between energy con-sumption and the physical operations consuming that energy. We reviewed the existing technologies and the state of the art to conclude that the costs of deployment were high in these kinds of systems. Our work was aimed to design and develop a system that would reduce the costs without compromising the functionality of the existing systems.

In our work, we showed that PZEM-004T power meter in conjuction with HLK-RM04 gateway board can be used to record energy consumption at a significant level of detail. As can be seen from the results of the case study we can explore the finer details of the levels of energy consumed at particular times and can associate these with actual activities. This gives us considerable more knowledge on what is occurring over the kWh value data which was previously available.

We started working on this project with the aim of having a low cost, yet still fully functional IoT system, with specific attention to the choice of the gateway. While reasearch-ing on the cost of a system, we found out that the most costly piece was in the form of the IOT gateway. We managed to built a cheaper gateway and this led to an overall cheaper system. The system that we built managed to deliver very good reliability during the tests we conducted on it.

gateway means that we are already using a reliable device that powers most of our homes network, while at the same time protecting the data with the bult-in firewall. While most Gateways remain outdated once they are deployed, our system will recieve frequent up-dates as soon as they are released. Indeed, OpenWRT is in constant development and this makes it one of the most secure platform available. Firmware vendors tend to update very rarely, while the open source nature of this system means that the flaws are corrected very fast.

This work showed that making a low cost energy monitoring is possible with relatively good accuracy. We found out that router architecture is actually very good for use as an IoT gateway. Using OpenWRT makes this implementation very flexible, as we can add different types of radio connections to this board. We can add for example a GPRS/UMTS or Zigbee connection. This is made very simple by OpenWRT. All we need to do is to select and download the right package and the connections will be fully functional in a couple of minutes. For this project we used a cheap Router Board. However, there are many more advanced routers with lots of processing power and network speed to fulfill more and more local processing and faster transfer rates at the same time. We implemented a possible framework for building intelligent systems using hardware we already have in our houses.

In the future, the system could be further developed to get more insights on energy usage profiles, adding a routine that could automatically learn to detect which appliance is in use. By learning the habits of the consumers, in the near future it could also be possible to give hints on how to individualize energy utilization, or when possible, the system could automatically take action by remotely powering on or off devices. Another aspect that could be further enhanced is the use of a better voltage and current sensor. This could further help fine tune the profiles for every building. Finally, building a mobile app for android and IOS nowadays is the norm, as it would make the system more appealing to new customers.

Bibliography

[1] S. Sohaib, I. Sarwar, M. H. Iftikhar, and A. Mahmood, “Low cost smart energy monitoring and control system for smart buildings,” 2016.

[2] A. Vega, F. Santamaria, and E. Rivas, “Modeling for home electric energy manage-ment: a review,” Renewable and Sustainable Energy Reviews, vol. 52, pp. 948–959, 2015.

[3] L. Atzori, A. Iera, and G. Morabito, “The internet of things: A survey,” Computer networks, vol. 54, no. 15, pp. 2787–2805, 2010.

[4] I. F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci, “Wireless sensor networks: a survey,” Computer networks, vol. 38, no. 4, pp. 393–422, 2002.

[5] H. Luan and J. Leng, “Design of energy monitoring system based on iot,” in Control and Decision Conference (CCDC), 2016 Chinese. IEEE, 2016, pp. 6785–6788. [6] Z. Bocheng, “Design of building energy monitoring and management system,” in

Business Computing and Global Informatization (BCGIN), 2012 Second Interna-tional Conference on. IEEE, 2012, pp. 645–648.

[7] F. Doyle, J. Cosgrove, and G. Mustafaraj, “Design of an embedded sensor network for application in energy monitoring of a sports stadium,” 2014.

[8] Q. Zhu, R. Wang, Q. Chen, Y. Liu, and W. Qin, “Iot gateway: Bridgingwireless sensor networks into internet of things,” in Embedded and Ubiquitous Computing (EUC), 2010 IEEE/IFIP 8th International Conference on. IEEE, 2010, pp. 347– 352.

[9] HLK-RM04. (2017, Apr.) Hlk-rm04 datasheet @ONLINE. [Online]. Available: https://e-radionica.com/productdata/2013042218402981701.pdf

[10] D.-M. Han and J.-H. Lim, “Design and implementation of smart home energy man-agement systems based on zigbee,” IEEE Transactions on Consumer Electronics, vol. 56, no. 3, 2010.

[11] SD3004. (2017, Apr.) Sd3004 datasheet @ONLINE. [Online]. Available: http://www.sdicmicro.com/DataSheet/SD3004%20datasheet%20v0.2c.pdf

[12] PZEM-004T. (2017, Apr.) Pzem-004t datasheet @ONLINE. [Online]. Available: https://www.circuitspecialists.com/content/189799/ac004.pdf

[13] ICS-Relay. (2017, Apr.) Ics-relay product page @ONLINE. [Online]. Available: http://www.icstation.com/icstation-micro-control-channel-relay-module-p-4012. html

[14] U. Hunkeler, H. L. Truong, and A. Stanford-Clark, “Mqtt-s—a publish/subscribe protocol for wireless sensor networks,” in Communication systems software and middleware and workshops, 2008. comsware 2008. 3rd international conference on. IEEE, 2008, pp. 791–798.

[15] MQTT. (2017, Apr.) Mqtt general @ONLINE. [Online]. Available: http://mqtt.org [16] B. Leighton, S. J. Cox, N. J. Car, M. P. Stenson, J. Vleeshouwer, and J. Hodge,

“A best of both worlds approach to complex, efficient, time series data delivery,” in International Symposium on Environmental Software Systems. Springer, 2015, pp. 371–379.

[17] InfluxDB. (2017, Apr.) Influxdb general @ONLINE. [Online]. Available: https://www.influxdata.com

[18] Grafana. (2017, Apr.) Grafana general @ONLINE. [Online]. Available: https: //grafana.com

Appendix BIBLIOGRAPHY [19] openwrt. (2017, Apr.) Openwrt website @ONLINE. [Online]. Available:

https://openwrt.org

[20] C. G. Kim and K. J. Kim, “Implementation of a cost-effective home lighting con-trol system on embedded linux with openwrt,” Personal and ubiquitous computing, vol. 18, no. 3, pp. 535–542, 2014.

[21] M. MQTT. (2017, Apr.) Mosquitto options @ONLINE. [Online]. Available: https://mosquitto.org/man/mosquitto-conf-5.html

[22] RabbitMQ. (2017, Apr.) Rabbitmq website @ONLINE. [Online]. Available: https://www.rabbitmq.com