Облачный Умный Дом. Часть 1: Контроллер и датчики



Сегодня, благодаря бурному развитию микроэлектроники, каналов связи, Интернет-технологий и Искусственного Интеллекта, тема умных домов становится все более и более актуальной. Человеческое жилище претерпело существенные изменения со времен каменного века и в эпоху Промышленной Революции 4.0 и Интернета Вещей стало удобным, функциональным и безопасным. На рынок приходят решения, превращающие квартиру или загородный дом в сложные информационные системы, управляемые из любой точки мира с помощью смартфона. Причем, для человеко-машинного взаимодействия уже не требуются знания языков программирования, — благодаря алгоритмам распознавания и синтеза речи человек говорит с умным домом на родном языке.

Некоторые системы умного дома, представленные сейчас на рынке, являются логичным развитием систем облачного видеонаблюдения, разработчики которых осознали необходимость в комплексном решении не только для контроля, но и для управления удаленными объектами.

Вашему вниманию предлагается цикл из трех статей, где будет рассказано о всех основных компонентах системы облачного умного дома, лично разработанной автором и запущенной в эксплуатацию. Первая статья посвящена оконечному клиентскому оборудованию, устанавливаемому внутри умного дома, вторая — архитектуре системы облачного хранения и обработки данных, и, наконец, третья — клиентскому приложению для управления системой на мобильных и стационарных устройствах.

Оборудование для умного дома


Сперва поговорим о том, как из обыкновенной квартиры, дачи или коттеджа сделать умный дом. Для этого, как правило, требуется разместить в жилище следующее оборудование:

  1. датчики, измеряющие различные параметры внешней среды;
  2. исполнительные устройства, воздействующие на внешние объекты;
  3. контроллер, производящий вычисления в соответствии с измерениями датчиков и заложенной логикой, и выдающий команды для исполнительных устройств.

На следующем рисунке показана схема умного дома, на которой расположены датчики протечки воды (1) в ванной, температуры (2) и освещения (3) в спальне, умная розетка (4) на кухне и камера видеонаблюдения (5) в прихожей.



В настоящее время широкое распространение получили беспроводные датчики, работающие по протоколам RF433, Z-Wave, ZigBee, Bluetooth и WiFi. Их главные преимущества — удобство монтажа и использования, а также дешевизна и надежность, т.к. производители стремятся вывести свои устройства на массовый рынок и сделать их доступными рядовому пользователю.

Датчики и исполнительные устройства, как правило, подключаются по беспроводному интерфейсу к контроллеру умного дома (6) — специализированному микрокомпьютеру, объединяющему все эти устройства в единую сеть и управляющему ими.

Впрочем, некоторые решения могут совмещать в себе датчик, исполнительное устройство и контроллер одновременно. Например, умная розетка может быть запрограммирована на включение или выключение по расписанию, а камера облачного видеонаблюдения умеет записывать видео по сигналу детектора движения. В простейших случаях можно обойтись без отдельного контроллера, но для создания гибкой системы со множеством сценариев он необходим.

Для подключения контроллера умного дома к глобальной сети может быть использован обычный Интернет-роутер (7), который уже давно стал привычным бытовым прибором в любом доме. Здесь есть еще один аргумент в пользу контроллера умного дома — если пропадет связь с Интернет, то умный дом продолжит работу в штатном режиме благодаря блоку логики, хранящейся внутри контроллера, а не в облачном сервисе.

Контроллер умного дома


Контроллер для системы облачного умного дома, рассматриваемой в данной статье, разработан на основе одноплатного микрокомпьютера Raspberry Pi 3 model B+, который был выпущен в марте 2018 года и обладает достаточными ресурсами и производительностью для задач умного дома. В его состав входит четырехядерный процессор Cortex-A53 на 64-битной архитектуре ARMv8-A, с тактовой частотой 1.4 ГГц, а также 1 ГБ ОЗУ, Wi-Fi 802.11ac, Bluetooth 4.2 и гигабитный адаптер Ethernet, работающий через шину USB 2.0.



