УДК 004
Sarapulov M.
Kazakh-British Technical University (Almaty, Kazakhstan)
METHODS FOR CREATING A UNIVERSAL GATEWAY FOR SMART THINGS
Аннотация: every day there are more and more different "smart" devices. In addition to the already familiar smartphones and cars, the Internet of Things (IoT) is actively developing Setting up a smart home is getting easier every day due to the large number of smart devices at a reasonable price and easy installation. The widespread popularity of "smart" devices creates a high demand in the market and a large number of companies produce a large number of devices. However, when creating their own devices, companies rarely look towards the interaction of their products with products from other companies. This creates problems when the user has to install several smart home control applications and buy additional devices - smart home control units. This fact suggests that it is not very convenient for users to have many applications and additional expenses.
Ключевые слова: smart things, smart devices, Internet.
I. INTRODUCING.
Before we start, it's worth introducing the concept of the Internet of Things. What is the Internet of Things? The book The Fourth Industrial Revolution gives the following concept - In its simplest form, it can be described as a relationship between things (products, services, places, etc.) and people that is made possible by connected technologies and various platforms.(1) This simple and concise description immediately makes it clear that the Internet of Things of things could be connected to smart homes or earthquake warning systems. There are a lot of devices that can communicate on the Internet of Things, and all of those devices need to be controlled or receive data from connected devices. Gateways are used for this purpose.
Gateways are a device that is the entry point for user interaction. If you connect the IoT to a building, the gateway is a door. This is the device that provides the
communication and processing of data from all devices connected to it, as well as providing an interface for working with data
As a rule, gateways are quite unique for each manufacturer of smart devices and can not work with devices of other companies. This imposes restrictions on the use of devices from different manufacturers. So, for example, so that we can use smart lights from one company and smart outlets from another, we need to buy two additional devices that will work with the devices. The more we want different devices, the more devices we have to buy
Based on this problem, we began to study the literature in search of solutions to create a unified gateway for all smart devices
During the literature review, it was decided to study past work on the creation of IoT gateways, as well as the issues of the operation of various protocols. First of all, it was decided to study the typical ways of creating an IoT network in order to determine the strengths and weaknesses of the available technologies and developments. Understanding these things will allow you to adjust the course of research and, before starting implementation, collect the necessary data on existing developments. A typical smart home architecture device consists of the following things: Data collectors, communication methods, cloud server.[1] Data collectors are some devices that can collect indoor weather data, door opening and closing data, water sensors, and so on. All of these devices communicate using various protocols. For closed companies, it is impossible to understand what protocol they use. However, there are also protocols known to all that allow devices to work with each other. One example of a common protocol for the interaction of smart home devices is Zigbee. This protocol is not new and many devices and smart homes are already successfully implemented on it (2), but like others, they require interaction with third-party cloud computing servers. During the study of this protocol, it was determined that it is the best solution for the implementation of our research task.
After the literature review, the following disadvantages were identified, which we would like to solve in the course of our study. One of the main disadvantages is the preference for cloud data processing, which does not allow us to use our smart home
devices in the absence of an Internet connection. Despite the fact that at the moment the Internet has been brought to almost all corners of our planet, there are still re gions with poor connection or not connected to the Internet at all. This does not allow the installation of smart devices in such places or requires significant investments in the creation of the necessary infrastructure, which requires advanced knowledge and skills. We want to simplify the process of creating a smart home by creating a simple device that will solve many problems. And to solve these problems, we decided to make a test bed that would work with the zigbee protocol and connect several devices to it
II. METHODOLOGY.
After researching other work on the topic, we determined for ourselves the goals and first of all, we decided to identify the necessary components of the system. In order to to build a test bench we decided to make minimum financial investments and to find on the market some ready and not expensive devices which would allow us work with ZigBee protocol.
During our research we found that there are different devices for working with ZigBee We found several options for using the ZigBee protocol, both off-the-shelf solutions which already work with this protocol and USB devices that allow to control smart devices with the help of PC
We chose the second type of devices as it allows us to work with the devices in a more delicate way and We don't have the limitations of off-the-shelf solutions. This approach allowed us to understand more precisely how smart devices work and how we can control them and how we can retrieve data
Based on this data we chose the ZigBee stick CC2652R (Fig 1) to work with our devices This stick has all the functionality we need, and does not require any additional configuration before use.
Fig. 1. Zigbee stick CC2652RB.
After determining the purchase of the stick, we went to the next step in building a test bench and began and started to investigate the technologies that were suitable for us. Based on our requirements we determined that the ZigBee format signals signals we had to process somehow. In the search for suitable technologies we went back to the research of solutions.
We found two popular technologies which allow to work with the ZigBee protocol using our device The next step was to do a comparative analysis to find the most suitable technology. While studying the documentation and the technology itself, the zigbee2mqtt project was selected. This project was chosen for the following reasons:
1) Clear and easy to understand documentation, which allows you to get started fairly quickly
2) The wide range of devices supported by this project from a huge number of vendors
3) Independence from the interface implementation. This project provides the user interface, but it we can use all the methods in our own application if we want to.
Î
Fig. 2. Schema of communication.
After selecting a project to work with ZigBee, we defined the basic scheme of work. In our vision, a single gateway will allow to unite many IoT devices from
different manufacturers and provide the user with a single interface to work with them. (Fig. 2)
Having defined the main elements of the system and the circuit diagram, we proceeded to the implementation of the test bench. To do this, after installing ZigBee2MQTT on the local machine. This system allows us to install applications in a docker container, which made our work much easier. Once the application was running we could see the available interfaces and make sure that everything worked.
Next we took one of the test devices and connected it to our system according to the documentation on the ZigBee2MQTT website. Each device has a unique connection to the obtained stand, which was taken into account in the ZigBee2MQTT project documentation. This allowed us to quickly test the capabilities of the connected devices.
As an example, we used a smart lightbulb. After connecting it we were able to receive data about the current state of the light bulb as well as control this state. HTTP requests in the format: base_topic/device_name Thus routing the request and sending signal to the desired device in the network
After the experiment with the ready-made solution we decided to move on to the next stage of the experiment, namely, implementation of our own application to provide maximum control in ZigBee network management. Before starting the experiment, we thoroughly studied the documentation provided by Texas Instruments to create a complete understanding of how the standard works and what things can be realized with their CC2652R chip After a lengthy analysis and review of the specifications, we set about implementing a test application based on Zigbee Network Processor(ZNP) technology
The existing Zigbee network was deployed using a previously configured computer with Zigbee2MQTT installed. This saved us a lot of time implementing the network from scratch and allowed us to develop the application faster.
The next thing we had to deal with was that not every firmware of the CC2652R radio module allowed us to communicate with it via UART. This complicated matters
and made us go back to studying the documentation. During the study we found out that there are different firmware configurations for different types of devices. After studying this issue we found some solutions in open source that helped us to flash the device and get started.
ZNP (Zigbee Network Processor) is a type of architecture used in Zigbee enabled devices. ZNP allows splitting the functions of Zigbee stacks between two components: a microcontroller and an RF module. In our case, the microcontroller was a mobile device running the Andoroid operating system, and the RF module was a module running the CC2652R processor. The module has a USB Type A connector, which is not a standard connection port for Android devices. Therefore, to ensure communication we connected 2 devices by means of an adapter. For the first device we used an adapter from Type A to Type C, and in the other case an adapter from Type A to Micro USB.
Only after completing these configurations can the device begin sending and receiving messages within the Zigbee network. This sequence of commands ensures that the device is correctly set up to participate in the network, supporting reliable and efficient communication. Proper configuration is essential for maintaining network stability and achieving seamless integration with other Zigbee devices.
This detailed process highlights the importance of careful and precise setup to fully leverage the capabilities of the Zigbee protocol, ensuring robust and secure communication across the network. For further technical details and command specifications, refer to the Zigbee documentation and the ZNP interface guides provided by Texas Instruments
III. RESULTS.
During the search for devices to be used in the test bench, we also found that there are other devices that work with this protocol During further research we determined that we can use only boards that are able to communicate with this protocol This knowledge allows us to conclude that for simple ready made solution we can use
any ready-made microcomputer, which will be combined with the board to work with ZigBee devices.
Thus having built a test bench we were able to get a result in the form of a ready to work smart gateway to work with various devices. The technical part of the work gave us the following understanding:
• There are ready-made solutions in the form of devices connected to a personal computer
• Off-the-shelf solutions in the form of fully working devices
• There are boards which allow connecting them to other boards and building your own ready-made device to work with with smart devices
The research of the software part has led us to the fact that there are projects that make it possible to conveniently convert ZigBee signals into program code and work with this data. In our case we used the ZigBee2MQTT project which converts the ZigBee signals into the MQTT protocol message format, which is sent in a queue for processing and then it is processed by the ZigBee2MQTT application. An existing off the shelf solution helped us to see which way most convenient way to communicate with ZigBee devices and helped us understand the existing standards for working with IoT devices.
MQTT (Message Queuing Telemetry Transport) is a lightweight publish-subscribe messaging protocol designed for efficient communication between devices over unreliable networks. It is commonly used in Internet of Things (IoT) applications to enable efficient and reliable data exchange between devices.
Here are some key characteristics of MQTT:
1) Publish-Subscribe Model: MQTT uses a publish subscribe pattern where devices can publish messages to topics, and other devices (subscribers) can subscribe to those topics to receive the messages. This decoupled communication model allows for efficient and scalable data distribution.
2) Lightweight and Efficient: MQTT is designed to be lightweight and efficient, making it suitable for resource constrained devices and networks with low bandwidth or high latency. It uses a small message header and has a minimal network footprint.
3) Quality of Service (QoS): MQTT provides three levels of Quality of Service: QoS 0 (at most once), QoS 1 (at least once), and QoS 2 (exactly once). These levels determine the guarantee of message delivery and allow trade-offs between reliability and network overhead.
Based on these data we were able to obtain data on how the interaction with ZigBee in general occurs at the software level and what approaches we can use to create our own gateway solution for smart devices The use of the MQTT protocol is great for working with smart devices because it allows you to efficiently work with short and frequent signals from smart devices.
Using the MQTT protocol we can build our own commu nication for the interaction of IoT devices with our gateway which will allow you to configure it more finely. It is also possible to use an off-the-shelf product like ZigBee2MQTT, However, this does not give much flexibility, and to create a single gateway for all IoT devices may not be suitable
Using this application gave us an understanding of the principles by which we can organize communication and what kind of data we can receive, but using the HTTP standard and the big data standard like JSON can slow down the
smart devices a lot, which would be less responsive. On this basis, we have taken into account that when creating our own gateway, we need to consider the standards of data transfer that will be used, because they require the ease and simplicity of serialization of this data
As a result, it was also found that despite the fact that in the current situation IoT gateways from different companies require a connection to the network to work, the presence of the Internet at the device is not an important factor. Gateways created in this way are autonomous and allow to work with the devices of the Internet of things without using the Internet connection of someone or of the participants. The presence of the Internet may be required only for remote control of smart devices. However, modern releases require a network connection not only for remote control, but also to control devices in general, which does not allow a comfortable use of smart devices without stable Internet connection
After creating a test stand and performing a number of tests we determined a number of advantages and disadvantages of ready-made solutions
IV. CONCLUSION AND FUTURE WORKS.
While working on the test bench, we identified a number of important things for working with smart devices and also found out a number of problems with current solutions. For example, the slow and heavy JSON data type can't always provide optimal performance. If you try to complicate the future gateway in the technical part you will inevitably face significant increase of component costs. This problem can be solved by using binary data types which are much easier to process with less powerful computers. Using simpler and lighter data types presumably will increase the speed of work with smart devices and become more responsive to the user
Working with the ZigBee2MQTT software gave us a basic understanding of how to make the devices with Gateway and how we can build our own software to work with smart devices. The need to build our own implementation of the software arises because of the high speed requirements which the device under test was unable to show. Also our own solution will allow us to create more flexible settings, and the use of faster technology will significantly reduce the speed of waiting for a reaction on the user's output. Using JavaScript as the main language for ZigBee2MQTT imposes certain limitations for use in fast smart devices such as a smart gateway
In future works, we plan to develop each of the described aspects of the gateway for smart devices in stages. First and foremost we will create our own implementation of ZigBee signals transformation into MQTT messages, which will allow to reduce latency with smart devices. This stage is an important area in understanding the principles of gateway creation and will allow us to look even deeper into the principles of of both the protocols and the devices themselves.
In future works we will conduct a series of experiments to create our own ready-made device which could replace all the regular Gateways of different companies with one Gateway
using all the knowledge we have received in these and and subsequent works.
СПИСОК ЛИТЕРАТУРЫ:
1. The Fourth Industrial Revolution. Klaus Schwab (2016);
2. The deployment of an IoT network infrastructure, as a localised regional service (2019);
3. ENABLING IOT SERVICES USING WIFI - ZIGBGATEWAY FOR A HOME AUTOMATION SYSTEM (2015);
4. A Multi-Protocol IoT Gateway and WiFi/BLE Sensor Nodes for Smart Home and Building Automation: Design and Implementation (2019);
5. Development of an Easy Payment System based on IoT Gateway (2018);
6. Communication Protocol Stack for Constrained IoT Systems (2018)