A home automation architecture based on LoRa technology and Message Queue Telemetry Transfer protocol

Abstract

In recent years, Internet of Things technologies gained momentum in various application areas, including the Smart Home field. In this view, the smart objects available in the house can communicate with each other and with the outside world by adopting solutions already proposed for Internet of Things. In fact, among the challenges to face during the design and implementation of an Internet of Things–based Smart Home infrastructure, battery usage represents a key point for the realization of an efficient solution. In this context, the communication technology chosen plays a fundamental role, since transmission is generally the most energy demanding task, and Internet of Things communication technologies are designed to reduce as much as possible the power consumption. This article describes an Internet of Things–oriented architecture for the Smart Home, based on the long-range and low-power technology LoRa. Moreover, in order to enable the devices to communicate with each other and the outside world, the Message Queue Telemetry Transfer protocol is used as a domotic middleware. We show that LoRa, designed by having in mind the typical requirements of Internet of Things (i.e. low power consumption, sporadic transmission, and robustness to interference), is well-suited to also meet the need of more established home automation systems, specifically the low latency in message delivery. Interoperability among different devices may also be obtained through the Message Queue Telemetry Transfer midlleware.

Keywords

Smart home building automation wireless sensor network LoRa Message Queue Telemetry Transfer interoperability

Introduction

The Smart Home (SH) domain encompasses a huge variety of technologies, applications, and services, aimed at improving the quality of life of the resident people. Intelligent capabilities in a SH allow to reduce the energy consumption, facilitate routine operations, and anticipate the inhabitants’ needs, by learning and understanding their behaviors. In recent years, the trend in the home and building automation has seen an increasing pervasiveness of the Internet of Things (IoT) paradigm. Such a concept was initially proposed by the International Telecommunication Union (ITU) in 2005:¹ it encompasses a wide range of services and applications which rely on objects that can compute and communicate.² In this view, IoT can be integrated into the smart environment, extending the smart objects capabilities and enabling the user to monitor the environment remotely.³

Among the key challenges identified in the IoT infrastructures for SH, Samuel⁴ lists the battery consumption. Since transmission is usually the most energy demanding task, the selected communication technology plays a fundamental role in the realization of an efficient SH solution. In this context, the technologies identified by Samuel are WiFi, Bluetooth Low Energy (BLE), ZigBee, Thread, and Z-wave. According to the author, the standard WiFi is energetically expensive and cannot be used in battery-powered sensors. BLE significantly reduces the power consumption, while providing a more limited connectivity range. ZigBee, Z-wave, and Thread consume less than WiFi, but the data transfer rate is slower, and, for the latter ones, the signal range is smaller.

The need for competitive solutions for machine-to-machine (M2M) communications opened the way to Low Power Wide Area Network (LPWAN) technologies that operate in license-free bands, as LoRa, SigFox, IEEE 802.11ah, or in licensed bands as Long Term Evolution (LTE) Cat-0 and LTE-Cat-M.⁵ More recently, the Narrow-Band Internet of Things (NB-IoT) was introduced in 3GPP-Release 13, with the aim to increase the indoor coverage, to connect a huge number of low throughput devices, assuming a battery-life of 10 years.⁶

In this article, we propose a SH architecture based on the Long-Range (LoRa) technology at the physical layer,⁷ and the Message Queue Telemetry Transfer (MQTT) protocol and show that by synergically adopting these technologies, we can face the typical requirements imposed by home automation architectures. The use of LoRa allows to provide the SH architecture with long-range, low-power wireless capabilities. Due to the low throughput, this technology is not useful for multimedia, audio and video streaming applications, although it fits perfectly with metering, sensing, and automation functionalities.⁸ MQTT is a lightweight publish-subscribe protocol. In this work, it acts as an interoperability middleware, interfacing the LoRa end nodes with other devices exploiting different transmission technologies. The choice of LoRa as the physical layer technique to implement a SH solution is based on the fact that it enables the deployment of proprietary networks in a free manner, differently from SigFox, but keeping the same advantages, such as low-cost devices, very long range, infrequent communication rate, and long battery lifetime. In addition, LoRa also serves the local network deployment. On the contrary, NB-IoT is expected to serve the higher-value IoT markets that are willing to pay for very low latency and high quality of service (QoS).⁹

The article is organized as follows. The “Background” section provides an overview of the communication technologies typically adopted in IoT, with a particular focus on the SH field. The sections “LoRa technology” and “MQTT protocol” provide the basic concepts about LoRa technology and MQTT protocol, respectively. A thorough description of the proposed system is reported in the section “System description,” while the experimental results are provided in the “Experimental results” section, and discussed in the “Discussion” section. Finally, the “Conclusion” section draws the main conclusion of the work.