Сборка контроллера очень проста — микрокомпьютер (1) устанавливается в пластиковый корпус (2), далее в него в соответствующие слоты устанавливается 8 ГБ карта памяти в формате microSD с программным обеспечением (3) и USB-контроллер сети Z-Wave (4). Контроллер умного дома подключается к электросети через адаптер питания 5В, 2.1А (5) и кабель USB — micro-USB (6). Каждый контроллер имеет уникальный идентификационный номер, который записывается в файле конфигурации при первом запуске и необходим для взаимодействия с сервисами облачного умного дома.

Программное обеспечение контроллера умного дома разработано автором данной статьи на основе операционной системы Linux Raspbian Stretch. Оно состоит из следующих основных подсистем:

  • серверного процесса для взаимодействия с оборудованием умного дома и облаком;
  • графического интерфейса пользователя для настройки конфигурации и рабочих параметров контроллера;
  • базы данных для хранения конфигурации контроллера.



База данных контроллера умного дома реализована на основе встраиваемой СУБД SQLite и представляет собой файл на SD-карте с системным ПО. Она служит хранилищем конфигурации контроллера — информации о подключенном оборудовании и его текущем состоянии, блока логических продукционных правил, а также информации, требующей индексации (например, имен файлов локального видеоархива). При перезагрузке контроллера эта информация сохраняется, что делает возможным восстановление работоспособности контроллера в случае сбоев электропитания.

Графический интерфейс контроллера умного дома разработан на языке PHP 7 с использованием микрофреймворка Slim. За работу приложения отвечает веб-сервер lighttpd, часто применяющийся во встраиваемых устройствах благодаря своей хорошей производительности и низким требованиям к ресурсам.


(кликните на картинку, чтобы открыть в большем разрешении)

Основной функцией графического интерфейса является подключение оборудования умного дома (IP-камер видеонаблюдения и датчиков) к контроллеру. Веб-приложение считывает конфигурацию и текущее состояние контроллера и подключенных к нему устройств из БД SQLite. Для изменения конфигурации контроллера оно посылает управляющие команды в формате JSON через интерфейс RESTful API серверного процесса.

Серверный процесс


Серверный процесс — ключевой компонент, выполняющий всю основную работу по автоматизации информационных процессов, составляющих основу умного дома: получение и обработку сенсорных данных, выдачу управляющих воздействий в зависимости от заложенной логики. Назначение серверного процесса — взаимодействие с оборудованием умного дома, выполнение продукционных логических правил, получение и обработка команд от графического интерфейса и облака. Серверный процесс в рассматриваемом контроллере умного дома реализован как многопоточное приложение, разработанное на языке С++ и запускаемое как отдельный сервис systemd операционной системы Linux Raspbian.

Основными блоками серверного процесса являются:

  1. Диспетчер сообщений;
  2. Сервер IP-камеры;
  3. Сервер устройств Z-Wave;
  4. Сервер продукционных логических правил;
  5. База Данных конфигурации контроллера и блока логических правил;
  6. RESTful API сервер для взаимодействия с графическим интерфейсом;
  7. MQTT клиент для взаимодействия с облаком.

Блоки серверного процесса реализованы как отдельные потоки, информация между которыми передается в виде сообщений в формате JSON (или структур данных, представляющих этот формат в памяти процесса).



Главным компонентом серверного процесса является диспетчер сообщений, который маршрутизирует сообщения в формате JSON для всех блоков серверного процесса. Типы информационных полей JSON-сообщения и значения, которые они могут принимать, перечислены в таблице:

deviceType protocol messageType deviceState command
camera onvif sensorData on streaming(On/Off)
sensor zwave command off recording(On/Off)
effector mqtt businessLogicRule streaming(On/Off) evice(Add/Remove)
businessLogic configurationData recording(On/Off)
bluetooth deviceState error
wifi
rf


