{"id":55356,"date":"2020-01-18T00:00:00","date_gmt":"2020-01-17T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/lytko-obedinyaet"},"modified":"2020-02-18T14:03:28","modified_gmt":"2020-02-18T11:03:28","slug":"lytko-obedinyaet","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/lytko-obedinyaet","title":{"rendered":"Lytko unites","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Some time ago, we introduced you to a smart thermostat<\/a><\/noindex>. This article was initially intended to demonstrate its firmware and control system. However, to explain the thermostat's functionality and what we have implemented, it is necessary to outline the entire concept as a whole.<\/p>\n

\"Lytko
\n<\/a><\/noindex><\/p>\n

About automation<\/h3>\n

\nGenerally, all automation can be divided into three categories:
\nCategory 1<\/u> \u2014 separate 'smart' devices. You purchase bulbs, kettles, etc., from different manufacturers. Pros: each device expands functionality and increases comfort. Cons: each new manufacturer requires its application. Device protocols from different manufacturers are often incompatible with one another.<\/p>\n

Category 2<\/u> \u2014 installation of a single-board PC or x86 compatible system. This removes limits on computing power, and you can install MajorDoMo or any other server distribution to manage your smart home. Thus, devices from most manufacturers are connected in a unified information space. That is, you have your own server for the smart home. Pros: compatibility under a single center provides expanded management capabilities. Cons: if the server fails, the whole system reverts to phase 1, meaning it becomes fragmented or useless.<\/p>\n

Category 3<\/u> \u2014 the most hardcore option. During the renovation phase, all communications are laid out and all systems are duplicated. Pros: everything is perfected to an ideal level, making the home truly smart. Cons: extreme cost compared to categories 1 and 2, requiring thorough planning of all details in advance.<\/p>\n

Most users choose option one and then gradually transition to option two. Eventually, the most persistent reach option three. <\/p>\n

However, there is an option that can be called a distributed system: each individual device will act as both a server and a client. Essentially, this is an attempt to combine option 1 with option 2. To take all their pros and eliminate the cons, finding a middle ground. <\/p>\n

Some might say that such an option has already been developed. However, these solutions are narrow-focused; intended for those well-versed in programming. Our goal is to lower the entry barriers for such distributed systems, both in terms of end devices and in integrating existing devices into our system. With a thermostat, for example, the user simply removes their old thermostat, installs a smart one, and connects their existing sensors to it. No additional actions are required.<\/p>\n

Let's consider the integration into our system using an example. <\/p>\n

Imagine we have 8 Sonoff modules in our network. Some users may find cloud control via Sonoff sufficient (category 1). Others will opt for third-party firmware and gradually transition to category 2. Most third-party firmware works on the same principle: data transmission to an MQTT server. OpenHub, Majordomo, or any other serve the same purpose \u2013 to unify disparate devices into a single informational space, located either on the Internet or within a local network. Consequently, having a server is mandatory. Hence, the main problem arises \u2013 if the server fails, the entire system stops functioning autonomously. To prevent this, systems become more complex, adding manual control methods that duplicate automatics in case of server failure. <\/p>\n

We, however, took a different approach, where each device is self-sufficient. Thus, the server does not play a crucial role, merely expanding functionality.<\/p>\n

Let's return to our thought experiment. Again, we will take the same 8 Sonoff modules and install Lytko firmware on them. All Lytko firmware implementations feature a function SSDP<\/a><\/noindex>. SSDP is a network protocol based on a set of Internet protocols used for announcing and discovering network services. A response to a request can be either standard or extended. In addition to standard functions, we have incorporated the creation of a list of devices on the network. Thus, the devices find each other on their own, and each will have such a list. An example of an SSDP list:<\/p>\n

\"ssdpList\": \n\t{\n\t\t\"id\": 94967291,  \n\t\t\"ip\": \"192.168.x.x\",\n                \"type\": \"thermostat\"\n\t}, \n\t{\n\t\t\"id\": 94967282,\n\t\t\"ip\": \"192.168.x.x\",\n                \"type\": \"thermostat\"\n\t}<\/code><\/pre>\n
\nAs seen in the example, the list includes device IDs, IP addresses in the network, and the type of block (in our case, a thermostat based on Sonoff). This list is updated every two minutes (this interval is sufficient to respond to dynamic changes in the number of devices in the network). Thus, we track the addition, modification, and disconnection of devices without any action from the user. This list is sent to the browser or mobile app, and the script generates a page with the specified number of blocks. Each block corresponds to one device\/sensor\/controller. Visually, the list looks like this:<\/p>\n
\"Lytko
\n
\nBut what if other radio sensors are connected to the esp8266\/esp32 via cc2530 (ZigBee) or nrf24 (MySensors)? <\/p>\n
About projects<\/h3>\n
\nThere are various distributed systems on the market. Our system allows integration with the most popular ones. <\/p>\n
Below are projects that in one way or another aim to change the situation with incompatibility between different manufacturers. These include, for example, SLS Gateway<\/a><\/noindex>, MySensors <\/a><\/noindex> or ZESP32<\/a><\/noindex>. ZigBee2MQTT <\/a><\/noindex> is tied to the MQTT server, so it does not fit the example. <\/p>\n
One of the implementations of MySensors is a gateway based on ESP8266. The other examples are on ESP32. In them, we can implement our principle of device detection and list creation. <\/p>\n
Let's conduct another thought experiment. We have a ZESP32 or SLS Gateway or MySensors gateway. How can we unify them in a single information space? We will add the SSDP protocol library to the standard functions of these gateways. When accessing this controller via SSDP, it will add a list of devices connected to it to the standard response. Based on this information, the browser will generate a page. In general, it will look like this:<\/p>\n
\"Lytko
\nWeb Interface<\/i><\/p>\n
\"Lytko
\nPWA application<\/i><\/p>\n
\"ssdpList\": \n{\n   \"id\": 94967291, \/\/ unique device identifier\n   \"ip\": \"192.168.x.x\", \/\/ IP address in the network\n   \"type\": \"thermostat\" \/\/ device type\n},\n{\n   \"id\": 94967292,\n   \"ip\": \"192.168.x.x\",\n   \"type\": \"thermostat\"\n},\n{\n   \"id\": 94967293,\n   \"ip\": \"192.168.x.x\",\n   \"type\": \"thermostat\"\n},\n{  \n   \"id\": 13587532, \n   \"type\": \"switch\"  \n},\n{  \n   \"id\": 98412557, \n   \"type\": \"smoke\"\n},\n{  \n   \"id\": 57995113, \n   \"type\": \"contact_sensor\"\n},\n{  \n   \"id\": 74123668,\n   \"type\": \"temperature_humidity_pressure_sensor\"\n},\n{\n    \"id\": 74621883, \n    \"type\": \"temperature_humidity_sensor\"\n}\n<\/code><\/pre>\n
\nThe example shows that devices are added independently of each other. Three thermostats with their own IP addresses and five different sensors with unique IDs are connected. If a sensor is connected to the Wi-Fi network, it will have its own IP; if connected to a gateway, the device's IP address will be that of the gateway.<\/p>\n
We use WebSocket for communication with devices. This minimizes resource consumption compared to GET requests and allows for dynamic information updates upon connection or changes. <\/p>\n
Data is taken directly from the device that owns the block, bypassing the server. Thus, if any device fails, the system continues to operate. The web interface simply does not display the missing device from the list. However, a notification about the loss will be sent to the user's application if necessary. <\/p>\n
The first attempt to implement such an approach was a PWA application. This allows for storing the block database on the user's device and requesting only the necessary data. However, due to structural features, this option is incomplete. The only solution is a native application for Android and iOS, which is currently in active development. By default, the application will only work in the internal network. If needed, everything can be switched to external management. Thus, when the user leaves the local network, the application automatically switches to the cloud. <\/p>\n
External management is a complete duplication of the page. When the page is activated, the user can log in to the server and control the devices through their personal account. Thus, the server expands functionality, enabling users to manage devices while away from home and not being tied to port forwarding or a static IP.<\/p>\n
Thus, the aforementioned option lacks the shortcomings of the server approach and has several advantages, such as flexibility in connecting new devices.<\/p>\n
About the thermostat<\/h3>\n
\nLet's consider the control system using our thermostat as an example.<\/p>\n
Features include:<\/p>\n
    \n
  1. Temperature regulation for each thermostat (displayed as a separate block);<\/li>\n
  2. Scheduling the operation of the thermostat (morning, day, evening, night);<\/li>\n
  3. Selecting the Wi-Fi network and connecting the device to it;<\/li>\n
  4. Airborne device updates;<\/li>\n
  5. MQTT configuration;<\/li>\n
  6. Configuring the network to which the device is connected.<\/li>\n<\/ol>\n
    \n\"Lytko
    \n
    \nIn addition to controlling via a web interface, we have provided a classic option \u2014 pressing on the display. It features a 2.4-inch Nextion NX3224T024 monitor. This choice was made due to the ease of use with the device. However, we are developing our own monitor based on STM32. Its functionality is just as good as that of the Nextion but will cost less, which will positively affect the final price of the device.<\/p>\n
    \"Lytko
    \n
    \nLike any respectable thermostat screen, our Nextion can:<\/p>\n