Background

The IoT domain covers a wide range of technologies, applications, and services. For this reason, it cannot be defined in terms of a single communication protocol.² In the literature, several studies have collected and summarized the proposals for IoT, providing a review of the most used technologies and protocols in this context. For example, Al-Fuqaha et al.¹⁰ affirm that the most used IoT architecture is composed by five layers:

Objects layer includes sensors and actuators;

Object abstraction layer transfers data produced by the object layer to the service management layer through various technologies;

Service management layer processes the received information, makes decisions, and delivers the services;

Application layer provides the user with the requested service;

Business layer deals with the management of the IoT system, from supporting decision-making process to building a business model.

The same authors state that there are two main categories of IoT devices: resource constrained and resource-rich devices. The former have enough software and hardware capabilities to support the TCP/IP (Transmission Control Protocol/Internet Protocol) protocol suite. Conversely, devices that do not feature sufficient resources should use a more lightweight protocol and rely on a gateway to interoperate with the other IoT elements. According to Stojkoska and Trivodaliev,¹¹ the standard IoT usually consists of many Wireless Sensor Networks (WSNs).

Regarding the IoT protocols, they can be divided into three main groups: application, service discovery, and infrastructure protocols.¹⁰ The former one provides higher level protocols. Some of the most popular are MQTT, HyperText Transfer Protocol (HTTP), Advanced Message Queuing Protocol (AMQP), and Constrained Application Protocol (CoAP). Each of these protocols is suited for a specific scenario and environment. In our case, we choose the MQTT protocol, since it delivers messages with a lower delay than CoAP when the packet loss rate is low.¹² The service discovery protocols provide mechanisms for the discovery and registration of the IoT elements. They are typically designed for resource-rich devices.¹⁰ Finally, the infrastructure protocols involve physical layer protocols. They allow to establish the underlying communication necessary for the IoT applications. Among the communication technologies competing to reach the IoT market, Gopalsamy¹³ lists ZigBee, Thread, SigFox, LoRa, Weightless, Bluetooth, Z-wave, NFC, cellular, and WiFi.

In general, communications can be classified by transmission range in short or long range. The former usually covers a few dozen meters and consumes less power than long-range one.¹⁴ The latter, on the contrary, can be divided into two main groups: cellular networks and LPWAN. The cellular network is very widespread and characterized by a great throughput, although economically and energetically expensive. Conversely, LPWAN solutions, by penalizing the data rate, offer the possibility to send the information over a long range with low power consumption.⁵ In any case, the choice of the transmitting technology is closely related to the target application.

According to Stojkoska and Trivodaliev,¹¹ IoT-based SH applications are very rare, even if IoT brings significant advantages over traditional communication technologies. Piyare and Lee¹⁵ present a low cost, home controlling and monitoring system which exploits a REST Web service. The kernel of the architecture described herein is the Arduino Ethernet server, acting as a gateway between the smart objects installed in the house and the user interfaces. A different approach has been proposed by Soliman et al.¹⁶ It aims at embedding the intelligence into sensors and actuators using the Arduino platform. The smart objects communicate to the service management layer through the ZigBee technology. Chung et al.¹⁷ present a scalable and flexible gateway architecture based on Social Web of Things (SWoT), supporting the interaction between users and objects. A proactive architecture based on Event-Condition-Action (ECA) rules has been proposed in Perumal et al.¹⁸ for IoT’s interoperability purposes in SHs. Feng et al.¹⁹ discuss a SH solution based on cognitive dynamic system paradigm, while Patel and Kanawade²⁰ proposes a SH system exploiting the Intel Edison board to control home appliances connected via WiFi. Finally, Stojkoska and Trivodaliev¹¹ present a review of IoT for SH mainly focused on energy saving and smart grids. Their review presents the most relevant papers from the literature addressing this topic, investigating challenges and proposing an holistic framework as a solution.

All the solutions presented so far exploit short-range communication technologies to transfer information between the object layer and the service management layer in the SH environment. Conversely, our proposal leverages the LoRa technology to communicate with the smart objects available in the home environment. This allows to cover large spaces avoiding multiple gateways, while limiting the power consumption. In addition, in order to ensure the communication with the outside world, we exploit a gateway able to forward the LoRa messages through a TCP/IP network, by the MQTT protocol.