Например, сообщение от детектора движения камеры выглядит следующим образом:

{
	"vendor": "*****",
	"version": "3.0.0",
	"timestampMs": "1566293475475",
	"clientType": "gateway",
	"deviceId": "1616453d-30cd-44b7-9bf0-************",
	"deviceType": "camera",
	"protocol": "onvif",
	"messageType": "sensorData",
	"sensorType": "camera",
	"label": "motionDetector",
	"sensorData": "on"
}

Продукционная логика


Чтобы получить или отправить сообщение от диспетчера, блок серверного процесса подписывается на сообщения определенного типа. Подписка представляет собой продукционное логическое правило типа «Если …, то … », представленное в JSON формате, и ссылку на обработчик сообщения внутри блока серверного процесса. Например, чтобы сервер IP-камеры мог получать команды от графического интерфейса и облака, нужно добавить следующее правило:

{
	"if": {
	    "and": [{
		"equal": {
		    "deviceId": "1616453d-30cd-44b7-9bf0-************"
		}
	    },
	    {
		"equal": {
		    "messageType": "command"
		}
	    }
	    ]
	},
	"then": {
	    "result": "true"
	}
}

Если условия, указанные в антецеденте (левой части) правила являются истинными, то выполняется консиквент (правая часть) правила, и обработчик получает доступ к телу JSON-сообщения. В антецеденте поддерживаются логические операторы, выполняющие сравнение JSON-пар «ключ-значение»:

  1. равно «equal»;
  2. не равно «not_equal»;
  3. меньше «less»;
  4. больше «greater»;
  5. меньше или равно «less_or_equal»;
  6. больше или равно «greater_or_equal».

Результаты сравнения можно связывать между собой с помощью операторов булевой алгебры:

  1. И «and»;
  2. ИЛИ «or»;
  3. НЕ «not».

Таким образом, записывая операторы и операнды в польской нотации, можно формировать достаточно сложные условия с большим количеством параметров.

Точно такой же механизм, основанный на JSON-сообщениях и правилах продукций в JSON формате, применяется в блоке сервера продукционной логики для представления знаний и осуществления логического вывода с использованием сенсорных данных с датчиков умного дома.

Пользователь с помощью мобильного приложения составляет сценарии, по которым должен функционировать умный дом. Например: «Если сработал датчик открытия входной двери, то включить свет в прихожей». Приложение считывает из базы данных идентификаторы датчиков (датчик открытия) и исполнительных устройств (умная розетка или умная лампа) и формирует логическое правило в формате JSON, которое пересылается в контроллер умного дома. Более подробно этот механизм будет рассмотрен в третьей статье нашего цикла, где пойдет речь о клиентском приложении для управления умным домом.

Рассмотренный выше механизм продукционной логики реализован с помощью библиотеки RapidJSON — SAX-парсера формата JSON на языке С++. Последовательное чтение и разбор массива продукционных правил позволяет легко реализовать функцию сопоставления данных внутри антецедентов:

void CRuleEngine::Process(PProperties pFact)
{
    m_pActions->clear();

    rapidjson::Reader   reader;
    for(TStringMap::value_type& rRule : m_Rules)
    {
        std::string sRuleId   = rRule.first;
        std::string sRuleBody = rRule.second;

        CRuleHandler            ruleHandler(pFact);
        rapidjson::StringStream ruleStream(sRuleBody.c_str());
        rapidjson::ParseResult  parseResult = reader.Parse(ruleStream, ruleHandler);
        if(!parseResult)
        {
            m_Logger.LogMessage(
                        NLogger2::ePriorityLevelError,
                        std::string("JSON parse error"),
                        "CRuleEngine::Process()",
                        std::string("RuleId: ") + sRuleId);
        }

        PProperties pAction = ruleHandler.GetAction();
        if(pAction)
        {
            pAction->Set("ruleId", sRuleId);
            m_pActions->push_back(pAction);
        }
    }
}

