Name: "Smart House" (HouseSpirit) Start: 03(March) 28 2011 Finish: 06(June) 12 2011 Location: Khanty-Mansiysk city Performers: ![]() Description: Implementation of the apartment house automation project - "Smart House" (HouseSpirit). | ![]() |
The object of automation is the house with equipment - the subject to automation. The system is designed to automate the actions performed by the user or service personnel to provide security, comfort, convenience at the automation object - the living room ( apartment, private house), as well as at the surrounding area (land, yard, garden) .
The system is designed for the solution of following tasks:
Objectives of the creation of the system are:
The area of the automation object - 300 m2. The air temperature in rooms intended for the server, sensors and actuators placement from 10 to 25 degrees Celsius. The air temperature outside the premises where the sensors and actuators are placed: from - 30 to 30 ° C.
The levels of pollution, humidity, light, noise and ionizing radiation correspond to sanitary and epidemiological requirements for residential buildings and premises (САНПИН 2.1.2.1002-00).
At the object there is electromagnetic radiation induced by the appliances, as well as by means of different equipment (Bluetooth, Wi-Fi, GSM).
The "Smart house. Control Server" system is a hardware-software module, which is the main control center of the automation object. The server receives and processes signals from various sensors, generates and transmits signals to control actuators, communicating with the user via GSM. Management of the system is made via the web interface.
The "Smart house. Control Server" system includes the following subsystems:
The block diagram of the house automation system is shown in Figure 1.
To control the various hardware of the house it was designed the hub and built the wireless network ZigBee of the devices for the equipment control. Overall equipment control, as well as providing the Web-based user interface and other methods of notification are made by the dedicated server of house automation. The hub if the ZigBee network is connected to the server through the RS-232 and ModBus/RTU protocol. Alarms in the automatics' control area will be sent to the user via SMS-notifications through the connected GSM-modem.
Wireless controller has the following specifications:
GSM-module has the following specifications (Siemens TC65):
The hardware of the server:
As a software environment, to serve the house automation functions - "Smart House" an open SCADA system OpenSCADA is used, in the environment of which it is designed the Web-based user interface "Smart House", and implemented the interrogation and control of devices via ZigBee concentrator.
OpenSCADA system has several ways of forming visualization user interfaces, stating from integrated development tools of standard interfaces of controls the various areas of automation and ending by the low-level mechanisms of libraries and interfaces of graphic concepts.
The integrated interfaces of OpenSCADA are:
The low-level mechanisms of constructing the user interfaces include any other graphics libraries, which have a rapid development tools of the user interface. The co-operation with OpenSCADA is produced as with data source and with the interface of the unified control of the equipment under different protocols.
In order to provide the ability of user's Web-interfaces formation directly in the OpenSCADA, the module "UI.WebUser" module is provided. Overall, the OpenSCADA contains all the basic functions of a typical Web-server, as follows:
Consequently, for the construction of any user control interface it is enough to have installed OpenSCADA system with the following modules: Transport.Sockets?, Transport.SSL, Protocol.HTTP and UI.WebUser.
In order to reduce the load on the fully dynamic formation of the user interface, as well as to facilitate the future expansion and modification of style the Web-interface was divided into static and dynamic parts.
The static part consists of a set of template HTML-files with labels of the dynamics placement and resource files: CSS, JavaScript and images. In general, the static part is represented by files, which are described in the table below:
File | Description |
HTML-templates (HouseSpirit/Web/*) | |
main.html | The main user interface template. Contains a general user interface with location tag of the pages' content "#####CONTEXT#####". |
auth.html | Template of the authorization interface with the tag of content's location "#####CONTEXT#####". It is created for using by the HTTP protocol module (/sub_Protocol/mod_HTTP). |
access.html | Access control template. |
temperature.html | Climate control template. |
light.html | Lighting control template. |
water.html | Water supply subsystem control template. |
tech.html | Electronic and household appliances control template. |
friend.html | User devices control template. |
user.html | Users manager template. |
devices.html | Device manager template. |
loginError.html | Page of authentication error messages, or lack of it. |
mess.html | Active alarm messages template. |
report.html | Template for alarms', actions and system messages reports formation. |
welcome.html | The welcome page displayed by default in the content field. |
Resources (HouseSpirit/Web/res/*) | |
stylesheet.css | Cascading Style Sheets of the user interface. |
main.js | JavaScript code of the main template for the time counter and session. |
devMon.js | JavaScript code that implements a dynamic AJAX interface for the monitoring of subsystems' device. |
access.png, accesson.png | Images of the access control subsystem. |
temperature.png, temperatureon.png | Images of the climate control subsystem. |
light.png, lighton.png | Images of the lightning control subsystem. |
water.png, wateron.png | Images of the water supply control subsystem. |
tech.png, techon.png | Images of the electronic appliances control subsystem. |
friend.png, friendon.png | Images of the user's devices control subsystem. |
user.png, useron.png | Images of the users' Manager. |
devices.png, deviceson.png | Images of the devices' manager. |
report.png, reporton.png | Images of the alarms, actions and system messages reports formation. |
help.png, helpon.png | Images of the help page. |
HouseSpirit.ico | Icon of the Web-based interface. |
hd_l.png, hd_r.png | The left and right parts of the header. |
select_l.png, select_r.png | Background images of the selected menu item on the left and right |
space_l.png, space_r.png | Images of the free menu item on the left and right. |
status_l.png, status_r.png status_edge.png | Images of the status bar. |
Report files (HouseSpirit/Web/reports/*) | |
rep_{user}.html | The latest report of the "user" user. |
The dynamic part is implemented by the scripts in the internal language of OpenSCADA - JavaLikeCalc, which are described in the table below:
In general, the algorithm processing the requests to the pages is(on the example of http://localhost:10002/WebUser/temperature?script=devMon):
The Devices Manager is available only for root and builds the form (Fig. 2) for edit, and and remove devices of two types: binary and decimal.
The created device are placed in the attributes list of the parameter of the specifically taken subsystem of "ZigBee" controller of the data source module ModBus (/sub_DAQ/mod_ModBus/cntr_ZegBee/). Recording format of an attribute is as follows:
In addition to direct sensors the configuration and formation of alarms is made in the form of text procedure. The program of formation is placed in the "var" attribute of the alarms controller parameter /sub_DAQ/mod_JavaLikeCalc/cntr_alarms/prm_rules.
The "var" attribute contains the following XML tree:
<ALARMS>
<it id = "temperature.cond1">
if(x<10) err = "Low temperature: "+x+" < 10";
</it>
</ALARMS>
According to the XML-tree the formation of alarms and sending SMS-notifications to the subscribed users is made in the controller's task /sub_DAQ/mod_JavaLikeCalc/cntr_alarms, which is executed with a period of 1 minute.
SMS-notifications are sent via the serial transport /sub_Transport/mod_Serial/out_GSM and through the user's SMS-protocol (/sub_Protocol/mod_UserProtocol/up_SMS).
You can also select the delayed giving of the control action. To do this, the user sets the right time, in the form of: {Min}:{Sec}. Processing of the delayed control is made in the controller /sub_DAQ/mod_JavaLikeCalc/cntr_timers by setting the "var" attribute of the "rules" parameter with the help of requests in the XML tree:
<TIMERS>
<timer id="temperature.tGhost1" tm="60" user="root">20</timer>
<timer id="temperature.cond1" tm="10" user="root">0</timer>
</TIMERS>
All visualization subsystems are served by the /sub_DAQ/mod_JavaLikeCalc/lib_web/devMon script. В этом скрипте осуществляется обработка запросов от скрипта динамической визуализации Web-браузера и передача ему данных об устройствах подсистемы, необходимых для визуализации (рис.3). Данные об устройствах передаются в соответствии с правами доступа вошедшего пользователя.
Конфигурация датчиков читается из параметра, соответствующего подсистеме контроллера «ZigBee» (/sub_DAQ/mod_ModBus/cntr_ZegBee). Значения читаются и записываются в атрибуты датчиков этих параметров или через контроллер отложенного управления.
Задача контроллера «ZigBee» исполняется с периодом 1 секунда, в процессе чего осуществляется запрос текущих значений всех сконфигурированных датчиков. Запись значений осуществляется по факту модификации независимо от задачи периодического опроса или через контроллер отложенного управления в случае установки ненулевого времени таймера.
Связь контроллера «ZigBee» осуществляется через последовательный исходящий транспорт /sub_Transport/mod_Serial/out_ZegBee.
Менеджер пользователей (рис.4) предназначен для создания, удаления и редактирования учётных записей обычных пользователей.
Пользователи условно делятся на администраторов и простых пользователей. Идентификация пользователя как администратора, в системе OpenSCADA, осуществляется включением его в группу «WebRoot» (/sub_Security/grp_WebRoot). Обычный пользователь включается в группу «Web» (/sub_Security/grp_Web).
В системе OpenSCADA у каждого пользователя (/sub_Security/usr_test1/) есть текстовое поле описания, которое в данном случае служит для хранения его специализированных параметров в виде:
TEL: +380679859815
SMS: true
Report: false
sub_access: --
sub_friend: --
sub_light: --
sub_tech: --
sub_temperature: rw
sub_water: --
В случае с администратором записи прав доступа к подсистемам отсутствуют, но присутствуют общесистемные параметры вроде времени жизни сеанса (/sub_Protocol/mod_HTTP).
Список сообщений формируется, исходя из перечня активных нарушений по их категории «ALARM:House:*» в виде таблицы с временем, категорией, уровнем и сообщением нарушения (рис.5).
В формировании отчёта указывается временной диапазон и выбираются типы сообщений. Предусмотрена генерация сообщений для типов:
Протокол формируется в виде таблицы (рис.6) с временем, категорией, уровнем и сообщением нарушения, которая также записывается в отдельный файл отчёта, в последствии доступный по ссылке для отдельного открытия.