The idea of using the MQTT protocol with LoRa, to address the home automation context, is quite innovative. In Prabaharan et al.,²¹ the authors present a solution for home automation based on MQTT, but the communication technology adopted is WiFi, as in many classical proposals. MQTT for an IoT-based home automation solution is presented also in Manohar and Reuban Gnana Asir,²² but again on a low-power WiFi link. In Hernandez-Rojas et al.,²³ a solution for precision agriculture is designed, based on the use of MQTT and BLE at the physical layer. Other papers address the use of MQTT with LoRa, for applications related to the context of Smart Cities, as in Lozano Murciego et al.,²⁴ where a waste monitoring and management platform is presented, based on the design of a low consumption wireless node, to obtain measurements of the weight, filling volume and temperature of a waste container. A solution integrating LoRa and MQTT is presented in Catherwood et al.,²⁵ with a LoRa/Bluetooth-enabled electronic reader for biomedical strip-based diagnostics system aimed at personalized monitoring. The LoRa-based transmission of test results is successfully performed over distances of 1.1–6.0 km, with data packets correctly and robustly received at the base station, overcoming radio path losses from 119 to 141 dB.

LoRa technology

LoRa is a physical layer technology, aimed for IoT and M2M communications.²⁶ More specifically, it is a proprietary spread spectrum modulation scheme, patented by Semtech Corporation, derived from the Chirp Spread Spectrum (CSS) modulation. Such a scheme implements a variable data rate, utilizing orthogonal spreading factors (SFs), which allows to trade throughput for coverage range or power, so as to optimize network performances in a constant channel bandwidth. Many legacy wireless systems use Frequency Shift Keying (FSK) as the physical layer because it is a very efficient modulation for achieving low energy consumption. On the contrary, LoRa is based on CSS modulation, which maintains the same low-power characteristics as FSK modulation, but significantly increases the communication range. CSS has been used in military and space communication for decades due to long range, relatively low transmission power requirements, and inherent robustness from channel degradation mechanisms (e.g. multipath, fading, Doppler, and in-band jamming interferers).²⁷ In the LoRa modulation, the spreading of the spectrum is achieved by generating a chirp signal that continuously varies in frequency. The main advantage of this method is that timing and frequency offsets between transmitter and receiver are equivalent, greatly reducing the complexity of the receiver design. The frequency bandwidth of this chirp is equivalent to the spectral bandwidth of the signal and can take values of 125, 250, or 500 kHz. The desired data signal is chipped at a higher data rate and modulated onto the chirp signal. LoRa modulation employs six orthogonal SF values, from 7 to 12, which enables multiple spread signals to be transmitted at the same time and on the same channel without collisions. Higher SFs provide long range traded off against a lower data rate. The data rate ranges from 0.3 to 5.5 kbps depending on the SF and channel bandwidth. Interference problems are mitigated by employing Forward Error Correction (FEC) in combination with Frequency Hopping Spread Spectrum (FHSS). This requires a small overhead of additional encoding of the data in the transmitted packet, which may have a data payload of maximum 255 bytes.

A standard LoRa frame is shown in Figure 1. As depicted in the figure, the frame begins with a preamble that allows the receiver to synchronize to the incoming data. After the preamble, there is an optional header. When present, it is transmitted with a code rate of 4/8. Such a field contains the packet length information in bytes, the code rate used for the transmission, and whether or not a 16-bit cyclic redundancy check (CRC) for the payload is present at the end of the frame. In addition, it includes a CRC to allow the receiver to discard packets with invalid headers. The payload size is stored using only one byte, limiting its total size to 255 bytes.

Figure 1.

Standard LoRa packet.

LoRa has been designed to work in Europe in the 868 MHz band. The radio modules have to adopt a duty cycled transmission (1% of the time), meaning that a maximum of totally 36 s can be transmitted by one node per hour, limiting the rate at which the end device can actually generate packets. However, by supporting multiple channels, LoRa allows the end node to employ longer data exchange procedures by changing carrier frequency, while respecting the duty cycle limit in each channel. In total, 10 channels are available for LoRa in the EU 868–870 MHz ISM band.²⁸ The maximum allowed transmission power is 14 dBm. This, in combination with the low sensitivity of the receiver (down to −142 dBm), leads to very high link budgets (up to 156 dB) which translates into a coverage range up to 5 km in urban areas and up to 15 km in rural areas.⁵

MQTT protocol