Здесь pFact — структура, содержащая пары «ключ-значение» из JSON-сообщения, m_Rules — строковый массив продукционных правил. Сопоставление входящего сообщения и правила продукции производится в функции reader.Parse(ruleStream, ruleHandler), где ruleHandler — это объект, содержащий логику булевых операторов и операторов сравнения. sRuleId — уникальный идентификатор правила, благодаря которому возможно хранить и редактировать правила внутри базы данных контроллера умного дома. m_pActions — массив с результатами логического вывода: JSON-сообщениями, содержащими консиквенты из базы правил и пересылаемые далее в диспетчер сообщений, чтобы потоки-подписчики могли их обработать.

Производительность RapidJSON сопоставима с функцией strlen(), а минимальные требования к системным ресурсам позволяют использовать эту библиотеку во встраиваемых устройствах. Использование сообщений и логических правил в JSON-формате позволяет реализовать гибкую систему информационного обмена между всеми компонентами контроллера умного дома.

Датчики и исполнительные устройства Z-Wave


Главное преимущество умного дома в том, что он умеет самостоятельно измерять различные параметры внешней среды и выполнять полезные функции в зависимости от ситуации. Для этого к контроллеру умного дома подключаются датчики и исполнительные устройства. В текущей версии — это беспроводные устройства, работающие по протоколу Z-Wave на специально выделенной частоте 869 МГц для России. Для своей работы они объединяются в mesh-сеть, в которой присутствуют ретрансляторы сигнала, чтобы увеличить зону покрытия. Также устройства имеют специальный режим энергосбережения — большую часть времени они проводят в спящем режиме и отправляют информацию только при изменении своего состояния, что позволяет существенно продлить жизнь встроенной батареи.



На рынке сейчас можно найти достаточно большое количество различных устройств Z-Wave. В качестве примера рассмотрим несколько:

  1. Умная розетка Zipato PAN16 может измерять следующие параметры: потребление электроэнергии (кВт/ч), мощность (Вт), напряжение (В) и ток (А) в электросети. Также она имеет встроенный выключатель, с помощью которого можно управлять подключенным электроприбором;
  2. Датчик протечки Neo Coolcam определяет наличие разлитой жидкости по замыканию контактов выносного щупа;
  3. Датчик задымления Zipato PH-PSG01 срабатывает при попадании частиц дыма в камеру газоанализатора;
  4. Датчик движения Neo Coolcam анализирует инфракрасное излучение тела человека. Дополнительно имеется датчик освещенности (Лк);
  5. Мультисенсор Philio PST02-A измеряет температуру (°C), освещенность (%), открытие двери, присутствие человека в помещении;
  6. Контроллер сети Z-Wave USB Stick ZME E UZB1, к которому подключаются датчики.

Очень важно, чтобы устройства и контроллер работали на одной частоте, — иначе они, по-просту, не увидят друг-друга в момент подключения. К одному контроллеру сети Z-Wave можно подключить до 232 устройств, что вполне достаточно для квартиры или загородного дома. Для расширения зоны покрытия сети внутри помещения умная розетка может быть использована как ретранслятор сигнала.



В серверном процессе контроллера умного дома, рассмотренном в предыдущем пункте, за взаимодействие с устройствами Z-Wave отвечает сервер Z-Wave. Для получения информации с датчиков он использует библиотеку OpenZWave на языке С++, которая предоставляет интерфейс для взаимодействия с USB-контроллером сети Z-Wave и работает со множеством датчиков и исполнительных устройств. Значение параметра внешней среды, измеренной датчиком, записывается сервером Z-Wave в виде JSON-сообщения:

{
	"vendor": "*****",
	"version": "3.0.0",
	"timestampMs": "1566479791290",
	"clientType": "gateway",
	"deviceId": "20873eb0-dd5e-4213-a175-************",
	"deviceType": "sensor",
	"protocol": "zwave",
	"messageType": "sensorData",
	"homeId": "0xefa0cfa7",
	"nodeId": "20",
	"sensorType": "METER",
	"label": "Voltage",
	"sensorData": "229.3",
	"units": "V"
}

