Some time ago we presented you . The current article was originally conceived as a demonstration of its firmware and control system. But in order to explain the logic of the thermostat and what we have implemented, it is necessary to outline the whole concept as a whole.
About automation
Conventionally, all automation can be divided into three categories:
Category 1 — separate “smart” devices. You purchase light bulbs, kettles, etc. from different manufacturers. Pros: Each device expands the possibilities and increases comfort. Cons: Each new manufacturer needs its own application. The protocols of devices from different manufacturers are often incompatible with each other.
Category 2 - installation of a single-board PC or x86 compatible. This removes the limitations on computing power, and MajorDoMo or any other server distribution kit for smart home control is installed on this machine. Thus, the devices of most manufacturers are connected in a single information space. Those. the Server for the smart house appears. Pros: compatibility under a single center, which gives advanced management options. Cons: if the server fails, the entire system returns to stage 1, i.e. becomes fragmented or rendered useless.
Category 3 — the most hardcore option. At the repair stage, all communications are laid and all systems are duplicated. Pros: everything is brought to the ideal and then the house becomes really smart. Cons: extremely expensive compared to categories 1 and 2, the need to think through everything in advance and take into account every little thing.
Most users choose option one and then smoothly transition to option two. And in the future, the most persistent reach option 3.
But there is a variant that can be called a distributed system: each individual device will be both a server and a client. In fact, this is an attempt to take and combine option 1 and option 2. Take all their pluses and eliminate the minuses, catch the golden mean.
Perhaps someone will say that such an option has already been developed. But such solutions are narrow-minded; for people savvy in programming. Our goal is to lower the threshold for entry into such distributed systems, both in the form of end devices and in the form of integrating existing devices into our system. In the case of a thermostat, the user simply removes their old thermostat, installs a smart one, and connects their existing sensors to it. Without any further action.
Let's consider integration into our system using an example.
Let's imagine that we have 8 Sonoff modules in our network. For some users, Sonoff Cloud Control (Category 1) will suffice. Some will use third-party firmware and smoothly move to category 2. The bulk of third-party firmware works on the same principle: transferring data to an MQTT server. OpenHub, Majordomo or any other serve one purpose - to unite disparate devices into a single information space located either on the Internet or on a local network. Therefore, the presence of the Server is mandatory. This is where the main problem arises - if the Server fails, the entire system stops working autonomously. To prevent this, systems become more complex, manual control methods are added that duplicate automation in case of a Server failure.
We took a different path, where each device is self-sufficient. Thus, the Server does not play a decisive role, but only expands the functionality.
Let's go back to the thought experiment. Again, take the same 8 Sonoff modules and install the Lytko firmware in them. All Lytko firmwares have the function . SSDP is a network protocol based on the Internet protocol suite for advertising and discovering network services. The response to the request can be either standard or extended. We included in this answer, in addition to standard functions, the creation of a list of devices on the network. Thus, the devices themselves find each other, and each of them will have such a list. An example SSDP sheet:
"ssdpList":
{
"id": 94967291,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967282,
"ip": "192.168.x.x",
"type": "thermostat"
}As you can see from the example, the list includes device id, network ip address, unit type (in our case, a thermostat based on Sonoff). This list is updated once every two minutes (this interval is sufficient to respond to dynamic changes in the number of devices in the network). Thus, we keep track of adding, changing and deactivating devices without any action from the user. This list is sent to the browser or mobile application, and the script itself generates a page with a given number of blocks. Each block corresponds to one device/sensor/controller. Visually, the list looks like this:
But if other radio sensors are connected to esp8266/esp32 via cc2530 (ZigBee) or nrf24 (MySensors)?
About projects
There are various distributed systems on the market. Our system allows you to integrate with the most popular ones.
Below are projects that somehow try to change the situation with the incompatibility of different manufacturers with each other. This, for example, , or . is tied to the MQTT server, so it is not suitable for the example.
One implementation of MySensors is a gateway based on the ESP8266. The remaining examples are on ESP32. And they can implement our principle of working to discover and create a list of devices.
Let's do another thought experiment. We have a ZESP32 or SLS Gateway or MySensors. How can they be combined in a single information space? Let's 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 that are connected to it to the standard response. Based on this information, the browser will generate a page. In general, it will look like this:
Web interface
PWA application
"ssdpList":
{
"id": 94967291, // уникальный идентификатор устройства
"ip": "192.168.x.x", // ip адрес в сети
"type": "thermostat" // тип устройства
},
{
"id": 94967292,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 94967293,
"ip": "192.168.x.x",
"type": "thermostat"
},
{
"id": 13587532,
"type": "switch"
},
{
"id": 98412557,
"type": "smoke"
},
{
"id": 57995113,
"type": "contact_sensor"
},
{
"id": 74123668,
"type": "temperature_humidity_pressure_sensor"
},
{
"id": 74621883,
"type": "temperature_humidity_sensor"
}
The example shows that the devices are added independently of each other. Connected 3 thermostats with their own ip-addresses and 5 different sensors with unique id. If the sensor is connected to a Wi-Fi network, then it will have its own ip, if it is connected to a gateway, then the device's ip-address will be the gateway's ip-address.
We use WebSocket to communicate with devices. This allows you to minimize resource overhead compared to get requests and get information dynamically when connecting or changing.
The data is taken directly from the device to which the block belongs, bypassing the server. Thus, if any of the devices fails, the system continues to work. The web interface only does not display the device missing from the list. But the signal about the loss, if necessary, will come in the form of a notification in the user's application.
The first attempt to implement this approach was a PWA application. This allows you to store the block database on the user's device and request only the necessary data. But due to the nature of the structure, this option is incomplete. And there is only one way out - a native application for Android and IOS, which is currently under active development. By default, the application will only work on the internal network. If necessary, you can transfer everything to external control. So, when the user leaves the local network, the application automatically switches to the cloud.
External control - complete duplication of the page. When the page is activated, the user can log in to the server and manage devices through their personal account. Thus, the Server expands the functionality, allowing you to manage devices while outside the home, and not be tied to port forwarding or a dedicated ip.
Thus, the above-described option is devoid of the disadvantages of the server approach, and also has a number of advantages in the form of flexibility for connecting new devices.
About the thermostat
Consider the control system using our thermostat as an example.
Provided:
- Temperature control of each thermostat (displayed as a separate block);
- Setting the thermostat operation schedule (morning, afternoon, evening, night);
- Selecting a Wi-Fi network and connecting a device to it;
- Device update “over the air”;
- MQTT setup;
- Set up the network to which the device is connected.
In addition to control via the web interface, we provided for the classic one - by clicking on the display. On board is a Nextion NX3224T024 2.4-inch monitor. The choice fell on him due to the simplicity of working with the device. But in development is its own monitor based on STM32. Its functionality is no worse than that of Nextion, but it will cost less, which will positively affect the final price of the device.
Like any self-respecting thermostat screen, our Nextion can:
- set the temperature required by the user (using the buttons on the right);
- turn on and off the scheduled operation mode (button H);
- display relay operation (arrow on the left);
- has child protection (physical pressing is blocked until the lock is removed);
- displays the WiFi signal strength.
In addition, using the monitor, you can:
- select the type of sensor installed by the user;
- operate the child safety feature;
- update firmware.
By clicking on the WiFi bar, the user will find out information about the connected network. The QR code is used to pair the device in the HomeKit firmware.
Display demo:
We have developed with three connected thermostats.
You ask: “What is special about your thermostat?” Now on the market there are many thermostats with Wi-Fi function, scheduling, touch control. And enthusiasts have written modules for interacting with most popular smart home systems (Majordomo, HomeAssistant, etc.).
Our thermostat is compatible with such systems and has all of the above. But the distinguishing feature is that the thermostat is constantly being improved, thanks to the flexibility of the system. With each update, the functionality will expand. To the standard way of managing the system (by schedule), we will add an adaptive one. The application allows you to get the user's geolocation. Due to this, the system will dynamically change operating modes depending on its location. And the weather module will allow you to adjust to the weather conditions.
And extensibility. Anyone can replace their regular thermostat with ours. With minimal effort. We have selected 5 of the most popular sensors on the market and added support for them. But even in case of exclusive characteristics of the sensor, the user will be able to connect it to our thermostat. To do this, you will need to calibrate the thermostat to work with a specific sensor. We will provide instructions.
By connecting a thermostat or any other device, it simultaneously appears everywhere: both in the web interface and in the PWA application. Adding a device happens automatically: you just need to connect it to a Wi-Fi network.
Our system does not need a Server, and in case of its failure it does not turn into a pumpkin. Even if one of the components fails, the system does not start working according to an emergency scenario. Controllers, sensors, devices - each element is both a Server and a client, therefore it is completely autonomous.
For those interested, our social networks: , , , , .
Mail: [email protected]
PS we do not call for abandoning the Server. We also have support for an MQTT server and have our own cloud. Our goal is to bring the stability and reliability of the system to a qualitatively new level. So that the Server is not a weak point, but complements the functionality and makes the system more convenient.
Source: habr.com