Smart home, as I sunk to such. Part 2

In the first part, I talked about the reasons that prompted me to start building my “smart home”, and about the “hardware” used.
But “hardware”, in itself, cannot be clever, the main thing is “software”. Here I also want to tell about this side of the project in this part. Banal lighting control from the console, of course, looks cool in the eyes of the uninitiated public, but there is no “mind” here.
So what is so clever you can do? And, most importantly, how?

As I said earlier, I have connected to the system:

• All apartment lighting
• Warm floor
• Ventilation
• CCTV
• Climate sensors
• Motion sensors
• Sensors for opening doors and windows

To begin with, I will give an incomplete list of what my system can do (and examples of what it is used for):

• Banal management of all that is connected from the web / smartphone / tablet :)
• Monitoring what is happening in the apartment and around from anywhere in the world where there is Internet (so, my houses, sleep during the day, I will not wake up while calling; the alarm went off on a motorcycle at the entrance - I connected to the camera, made sure everything was fine, etc. )
• The inclusion of lighting in the corridor when someone came home and at the same time it was dark on the street, and nobody was at home
• Turning off the lights in the entire apartment and transfer the floor to the economy mode when there is no one
• Schedule lighting control (imitation of presence)
• Scenario lighting control with one touch: extinguish everything (the child wakes up and do not need to wake up, 3 o'clock in the morning, the parents still roam;)), extinguish everything except the light in the corridor (I carry the child out of the bathroom with the words, look everyone is asleep and it's time you) etc.
• Management of a heat-insulated floor according to the schedule and temperature
• Ventilation control on schedule and temperature
• Disable ventilation when windows are open (to save filter resource)
• Manage video recording of various events (unlocked front door, movement, etc.)
• Managed event alerts (someone came, everyone left, the front door is not locked for 15 minutes, etc.)
• ...

The most difficult task at first glance seemed to be solving the problem: “Is there anyone at home?”

After all, if there is, but they are sleeping, then no motion sensor will detect anything, and turning on the light at the entrance is undesirable, as well as turning off the heating. For a long time I broke my head over it, starting with the options for counting incoming / outgoing and ending with the definition of all movements in the apartment (the end point is the door, it means no one, the bed, then they sleep).
But as they say, all ingenious is simple, I paid attention to the regularity that has become a habit:

• If someone comes home, it always closes the latch.
• If someone does not leave the last, then closes one lock (so that the rest would be more convenient to open
• And only if everyone is gone, then we close all the locks and at the same time it is impossible to close the latch

I put the sensors on all the locks and voila, in a year and a half not a single false alarm, 100% determination of the presence of someone’s home.
')
System architecture
The system has the following entities:

• Sensor - this is where you can read data
• Trigger - a condition dependent on the sensor or time control controls
• Control - what you can control
• The messenger is essentially the same as the control, only it sends the message

The control (messenger) is associated with several triggers, which, in turn, are triggered by events from the sensors.


Sensors are divided into five groups:

• Sensor value: returns an absolute value, such as temperature
• Sensor-key: returns the time since the last triggering and a state, for example, a motion sensor
• Sensor command: returns the value of an arbitrary linux shell command, for example, disk temperature
• Macrosensor: a combination of several sensors, for example, the NOBODY_HOME sensor is defined as: min(abs(FRONTDOOR_KEY),
-FRONTDOOR_LATCH_KEY,
FRONTDOOR_LOCK_LOWER_KEY,
FRONTDOOR_LOCK_UPPER_KEY) min(abs(FRONTDOOR_KEY),
-FRONTDOOR_LATCH_KEY,
FRONTDOOR_LOCK_LOWER_KEY,
FRONTDOOR_LOCK_UPPER_KEY)
  What translates into Russian means: no one is home from the moment the door was closed (FRONTDOOR_KEY), the heck is opened (FRONTDOOR_LATCH_KEY) and the locks are closed (FRONTDOOR_LOCK_LOWER_KEY, FRONTDOOR_LOCK_UPPER_KEY)
• Sensor control: returns the time since the last control change and its state

Triggers can do the following:

• on - enable control when a condition occurs
• off - Disable control when a condition occurs.
• switch on - enable on condition and off when non-compliant
• switch off - turn off when the condition is met and turn on when non-compliance

Controls are divided into three groups:

• 1-wire control - on / off device on the bus 1-wire
• cmd control - execute linux shell command
• Custom control - everything your heart desires, but you have to go into the code

Let us analyze this scheme on the example of a simplified version of the management of a warm floor.
For example, we have the following tasks:

• Maintain a temperature of 34 degrees
• Disconnect for the night
• Turn off when there is no one
• Turn on when somebody is at home

We depict the interaction scheme in the diagram:

• Trigger 1, means that when the temperature drops below 34 the floor must be turned on, otherwise off
• Trigger 2, means that from 1:00 AM, within 8 hours, the floor should be off.
• Trigger 3, means that since when no one is home more than 1 second, you need to turn off the floor
• Trigger 4 means that when someone is at home for more than 1 second, you need to turn on the floor

Here is such a simple architecture that allows you to specify most of the actions I need. There are, of course, more difficult situations. In such cases, I just write custom control. For example, to turn on / off ventilation, you need more complex logic than just turning on / off a duct fan, you also need to close the flap according to certain rules.

Party projects
My whole system is written in Python and is running on a server running Ubuntu. MySQL is used as a database. For connection to 1-wire, the owpython library is used .
But of course, it makes no sense to write everything; it is often easier to take ready-made solutions.

For video surveillance, I did not reinvent the bikes and used the OpenSource system ZoneMinder , especially since it has a very good API that allows, for example, to enable / disable recording according to the rules I need. Or vice versa, hang your event handling when movement appears in a protected area. She can also give the image from the camera.

User interface
The system has three main management interfaces:

• Classic (switches on the walls)
• Native Android application
• Web interface

From the point of view of the system, a classic switch is simply a sensor-key, which with the help of triggers is attached to any control. If desired, you can tie, for example, a switch in the kitchen to the light in the nursery (which I usually do on the 1st of April)


Since, while writing the Android application, I was fascinated by the Star Trek TV series, I also made a theme for the style of the terminals from this cult tape.
The terminal has a main window that displays the general state of the system:

On the left - the general condition.
In the middle - an apartment plan, with a display of the state of the main controls and sensors.
Above is a common information panel for the entire application.
On the right - the main buttons (turn off all, street sensor monitor, settings)

Windows for each room. Actually, in each room where the tablet hangs, the window of this particular room is open and the lighting is turned on / off with one touch of a rather large button, which does not cause any inconvenience.


Also in each room you can see different information on the sensors, for example, a temperature graph


I am not a designer and not a layout fronder, so my web interface is simple, clumsy and minimalist.

Upper Blocks - Monitoring
Left - control and trigger management
In the center - video surveillance
On the right - reference information not directly related to the "smart home".

It was originally intended to use classic switches on the walls as the main interface in the children's habitats, and where adults use Android tablets instead of switches, but life seems to make its own adjustments. So, it turned out that children are much more interesting to poke on the tablet, and my wife is more like ordinary buttons.

UP:
Continued here Smart home, as I sunk to such. Part 3