Далее оно пересылается в диспетчер сообщений серверного процесса, чтобы потоки-подписчики могли его получить. Основным подписчиком является сервер продукционной логики, который сопоставляет значения полей сообщения в антецедентах логических правил. Результаты логического вывода, содержащие команды управления, пересылаются обратно в диспетчер сообщений и оттуда попадают в сервер Z-Wave, который их декодирует и отсылает в USB-контроллер сети Z-Wave. Далее они попадают в исполнительное устройство, которое меняет состояние объектов внешней среды, и умный дом, таким образом, совершает полезную работу.


(кликните на картинку, чтобы открыть в большем разрешении)

Подключение устройств Z-Wave производится в графическом интерфейсе контроллера умного дома. Для этого нужно перейти на страничку со списком устройств и нажать кнопку «Добавить». Команда добавления через интерфейс RESTful API попадает в серверный процесс и, затем, пересылается диспетчером сообщений серверу Z-Wave, который переводит USB-контроллер сети Z-Wave в специальный режим добавления устройств. Далее, на устройстве Z-Wave нужно произвести серию быстрых нажатий (3 нажатия в течении 1,5 секунд) сервисной кнопки. USB-контроллер подключает устройство в сеть и отправляет информацию о нем в сервер Z-Wave. Тот, в свою очередь, создает новую запись в БД SQLite с параметрами нового устройства. Графический интерфейс по истечении заданного интервала времени возвращается на страничку списка устройств Z-Wave, считывает информацию из БД и отображает новое устройство в списке. Каждое устройство при этом получает свой уникальный идентификатор, который используется в правилах продукционного логического вывода и при работе в облаке. Работа этого алгоритма показана на UML-диаграмме:


(кликните на картинку, чтобы открыть в большем разрешении)

Подключение IP-камер


Система облачного умного дома, рассматриваемая в данной статье, является модернизацией системы облачного видеонаблюдения, также разработанной автором, которая уже несколько лет присутствует на рынке и имеет множество инсталляций в России.

Для систем облачного видеонаблюдения одной из острых проблем является ограниченный выбор оборудования, с которым можно произвести интеграцию. Программное обеспечение, отвечающее за подключение к облаку, устанавливается внутри видеокамеры, что сразу же предъявляет серьезные требования к ее аппаратной начинке — процессору и количеству свободной памяти. Этим, главным образом, и объясняется более высокая цена камер облачного видеонаблюдения по сравнению с обычными IP-камерами. Кроме этого, требуется длительный этап переговоров с компаниями-производителями камер видеонаблюдения для получения доступа к файловой системе камеры и всех необходимых средств разработки.



С другой стороны, все современные IP-камеры имеют стандартные протоколы для взаимодействия с другим оборудованием (в частности, видеорегистраторами). Таким образом, использование отдельного контроллера, осуществляющего подключение по стандартному протоколу и трансляцию видеопотоков с IP-камер в облако, предоставляет существенные конкурентные преимущества для систем облачного видеонаблюдения. Более того, если у клиента была уже установлена система видеонаблюдения на основе простых IP-камер, то появляется возможность ее расширения и превращения в полноценный облачный умный дом.

Самый популярный протокол для систем IP-видеонаблюдения, поддерживаемый сейчас всеми без исключения производителями IP-камер, — это ONVIF Profile S, спецификации которого существуют на языке описания веб-сервисов WSDL. С помощью утилит из инструментария gSOAP возможно сгенерировать исходный код сервисов, работающих с IP-камерами:

$ wsdl2h -o onvif.h \
	https://www.onvif.org/ver10/device/wsdl/devicemgmt.wsdl \
	https://www.onvif.org/ver10/events/wsdl/event.wsdl \
	https://www.onvif.org/ver10/media/wsdl/media.wsdl \
	https://www.onvif.org/ver20/ptz/wsdl/ptz.wsdl