MQTT is an open and low complexity standard approved by the Organization for the Advancement of Structured Information Standards (OASIS) in 2014 as a reference standard for IoT and M2M communications.²⁹ MQTT is a lightweight protocol built upon the TCP. It requires only 2 bytes for message heading, while other 2 bytes are optional. For this reason, it is more suitable than other protocols, such as HTTP, for adoption by devices with limited resources. As already mentioned, it features a publish-subscribe paradigm (also known as pub-sub), which involves three entities: publisher, subscriber, and broker. The former one is able to send messages on a specific topic. Such messages are received by the broker which, in its turn, forwards them to the clients registered to the same topic, called subscribers. Since the MQTT protocol is based on TCP, clients willing to initiate a communication need to send a CONNECT message to the broker, which responds with a CONNACK message. After that, the connection remains open and publisher and subscriber can send and receive messages until they disconnect.

For each published message, the client can choose the desired QoS, depending on the requirements of the application. Also the subscriber, when it registers to a topic, has to choose the QoS level. The QoS levels offered by MQTT are as follows:

Level 0: each message is transmitted at most once;

Level 1: the message can be sent more than once, until the sender gets an acknowledgment from the receiver;

Level 2: the message is delivered exactly once, avoiding duplications, by following a four-steps handshake between sender and receiver.

Obviously, the first level offers the best effort delivery, but it is unreliable, since the message may be lost during the communication. On the contrary, level 2 ensures the message reception, but due to the four-steps handshake, it is slower. In this view, level 1 represents a compromise choice between speed and reliability.

MQTT has gained momentum in recent years, and several free and open source libraries are available for different platforms. A reference list of available implementations may be found in Github.³⁰ A variety of brokers have been implemented too, thus making it easy and immediate for developers to design their own application and test the protocol functioning.

System description

The architecture of the proposed home automation system is shown in Figure 2. Sensors and actuators communicate with a local Data Concentrator via LoRa technology. The local Data Concentrator acts as a gateway, converting LoRa packets into MQTT messages. It integrates a LoRa radio module, a Processing Unit capable of interpreting, translating, and forwarding the received messages, and an MQTT client. The latter communicates with the broker through a generic data connection (e.g. LAN-Ethernet, WiFi, 4G). The broker manages the communications between the end nodes and any third-party MQTT client. All SH operation rules are managed by the broker which, through the pub-sub paradigm, knows to which end node the message must be forwarded. Below, the hardware and software components of the system are described in more detail.

Figure 2.

System architecture.

LoRa end nodes

Each sensor or actuator of the SH network is connected to a LoRa end node, which integrates an M0 Adafruit Feather board. Such a board is equipped with the Semtech SX1276 IC transceiver³¹ and ATSAMD21G18 ARM Cortex M0 processor.³² It features a very low power consumption: 300 µA during full sleep, 120 mA peak during +20 dBm transmission, 40 mA during active radio listening.

The board is able to send and receive frames formatted according to the LoRa specifications. Specifically, in this application scenario, the payload of the LoRa frame is characterized by the following syntax: msgID=* * * *&value=*&nodeID=*&time=* ** * * * * * * *, where each * denotes a decimal figure. Therefore, four decimals are used to encode the message identifier, one for the value, one for the node (sensor or actuator) identifier, and 10 decimals for the message timestamp.

Data Concentrator

The Data Concentrator includes three main components: a LoRa module, a Processing Unit, and an MQTT client. The Lora module is the same as used for sensors and actuators and it provides the physical layer of the communication. A Raspberry Pi 3, equipped with a Linux-based Raspbian O.S., operates as the Processing Unit and interacts with the radio module via serial connection. The message format conversion, from LoRa to MQTT and vice versa, is implemented by an MQTT client, exploiting the Paho library.³³ The Concentrator collects LoRa frames through the Lora end node’s radio interface and provides their conversion into MQTT messages, and publishes them on a specific topic, through a generic data connection. The association between publishers and subscribers and, consequently, all the system operating rules, are in charge of the MQTT broker.

MQTT-based communication protocol

The data transmission protocol implemented in this project provides a LoRa-to-MQTT and MQTT-to-LoRa format conversion, operated by the Raspberry Pi used as the Processing Unit of the Data Concentrator. A similar architecture had already been proposed in Del Campo et al.³⁴ In such a case, the WSN communicates via BLE and the MQTT client resides in a home gateway, providing an intermediate integration level.

