Эта статья написана на основе личного опыта автора, полученного при создании своего умного дома, и представляет собой техническое руководство с примерами, целью которого служит желание помочь другим владельцам умных устройств экосистемы Xiaomi в создании сложных и простых сценариев их использования, а также популяризация среды визуального программирования умного дома экосистемы Xiaomi.
Когда стандартных возможностей Mi Home больше не хватает
Создание типового сценария автоматизации для умного дома экосистемы Xiaomi в приложении Mi Home в общем не сильно отличается от создания сценариев в других экосистемах и состоит из типовых блоков: «триггер/событие», «условия выполнения» и «выполнение действия».
Всё лаконично, просто, понятно и удобно, но эта простота содержит в себе ряд ограничений: что делать, если блок действий сложный, содержит внутри себя условия выполнения и ветвления и активатором действий могут выступать несколько различных триггеров? Я впервые столкнулся с ограничениями Mi Home при подключении умного термостата HeatCold TH123: оказалось, что в нём некорректно реализован аппаратный триггер и вместо создания событий при изменении температуры он просто несколько раз в секунду порождал поток событий, с которыми невозможно было работать. Одним из вариантов решения задачи был бы опрос состояния датчиков в цикле, но, как оказалось, в стандартных сценариях Mi Home нет цикла, а создание набора однотипных таймеров выглядело бы некрасиво и было бы трудным в сопровождении. К тому же, владельцы китайских устройств, привязанных к китайскому облаку, рано или поздно сталкиваются с задержками выполнения сценариев или вообще с необъяснимыми отказами. И возникает желание сделать так, чтобы сценарии при исполнении никуда наружу в «облако» не «ходили», а исполнялись в домашней локальной сети.
В интернете на различных тематических форумах описывается множество программных и программно-аппаратных вариантов для решения подобных задач. Наиболее популярным и поддерживаемым сообществом является Home Assistant (далее HASS), но его установка и настройка, несмотря на большое количество информации в интернете, может вызвать затруднения у неподготовленного пользователя. Для устройств экосистемы Xiaomi есть готовая HASS-интеграция MIOT, которая «из коробки» позволяет создавать локальные и облачные сценарии.
В 2022 году Xiaomi в новые модели роутеров (на момент написания статьи — BE3600PRO и BE6500PRO) и хабов (Xiaomi Home Hub) начала добавлять своё решение для создания локальных сценариев Mijia Automation Geek Edition, и далее я хочу его сравнить именно с HASS.
К очевидным достоинствам HASS можно отнести:
-
Гибкость платформы, возможность интеграции устройств различных экосистем.
-
Наличие документации и множество примеров использования.
-
Поддержку сообщества и энтузиастов.
Недостатки тоже есть:
-
Необходимость наличия сервера для развёртывания HASS и MIOT. Малогабаритные barebone-системы, например, Raspberry PI, могут стоит относительно дорого в зависимости от конфигурации, и для их настройки нужно иметь определённые знания.
-
Относительная сложность подключения новых устройств — извлечение токенов устройств, настройка конфигураций и т. д.
-
Сложность создания локальных сценариев с использованием нетиповых устройств, типа виртуальных панелей.
Mijia Automation имеет свои преимущества:
-
Не требуется отдельный сервер — софт встроен в прошивку хаба.
-
Все сценарии только локальные.
-
Поддержка почти всех устройств экосистемы Xiaomi «из коробки».
Недостатки по сравнению с HASS:
-
Поддерживаются только устройства экосистемы Xiaomi.
-
Интерфейс среды только на китайском, работает только в китайском регионе.
-
Ограниченные возможности самой среды: только самое необходимое, никаких свойств и конфигураций элементов и блоков.
-
Закрытость системы.
-
Полное отсутствие документации.
Как видите, недостатков у Mijia Automation перечислено больше, чем у HASS, поэтому на идеальное решение для умного дома среда не претендует. Но, с моей точки зрения, она достаточно интересная и заслуживает внимания как удобная для быстрой разработки сложных локальных сценариев, особенно если производитель сможет довести её до ума в будущем — хотя бы сделает поддержку языков, кроме китайского. Эта статья посвящена последнему перечисленному недостатку, связанному с документацией и инструкциями, и я покажу, что в использовании среды Mijia Automation нет ничего сложного.
Описание функционала среды разработки Mijia Automation
Как я уже писал, китайская (скорее, восточная) техногик-идеология устроена таким образом, что самые новые, технологичные и интересные (в том числе по цене) устройства выпускают только для китайского рынка. Именно поэтому большинство пользователей рано или поздно переезжают на китайское облако экосистемы, потому что глобальные облачные сервисы эти устройства не поддерживают. Xiaomi Home Hub или роутер с функциональностью Geek Automation не стали исключением из правил: подключаются только в регионе Китай, и по сравнению со списком функций «обычного» хаба или роутера появился раздел для подключения к среде.
Если у вас уже есть такое устройство, откройте плагин в приложении Mi Home и заходите в раздел «Функция центра управления». Там вы увидите IP-адрес сервера, а ниже отображается OTP-код, необходимый для входа на основную страницу среды программирования.
После перехода по ссылке открывается страница входа в среду разработки сценариев. Для телефона среда не адаптирована, хотя страница в домашней сети и откроется, и этим можно пользоваться, когда срочно нужно что-то сделать, например, активировать или деактивировать автоматизацию. Но работать там, создавать или редактировать какие-то сценарии с разветвлённой логикой будет очень неудобно. Поэтому рекомендуется использовать десктоп с большим монитором. При работе на компьютере нужно запустить Chrome-браузер, ввести в адресной строке IP-адрес из функциональности управления Xiaomi Home Hub, и откроется страница входа (как на картинке ниже), на которой также необходимо ввести ОТР-код из приложения (как показано на картинке выше):
Далее открывается основная страница среды. Как я уже писал выше, к сожалению, в данный момент среда доступна только на китайском языке и только в браузере Chrome, поэтому, рекомендуется использовать на страницах встроенный в Chrome Google Переводчик. Мне привычнее переводить на английский, потому что в контексте программирования по терминологии и качеству получается немного лучше и точнее, чем при переводе на русский. К тому же переменные при переводе страницы не переводятся. То есть далее все описания блоков будут идти по названиям в английском переводе Google Переводчика. При автопереводе иногда наблюдается небольшая проблема: открывается пустая страница и закрывается сессия. Видимо, перевод заменяет и текст в ссылках, поэтому приходится заходить заново. Рекомендую чаще сохраняться или использовать приложения для экранного перевода.
Основное окно содержит список сценариев пользователя (1), поддерживается фильтрация и сортировка по полям. В правой части строки сценария (2) есть выпадающее меню стандартных действий (3): переименовать, создать копию, удалить и тумблер переключения состояния сценария. Помимо отключения выполнения всех действий внутри сценария этот тумблер выполняет ещё одну очень важную роль: выступает триггером для запуска некоторых блоков, но об этом ниже. В последних версиях прошивки хаба наконец-то появилась полезная функция (4) экспорта всех запрограммированных сценариев в файл, а также возможность восстановления конфигурации умного дома. В верхнем правом углу (5) есть ссылки на блог, FAQ на китайском и описание изменений в релизах среды. Иногда можно узнать что-нибудь полезное.
Под списком сценариев (6) следует список оборудования, поддерживающего локальные автоматизации с помощью среды. У меня в список попали почти все устройства умного дома (находящиеся в данный момент в онлайне), включая добавленные через Mi Home VEVS неродного региона. По какому принципу какое-то устройство может быть недоступно в среде, понять невозможно, будем надеяться, что по мере развития среды недоступные ранее тоже будут появляться в списке (как это происходит, например, в умном доме Яндекса). Также выборку можно ограничить по размещению или типу устройства.
При выборе устройства видно, какие типы событий может сгенерировать устройство, какие состояния можно запросить из среды и какие типы действий доступны:
В левой панели есть ещё одно очень полезное нововведение последних прошивок: работа с переменными (7). Среда поддерживает изоляцию данных, переменные делятся на глобальные и локальные. Локальные работают только внутри сценария, а глобальные нужны, когда нужно передать что-то между различными сценариями. Самое интересное, что при сохранении сценария среда автоматически чистит неиспользуемые локальные переменные, поэтому не удивляйтесь, если они вдруг куда-то при сохранении сценария пропали.
При нажатии кнопки «+ Create Automation» в верхнем правом углу основного экрана переходим к разделу, посвященному компонентам среды и описанию того, что они делают. Там, где требуется приведем примеры сценариев, где эти компоненты используются.
Основные элементы управления на странице создания автоматизации (модуля):
-
Палитра функциональных блоков, используемых для создания сценариев. Подробно будут описаны ниже.
-
Отмена и повтор редактирования.
-
Вызов экрана работы с локальными переменными.
-
Выгрузка сценария в картинку (.jpg)
-
Добавление на экран блока для комментариев.
-
Вызов в нижней части экрана отладчика сценария.
-
Вызов в нижней части экрана подсказки по горячим клавишам.
-
Сохранение программы.
-
Изменение масштаба элементов на экране.
При создании сценария основной подход, используемый в Mi Home — захват события, анализ и учёт условий выполнения. Формирование действие в общем сохраняется, но при этом становятся доступны логика и алгоритмы, которые в Mi Home были недоступны.
Mijia Automation Geek Edition — это визуальная (no-code) среда разработки. Программирование сценариев автоматизаций в ней представляет собой перетаскивание на подложку в центре экрана из панели в левой части логических элементов и соединение их нитями-связями процессов и условий. Процесс может ветвиться — иметь параллельные нити сценариев.
Ниже приведены описания этих блоков, для некоторых приведены примеры использования. Блоки имеют входные и выходные коннекторы, синим обозначены коннекторы для нитей процесса, зелёным — для связи с блоками-условиями. Двухцветные коннекторы могут одновременно выступать как для связи с коннектором процесса, так и с коннектором условия. Соединить синий и зелёный коннектор нельзя. Также нельзя соединить два входа или два выхода: строго стрелка из выхода одного блока на вход другого. Блоки-триггеры (с которых начинается процесс) не имеют входных коннекторов. Из выходного коннектора могут выходить несколько нитей процесса (ветвление), но нельзя несколько нитей завести во входящий. Если требуется объединение процессов в один результирующий, то необходимо использовать блоки логики, описанные ниже — «Meets all conditions» (объединение через логическое И) или «Meets any conditions» (объединение через логическое ИЛИ).
В самой среде блоки сгруппированы в шесть групп: Equipment (работа с оборудованием), Time (таймеры и условия по времени), Process (циклы и процессные переключатели и обработчики условий), Logic (процессная логика), Other (то, что не попало в вышеперечисленную классификацию) и Variables (группа работы с переменными — триггеры, запросы состояния, функции работы с переменными). Деление весьма условное и непонятное, я бы сделал по-другому, но самая интересная из них — это последняя группа, она появилась в одной из последних прошивок и позволяет сделать реально полезные вещи, которые будут описаны ниже.
1. Группа Equipment
1.1 Блок захвата события
Блок захвата события — один из типов триггеров, который используется для запуска процесса сценария, например, по событию изменения температуры на датчике, или включения-выключения реле, или нажатия кнопки. Может формировать и выход процесса, и условие выполнения. Указывается с условием, при выполнении которого процесс идёт дальше. Переключатель в нижней части посередине ограничивает срабатывание триггера одним разом. Сам поток событий формируется аппаратно самим устройством, реализация может быть весьма специфична в зависимости от производителя. Например, разные производители датчиков температуры могут формировать изменения температуры с разным шагом (возможно и 0,1, и 0,5, и 1 градус). Встречал также устройства, которые просто выдают в эфир события генератором. Обычно ни в каких инструкциях к устройству это не описывается, в открытых источниках информации тоже мало, но реальную картину хорошо видно при анализе выполнения сценария при помощи встроенного отладчика (описание работы которого я приведу ниже).
1.2 Блок запроса показаний и состояния
Этот блок запрашивает необходимые данные у устройства, сравнивает с указанным условием и формирует два выхода: если условие выполняется и если не выполняется. В отличие от описанного выше блока не является триггером, то есть процесс с таким блоком вначале запускаться не будет.
1.3 Блок действия
Изменяет статус устройства, настройки и конфигурации, выполняет аппаратные команды — переключает реле, включает физические действия устройства.
2. Группа Time
2.1 Блок Timing (Таймер)
Это триггер для запуска процесса в конкретное время или по расписанию.
2.2 Блок Time Period (Период выполнения)
Является триггером для запуска процесса (срабатывает, если текущее время попадает в указанный диапазон) и условием. Подключается как условие, когда необходимо ограничить сценарий или его часть по периоду времени. Условие используется, как правило, вместе с блоками, описанными ниже: 3.1 когда-если-то или блоками агрегации условий — 4.2 выполнены все условия или 4.2 выполнено одно из условий.
2.3 Блок Delay (Задержка)
Тут всё просто: останавливает нитку процесса на указанный период времени.
2.4 Блок State lasted for a while
Блок по смыслу похож на Delay, с той лишь разницей, что создан для обработки условий, формирует выход процесса или выполнение условия в зависимости от времени, которое прошло между обращением к нему на входе. Например, для формирования события окно открыто 5 секунд. Применяется так же, как и в 2.2 с блоками обработки логики. Ниже приведён синтетический пример, демонстрирующий работу блоков задержек 2.3 и 2.4. Изменяя время задержки в блоке Delay, можно добиться разных комбинаций работы выходов процессов:
2.5 Блок Events occurred successively
Блок используется для объединения в одно действие двух событий, которые произошли в течение заданного времени. Например, сработал датчик открытия двери и датчик присутствия в коридоре — в течение 5 секунд включаем свет в зале.
3 Группа Process
3.1 Блок When-If-Then
Один из основных блоков процессной логики. Применяется для проверки заданных условий (через зелёный вход) и формирования позитивного выхода, если проверка прошла успешно, или негативного, если проверка завершилась неудачно.
3.2 Блок Cycle
Блок предназначен для генерации выходов процесса с заданной частотой, при этом не является (!) запускающим процесс триггером. Для его запуска на вход необходимо подать некое активирующее действие, например, выход из блока 5.2 When this automation is enabled Например, как на картинке ниже. Для остановки цикла генерации действий необходимо использовать второй нижний синий вход.
3.3 Блок Trigger at most the specified numbers of times
Это на самом деле не триггер, а ограничитель количества выполнения циклов сценария в штуках. Например, для включения света при открытии двери один раз в день. Синий нижний вход предназначен для сброса счётчика, туда можно подключить выход 2.3 задержки или 2.1 таймера. Ниже приведён синтетический пример реализации этой логики:
3.4 Блок When the specified number of times is reached
Блок внешне похож на 3.3, но, в отличие от него, не ограничивает сценарий по количеству событий, а является счётчиком, который при достижении заданной величины событий на входе формирует действие и продолжает процесс или формирует условие. Так же, как в 3.3, нижний вход предназначен для сброса счётчика.
Ниже приведен пример сценария, при котором настенный выключатель при двойном нажатии в течение 2 секунд включает свет на балконе.
3.5 Блок Mode Switching
Применяется для случаев, когда требуется по последовательным событиям на вход последовательно сформировать действия на выходах от первого до последнего и так далее в цикле. Например, нажатие беспроводной кнопки последовательно включает свет в коридоре, прихожей и зале, а четвёртое нажатие всё выключает, и так далее с начала.
4. Группа Logic
4.1 Блок When any event occurs
Тоже один из самых часто используемых блоков. Если стрелки-связи из одного выхода блока для ветвления процесса можно создавать в неограниченном количестве, то обратно сводить ветвления процесса в один можно только через логические блоки. В данном случае процессы складываются в один через логическое ИЛИ. Блока для объединения процессов через логическое И не предусмотрено ввиду низкой вероятности таких событий, но если такая потребность возникнет, то для этого можно использовать блоки для объединения условий, описанные ниже.
4.2 Блок Meet any conditions
По смыслу аналогичен блоку 4.1, но предназначен для объединения условий (зелёные стрелки) через логическое ИЛИ. На выходе может формировать и условие, и процесс.
4.3 Блок Meet all conditions
Предназначен для объединения условий (зелёные стрелки) через логическое И. На выходе может формировать и условие, и процесс.
4.4 Блок Status inversion
Блок для преобразования статуса условия на обратное или преобразования условия в процесс.
5. Группа Other
5.1 Блок Custom Status
В отличии от 4.4 преобразование выполняется в обратную сторону: нитей процессов в условие.
5.2 Блок When this automation is enabled
Блок является триггером для запуска сценария и предназначен для взаимодействия автоматизации на основном экране среды (список автоматизаций) и блоков внутри программного модуля. То есть при активации тумблера в списке автоматизаций ниже формируется событие на выходе из блока:
6. Группа Variables
Далее следует самая интересная группа элементов, которая, как я писал выше, появилась в одной из последних прошивок и даёт достаточно много новых возможностей для автоматизаций — работу с переменными. Переменные в среде могут быть глобальными и локальными, и если вы используете их только внутри модуля, то желательно избегать использования глобальных, потому что есть риск неумышленного переопределения значений в процессах из разных модулей. При этом если есть необходимость передачи значений между процессами в разных модулях, глобальные переменные с этим хорошо справляются. Локальные переменные, как было описано выше, заводятся внутри модуля, для глобальных есть специальный раздел на основной странице.
6.1 Блок Device trigger assignment (Подписка на события)
По сути, наследник триггера 1.1 — блока захвата события, с существенным отличием: при появлении события присваивает его указанной переменной, а обработка условий вынесена в отдельный, предусмотренный для этого блок 6.4. Переключатель в нижней части посередине ограничивает срабатывание триггера одним разом.
Пример использования. Некоторые производители экосистемы Xiaomi уже начали делать устройства, которые максимально раскрываются в среде Mijia Automation. Например, панель Linptech Touch Screen Switch S2, в которой есть так называемые виртуальные устройства. Выбор устройств пока небольшой: это управление светом, шторами и кондиционером, но технология выглядит очень многообещающей.
Среда Mijia Automation позволяет «отловить» события на виртуальной панели и присвоить значения полученных данных динамическим переменным среды. Например, мы можем прочитать значение целевой температуры при изменении на панели и передать его прямо в блок действия кондиционера. И подобным образом мы можем запрограммировать управление любыми настройками устройств, доступных в среде.
6.2 Блок Query device and assign values (Запрос показаний в переменную)
Это наследник блока 1.2. Предназначен для запроса показаний датчиков и состояния устройства и назначения этих значений в указанную переменную. В отличие от блока 1.2 функциональность анализа условий вынесена в отдельный блок 6.4.
6.3 Блок Variable value update (Захват события обновления переменной).
Это триггер для запуска процесса, который срабатывает при обновлении переменной и сравнивает значение с указанным условием, формирует выход процесса и условия. Переключатель в нижней части посередине ограничивает срабатывание триггера одним разом.
6.4 Блок Query variable value (Обработка условий)
Как такового запроса (Query) тут нет (видимо, некорректное название или перевод), это блок для сравнения переменной с указанными условиями, вынесенный из 1.1 и 1.2 и используемый в связке с 6.1 и 6.2, а также в других местах, где требуется. Формирует выход для успешного и неуспешного выполнения условия.
6.5 Блок работы с числовыми переменными
Блок позволяет проводить с полученными данными широкий спектр различных математических вычислений, включая сравнение показаний разных датчиков или установленных на различных панелях целевых значений и текущих показаний устройств. Для того, чтобы вставить в формулу ссылку на переменную, введите в строке вычисления знак $ или нажмите на значок (х), и среда откроет за значком список доступных в автоматизации переменных, включая глобальные. При нажатии на значок f(x) открывается список доступных математических функций.
6.6 Блок работы с текстовыми переменными
Блок предназначен для формирования динамических строк для вывода на панели, которые поддерживают текстовый вывод. При сложении текстовых строк и числовых значений среда сама выполняет необходимые преобразования типов.
Отладка сценариев
При разработке сценариев очень часто возникает такая ситуация, когда всё вроде бы составлено правильно, но автоматизация либо не работает, либо её поведение отличается от задуманного сценария. И тут сильно может помочь очень полезный и важный инструмент — отладчик сценариев (или debugger), пользоваться которым не составит большого труда и не потребует каких-то тайных знаний. Среда выполнения автоматизаций на каждом шаге журналирует свои действия, и чтобы увидеть исполнение сценария по шагам необходимо в верхней правой части экрана нажать на значок листа с записями (между значками «Т» и «i»):
В нижней части страницы мы видим элементы для ввода диапазона дат и времени, в левой части значок запроса и обновления данных. Если данные обнаружены, в верхней части экрана появится сообщение с зелёной иконкой, если нет — с красной. После того, как данные подгрузились, с помощью стрелок «<» и «>» можно пройти сценарий от начала и до конца или наоборот, и легко найти, в каком месте ошибка.
Интеграция Mijia Automation с облачной средой Mi Home
Как было уже написано выше, сценарии, созданные в Mijia Automation, хранятся и выполняются локально на хабе и только в домашней сети. Но часто возникает необходимость что-то передать в среду Mi Home или наоборот. Например, вы сделали для охраны дома локальные сценарии с датчиками движения, открытия дверей или вибрации, и вам необходимо получать событие постановки или снятия режима охраны и в обратную сторону — при срабатывании датчиков отсылать уведомления через приложение. Для этого в хабе предусмотрена функция виртуальных событий, с помощью которой можно связать автоматизации в Mijia Automation и Mi Home. Вот пример, как это можно сделать:
Блок также поддерживает работу со строковыми переменными — при нажатии на (х) откроется список доступных для использования.
Заключение
Я надеюсь, что в текущей ситуации с полным отсутствием документации по среде Mijia Automation Geek Edition это руководство будет полезно, чтобы вы могли сделать первые шаги в использовании или найти ответы на какие-то вопросы. Если в статье вы обнаружите неточности или там чего-то не хватает, просьба написать мне сообщение или комментарий, я обязательно исправлю или внесу изменения.
Теги:
Хабы:
Автор: llebedev1975