$ soapcpp2 -Cwvbj -c++11 -d cpp_files/onvif -i onvif.h

В результате мы получаем набор заголовочных «*.h» и исходных «*.cpp» файлов на языке С++, который можно поместить прямо в приложение или отдельную библиотеку и откомпилировать с помощью компилятора GCC. Из-за множества функций код получается большим и требует дополнительной оптимизации. Микрокомпьютер Raspberry Pi 3 model B+ обладает достаточной производительностью, чтобы исполнять этот код, но в случае, если возникнет необходимость портировать код на другую платформу, необходимо правильно подобрать процессорную архитектуру и системные ресурсы.

IP-камеры, поддерживающие стандарт ONVIF, при функционировании в локальной сети подключаются к специальной мультикастовой группе с адресом 239.255.255.250. Существует протокол WS-Discovery, который позволяет автоматизировать поиск устройств в локальной сети.

В графическом интерфейсе контроллера умного дома реализована функция поиска IP-камер на языке PHP, который очень удобен при взаимодействии с веб-сервисами посредством XML-сообщений. При выборе пунктов меню Устройства > IP-камеры > Сканирование запускается алгоритм поиска IP-камер, выводящий результат в виде таблицы:


(кликните на картинку, чтобы открыть в большем разрешении)

При добавлении камеры в контроллер можно указать настройки, в соответствии с которыми она будет взаимодействовать с облаком. Также на этом этапе ей автоматически присваивается уникальный идентификатор устройства, по которому ее в дальнейшем можно будет легко иденифицировать внутри облака.



Далее формируется сообщение в формате JSON, содержащее все параметры добавляемой камеры, и отправляется в серверный процесс контроллера умного дома через команду RESTful API, где параметры камеры декодируются и сохраняются во внутренней БД SQLite, а также используются для запуска следующих потоков обработки:

  1. установления RTSP-соединения для получения видео и аудио потоков;
  2. транскодирования аудио из форматов G.711 mu-Law, G.711 A-Law, G.723, итд. в формат AAC;
  3. транскодирования потоков видео в формате H.264 и аудио в формате AAC в контейнер FLV и передача его в облако по протоколу RTMP;
  4. установления соединения с конечной точкой детектора движения IP-камеры по протоколу ONVIF и ее периодический опрос;
  5. периодической генерации уменьшенного изображения предварительного просмотра (preview) и пересылке его в облако по протоколу MQTT;
  6. локальной записи видео и аудио потоков в виде отдельных файлов в формате MP4 на SD- или Flash-карту контроллера умного дома.



Для установления соединения с камерами, транскодирования, обработки и записи видеопотоков в серверном процессе используются функции из библиотеки FFmpeg 4.1.0.

В эксперименте на тестирование производительности к контроллеру были подключены 3 камеры:

  1. HiWatch DS-I114W (разрешение — 720p, формат сжатия — H.264, битрейт — 1 Mb/s, звук G.711 mu-Law);
  2. Microdigital MDC-M6290FTD-1 (разрешение — 1080p, формат сжатия — H.264, битрейт — 1 Mb/s, без звука);
  3. Dahua DH-IPC-HDW4231EMP-AS-0360B (разрешение — 1080p, формат сжатия — H.264, битрейт — 1.5 Mb/s, звук AAC).



Все три потока одновременно выводились в облако, транскодирование звука осуществлялось только с одной камеры, запись локального архива была отключена. Загрузка CPU составила примерно 5%, использование RAM — 32 МБ (на процесс), 56 МБ (всего вместе с ОС).

Таким образом, к контроллеру умного дома можно подключить примерно 20 — 30 камер (в зависимости от разрешения и битрейта), что достаточно для системы видеонаблюдения трехэтажного коттеджа или небольшого склада. В задачах, где требуется большая производительность, можно использовать неттоп с многоядерным процессором Intel и ОС Linux Debian Sarge. В настоящее время контроллер проходит опытную эксплуатацию, и данные о производительности его работы будут уточняться.