As shown in the examples reported in Figure 3, the communication can take place in two different ways: between end nodes of the same SH network or between an end node and an external device. In the former case, the end node sends the message to the data concentrator via LoRa. The concentrator, in its turn, publishes the LoRa payload, along with the local timestamp, on a specific topic (i.e. from_sensor_to_sensor). The MQTT broker, following the defined operating rules, delivers the message to all the clients subscribed to the same topic, included the data concentrator. The latter sends back the message to the recipient node via LoRa. In this case, the concentrator simultaneously plays the role of publisher and subscriber. This choice may seem non-optimal as both the end nodes belong to the same network. However, it allows to centralize all the operating rules within the broker, making the system configuration easier.

Figure 3.

Examples of communications between the smart objects installed in the SH environment.

In the latter case, an external MQTT client publishes a message on a specific topic (i.e. from_outside_to_sensor). This message is delivered by the MQTT broker to all the clients subscribed to that topic, and included the Raspberry Pi which sends the command via LoRa to the end node. Vice versa, if the end node wants to communicate with the external device, for example, to transmit an alarm message, it sends the data to the concentrator. In its turn, it publishes such a message on the topic from_sensor_to_outside, to which the external device is registered.

A summary of the system’s operating rules is reported in Table 1.

Table 1.

List of topics to which the MQTT clients are subscribed and published on.

MQTT client	Subscribed to	Publishes on
Data Concentrator	from_sensor_to_sensor	from_sensor_to_sensor
	from_outside_to_sensor	from_sensor_to_outside
External Device	from_sensor_to_outside	from_outside_to_sensor

MQTT, Message Queue Telemetry Transfer.

MQTT as a domotic interoperability framework

With the paradigm of publish-subscribe, MQTT acts as domotic framework, able to make possible a communication among devices from different producers, but adopting the same syntax for the MQTT payload. In fact, sensors and actuators subscribe on different topics, as a function of the relationship between them. An actuator subscribes on the same topic of the sensor that controls it, and an external devices subscribes on the same topic of the actuator that is remotely controlled. The domotic network is then organized in groups of sensors and actuators on the basis of the topic they subscribed to. With this approach, no limits are imposed on the technology of the nodes belonging to the domotic network. It is in fact sufficient that nodes communicate by publishing on the same MQTT topic, independently, as an example, of the adopted communication technology.

Experimental results

In order to verify the proper functioning of the proposed architecture, several tests have been performed. In the following, we present, first, experiments for the evaluation of the LoRa radio coverage, and then tests for the system performance verification.

Radio coverage evaluation

The evaluation of the radio coverage has been performed in four different scenarios: indoor on the same floor of a large building, indoor in different floors, deep-indoor, and outdoor. These scenarios may be brought back to the case of a home automation system deployed within a large apartment, with accessible external areas, in which different propagation conditions may be experienced. A brief description of each test campaign is provided below.

Same floor tests

As a first experimental evaluation, we conducted a campaign of measures to assess the coverage of LoRa technology in indoor environments. To replicate a home automation scenario, we acquired data from sensors sparsely distributed at the second floor of the Information Engineering Department of the Università Politecnica delle Marche. The gateway is located within the Telecommunications Lab as shown in Figure 4. GW, in blue, indicate the gateway position while the red flags from 1 to 7 indicate the various Points of Measurement (PoMs). For each PoM, 120 LoRa packets with a data payload of 20 bytes and a SF of 7 were transmitted over 30 min. Due to the environment-related interference, the packets received by the gateway from each point are less than the 120 expected, as shown in Table 2. The average Received Signal Strength Indicator (RSSI) values of the packets collected from each position are shown in the table, along with the distance between the various PoMs and the gateway, and the number of walls crossed by the LoRa signal.

Figure 4.

PoMs and gateway (GW) location in the same floor scenario: the blue marker indicates the gateway, while flags from 1 to 7 locate the different positions of the end nodes.

Table 2.

Results of the test campaign carried out in the same floor in terms of average RSSI and packet delivery success ratio.

PoM	Distance (m)	No. of walls	Average RSSI (dBm)	Success ratio
1	13 ± 0.01	3	−61 ± 1	91%
2	53 ± 0.01	13	−83 ± 1	92%
3	9 ± 0.01	1	−42 ± 1	92%
4	27 ± 0.01	6	−75 ± 1	84%
5	22 ± 0.01	1	−60 ± 1	92%
6	29 ± 0.01	7	−79 ± 1	92%
7	40 ± 0.01	11	−95 ± 1	93%

RSSI, Received Signal Strength Indicator; PoM, Point of Measurement.

