SMART Life (cont.)
In the previous article, we talked about the advantages and problems of using the Smart Home system from the point of view of users. Now let's talk about the specific implementation.
Tell us about the general scheme of interaction?
')
Yuri: the local server is organized on the mini PC to which the USB controller is connected, which controls all the connected z-wave devices and contains data about them. Connecting mobile devices (smartphones, tablets) is organized through a wi-fi router. This local scheme. In the future, we also plan to use a support server that will be managed by us and where the data about the connected users will be stored, their critical data for possible system recovery. The server will be used to track critical errors and fix them, release updates. Through the server, we implement push, sms, e-mail notifications. This is the general scheme for building server logic.
What distinguishes our existing interface from others?
Julia: The main advantage of our interface is convenient control of both individual sensors and the entire system. This is possible with the help of two control modes oriented towards preferences, but rather a feeling of convenience for the main user groups. Someone likes and more clearly controls the plan, where the main necessary functionality is displayed, someone needs all the information on the system at once.
Alexander B.: Yes, we have a quick switch between different modes of displaying the plan: normal and expert. Normal mode allows you to quickly see how the system works, and by pressing a single button you can go into expert mode, where you can find extended information on all sensors (for example, battery status, recent events in the room, etc.)
Julia: the sensor filter system is also well thought out: the user can independently configure the system so that only the sensors he needs are displayed.
In addition, in our system there is a convenient editor of the plan of the room itself, when the user independently draws or changes the plan of the house / apartment
How hard is it to customize the system? Give a couple of practical examples.
Alexander B.: the user has a server where the USB stick is connected directly, with which we communicate with z-wave devices: sensors, controllers, sensors. If the user wants to expand the system, he buys the desired z-wave device and performs a simple procedure of physically binding the devices to the z-wave stick (so that the adapter sees the new device in the system and informs us about it)
The standard binding of z-wave devices is done by single pressing the button on the z-wave stick and triple pressing the system button on the z-wave device itself. After this binding, a light signal is given on the successful completion of the operation. We programmatically bind all new sensors to the system through an interface accessible to the user.
In our software, we receive a message about the appearance of a new device on the user's network. And then we offer the opportunity to rename it, change its type visually. A simple example: a user bought an outlet, connected it with a USB adapter and plugged a floor lamp into it. On the plan of the house / apartment it is more logical and clearer that the device is displayed as a light bulb, and not an outlet. And if the user moved the floor lamp to another place (not where the socket itself is located), then the program allows you to drag the device icon to another place on the house plan.
Of course, there are more complex devices, for example, thermostatic heads for radiators or modules that require the involvement of specialists (for example, electricians). But there is a minimum set of sensors (socket, smoke sensor, movement, water leaks, humidity, earthquake), which the user can install on their own.
It is worth noting that the sensors are mobile, small, well suited to any interior. Now manufacturers are striving to make them beautiful and miniature. There are firms, I will not call them, very tiny, round, not so long ago, very functional devices. They are almost imperceptible. And there are models and older, they are a little cumbersome, but also perform their function.
What are the problems and difficulties encountered in the implementation of the project?
Yuri: with regard to the server part, we have sufficient experience in developing high-load systems. As far as implementation of server logic is concerned, we didn’t have any particular problems. Of course, I had to tinker with the z-wave API to figure out the protocol, understand how z-wave devices communicate with the controller, and in what format commands are given. This is the only difficult place we are still working with, because different types of sensors have their own characteristics. Each sensor must be approached individually, to deal with its features.
Alexander B.: but at the same time it is worth noting that we strive to unify our server solution, because there are more than 1,000 sensors on the market, and we try to provide for some types and categories (into which these sensors can be divided) so that they can all connect to our system. Many systems on the market work only with certain sensors and do not allow connecting similar devices by type, functionality, because the system is not adapted for any parameter and this sensor cannot be added. Do not forget that the market is developing, new devices are released. They seem to be of the same type, but they cannot be controlled or the management functionality is very limited. We are trying to unify the server side, connecting more and more new sensors of similar types from the same family and trying to find the “golden mean” of correct communication with them.
Yuri: the format of communication is different between the types of devices. We need to understand which command to send to a specific type of device. For devices that control lighting and are responsible for opening / closing locks, the commands will be of a different type.
Julia: We encountered difficulties in the development of the interface. The fact is that the system carries a large amount of information, includes a huge number of sensors. And the difficulty was in displaying all the necessary information in an understandable and simple form, without overloading the interface. For this, we used a filter system when the user chooses which sensors he wants to see on the plan.
A lot of time was occupied by the development of scenarios, which not only solves practical problems, but also creative ones. I think it's great when a user can create scripts based on his preferences and run all this with one click. Thus, the house finds its individuality. System management becomes extremely simple.
Alexander B.: We faced another problem. On the door trim with the keypad, we literally had batteries for a month, and not just once, although we did not use it. You will need to further study the settings to understand exactly what the problem is. While it is possible to assume only. The fact is that for devices that run on batteries, there is a certain wake-up interval, and if it is made very small, for example, less than 1000, then the batteries on the device sit in less than a year, and maybe in a couple of months, because that it will constantly “wake up”, look for information and “fall asleep” further. Everything is difficult with the door trim: there is a mechanism that opens and closes a lock, a keypad, a backlight, i.e. There are many reasons that can contribute to the rapid discharge (4 AAA batteries). We assume that this may be some kind of glitch of the device itself, since device used is not from the premium segment. Discharging a battery is one of the dark and incomprehensible reasons for only one device.
We were afraid of problems with an individual donation, but this question was resolved quite simply. The device configuration is provided in our admin section: the user himself will be able to configure and change any parameter of any connected device.
Another interesting fact is that for dimmers on / off occurs as a standard command, and if you start dimming any light source, then directly when dimming, the values ​​are not sent to the controller. We solved this problem by periodically polling the device by its value. This is a flaw in the device itself, not in the z-wave library.
There is a small problem with the doorbell. The system consists of a bell and a button. When we attach a push button to our controller, the connection between the button and the doorbell itself (the doorbell) is lost, while the connection between the call and the button works directly. Manufacturers have not laid the easy connectivity - one of the most ill-conceived devices. It turns out that for $ 30 there is only a button and a call with five simple melodies.
Therefore, we strongly recommend that you carefully study the technical description of the devices you intend to purchase.
What sensors were used, and on what basis were they selected?
Alexander B.: I opened an online store and from a certain type I chose 1-2 sensors of various variations: from a leakage sensor to controllers for managing 1.5-2-3.5 kW loads with the possibility of dimming and without. We also bought a box to hang up on the phases after the meters and take readings of electricity consumption.
In general, the sensors of the middle price category - $ 20-30 - are rustic, but they perform their function. There are sensors that cost $ 10-15 more expensive, but they are more thoughtful, more complex, more advanced sensor capabilities, and the style has been worked out.
If you select from all manufacturers, I would point out Fibaro. They are trying for any device to think through an individual design, the logic of interaction between their devices without a controller. This is an important element in building z-wave networks.
In conclusion, I want to say that we are ready to cooperate with distributors of z-wave devices and mini PC.
We will be happy to answer your questions and listen to your opinion!
Tell us about the general scheme of interaction?
')
Yuri: the local server is organized on the mini PC to which the USB controller is connected, which controls all the connected z-wave devices and contains data about them. Connecting mobile devices (smartphones, tablets) is organized through a wi-fi router. This local scheme. In the future, we also plan to use a support server that will be managed by us and where the data about the connected users will be stored, their critical data for possible system recovery. The server will be used to track critical errors and fix them, release updates. Through the server, we implement push, sms, e-mail notifications. This is the general scheme for building server logic.
What distinguishes our existing interface from others?
Julia: The main advantage of our interface is convenient control of both individual sensors and the entire system. This is possible with the help of two control modes oriented towards preferences, but rather a feeling of convenience for the main user groups. Someone likes and more clearly controls the plan, where the main necessary functionality is displayed, someone needs all the information on the system at once.
Alexander B.: Yes, we have a quick switch between different modes of displaying the plan: normal and expert. Normal mode allows you to quickly see how the system works, and by pressing a single button you can go into expert mode, where you can find extended information on all sensors (for example, battery status, recent events in the room, etc.)
Julia: the sensor filter system is also well thought out: the user can independently configure the system so that only the sensors he needs are displayed.
In addition, in our system there is a convenient editor of the plan of the room itself, when the user independently draws or changes the plan of the house / apartment
How hard is it to customize the system? Give a couple of practical examples.
Alexander B.: the user has a server where the USB stick is connected directly, with which we communicate with z-wave devices: sensors, controllers, sensors. If the user wants to expand the system, he buys the desired z-wave device and performs a simple procedure of physically binding the devices to the z-wave stick (so that the adapter sees the new device in the system and informs us about it)
The standard binding of z-wave devices is done by single pressing the button on the z-wave stick and triple pressing the system button on the z-wave device itself. After this binding, a light signal is given on the successful completion of the operation. We programmatically bind all new sensors to the system through an interface accessible to the user.
In our software, we receive a message about the appearance of a new device on the user's network. And then we offer the opportunity to rename it, change its type visually. A simple example: a user bought an outlet, connected it with a USB adapter and plugged a floor lamp into it. On the plan of the house / apartment it is more logical and clearer that the device is displayed as a light bulb, and not an outlet. And if the user moved the floor lamp to another place (not where the socket itself is located), then the program allows you to drag the device icon to another place on the house plan.
Of course, there are more complex devices, for example, thermostatic heads for radiators or modules that require the involvement of specialists (for example, electricians). But there is a minimum set of sensors (socket, smoke sensor, movement, water leaks, humidity, earthquake), which the user can install on their own.
It is worth noting that the sensors are mobile, small, well suited to any interior. Now manufacturers are striving to make them beautiful and miniature. There are firms, I will not call them, very tiny, round, not so long ago, very functional devices. They are almost imperceptible. And there are models and older, they are a little cumbersome, but also perform their function.
What are the problems and difficulties encountered in the implementation of the project?
Yuri: with regard to the server part, we have sufficient experience in developing high-load systems. As far as implementation of server logic is concerned, we didn’t have any particular problems. Of course, I had to tinker with the z-wave API to figure out the protocol, understand how z-wave devices communicate with the controller, and in what format commands are given. This is the only difficult place we are still working with, because different types of sensors have their own characteristics. Each sensor must be approached individually, to deal with its features.
Alexander B.: but at the same time it is worth noting that we strive to unify our server solution, because there are more than 1,000 sensors on the market, and we try to provide for some types and categories (into which these sensors can be divided) so that they can all connect to our system. Many systems on the market work only with certain sensors and do not allow connecting similar devices by type, functionality, because the system is not adapted for any parameter and this sensor cannot be added. Do not forget that the market is developing, new devices are released. They seem to be of the same type, but they cannot be controlled or the management functionality is very limited. We are trying to unify the server side, connecting more and more new sensors of similar types from the same family and trying to find the “golden mean” of correct communication with them.
Yuri: the format of communication is different between the types of devices. We need to understand which command to send to a specific type of device. For devices that control lighting and are responsible for opening / closing locks, the commands will be of a different type.
Julia: We encountered difficulties in the development of the interface. The fact is that the system carries a large amount of information, includes a huge number of sensors. And the difficulty was in displaying all the necessary information in an understandable and simple form, without overloading the interface. For this, we used a filter system when the user chooses which sensors he wants to see on the plan.
A lot of time was occupied by the development of scenarios, which not only solves practical problems, but also creative ones. I think it's great when a user can create scripts based on his preferences and run all this with one click. Thus, the house finds its individuality. System management becomes extremely simple.
Alexander B.: We faced another problem. On the door trim with the keypad, we literally had batteries for a month, and not just once, although we did not use it. You will need to further study the settings to understand exactly what the problem is. While it is possible to assume only. The fact is that for devices that run on batteries, there is a certain wake-up interval, and if it is made very small, for example, less than 1000, then the batteries on the device sit in less than a year, and maybe in a couple of months, because that it will constantly “wake up”, look for information and “fall asleep” further. Everything is difficult with the door trim: there is a mechanism that opens and closes a lock, a keypad, a backlight, i.e. There are many reasons that can contribute to the rapid discharge (4 AAA batteries). We assume that this may be some kind of glitch of the device itself, since device used is not from the premium segment. Discharging a battery is one of the dark and incomprehensible reasons for only one device.
We were afraid of problems with an individual donation, but this question was resolved quite simply. The device configuration is provided in our admin section: the user himself will be able to configure and change any parameter of any connected device.
Another interesting fact is that for dimmers on / off occurs as a standard command, and if you start dimming any light source, then directly when dimming, the values ​​are not sent to the controller. We solved this problem by periodically polling the device by its value. This is a flaw in the device itself, not in the z-wave library.
There is a small problem with the doorbell. The system consists of a bell and a button. When we attach a push button to our controller, the connection between the button and the doorbell itself (the doorbell) is lost, while the connection between the call and the button works directly. Manufacturers have not laid the easy connectivity - one of the most ill-conceived devices. It turns out that for $ 30 there is only a button and a call with five simple melodies.
Therefore, we strongly recommend that you carefully study the technical description of the devices you intend to purchase.
What sensors were used, and on what basis were they selected?
Alexander B.: I opened an online store and from a certain type I chose 1-2 sensors of various variations: from a leakage sensor to controllers for managing 1.5-2-3.5 kW loads with the possibility of dimming and without. We also bought a box to hang up on the phases after the meters and take readings of electricity consumption.
In general, the sensors of the middle price category - $ 20-30 - are rustic, but they perform their function. There are sensors that cost $ 10-15 more expensive, but they are more thoughtful, more complex, more advanced sensor capabilities, and the style has been worked out.
If you select from all manufacturers, I would point out Fibaro. They are trying for any device to think through an individual design, the logic of interaction between their devices without a controller. This is an important element in building z-wave networks.
In conclusion, I want to say that we are ready to cooperate with distributors of z-wave devices and mini PC.
We will be happy to answer your questions and listen to your opinion!
Source: https://habr.com/ru/post/257055/
All Articles