Взаимодействие с облаком


Облачный умный дом хранит пользовательские данные (видео и измерения датчиков) в облаке. Более подробно архитектура облачного хранилища будет рассмотрена в следующей статье нашего цикла. Сейчас поговорим об интерфейсе передачи информационных сообщений от контроллера умного дома в облако.

Состояния подключенных устройств и измерения датчиков передаются по протоколу MQTT, который часто применяется в проектах Интернета Вещей из-за простоты и энергоэффективности. MQTT использует клиент-серверную модель, когда клиенты подписываются на определенные топики внутри брокера и публикуют свои сообщения. Брокер рассылает сообщения всем подписчикам по правилам, определяемым уровнем QoS (Quality of Service):

  • QoS 0 — максимум один раз (нет гарантии доставки);
  • QoS 1 — хотя бы один раз (с подтверждением доставки);
  • QoS 2 — ровно один раз (с дополнительным подтверждением доставки).

В нашем случае в качестве MQTT-брокера используется Eclipse Mosquitto. Именем топика является уникальный идентификатор контроллера умного дома. MQTT-клиент внутри серверного процесса подписывается на данный топик и транслирует в него JSON-сообщения, приходящие от диспетчера сообщений. И, наоборот, сообщения из MQTT-брокера пересылаются им в диспетчер сообщений, который далее мультиплексирует их своим подписчикам внутри серверного процесса:



Для передачи сообщений о состоянии контроллера умного дома используется механизм сохраненных сообщений retained messages протокола MQTT. Это позволяет правильно отслеживать моменты переподключений при сбоях электропитания.

MQTT-клиент был разработан на основе реализации библиотеки Eclipse Paho на языке С++.

Медиапотоки H.264 + AAC отправляются в облако по протоколу RTMP, где за их обработку и хранение отвечает кластер медиасерверов. Для оптимального распределения нагрузки в кластере и выбора наименее загруженного медиасервера контроллер умного дома делает предварительный запрос к облачному балансировщику нагрузки и только после этого отправляет медиапоток.

Заключение


В статье была рассмотрена одна конкретная реализация контроллера умного дома на базе микрокомпьютера Raspberry Pi 3 B+, который умеет получать, обрабатывать информацию и управлять оборудованием по протоколу Z-Wave, взаимодействовать с IP-камерами по протоколу ONVIF, а также обменивается данными и командами с облачным сервисом по протоколам MQTT и RTMP. Разработан движок продукционной логики на основе сопоставления логических правил и фактов, представленных в JSON формате.

Сейчас контроллер умного дома проходит опытную эксплуатацию на нескольких объектах в Москве и Подмосковье.