Position 3 is the best one in terms of average RSSI. In fact, the shortest distance (i.e. 9 m) in combination with the smallest number of walls (i.e. 1) provides an RSSI value of −42 dBm. Figure 5 shows the variation of the minimum, average, and maximum RSSI at each point of measurement, as a function of its distance from the gateway.

Figure 5.

Maximum (M), minimum (m), and average (a) RSSI value for each PoM, with respect to the distance from the gateway. The PoMs are shown in parentheses.

As the distance increases, there is a worsening in RSSI values except for PoM 2, even though the number of crossed walls is greater. This is due to the fact that, to reach the position 7, the LoRa signal has to cross reinforced concrete pillars; therefore, the received signal is more attenuated than in other positions.

Different floors tests

The same measures were replicated on the third floor, considering the same PoMs except for points 6 and 7 that are not accessible in such a floor. The gateway was still in the Telecommunications Lab at the second floor. The results are summarized in Table 3.

Table 3.

Results of the test campaign carried out in a different floor in terms of average RSSI and success ratio.

PoM	Distance (m)	Average RSSI (dBm)	Success ratio
1	13.68 ± 0.01	−75 ± 1	92%
2	53.77 ± 0.01	−99 ± 1	91%
3	10.08 ± 0.01	−55 ± 1	93%
4	27.50 ± 0.01	−85 ± 1	93%
5	23.05 ± 0.01	−70 ± 1	92%

RSSI, Received Signal Strength Indicator; PoM, Point of Measurement.

By comparing the average RSSI values for the corresponding PoMs of the two floors (see Figure 6), we can notice an average attenuation of about 12.6 dB, due to the crossing of the ceiling/floor by the LoRa signal.

Figure 6.

Comparison between average RSSI values of PoMs in the second and third floor.

Deep-indoor tests

The third test campaign was held using the same measurement setup. In this case, measurements were carried out in a deep-indoor environment. For such an environment, we choose as PoM a point at the bottom of the stairs, located 33 m (three floors below) far from the gateway. Due to the high number of floors, walls, and obstacles encountered by the radio signal, just 70 of the 120 transmitted packets were received correctly from the gateway, with an average RSSI value of −113 dBm.

Outdoor tests

For the outdoor scenario, three points were chosen in the University Campus, as shown in Figure 7. The gateway is located in the Telecommuni-cations Lab. Success ratio and average RSSI value are reported in Table 4 for each PoM. Also in this case, the RSSI values are well over the receiver sensitivity (i.e. −142 dBm), providing an adequate radio coverage.

Figure 7.

PoMs and gateway location in the outdoor environment: the blue marker indicates the gateway, while flags 8 to 10 represent the different positions of the end nodes.

Table 4.

Results of the test campaign carried out outdoor in terms of average RSSI and success ratio.

PoM	Distance (m)	Average RSSI (dBm)	Success ratio
8	35.35 ± 0.01	−72 ± 1	91%
9	53.23 ± 0.01	−80 ± 1	90%
10	35.44 ± 0.01	−68 ± 1	91%

RSSI, Received Signal Strength Indicator; PoM, Point of Measurement.

System performance

A functional test of the proposed system was developed, by connecting two LoRa end nodes with a button and a lamp. By pressing the button, through appropriate publishing and subscription rules, the lamp turns on. Moreover, by means of a smartphone application implementing the MQTT protocol, the light can be turned on remotely. The system works properly and the latency time between the command issuing and its actuation is acceptable. In fact, we measured the delay occurred from the activation of the button and the lightening of the lamp. As shown in the oscilloscope screenshot in Figure 8, the time delay between the transmission of the command and its execution is identified by the shift between the a and b markers and results to be 174.0-ms long. Such a value is compatible with the delay requirements posed by real-time home and building automation applications, that is, 200 ms.³⁵

Figure 8.

The blue track shows the push of a button for the command transmission, while the red track shows the command execution (i.e. the turning on of a light).

Discussion

The results provided by the experimental tests demonstrate the effectiveness of our method in properly supporting the real-time home or, more in general, building automation services. Extensive experiments carried out within the Department of Information Engineering have shown that LoRa technology is a suitable alternative to the usual technologies employed in the SH domain. It provides adequate radio coverage for small and large dwellings, covering even the surrounding space, such as the courtyard. This makes it possible to avoid the installation of multiple access points.

The combination of the LoRa technology with the MQTT protocol enables the interfacing of the SH architecture with any third-party MQTT client. This way, sensors and actuators can not only communicate with end nodes in same SH network but also with devices pertaining to different networks. This potentially opens up new application scenarios, such as the smart community one, where the single SH can communicate with the neighborhood homes.

