Сегодня, благодаря бурному развитию микроэлектроники, каналов связи, Интернет-технологий и Искусственного Интеллекта, тема умных домов становится все более и более актуальной. Человеческое жилище претерпело существенные изменения со времен каменного века и в эпоху Промышленной Революции 4.0 и Интернета Вещей стало весьма удобным, а такде функциональным и безопасным. На рынок приходят решения, превращающие квартиру или загородный дом в сложные информационные системы, управляемые из любой точки мира с помощью смартфона. Причем, для человеко-машинного взаимодействия уже не требуются знания языков программирования, — благодаря алгоритмам распознавания и синтеза речи человек говорит с умным домом на родном языке. Некоторые системы умного дома, представленные сейчас на рынке, являются логичным развитием систем облачного видеонаблюдения, разработчики которых осознали необходимость в комплексном решении не только для контроля, но и для управления удаленными объектами.
Вашему вниманию предлагается цикл из трех статей, где будет рассказано о всех основных компонентах системы облачного умного дома, лично разработанной автором и запущенной в эксплуатацию. Первая статья посвящена оконечному клиентскому оборудованию, устанавливаемому внутри умного дома, вторая — архитектуре системы облачного хранения и обработки данных, и, наконец, третья — клиентскому приложению для управления системой на мобильных и стационарных устройствах.
Оборудование для умного дома
Сперва поговорим о том, как из обыкновенной квартиры, дачи или коттеджа сделать умный дом. Для этого, как правило, требуется разместить в жилище следующее оборудование:
- датчики, измеряющие различные параметры внешней среды;
- исполнительные устройства, воздействующие на внешние объекты;
- контроллер, производящий вычисления в соответствии с измерениями датчиков и заложенной логикой, и выдающий команды для исполнительных устройств.
На следующем рисунке показана схема умного дома, на которой расположены датчики протечки воды (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.
Основными блоками серверного процесса являются:
- Диспетчер сообщений;
- Сервер IP-камеры;
- Сервер устройств Z-Wave;
- Сервер продукционных логических правил;
- База Данных конфигурации контроллера и блока логических правил;
- RESTful API сервер для взаимодействия с графическим интерфейсом;
- 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-пар «ключ-значение»:
- равно «equal»;
- не равно «not_equal»;
- меньше «less»;
- больше «greater»;
- меньше или равно «less_or_equal»;
- больше или равно «greater_or_equal».
Результаты сравнения можно связывать между собой с помощью операторов булевой алгебры:
- И «and»;
- ИЛИ «or»;
- НЕ «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. В качестве примера рассмотрим несколько:
- Умная розетка Zipato PAN16 может измерять следующие параметры: потребление электроэнергии (кВт/ч), мощность (Вт), напряжение (В) и ток (А) в электросети. Также она имеет встроенный выключатель, с помощью которого можно управлять подключенным электроприбором;
- Датчик протечки Neo Coolcam определяет наличие разлитой жидкости по замыканию контактов выносного щупа;
- Датчик задымления Zipato PH-PSG01 срабатывает при попадании частиц дыма в камеру газоанализатора;
- Датчик движения Neo Coolcam анализирует инфракрасное излучение тела человека. Дополнительно имеется датчик освещенности (Лк);
- Мультисенсор Philio PST02-A измеряет температуру (°C), освещенность (%), открытие двери, присутствие человека в помещении;
- Контроллер сети 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, а также используются для запуска следующих потоков обработки:
- установления RTSP-соединения для получения видео и аудио потоков;
- транскодирования аудио из форматов G.711 mu-Law, G.711 A-Law, G.723, итд. в формат AAC;
- транскодирования потоков видео в формате H.264 и аудио в формате AAC в контейнер FLV и передача его в облако по протоколу RTMP;
- установления соединения с конечной точкой детектора движения IP-камеры по протоколу ONVIF и ее периодический опрос;
- периодической генерации уменьшенного изображения предварительного просмотра (preview) и пересылке его в облако по протоколу MQTT;
- локальной записи видео и аудио потоков в виде отдельных файлов в формате MP4 на SD- или Flash-карту контроллера умного дома.
Для установления соединения с камерами, транскодирования, обработки и записи видеопотоков в серверном процессе используются функции из библиотеки FFmpeg 4.1.0.
В эксперименте на тестирование производительности к контроллеру были подключены 3 камеры:
- HiWatch DS-I114W (разрешение — 720p, формат сжатия — H.264, битрейт — 1 Mb/s, звук G.711 mu-Law);
- Microdigital MDC-M6290FTD-1 (разрешение — 1080p, формат сжатия — H.264, битрейт — 1 Mb/s, без звука);
- 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. Это позволит сэкономить на отдельном контроллере и перенести функционал умного дома в обычный бытовой роутер.
Автор: Артем Орлов
Источник: https://habr.com/
