Daily activities have become more efficient and convenient with home automation. There are many different home automation devices in the market for consumers to enjoy their home for being smarter, resourceful, and remotely accessible. However, current home automation protocols lack extensibility and compatibility. In this paper, we propose a protocol standard for home automation system called Home Automation Device Protocol (HADP). This protocol standard aims for the interoperability of home automation devices across different platforms. Based on the IFTTT (IF-This-Then-That) model, we define a set of device communication protocols where devices’ triggers and actions are combined to generate and manage interactions through a central node. The proposed protocol standard offers low power consumption and low bandwidth requirements using the minimum data packets to trigger an action on a home automation device. The protocol supports various communication mediums such as Wi-Fi, Bluetooth 4.2, ZigBee IP, 6LoWPAN, IEEE 802.15.4 standards, and Ethernet orany network layer supporting IPv6 protocol.
Internet of Things (IoT) is changing the way to interact and access the devices in various automated environment. The main objective of IoT is to enhance both device-to-device interactions, as well as device-to-human interactions via Internet [
There exists several home automation systems and each of them can utilize separate protocols such as Wi-Fi, ZigBee, Z-Wave, X10, Universal Powerline Bus (UPB) and more [
The choice of communication medium depends on the type of sensors or actuators in home automation system. Nevertheless, the communication protocol must allow low energy consumption and sufficient data security. For wireless devices, low energy consumption is crucial for battery life. In particular for IoT devices, power consumption is even more critical. There are varieties of wireless protocols aimed for low power consumptions. ZigBee IP and Bluetooth 4.2 are available options that can be used for sensor nodes. For providing a low power direct Internet accessibility to the sensors, a protocol called 6LoWPAN can be considered. It implements the reduced version of IPv6 protocol for maximizing IEEE 802.15.4 standard’s power and communication efficiency [
Beside the communication protocol, home automation requires an approach to program interactions among different devices. In this paper, we utilize the notion of IFTTT (IF-That-Then-This) to address this issue. IFTTT is a web-based service that allows Internet users to create a chain-reaction from one web service application to another [
The IFTTT model can be applied to home automation devices where one device can trigger the action of another device.
In this paper, we present a protocol standard for unifying home device interactions called Home Automation Device Protocol (HADP). This protocol is focused on enabling compatible connectivity of any home automation devices developed by different manufacturers. The protocol is based on the IFTTT (IF-This-Then-That) model, optimized for low power, and utilizes IPv6 UDP network protocol. The proposed home automation protocol provides the unified standard and techniques for connecting home automation devices, and user-defined home device interactions through the central node. This allows communication mediums such as Wi-Fi, Bluetooth 4.2, ZigBee IP, 6LoWPAN or Ethernet to be used for HADP.
This paper is organized as follows: Section 2 presents the full description of HADP including details of the protocol mechanism; Section 3 discusses the technical approach towards the reliability of HADP; Section 4 de-
scribes the importance of Quality-of-Service (QoS) in HADP; Section 5 explains multi-hop routing scheme in HADP; Section 6 summarizes this paper.
The proposed HADP is designed to support the needs of the home automation network. It defines a set of rules which allows users to implement configurations over a set of interactions known as recipes. These recipes consist of associating actions/triggers to various devices in the home automation network. Therefore, each device requires to define and provide a set of triggers and a set of actions to be performed. Below, we present a complete description of the protocol, and define triggers and actions in detail. The proposed protocol is inspired by the CoAP protocol, designed for resource-constrained IoT devices [
A new device upon connection to a network must register to the central node. Therefore, the new device sends a broadcast message called Discovery packet in order to find the central node which is followed by a reply from the central node. In this initial stage, the central node sends request to the device asking its features, which is a description of the different triggers and actions described below. The device formats this data in a Descriptor packet. Even though this packet can be potentially large, this will not impact on the device power consumption since it should only be sent once when initially introduced in the network.
The triggers are sent from a device to the central node. It can be either an empty packet with a trigger flag and the trigger ID, or it can contain a certain payload, with a type defined in the device descriptor. In the case of a packet with embedded data, the central node can propose different actions to the user depending on the nature of the data and its value. For example, the trigger of a temperature sensor would have the measured temperature as part of the packet’s data.
The actions are controlled from the central node. As for the trigger, the packet can be empty with just an action flag and the action ID, or contain a payload. The payload can be used to configure the action to defined parameters. For example, the Action packet for a RGB light bulb would contain the new color intensities for red, green and blue.
All packets start with two bits defining the version of the protocol (00 for this revision), and two bits defining the packet type. The protocol is composed of four different types of packets: Connection, Descriptor, Trigger and Action.
The Connection packet is used to handle the connection between the central node and the home device. It is used by devices to discover the available central node(s), perform connection request and confirmation, and finally generate acknowledgement packets.
・ The Acknowledgment packet is used to acknowledge the reception of a packet that requires acknowledgement. The next byte in the header is the packet ID (3 bits).
・ The Discovery packet is used to send a discovery request on the network. This packet should be sent by the device in multicast over the network. Next byte is a token for the request.
・ The Offer packet is used by the central node to respond to a Discovery request and offers the device to connect. The next byte is the token from the Discovery request.
・ The Confirm packet is used by the device to confirm the connection to a central node. The token found in the Discovery and Offer packets is included in the data, as well as the Vendor ID, Product ID and Serial number of the device that is unique as shown in
The connection process is shown in
In order to support basic Quality-of-Service (QoS), the Connection packet supports the transmission of QoS related data, with the packet format defined in
・ BW: Indicates that a bandwidth/throughput requirement is embedded in the data;
・ BER: Indicates that a Bit Error Rate information is embedded in the data;
・ Prio.: Indicates that a priority information is embedded in the data;
・ Delay: Indicates that a maximum delay requirement is embedded in the data;
・ Batt.: Indicates that a battery level information is embedded in the data.
An extra Request flag is available so that the central node can force the nodes to transmit the data. Data selection is done by enabling each individual flag of the required data. No acknowledgement is required for this packet.
The Descriptor packet is used to transmit the different features of the device. It contains all the information about the different triggers and actions, and the type of data they support.
The transmitted data contains the Vendor ID, Product ID and Serial number of the device. Then, it is followed by the number of triggers, and the description of each trigger, and then the number of actions and the description of each action.
The data type includes information about the data transmitted, with not only the type of data, but also can include a small description, formatted as shown in
A flag allows to define the data as being an array of variables of the same type. In this case, the data is preceded by one byte defining the number of elements on the array in the following packets for trigger and action. The UTF-8 string is a natural array and its format is also preceded by the size of the string, but over 2 bytes.
The Trigger packet is sent by the device to the central node to report an event or a value. The packet is organized as shown in
Code | Data Type |
---|---|
000000 | Boolean |
000001 | Char |
000010 | Unsigned char |
000011 | Short |
000100 | Unsigned short |
000101 | Int |
000110 | Unsigned int |
000111 | Long |
001000 | Unsigned long |
001001 | 128 bits |
001010 | Unsigned 128 bits |
001011 | 256 bits |
001100 | Unsigned 256 bits |
001101 | Float |
001110 | Double |
001111 | UTF-8 |
010000 | UTF-8 String |
010001 | Localization (Country/Region) |
010010 | Localization (GPS) |
010011 | Time |
010100 | Forecast Summary |
The second byte includes two flags:
・ The Multi-packet flag indicates that the packet includes data for different devices, and that data needs to be relayed. This functionality is described in Section 2.4.6;
・ The Frag. flag indicates that the packet is divided across several packets. This can replace or complement the eventual lower layers of the network stack. When this functionality is used, a token is inserted to keep track of the data between the different packets.
The remaining 6 bits are used to indicate the Trigger ID, which defines the type of data that is transmitted, if any. The type of data transmitted needs to match the one described in the Descriptor.
The Action packet is sent by the central node to device. The packet is virtually identical to the Trigger packet, as shown in
The second byte includes two flags:
・ The Multi-packet flag indicates that the packet includes data from different devices, and that data needs to be relayed to the central node. This functionality is described in Section 2.4.6;
・ The Frag. flag indicates that the packet is divided across several packets. It has the same purpose than for the Trigger packets.
The remaining 6 bits are used to indicate the Action ID, which defines the type of data that is transmitted, if any. The type of data transmitted needs to match the one described in the Descriptor.
Several actions and triggers can be concatenated in a single packet in an attempt to save power by reducing the number of transmitted packets. The functionality differs between the actions and the triggers. The central node can decide to pack a certain number of actions in a single packet, to be sent to several nearby devices on the network. This allows to minimize the number of packets transmitted through the network.
The actions are read sequentially and therefore the efficiency of this method depends on the capability of the central node to determine an optimum route. In this case, the central node also expects only one acknowledgement from the last node addressed in the packet, if requested.
The triggers concatenation is managed by the devices relaying the data to the central node. The behavior is more opportunistic, and consists of adding its own trigger to the packet if the device was about to send it on another packet. In this case, the devices still require separated acknowledgement packets, but a device adding data to the packet can eventually acknowledge the data in place of the central node, and take care of the retransmission in case the central node doesn’t acknowledge the data.
When the Multi-packet flag is set, the data is preceded by the offset for the next data in bytes. Each data is also followed by the IP of the next device. The IPv6 device addresses are compressed using the method defined by the 6LoWPAN protocol.
Reliability of data transmission is crucial in home automation application. To date, several techniques have been designed to address the reliability of packet transmission in TCP/UDP protocols. However, these protocols are not lightweight and therefore not suitable for home automation applications. The reliable transmission of a packet in the proposed protocol is initiated by marking the packet as “acknowledgeable” in the HADP header. An acknowledgeable packet always specifies that it requires confirmation from the receiver by setting the ACK flag. The receiver is required to confirm the reception of the packet by sending an acknowledgement packet. The acknowledgement packet must echo the packet ID of the acknowledgeable packet. In case the sender does not receive any reply from the receiver, it retransmits the acknowledgeable packet until it receives a confirmation packet or runs out of attempts. Retransmission is controlled by two parameters: a timeout and a retransmission counter. HADP node needs to keep track of these values for each sent packet while waiting for an acknowledgement. For a new acknowledgeable packet, the timeout is set to a random value called TIMEOUT_RETRANSMIT and the retransmission counter is set to the value zero. When the timeout is triggered and the retransmission counter is less than TIMEOUT_RETRANSMIT, the packet will be retransmitted with the same ID and the retransmission counter is incremented. If the retransmission counter reaches TIMEOUT_RETRANSMIT on a timeout for a maximum number of retransmission, then the sender will stop sending the packet and inform the process of failure in delivery. Otherwise, if the endpoint receives an acknowledgement in time, the packet transmission is considered successful. This approach ensures the reliability of message and can be implemented on resource-constraint devices.
Providing Quality-of-Service (QoS) is among the most important requirements of multimedia services for the home automation networks. The increase of demands for high bandwidth devices such as high quality Audio/Video, streaming, Voice over IP (VoIP) and Internet TV, requires fair allocation of network resources among
different devices inside homes. Furthermore, the delay sensitive devices such as VoIP phones make the QoS implementation in home automation more appealing. However, current QoS frameworks, such as Universal Plug and Play QoS architecture [
・ Delay: The packet delivery time is crucial mainly for multimedia applications in home automation where only few milliseconds of delay could result in service disruption. The delay often due to the queuing of the data or the transmission delay.
・ Bit Error Rate (Wireless Quality): Reliability of data transmission could be affected by the ratio of the number of error bits received at the receiver to the number of bits generated by the sender known as Bit Error Rate (BER). Higher BER could result in the waste of valuable energy since the packet needs to be re-trans- mitted.
・ Energy Consumption: It is important to allocate resource with the goal to minimize the overall energy consumption of the devices. Besides, some devices are battery-powered and their energy needs to be saved for long time.
・ Throughput: Devices require homogeneous packet delivery ratio in a home automation which varies from few bits per second to several megabits per second depending on the application requirements.
The application of home automation spans from a small-size house to large commercial buildings. Since the HADP design is a centralized solution, it mainly relies on the central node to perform resource allocation and scheduling. Therefore, providing signal coverage for large-scale scenarios becomes a challenging task and requires careful planning. Furthermore, a pure centralized approach may increase the overall energy consumption of the system as the energy depletion due to transmission increases exponentially with distance between the sender and the receiver. In order to overcome this challenge, we propose to utilize the wireless multi-hop routing between devices. This approach is similar to IPv6 header characteristic where the options are linked together in the format of a linked list. Suppose a central node needs to send a message to node A and B which are in the vicinity of each other while the device A is closer to the central node. Then, central node will create a concatenated packet as shown in
Whenever the device A receives a multi-hop packet, it pops the top part of the message body and sends the remaining part of the message to the next device. Two issues may arise in this setting. First, the existence of multiple messages inside a single packet will increase the size of the packet and therefore waste the energy consumption of intermediate nodes. Furthermore, security is a big challenge in this approach as devices are able to observe or modify the messages belonging to other devices. In order to tackle the first issue we propose to use the IPv6 address compression which has been implemented in 6LoWPAN [
of processing constrains are left as Reduced-Function Devices (RFD) and kept out of the multi-hop routing. As for the security issue, the suggested solution is to encrypt or sign the data contained in the message when necessary.
In this paper, we proposed the Home Automation Device Protocol (HADP) to allow scalability, extensibility and compatibility of home automation systems. Using the proposed home automation protocol standard, we incline to transcend the barrier of incompatibility across the home automation platforms. This paper proposes a device communication protocol based on the IFTTT model with triggers and actions defined for each device and managed using a central node. The proposed protocol standard operates with four different types of packets designed to allow low power consumption and low bandwidth requirements on the wired/wireless mediums. The use of the IPv6 allows any supported medium to work with HADP. Examples of HADP-enabled mediums include Wi-Fi, Bluetooth 4.2, ZigBee IP, 6LoWPAN and IEEE 802.15.4 standards.
ThomasGonnot,Won-JaeYi,EhsanMonsef,JafarSaniie, (2015) Home Automation Device Protocol (HADP): A Protocol Standard for Unified Device Interactions. Advances in Internet of Things,05,27-38. doi: 10.4236/ait.2015.54005