В следующей версии контроллера планируется подключение устройств других типов (RF, Bluetooth, WiFi, проводные). Для удобства пользователей процедура подключения датчиков и IP-камер будет перенесена в мобильное приложение. Также есть идеи по оптимизации кода серверного процесса и портировании программного обеспечения на операционную систему OpenWrt. Это позволит сэкономить на отдельном контроллере и перенести функционал умного дома в обычный бытовой роутер.
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 19

    +3
    Вы по каким-то политическим мотивам не используете Domoticz или OpenHab?
      0
      Domoticz, OpenHab, MajorDoMo, Rubetek, Ростелеком,… — уважаемые и зарекомендовавшие себя на рынке системы. Мотивы личные — хотелось опробовать свои решения и разработать систему умного дома с контроллером, облаком и мобильным приложением.
      0
      все хорошо. а mqtt зачем в облаке?
        0
        Спасибо за вопрос. Для обмена сообщениями между контроллером умного дома и облачным сервером бизнес-логики. Во второй статье постараюсь раскрыть этот вопрос полнее.
        0

        Прочитав статью, вспомнил как в далекие 90-е мы интегрировали системы контроля доступа (СКД) с системами защиты от несанкционирванного доступа (НСД) к компьютерам. Тоже элементы умного дома:
        image
        Ну а серверные сегодня на картинке надо заменить просто на облака.

          0
          Да, с того времени технологии шагнули вперед. Уверен, что вы бы не отказались интегрировать парочку модных фич, типа Push-уведомлений или голосовых сценариев. ;)
          0
          почему z-wave, а не zigbee?
            0
            У Z-Wave больше ассортимент оборудования и удобные для интеграции контроллеры сети. Хотелось бы научиться поддерживать все стандарты: Zigbee, RF, WiFi, Bluetooth. Но это — задача максимум.
            0
            Интересно, ждемс продолжения.
              +1
              Извините, я видимо не до конца понял. В статье предлагается вынести личные данные и логику в облако (ресурс за пределами дома, над которым у человека нет однозначного контроля), или просто хранить там бэкапы и копии данных мониторинга?
                0
                Вы правы, эту тему я еще не раскрыл. Не смог все уместить в одну статью — много интересного материала. Планирую во второй статье более подробно описать облачную архитектуру.
                  0
                  Мне кажется, что мотивацию и архитектуру надо расписывать сразу. После этой статьи мне кажется, что Вы советуете поступить в лучших традициях Звёздных войн — поставить генератор защитного поля снаружи этого поля.
                    0
                    Нет, это не так. Это — моя первая статья на Хабре. Но, видимо, не все гладко получилось. Обещаю исправиться. Пока советую подписаться на мой аккаунт, — когда выйдет статья про облачную архитектуру, которая Вам более интересна, думаю придет уведомление. В любом случае, спасибо за критику.
                0

                А как насчёт шифрования S2, которое OpenZwave не поддерживает и никогда не будет поддерживать? Как насчёт обязательных для новых устройств функций протокола, которые тоже остались за бортом (Smart Start, добавление по QR коду)?
                Не знаю, сколько времени ушло на разработку системы, но в 2019 она выглядит, как "немного из прошлого". На пятом чипе Zwave свисти многие уже не производят, а седьмые чипы пока OpenZwave не умеет нормально.
                Какие перспективы у велосипеда? Нет желания запрыгнуть на стандартные рельсы типа Z/IP?

                  0
                  Разработка велась в сжатые сроки, поэтому какие-то компоненты не были включены. OpenZWave применяется во многих проектах умного дома и развивается — пока я интегрировал его в свое приложение, вышло 2 новых версии. Проблем с работой на USB-контроллере не заметил, все необходимые мне функции поддерживаются. В проекте для меня было важно разработать универсальный механизм для подключения различных устройств по раличным протоколам (сейчас это Z-Wave и ONVIF), нежели интегрировать все новые фичи, для которых производители пока не выпустили достаточно оборудования.
                  Добавление по QR-коду есть в мобильном приложении. Я расскажу об этом в третьей статье.
                  0
                  В сторону Mozilla IoT не смотрели? Может лучше там плагинов под себя написать, если надо?
                    0
                    Да, я пересмотрел много фреймворков, когда начинал работу над проектом, в том числе и Mozilla IoT. Особенность задачи состояла в поддержке системы облачного видеонаблюдения, благодаря которой мы уже обросли клиентами. Ну, и коммерческий аспект, продавать опенсорс — это сложно. В итоге пришел к выводу, что нужно сделать свою систему облачного умного дома.
                    0

                    Держать БД на флешке плохая идея.

                      0
                      Да, верно. Моя первая рабочая SD-карта вышла из строя через полгода активного использования. Поэтому операции записи были очень сильно заоптимизированы. Фактически запись происходит только когда меняется состояние подключенного оборудования, а это — достаточно редко. Все логи были перенесены в tmpfs, то бишь RAM. По моим расчетам ресурса 8 ГБ SD-карты должно хватить на 4 года непрерывного использования, что вполне приемлимо.

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое