Pull to refresh

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

Reading time 16 min
Views 54K


Сегодня, благодаря бурному развитию микроэлектроники, каналов связи, Интернет-технологий и Искусственного Интеллекта, тема умных домов становится все более и более актуальной. Человеческое жилище претерпело существенные изменения со времен каменного века и в эпоху Промышленной Революции 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. Это позволит сэкономить на отдельном контроллере и перенести функционал умного дома в обычный бытовой роутер.
Tags:
Hubs:
+6
Comments 19
Comments Comments 19

Articles