Smart home NooLite. Scenario number 1 - "Master of the house"
Good day, dear community.
Today I want to share with you the experience of building smart with the use of the equipment of NooTechnika, or more precisely, the implementation of the “Master of the House” scenario. What do I mean by that? Launch of a special “script”, at the time of arrival of the “master” home. I understand myself as the owner in this case, and the scenario consists of switching on the light sources in the hallway and decorative lighting in other rooms.
As the hardware for the smart home, I chose the equipment of the company Nootehnika .
Those who are already familiar with the devices from Notech and want to go straight to the description of the implementation of the scenario, can safely scroll to section 2. I invite everyone else to get acquainted with a brief introduction, giving a general idea of ​​how to set up a smart home from Notechnika.
')
As a hardware for my smart home, I have been using the equipment of the company Notechnika for several years. The range of devices is wide enough to build a smart home within a city apartment and is constantly expanding. At the moment there are radio switches of different configurations, power units for connecting light sources and electrical appliances, motion, humidity and temperature sensors, as well as transmitters and command receivers (for connecting to a computer). There are still so-called. Ethernet-gateway, which can also be used for centralized control of smart home devices from the company Nootehnika.
At the moment, in my smart home, I use several 3-button switches, about 10 power units, 2 motion sensors, as well as a signal transmitter (model PC1116) power units and a receiver (model RX2164) signals from sensors and switches.
As a smart home control, I use a 3VI nettop based on the Intel ATOM D525 processor with Debian 7 OS on board. A receiver and a transmitter are connected to it.
I use a set of Linux utilities from Oleg Artamonov, which is available on GitHub - github.com/olegart/noolite, as software for managing the smart home. Also on a nettop, a web server and a handwritten web interface are raised to communicate with smart home devices.
Before starting the description of the implementation of the script, a few words about the devices themselves and what is meant for what:
An example of a general scheme of the interaction of components is shown in Figure 1.
Figure 1 - The general scheme of the interaction of components
This concludes the introduction and presentation of general information about the components of a smart home from Nootech. Comprehensive data can be obtained on the Notek off site . Next, turn to the description of the script and its implementation.
It is necessary to realize the inclusion of light sources in the hallway area, as well as decorative light sources in the hall and corridor at the moment when the owner (that is, your humble servant) returns home.
At this stage I want to note a few points that need to be addressed at the stage of solving the problem:
To solve the problem №1, it was decided to use the host’s smartphone as its (master) identifier. Those. If the smartphone is connected to a home WiFi-router, then the owner of the house. A static record of the correspondence of the IP address with the MAC address of the smartphone has been created on the router's DHCP server. Thus, the smartphone always appears on the network with the same IP address.
To solve the task â„–2, two motion sensors of the Nomener of model PM112 and the receiver of signals RX2164 are used. One of them is installed in front of the entrance door to the apartment in the vestibule. The second is installed inside the apartment, right near the front door. The idea is to identify the arrival event to the apartment by the sequential operation of the sensors in the vestibule and in the apartment. A description of the solution to this subtask is given in section 4.
To solve task No. 3, a script is used - the “status generator” (see Figure 3), which checks the connection of the host’s smartphone to the WiFi router every minute and writes the current status to a file. I set up the logic in the script in such a way that it does NOT generate a host home event if its absence is less than 20 minutes (for example, if the host went out for a couple of minutes). Of course, this threshold can be configured as you like. A description of the solution to this subtask is given in section 5.
In addition, you need something that can link all the events from the sensors, and run the script, which in turn will check the status and if the conditions are met (ie, the host arrives home), turn on the lights. To solve this problem, I chose the software Simple Event Correlator , running under Linux and freely distributed. I wrote a script in addition to it - “smartphone connection checker” (see Figure 3). A description of the solution to this subtask is given in section 6.
I installed the PM112 motion sensors as shown in Figure 2.
Figure 2 - The layout of the movement sensors PM112
The locations for the sensors, as well as their sensitivity, were chosen and tuned in such a way as to eliminate false alarms.
Further briefly describe the interaction scheme of all components of the solution.
The receiver of signals from Noolite sensors is connected to a nettop (hereinafter referred to as a PC, see Figure 1). The PC is configured to record messages received from the sensors in a log file in real time (see Figure 3). Simple Event Correlator (hereinafter referred to as SEC) runs on a PC and reads a log file (where events from sensors arrive). In the SEC, a rule is set up that triggers in the case of receiving signals about movement from sensor 1 (see Figure 2) and for no more than 60 seconds followed by a signal about movement from sensor 2 (see Figure 2). When this rule is triggered, a script scanner is launched that checks the status of the master smartphone, reading the information from the status file and also performing independent checks (to reduce false positives). In the case of registration by the script of the fact of the arrival of the host home, the launch of the scenario program for switching on the light is performed.
It is also necessary to mention the script - the status generator. This script continually checks the status of the host’s smartphone, regardless of whether the host is at home or not, and starts internal counters in case of its (status) change. In a word - monitors the status of the smartphone.
A diagram explaining the above is shown in Figure 3.
Figure 3 - Block diagram of the interaction of system components
In this section, I will discuss the connection and configuration of the PM112 motion sensors, as well as the settings of the RX2164 receiver control utility.
The locations for the sensors, as well as their sensitivity, were chosen and tuned in such a way as to eliminate false alarms. Sensor No. 1 I installed above the cabinet for the shoes (see Figure 4) and adjusted the sensitivity so that it responds to movement at a distance of about 50 cm (this corresponds to the position of the sensitivity regulator, as in Figure 5 - slightly more than half the regulator stroke ). If you make the sensitivity more, it can react to the neighbors passing by, and if you put it under the cabinet, then the household can make it trivial. The illumination setting is set to the "On" position - the lowest one. Although other illumination settings provide energy saving (it works on batteries), but with different illumination settings I was not able to achieve a stable response. Most likely the reason is not very abundant lighting at the sensor installation sites. I set the on time for 5 seconds. For me, this parameter is not very important, because My sensors are tied to the receiver connected to the PC and I only need to receive motion detection events in the sensor's operating area.
I installed the second sensor above the entrance door from the side of the apartment (see Figure 6). The entrance door is in a small niche, so there is a very convenient place above it for fixing the sensor. Krepil on screws. The sensitivity threshold set the same threshold as sensor No. 1, so that it triggered the movement approximately at a distance of 50cm. If more, then there will be a lot of false positives when someone climbs into the closet for clothes or domestic animals.
Figure 4 - Installation of the sensor in the chain area
Figure 5 - Motion Sensor Setup
Figure 6 - Installation of the sensor in the hallway area
To receive messages from motion sensors, I use a set of utilities running under the Linux operating system. In my case, this is Debian 7.
This set of utilities was developed by Oleg Artamonov and is available on GitHub . The installation of a set of utilities is well described by the author himself, so I will not dwell on it. Just note that for its implementation, you still need knowledge of Linux and in particular the understanding of the device scripts / etc / init.d /.
The first thing you need to "tie" motion sensors PM112 to the receiver RX2164. To do this, follow these steps:
This procedure must be performed for each sensor. In my case, there are two of them and they are tied to channels 2 and 3, therefore:
In order for the nooliterx utility to work in the background, you need to start it using the /etc/init.d/nooliterx script. This script is on github in a place with utilities, but under my Debian it did not work, so I modified it a bit. The result was the following:
By default, nooliterx writes messages about the movement of motion sensors in a syslog. It is very convenient. In order for the messages from the sensors to fall into a separate file (which will be analyzed by the SEC) I set up a redirect to syslog-ng installed on the PC. To do this, add the following lines to the relevant sections of the /etc/syslog-ng/syslog-ng.conf file:
Restart syslog-ng to apply the changes:
To work in the background nooliterx runs as follows:
To check the operation of the configured scheme, we create motion near the sensors and look at the messages coming in the /var/log/sec.log file. They should look something like this:
Moreover, at each event of motion fixation two messages should appear in the log file since due to the design feature of the sensors, they send two signals for each of their operation. This is done to ensure the delivery of the message, since the communication is unidirectional and in very rare cases, messages from the sensor to the receiver can be lost.
The script - “status generator” checks the connection of the smartphone to the home WiFi network every minute and writes the current status to the file. The verification is very simple - by sending ICMP packets to the IP address of the smartphone. A block diagram of the logic according to which the script calculates the status is shown in Figure 7.
Based on the data that the script writes to the status file, a correlation is made when motion sensors are triggered and a decision is made to launch the script (this is done by the script-checker, which is described in section 6).
The script runs every minute and updates the information in the status file, as well as appends the status information with the current timestamp to the log file.
Information in the status file consists of:
The “athome” status indicates that the smartphone is connected to the network at home. The status of "away", respectively, indicates the absence of a smartphone at home (network connection). The status "arrived" appears when the smartphone has just appeared on the network and the scenario program has not yet been launched. As soon as the light-on scenario worked, the status changes to “athome”. This is done to eliminate multiple positives.
The absence of the owner of the house is considered the lack of connecting the smartphone to the network for more than 20 minutes. Such logic is set up to filter out false positives (if, for example, the smartphone has been disconnected from the network for a short time) and so that the script does not activate, if the owner has left the house for a short time. This condition is provided in the block diagram. And for this purpose, introduced different types of meters - "left" and "at home". In the absence of a smartphone on the network, the “athome” status is maintained and the countdown of the “outgoing” counter begins, while the “athome” status is maintained. As soon as the counter value exceeds 20, the status changes to “away”.
Figure 7 - Block diagram of the "status generator"
Below is a complete listing of the status generator script.
The launch of the light source switching script should be performed under the following conditions:
Tasks 1 and 2 are solved by SEC. The solution of task 3, as well as the launch of the script, is performed by the script - “smartphone connection checker”.
I will not describe in detail the installation and initial configuration of the SEC. The network has enough materials and detailed MAN for this utility. In my case, the SEC is configured to read the file /var/log/sec.log. events coming from Noolite sensors are sent to this file.
SEC configuration files are listed below. The file / etc / default / sec (contains the basic settings - a configuration file with a description of the correlation rules in the “conf” parameter, the analyzed log file in the “input” parameter, a syslog facility into which the SEC events are written in the “detach” parameter):
The /etc/sec.conf file with the description of the correlation rule that executes the checker script in the event of motion being recorded, first by sensor 1, and then by sensor 2 for 1 minute:
As you can see, the rule looks for sensor trigger events based on regular expressions, which are recorded in the “pattern” parameters.
When the SEC conditions are met, the /usr/local/smarthome/imhome/check_phone.sh script is run and passes the smartphone’s IP address 192.168.22.155 as an argument.
The script, in turn, checks the availability of the smartphone (by sending ICMP packets) and, if successful, checks the current status of the smartphone in the status file (created by the script — the status generator). If the status is “away” or “arrived”, then it runs the script to turn on the light sources and overwrites the status value in the status file to “athome”. The block diagram of the script is shown in Figure 8.
Figure 8 - Block diagram of the script - the checker
Below is a complete listing of the script. As a scenario program, I perform the inclusion of 4 light sources using the noolitepc utility and also send an e-mail message to myself (this was done in order to simplify debugging for the testing period). Between the inclusions of light sources made a pause. When teams follow without it, they do not always reach power blocks.
As you can see, the script performs several verification cycles (using a while loop). This is done to ensure the launch of the script in the event that the smartphone did not have time to connect to WiFi at the time of the sensors. As shown by testing, this happens occasionally.
As a result, I have a system that can run any scenario programs in the event of registering the arrival of a certain person’s home. The scenario can be not only the inclusion of lighting, but everything that is enough imagination. For example, you can turn on the background music, make a photo of the visitor (using an IP camera) and much more.
The SEC correlator monitors the arrival of someone's home (by analyzing events from Noolite sensors), and then sends the data to the script to check who exactly came home. This means that you can customize different programs for different households. By transferring the IP addresses of different smartphones to the script and adding the appropriate conditions.
I would like to say a separate BIG THANKS to the company Nootech for providing the PM112 motion sensors and the RX2164 receiver provided for the implementation of this system.
Today I want to share with you the experience of building smart with the use of the equipment of NooTechnika, or more precisely, the implementation of the “Master of the House” scenario. What do I mean by that? Launch of a special “script”, at the time of arrival of the “master” home. I understand myself as the owner in this case, and the scenario consists of switching on the light sources in the hallway and decorative lighting in other rooms.
As the hardware for the smart home, I chose the equipment of the company Nootehnika .
Those who are already familiar with the devices from Notech and want to go straight to the description of the implementation of the scenario, can safely scroll to section 2. I invite everyone else to get acquainted with a brief introduction, giving a general idea of ​​how to set up a smart home from Notechnika.
')
1. Introduction
As a hardware for my smart home, I have been using the equipment of the company Notechnika for several years. The range of devices is wide enough to build a smart home within a city apartment and is constantly expanding. At the moment there are radio switches of different configurations, power units for connecting light sources and electrical appliances, motion, humidity and temperature sensors, as well as transmitters and command receivers (for connecting to a computer). There are still so-called. Ethernet-gateway, which can also be used for centralized control of smart home devices from the company Nootehnika.
At the moment, in my smart home, I use several 3-button switches, about 10 power units, 2 motion sensors, as well as a signal transmitter (model PC1116) power units and a receiver (model RX2164) signals from sensors and switches.
As a smart home control, I use a 3VI nettop based on the Intel ATOM D525 processor with Debian 7 OS on board. A receiver and a transmitter are connected to it.
I use a set of Linux utilities from Oleg Artamonov, which is available on GitHub - github.com/olegart/noolite, as software for managing the smart home. Also on a nettop, a web server and a handwritten web interface are raised to communicate with smart home devices.
Before starting the description of the implementation of the script, a few words about the devices themselves and what is meant for what:
- Power units (there are different, to support different loads, ranging from 200 W and ending with several KW). They are connected to the AC network and are designed to control electrical appliances (they are connected "into the gap" between the network and the electrical appliance);
- Radio switches. Intended for:
- sending commands on, off, load changes (dimming) on ​​the power blocks,
- sending commands to the receiver RX2164 (connected to a PC); - Motion sensors, temperature, humidity. Designed to send commands to the power units or the receiver;
- Signal receiver RX2164. Designed to receive signals from sensors or switches;
- Signal Transmitter PC1116. Designed to send control signals to power units.
An example of a general scheme of the interaction of components is shown in Figure 1.
Figure 1 - The general scheme of the interaction of components
This concludes the introduction and presentation of general information about the components of a smart home from Nootech. Comprehensive data can be obtained on the Notek off site . Next, turn to the description of the script and its implementation.
2. Statement of the problem
It is necessary to realize the inclusion of light sources in the hallway area, as well as decorative light sources in the hall and corridor at the moment when the owner (that is, your humble servant) returns home.
At this stage I want to note a few points that need to be addressed at the stage of solving the problem:
- It is necessary to identify the visitor (that this is the owner);
- It is necessary to make sure that the owner has come, and not just was near the door (for example, to check whether the lock is locked);
- It is necessary to make sure that the owner has come, and not just left the house for a couple of minutes and returned (to meet the courier, open the door in the vestibule, etc.).
3. Description of the solution
To solve the problem №1, it was decided to use the host’s smartphone as its (master) identifier. Those. If the smartphone is connected to a home WiFi-router, then the owner of the house. A static record of the correspondence of the IP address with the MAC address of the smartphone has been created on the router's DHCP server. Thus, the smartphone always appears on the network with the same IP address.
To solve the task â„–2, two motion sensors of the Nomener of model PM112 and the receiver of signals RX2164 are used. One of them is installed in front of the entrance door to the apartment in the vestibule. The second is installed inside the apartment, right near the front door. The idea is to identify the arrival event to the apartment by the sequential operation of the sensors in the vestibule and in the apartment. A description of the solution to this subtask is given in section 4.
To solve task No. 3, a script is used - the “status generator” (see Figure 3), which checks the connection of the host’s smartphone to the WiFi router every minute and writes the current status to a file. I set up the logic in the script in such a way that it does NOT generate a host home event if its absence is less than 20 minutes (for example, if the host went out for a couple of minutes). Of course, this threshold can be configured as you like. A description of the solution to this subtask is given in section 5.
In addition, you need something that can link all the events from the sensors, and run the script, which in turn will check the status and if the conditions are met (ie, the host arrives home), turn on the lights. To solve this problem, I chose the software Simple Event Correlator , running under Linux and freely distributed. I wrote a script in addition to it - “smartphone connection checker” (see Figure 3). A description of the solution to this subtask is given in section 6.
I installed the PM112 motion sensors as shown in Figure 2.
Figure 2 - The layout of the movement sensors PM112
The locations for the sensors, as well as their sensitivity, were chosen and tuned in such a way as to eliminate false alarms.
Further briefly describe the interaction scheme of all components of the solution.
The receiver of signals from Noolite sensors is connected to a nettop (hereinafter referred to as a PC, see Figure 1). The PC is configured to record messages received from the sensors in a log file in real time (see Figure 3). Simple Event Correlator (hereinafter referred to as SEC) runs on a PC and reads a log file (where events from sensors arrive). In the SEC, a rule is set up that triggers in the case of receiving signals about movement from sensor 1 (see Figure 2) and for no more than 60 seconds followed by a signal about movement from sensor 2 (see Figure 2). When this rule is triggered, a script scanner is launched that checks the status of the master smartphone, reading the information from the status file and also performing independent checks (to reduce false positives). In the case of registration by the script of the fact of the arrival of the host home, the launch of the scenario program for switching on the light is performed.
It is also necessary to mention the script - the status generator. This script continually checks the status of the host’s smartphone, regardless of whether the host is at home or not, and starts internal counters in case of its (status) change. In a word - monitors the status of the smartphone.
A diagram explaining the above is shown in Figure 3.
Figure 3 - Block diagram of the interaction of system components
4. Identification of the event coming home
In this section, I will discuss the connection and configuration of the PM112 motion sensors, as well as the settings of the RX2164 receiver control utility.
The locations for the sensors, as well as their sensitivity, were chosen and tuned in such a way as to eliminate false alarms. Sensor No. 1 I installed above the cabinet for the shoes (see Figure 4) and adjusted the sensitivity so that it responds to movement at a distance of about 50 cm (this corresponds to the position of the sensitivity regulator, as in Figure 5 - slightly more than half the regulator stroke ). If you make the sensitivity more, it can react to the neighbors passing by, and if you put it under the cabinet, then the household can make it trivial. The illumination setting is set to the "On" position - the lowest one. Although other illumination settings provide energy saving (it works on batteries), but with different illumination settings I was not able to achieve a stable response. Most likely the reason is not very abundant lighting at the sensor installation sites. I set the on time for 5 seconds. For me, this parameter is not very important, because My sensors are tied to the receiver connected to the PC and I only need to receive motion detection events in the sensor's operating area.
I installed the second sensor above the entrance door from the side of the apartment (see Figure 6). The entrance door is in a small niche, so there is a very convenient place above it for fixing the sensor. Krepil on screws. The sensitivity threshold set the same threshold as sensor No. 1, so that it triggered the movement approximately at a distance of 50cm. If more, then there will be a lot of false positives when someone climbs into the closet for clothes or domestic animals.
Figure 4 - Installation of the sensor in the chain area
Figure 5 - Motion Sensor Setup
Figure 6 - Installation of the sensor in the hallway area
To receive messages from motion sensors, I use a set of utilities running under the Linux operating system. In my case, this is Debian 7.
This set of utilities was developed by Oleg Artamonov and is available on GitHub . The installation of a set of utilities is well described by the author himself, so I will not dwell on it. Just note that for its implementation, you still need knowledge of Linux and in particular the understanding of the device scripts / etc / init.d /.
The first thing you need to "tie" motion sensors PM112 to the receiver RX2164. To do this, follow these steps:
- enable the binding mode on the sensor itself by pressing the “snap / untie” button on the rear wall of the sensor once;
- on the PC, execute the command in the console:
# nooliterxcfg –bind < 1 64> This procedure must be performed for each sensor. In my case, there are two of them and they are tied to channels 2 and 3, therefore:
# nooliterxcfg –bind 2 # nooliterxcfg –bind 3 In order for the nooliterx utility to work in the background, you need to start it using the /etc/init.d/nooliterx script. This script is on github in a place with utilities, but under my Debian it did not work, so I modified it a bit. The result was the following:
#!/bin/sh # nooliterx Starts and stops the NooLite RX1164 receiver daemon # chkconfig: 2345 55 25 # description: NooLite RX1164 smart home wireless receiver daemon # Source function library. . /lib/lsb/init-functions #. /etc/rc.d/init.d/functions nooliterx="/usr/local/bin/nooliterx" prog=`basename $nooliterx` lockfile="/var/lock/subsys/nooliterx" pidfile="/var/run/$prog.pid" start() { [ -x $nooliterx ] || exit 5 echo -n "Starting $prog: " start-stop-daemon --start --exec $nooliterx --make-pidfile --pidfile $pidfile --background retval=$? echo [ $retval -eq 0 ] && touch $lockfile return $retval } stop() { echo -n "Stopping $prog: " killproc -p $pidfile $prog retval=$? echo [ $retval -eq 0 ] && rm -f $lockfile return $retval } restart() { stop start } case "$1" in start) $1 ;; stop) $1 ;; restart) $1 ;; *) echo $"Usage: $0 {start|stop|restart}" exit 2 esac By default, nooliterx writes messages about the movement of motion sensors in a syslog. It is very convenient. In order for the messages from the sensors to fall into a separate file (which will be analyzed by the SEC) I set up a redirect to syslog-ng installed on the PC. To do this, add the following lines to the relevant sections of the /etc/syslog-ng/syslog-ng.conf file:
destination sec_log { file("/var/log/sec.log"); }; filter motion_sens { program("nooliterx.*"); }; log { source(s_src); filter(motion_sens); destination(sec_log); }; Restart syslog-ng to apply the changes:
# /etc/init.d/syslog-ng restart To work in the background nooliterx runs as follows:
# /etc/init.d/nooliterx start To check the operation of the configured scheme, we create motion near the sensors and look at the messages coming in the /var/log/sec.log file. They should look something like this:
Dec 19 08:40:55 vmon nooliterx[23022]: Received: status 135, channel 2, command 25, format 1, data 1 0 0 0 Dec 19 08:41:19 vmon nooliterx[23022]: Received: status 8, channel 3, command 25, format 1, data 1 0 0 0 Dec 19 08:41:22 vmon nooliterx[23022]: Received: status 137, channel 3, command 25, format 1, data 1 0 0 0 Moreover, at each event of motion fixation two messages should appear in the log file since due to the design feature of the sensors, they send two signals for each of their operation. This is done to ensure the delivery of the message, since the communication is unidirectional and in very rare cases, messages from the sensor to the receiver can be lost.
5. Status generator
The script - “status generator” checks the connection of the smartphone to the home WiFi network every minute and writes the current status to the file. The verification is very simple - by sending ICMP packets to the IP address of the smartphone. A block diagram of the logic according to which the script calculates the status is shown in Figure 7.
Based on the data that the script writes to the status file, a correlation is made when motion sensors are triggered and a decision is made to launch the script (this is done by the script-checker, which is described in section 6).
The script runs every minute and updates the information in the status file, as well as appends the status information with the current timestamp to the log file.
Information in the status file consists of:
- the current status of the smartphone, which can take the values ​​arrived, athome, away;
- the names of the time counter - “left” or “at home”;
- counter value (corresponds to the number of minutes).
The “athome” status indicates that the smartphone is connected to the network at home. The status of "away", respectively, indicates the absence of a smartphone at home (network connection). The status "arrived" appears when the smartphone has just appeared on the network and the scenario program has not yet been launched. As soon as the light-on scenario worked, the status changes to “athome”. This is done to eliminate multiple positives.
The absence of the owner of the house is considered the lack of connecting the smartphone to the network for more than 20 minutes. Such logic is set up to filter out false positives (if, for example, the smartphone has been disconnected from the network for a short time) and so that the script does not activate, if the owner has left the house for a short time. This condition is provided in the block diagram. And for this purpose, introduced different types of meters - "left" and "at home". In the absence of a smartphone on the network, the “athome” status is maintained and the countdown of the “outgoing” counter begins, while the “athome” status is maintained. As soon as the counter value exceeds 20, the status changes to “away”.
Figure 7 - Block diagram of the "status generator"
Below is a complete listing of the status generator script.
#! /bin/sh dir=/usr/local/smarthome/imhome phone_ip=$1 stat_file="$dir/status" log_file="$dir/log_status" dt=`date` if ping -c 5 $phone_ip > /dev/null then if grep "athome" $stat_file then count=$(($(cat $stat_file|grep pingok | awk -F "_" '{print $2}')+1)) stat="athome" png="pingok_" elif grep "arrived" $stat_file then count=$(($(cat $stat_file|grep pingok | awk -F "_" '{print $2}')+1)) stat="arrived" png="pingok_" else count="1" stat="arrived" png="pingok_" fi else if grep "athome" $stat_file then if grep pingnok $stat_file then count=$(($(cat $stat_file|grep pingnok | awk -F "_" '{print $2}')+1)) if [ "$count" -gt 20 ] then count="1" stat="away" png="pingnok_" else stat="athome" png="pingnok_" fi else count="1" stat="athome" png="pingnok_" fi elif grep "away" $stat_file then count=$(($(cat $stat_file|grep pingnok | awk -F "_" '{print $2}')+1)) stat="away" png="pingnok_" else count="1" stat="away" png="pingnok_" fi fi printf "$stat\n$png$count\n" > $stat_file printf "$dt $stat $png$count\n" >> $log_file 6. SEC. Event Correlation and Script Launch
The launch of the light source switching script should be performed under the following conditions:
- Movement detected by the sensor 1;
- Not later than 60 seconds after event 1, movement was detected by sensor 2;
- The host's smartphone has connected to the WiFi network for a 1 minute time window.
Tasks 1 and 2 are solved by SEC. The solution of task 3, as well as the launch of the script, is performed by the script - “smartphone connection checker”.
I will not describe in detail the installation and initial configuration of the SEC. The network has enough materials and detailed MAN for this utility. In my case, the SEC is configured to read the file /var/log/sec.log. events coming from Noolite sensors are sent to this file.
SEC configuration files are listed below. The file / etc / default / sec (contains the basic settings - a configuration file with a description of the correlation rules in the “conf” parameter, the analyzed log file in the “input” parameter, a syslog facility into which the SEC events are written in the “detach” parameter):
#Defaults for sec RUN_DAEMON="yes" DAEMON_ARGS="-conf=/etc/sec.conf -input=/var/log/sec.log -pid=/var/run/sec.pid -detach -syslog=local6" The /etc/sec.conf file with the description of the correlation rule that executes the checker script in the event of motion being recorded, first by sensor 1, and then by sensor 2 for 1 minute:
type=PairWithWindow ptype=RegExp pattern=\w+\s+\d+\s+\d+\:\d+\:\d+\s+\w+\s+nooliterx\S+\s+Received\:\s+status\s+\d+,\s+channel\s+3,\s+command\s+25.* desc=Motion sensor outside front door triggered action=logonly ptype2=RegExp pattern2=\w+\s+\d+\s+\d+\:\d+\:\d+\s+\w+\s+nooliterx\S+\s+Received\:\s+status\s+\d+,\s+channel\s+2,\s+command\s+25.* desc2=Motion sensor by the front door inside the flat triggered action2=shellcmd (/usr/local/smarthome/imhome/check_phone.sh 192.168.22.155); write /usr/local/smarthome/imhome/test_corr_info %.year-%.mon-%.mday_%.%.hmsstr someone came window=60 As you can see, the rule looks for sensor trigger events based on regular expressions, which are recorded in the “pattern” parameters.
When the SEC conditions are met, the /usr/local/smarthome/imhome/check_phone.sh script is run and passes the smartphone’s IP address 192.168.22.155 as an argument.
The script, in turn, checks the availability of the smartphone (by sending ICMP packets) and, if successful, checks the current status of the smartphone in the status file (created by the script — the status generator). If the status is “away” or “arrived”, then it runs the script to turn on the light sources and overwrites the status value in the status file to “athome”. The block diagram of the script is shown in Figure 8.
Figure 8 - Block diagram of the script - the checker
Below is a complete listing of the script. As a scenario program, I perform the inclusion of 4 light sources using the noolitepc utility and also send an e-mail message to myself (this was done in order to simplify debugging for the testing period). Between the inclusions of light sources made a pause. When teams follow without it, they do not always reach power blocks.
#! /bin/sh dir="/usr/local/smarthome/imhome" phone_ip=$1 stat_file="$dir/status" log_file="$dir/log_status" dt=`date` noolite="/usr/local/bin/noolitepc" a=1 MAIL="$dir/mail.letter" while [ "$a" -lt 10 ] do if ping -c 2 $phone_ip > /dev/null then if grep 'arrived\|away' $stat_file then printf "$dt $phone_ip has come home. Welcome!\n" >> $log_file printf "Subject: Welcome home Boss!\nThe exact time is $dt\n" > $MAIL /usr/sbin/ssmtp test_email@gmail.com < $MAIL $noolite --on 3 sleep 1 $noolite --on 2 sleep 1 $noolite --on 6 sleep 1 $noolite --on 8 printf "athome\npingok_1\n" > $stat_file fi break fi a=$((a+1)) done As you can see, the script performs several verification cycles (using a while loop). This is done to ensure the launch of the script in the event that the smartphone did not have time to connect to WiFi at the time of the sensors. As shown by testing, this happens occasionally.
7. Conclusion
As a result, I have a system that can run any scenario programs in the event of registering the arrival of a certain person’s home. The scenario can be not only the inclusion of lighting, but everything that is enough imagination. For example, you can turn on the background music, make a photo of the visitor (using an IP camera) and much more.
The SEC correlator monitors the arrival of someone's home (by analyzing events from Noolite sensors), and then sends the data to the script to check who exactly came home. This means that you can customize different programs for different households. By transferring the IP addresses of different smartphones to the script and adding the appropriate conditions.
I would like to say a separate BIG THANKS to the company Nootech for providing the PM112 motion sensors and the RX2164 receiver provided for the implementation of this system.
Source: https://habr.com/ru/post/318162/
All Articles