Experimental results have shown the feasibility of the proposed method also in terms of command latency. In fact, the time requested by a message to cause a state change in the actuator node amounts to approximately 174 ms. Such a value is compatible with the delay requirements posed by real-time home and building automation applications.

Conclusion

In this article, we propose a MQTT–LoRa architecture for SH applications. The system exploits the LoRa technology to provide sensors and actuators with long-range, low-power communication capabilities. The integration of the MQTT protocol, acting as a middleware, enables the system to communicate with any third-party MQTT client, providing interoperability between different devices. Extensive experimental measurement campaigns proved that LoRa is well suited to ensure adequate radio coverage both in indoor and outdoor scenarios. This allows to cover large buildings, including the courtyard, without the need of multiple gateways. In addition, the performance of the entire system has been tested, verifying its proper functioning. Experimental results demonstrate that the system meets the time requirements for real-time home and building automation services.

Footnotes

Acknowledgements

This work was developed within the framework of the Italian National Technology Cluster project SHELL (Shared interoperable Home Ecosystems for a green, comfortabLe and safe Living), project code: CTN01 00128 111357.

Handling Editor: Jui-Pin Yang

Declaration of conflicting interests

The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding

The author(s) received no financial support for the research, authorship, and/or publication of this article.

ORCID iDs

Laura Montanini

Susanna Spinsante

References

International Telecommunication Union (ITU). ITU internet reports 2005: the Internet of Things. Geneva: ITU, 2005.

Nolan

Guibene

Kelly

. An evaluation of low power wide area network technologies for the Internet of Things. In: International wireless communications and mobile computing conference (IWCMC), Paphos, 5–9 September 2016, pp.439–444. New York: IEEE.

Ahmed

Yaqoob

Gani

et al . Internet-of-Things-based smart environments: state of the art, taxonomy, and open research challenges. IEEE Wirel Commun 2016; 23(5): 10–16.

Samuel

SSI

. A review of connectivity challenges in IoT-smart home. In: 3rd MEC international conference on big data and smart city (ICBDSC), Muscat, Oman, 15–16 March 2016, pp.1–4. New York: IEEE.

Raza

Kulkarni

Sooriyabandara

Low power wide area networks: an overview. IEEE Commun Surv Tut 2017; 19(2): 855–873.

Beyene

Jantti

Ruttik

et al . On the performance of narrow-band Internet of Things (NB-IoT). In: IEEE wireless communications and networking conference (WCNC), San Francisco, CA, 19–22 March 2017, pp.1–6. New York: IEEE.

LoRa-Alliance. A technical overview of LoRa and LoRaWAN. White paper, November 2015, https://www.tuv.com/media/corporate/products_1/electronic_components_and_lasers/TUeV_Rheinland_Overview_LoRa_and_LoRaWANtmp.pdf

Augustin

Clausen

et al . A study of LoRa: long range and low power networks for the Internet of Things. Sensors 2016; 16(9): 1466.

Mekki

Bajic

Chaxel

et al . A comparative study of LPWAN technologies for large-scale IoT deployment. ICT Express. Epub ahead of print 4 January 2018. DOI: 10.1016/j.icte.2017.12.005.

10.

Al-Fuqaha

Guizani

Mohammadi

et al . Internet of Things: a survey on enabling technologies, protocols, and applications. IEEE Commun Surv Tut 2015; 17(4): 2347–2376.

11.

Stojkoska

BLR

Trivodaliev

. A review of Internet of Things for smart home: challenges and solutions. J Clean Prod 2017; 140: 1454–1464.

12.

Thangavel

Valera

et al . Performance evaluation of MQTT and CoAP via a common middleware. In: IEEE ninth international conference on intelligent sensors, sensor networks and information processing (ISSNIP), Singapore, 21–24 April 2014, pp.1–6. New York: IEEE.

13.

Gopalsamy

. Communication trends in Internet of Things. In: Sugumaran

(ed.) Developments and trends in intelligent technologies and smart systems. Hershey, PA: IGI Global, 2017, pp.284–305.

14.

Centenaro

Vangelista

Zanella

et al . Long-range communications in unlicensed bands: the rising stars in the IoT and smart city scenarios. IEEE Wirel Commun 2016; 23(5): 60–67.

15.

Piyare

Lee

. Smart home-control and monitoring system using smart phone. In: International conference on control and automation (ICCA), Hangzhou, China, 12–14 June 2013, ASTL vol. 24, pp.83–86. New York: IEEE.

16.

Soliman

Abiodun

Hamouda

et al . Smart home: integrating Internet of Things with web services and cloud computing. In: IEEE 5th international conference on cloud computing technology and science, Bristol, 2–5 December 2013, vol. 2, pp.317–320. New York: IEEE.

17.

Chung

Mashal

Alsaryrah

et al . Design and implementation of light-weight smart home gateway for social web of things. In: Sixth international conference on ubiquitous and future networks (ICUFN), Shanghai, China, 8–11 July 2014, pp.425–430. New York: IEEE.

18.

Perumal

Sulaiman

Mustapha

et al . Proactive architecture for Internet of Things (IoTs) management in smart homes. In: IEEE 3rd global conference on consumer electronics (GCCE), Tokyo, Japan, 7–10 October 2014, pp.16–17. New York: IEEE.

19.

Feng

Setoodeh

Haykin

Smart home: cognitive interactive people-centric Internet of Things. IEEE Commun Mag 2017; 55(2): 34–39.

20.

Patel

Kanawade

SY.

Internet of Things based smart home with Intel Edison. In: Modi

Verma

Trivedi

(eds) Proceedings of international conference on communication and networks. Singapore: Springer, 2017, pp.385–392.

21.

Prabaharan

Swamy

Sharma

et al . Wireless home automation and security system using MQTT protocol. In: 2nd IEEE international conference on recent trends in electronics, information communication technology (RTEICT), Bangalore, India, 19–20 May 2017, pp.2043–2045. New York: IEEE.

22.

Manohar

Reuban Gnana Asir

. Data consumption pattern of MQTT protocol for IoT applications. In: Venkataramani

Sankaranarayanan

Mukherjee

et al . (eds.) Smart secure systems—IoT and analytics perspective. Singapore: Springer, 2018, pp.12–22.

23.

Hernandez-Rojas

Mazon-Olivo

Novillo-Vicuña

et al . IoT Android gateway for monitoring and control a WSN. In: Botto-Tobar

Esparza-Cruz

León-Acurio

et al . (eds) Technology trends. Cham: Springer, 2018, pp.18–32.

24.

Lozano Murciego

Caridad

Francisco De Paz

et al . Smart waste collection system with low consumption LoRaWAN nodes and route optimization. Sensors 2018; 18: E1465.

25.

Catherwood

Steele

Little

et al . A community-based IoT personalized wireless healthcare solution trial. IEEE J Transl Eng Health Med 2018; 6: 1–13.

26.

LoRa-Alliance. LoRaWAN 101—a technical introduction, 2017, https://docs.wixstatic.com/ugd/eccc1a_20fe760334f84a9788c5b11820281bd0.pdf

27.

Semtech Corporation. AN1200.22 LoRa modulation basics. Semtech, Application note Revision 2, 2015, http://www.semtech.com/uploads/documents/an1200.22.pdf (accessed 8 October 2018).

28.

Semtech Corporation. AN1200.13 SX1272/3/6/7/8: LoRa modem designer’s guide. Semtech, 2013, https://www.semtech.com/uploads/documents/LoraDesignGuide_STD.pdf (accessed 8 October 2018).

29.

OASIS. MQTT version 3.1.1. Burlington, MA: OASIS, 2014.

30.

Github. MQTT libraries, 2017, https://github.com/mqtt/mqtt.github.io/wiki/libraries

31.

Semtech Corporation. SX1276/77/78/79 - 137 MHz to 1020 MHz low power long range transceiver datasheet. Semtech, 2016, https://www.semtech.com/uploads/documents/DS_SX1276-7-8-9_W_APP_V5.pdf (accessed 8 October 2018).

32.

Microchip. 32-bit ARM-based microcontrollers: Sam D21E / SAM D21G / SAM D21J, 2017, http://ww1.microchip.com/downloads/en/DeviceDoc/40001882A.pdf

33.

Eclipse. Eclipse paho—MQTT and MQTT-SN software, 2012, https://www.eclipse.org/paho

34.

Del Campo

Gambi

Montanini

et al . MQTT in AAL systems for home monitoring of people with dementia. In: IEEE 27th annual international symposium on personal, indoor, and mobile radio communications (PIMRC), Valencia, 4–8 September 2016, pp.1–6. New York: IEEE.

35.

Zhu

Pang

Xie

et al . IETF IoT based wireless communication for latency-sensitive use cases in building automation. In: IEEE 25th international symposium on industrial electronics (ISIE), Santa Clara, CA, 8–10 June 2016, pp.1168–1173. New York: IEEE.