Как WirenBoard помогал садоводству (часть III)

Введение

Приветствую, коллеги. Незаметно подобралась осень и можно рассказать о очередных шагах в области автоматизации дачного хозяйства на любительском уровне. Напомню, что это уже третья статья на данную тему. Предыдущие размещаются вот тут – первая ^[1], вторая ^[2].

В этом номере я расскажу про небольшие работы над ошибками (когда что-то пришлось переделать), новые шаги в области автоматизации, дополнительно установленное оборудование, технологические нюансы и дальнейшие планы. А они растут в прямой аналогии знаменитому изречению Сократа ^[3]: «Чем больше я знаю, тем больше я понимаю, что ничего не знаю». В моей трактовке звучит как: «Чем больше я делаю, тем больше хочу сделать». Также нужно отметить, что некоторые изображения (в мультипликационном стиле) выполнены с помощью сервиса GigaChat (2023 год) и «Шедеврум».

 Точность

Как и анонсировал, начинаю с работы над ошибками. Первое, что достаточно быстро стало неудобным в эксплуатации это ограниченность состояний резервуара с водой (бочки): пустая, полная и ни то ни другое. Поскольку наполнение бочки процесс достаточно долгий и визуальный контроль отсутствует нужно было гадать, а сколько же ещё она будет наполняться? Значит неудобство нужно устранять, благо модуль аналоговых вводов уже есть в наличии и используется для контроля давления в системе. Ой, с этими датчиками как раз была забавная ситуация. Всё-таки эксплуатация это дело живое и постоянно вылезают какие-то приколы. Вот и в один из дней после включения полива буквально «на глазах» в графическом интерфейсе давление падает в ноль! Выезд на объект показал, что у насоса полива на входе забился обратный клапан и он не смог создать давление в системе. Конечно через некоторое время отсутствие расхода воды из резервуара было бы обнаружено, но тут время детекции было буквально мгновенным.

Возвращаемся к проблематике – нужен датчик наполненности бочки, позволяющий с какой-то погрешностью (пусть ±10%) определять уровень воды в резервуаре. Да простят меня экономисты – взял не глядя «Датчик уровня воды SOWAKAM 0-500 м» (ссылка ^[4]). Интерфейс вполне стандартный для таких устройств –токовый выход 4-20mA, который проходя через резистивную нагрузку формирует пропорциональный измеряемой величине отклик. Было интересно попробовать такое устройство, причём приобрёл сразу с диапазоном в 3 метра, чтобы можно было использовать и для более глубокого резервуара. Датчик, кстати, может измерять и масло, и топливо, и другие жидкости. Это, как говориться, кому интересно.

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

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

Простота

Говорят, что фраза: «Самые простые решения – одновременно самые лучшие!» принадлежит Наполеону Бонапарту. Вот и в части автоматизации дачного хозяйства получены два подтверждения этой мысли.

Во-первых, как было приведено во второй статье, фитолампы в теплице включаются за некий период до восхода Солнца. При этом время восхода, как величина переменная, каждый день запрашивалась в Интернете. Но в комментариях к статье @garageman ^[5] предложил вместо опроса ресурсов Интернета использовать несколько функций Владимира Агафонкина, опубликованных в статье технической поддержки производителя контроллера (ссылка ^[6]). Сделано, работает. Плюсом получил независимость хотя бы такой маленькой функции от каналов связи и ощущение, что нахожусь в компании коллег, ратующих за простоту и надёжность. Большое спасибо 😊.

Вторым эпизодом для потенциального упрощения стали особенности эксплуатации беспроводного интерфейса ZigBee. Кстати, несмотря на личную симпатию и достаточно давнее знакомство с этим беспроводным интерфейсом, обратил внимание ^[7], что в целом удобство подключения компенсируется периодическими отказами. Вот такой график (см. рисунок ниже) в телеграмм-группу контроллер присылает каждый день в 10 утра. Небольшой голубой прямоугольник отражает факт включения обогревателя в теплице при условии снижения температуры (синяя линия) ниже порогового значения (черная горизонтальная линия). И вот, в один из вечеров датчик почему-то решил «залипнуть» и не присылать больше свои значения. Правда, на этом же графике можно заменить, что и обогреватель почему-то выключился через 30 мин. после события и похоже плавающий дефект не только в данных от датчика.

Справедливости ради отмечу, что дефект далеко не системный и скорее даже можно назвать его сбоем. К примеру, привожу выгрузку за 3 других дня, никаких проблем не просматривается, но звоночек неприятный. Наблюдение будет продолжено, количество беспроводных устройств увеличено для более полной статистики. Предлагаю поделиться в комментариях историями, когда беспроводка подвела – помехи, препятствия и пр…

Пока лично у меня предпочтения склоняются скорее к проводным каналам, поскольку питание к местам развёртывания датчиков или исполнительных элементов всё равно подводить, а уж 2 или 4 провода не так важно. И это банально проще.

Технологии

И вот тут мы подходим к самому необычному для дачи разделу. Речь пойдёт о DevOps, то есть о процессной части разработки и эксплуатации программного обеспечения. С особенностями версионирования, отладки и установки сталкивается любой разработчик и особенно остро эти проблемы встают, когда модернизация ПО проходит спорадически или в команде. Я пока единственный разработчик кода, но уже как минимум 2 раза проводил полную переустановку программного кода и один раз полностью менял конфигурацию периферийного оборудования.

Как говориться, «пока не началось», решил уделить вопросу более детальное внимание.

Скрытый текст

В бар забегает мужик, подбегает к стойке и говорит:
— Давай, наливай быстрее, пока не началось.
Бармен пожал плечами, наливает, мужик выпивает.
— Давай еще наливай, быстрее, быстрее, пока не началось.
Снова наливает, мужик выпивает.
— Давай, давай, не спи, наливай еще, пока не началось.
— Мужик, ты платить то собираешься?
— Ну вот, началось.

А там пошло-поехало и этому предшествовали несколько благоприятных событий:

• IT-гигант Яндекс в феврале 2025 года выпустил в эксплуатацию первую версию SourceCraft (ссылка ^[8]). Отечественная версия платформы для разработки, тестирования и сборки проектов позволяет не зависеть от внешней инфраструктуры, которая как мы поняли, в один момент может оказаться недоступной.

• Производитель контроллера WirenBoard включил в состав своего кода поддержку голосового помощника Алиса (ссылка ^[9]) с использованием интерфейса Node-RED и выпустил версию своего облака Wiren Board Cloud для развёртывания на серверах клиента (ссылка ^[10]).

Таким образом у меня, как у клиента, появляется возможность выполнять полный цикл удалённой разработки и эксплуатации кода контроллера, включая управление на естественном (русском) языке. Есть правда одно «НО». Всё это требует либо «белого» IP адреса с одной или обеих сторон, либо выделенного сервера в Интернет (с тем же «белым» IP). По какому пути и куда с этим идти решается прямо сейчас, но безусловно все перечисленные функции заслуживают особого внимания.

Первой задачей стала автоматизация рассылки новых версий с помощью worker от SourceCraft. К сожалению, в начале worker не работал на armhf архитектуре, поэтому было заведено issue, который команда SourceCraft быстро обработала и предоставила решение (ссылка ^[11]).

Оставалось только проверить экспериментальное решение на контроллере, прописав небольшую инструкцию для worker’а в .src.ci ^[12].yaml.

tasks:

  - name: my-test-task

    runs_on: self-hosted

    cubes:

      - name: my-test-cube

        script:

          - systemctl stop wb-rules

          - ./scripts/post-checkout.sh

          - cp -Ru rules/. /etc/wb-rules/

          - systemctl start wb-rules

Если пояснить код, который здесь приведён, то worker’у на исполнение ставится задача под названием my-test-task. Для задачи указывается на каких воркерах она должна использоваться и перечисляются команды, которые необходимо выполнить на контроллере. Перечень исполняемых на контроллере команд:

• остановить службу контроллера, выполняющую правила (собственно команды автоматизации);

• выполнить скрипт проверки временных меток для файлов из git (по умолчанию система указывает время, в которое эти файлы оказались в системе);

• копировать файлы, редактируемые позже, чем находящиеся на контроллере с идентичными именами;

• запустить службу выполнения правил.

Теперь, когда есть скрипт, расписание его исполнения можно доверить SourceCraft или другими словами – сделать первые шаги в сторону CI/CD на контроллерах WirenBoard.

Скрытый текст

CI/CD (Continuous Integration, Continuous Delivery; непрерывная интеграция и доставка) — это методология автоматизации тестирования и передачи новых модулей разрабатываемого проекта потребителям (как пользователям, так и другим участникам процесса, в т.ч. разработчикам).

Сейчас в процесс взаимодействия с контроллером добавляются функции:

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

• отслеживание работоспособности и сигнализация при сбоях.

К сожалению, интеграционные шаги выполняются не так быстро, как хотелось бы, поэтому их технологические особенности пока оставим за пределами статьи (заработает – расскажем).

Безопасность

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

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

Вариантом технического решения задачи стала реализация пяти профилей настройки, отличающихся друг от друга уровнем беспечности или паникёрства. То есть это так сказать грубая настройка – в каждом уровне функция безопасности настраивается независимо. К примеру, переход в режим «Паника» приводит к запиранию ворот, всех запорных устройств, включению освещения при движении в области видимости датчика и видеофиксации со всех точек, где размещены видеокамеры. Кроме предустановленных грубых профилей уже внутри него можно изменить любую функцию, если в конкретный момент она мешает. Например, выключить принудительно отправку сообщений в телеграмм.

Второй частью плана стало введение трех-стадийного интервала времени, который позволяет постепенно снижать уровень применяемых мер. К примеру, на участок забрёл гуляющий сам по себе котик, что-то там натворил и то ли ушёл, то ли затаился, то ли друзей позвал. В этом случае алгоритм последовательно выполняет три стадии с возможностью настройки действий в каждой из них в зависимости от профиля настройки (см. выше). ТО есть профиль берёт на себя задачи по объёму применяемых действий, а стадии, по их продолжительности.

Вернёмся к котику. Представим, что его появление в ночной период вызывает срабатывание датчика движения или объёма в варианте превышения порога. В этом случае выполняются действия для «красной» стадии профиля «Паника»:

• красная, 10 мин – отправляются уведомления в чат, повышается чувствительность датчиков движения (порог), включается свет и сигнализация, запираются замки, отсчёт таймера ведётся от последнего срабатывания;

• жёлтая, 5 мин – выключается сигнализация, чувствительность возвращается к номинальному значению;

• зелёная, 10 мин – выключается освещение вне зоны действия сработавших датчиков;

• таймеры завершились – всё возвращается к исходному состоянию.

Следует отметить, что как раз котики больше всего доставили неудобств в отладке сценария и поиску того самого порога, когда котиков мы ещё не видим, а человека уже не пропускаем. Но в целом по своему скромному мнению задачу решить удалось. Пока исполнительных элементов ещё не так много – всего лишь два датчика движения и две линии подачи освещения (внутри и снаружи), но главное скелет. Дальше дополнить однотипными элементами уже не так сложно.

Оперативность

Ключевые особенности архитектуры в любой сложной системе задают интерфейсы. Пришла пора обсудить их снова. Как я уже отмечал, рассматриваемая в вот уже третьей статье игрушка подключена по каналу LTE. Провайдер МТС, физическая SIM-карта, модем установлен производителем контроллера WBC-4G v.2, антенны внешние, сигнал от провайдера уверенный. Внешне всё хорошо, тесты в моменте проходили замечательно.

Но раз в 10-15 дней контроллер внезапно терял сигнал мобильной связи и модем переходил в состояние «нет подключения» и самостоятельно из этого режима уже не выходил. При этом возможность управлять объектом для меня полностью пропадала до конца недели (напомню, объект посещается только на выходных), что в моих условиях неприемлемо.

Сначала ставим заплатку – ей стала безусловная принудительная перезагрузка раз в сутки (в 2-3 часа ночи). Можно конечно ехидствовать, но помогло, сбои полностью прекратились. Дальше действуем как образцовый пользователь – заводим обращение в службу технической поддержки производителя (обращение ^[14]). Конечно с моим графиком детектирования отказов выявление проблемы заняло немало времени, но в конце концов мне порекомендовали заменить SIM-карту. Исходя из того, что проблема разрешилась периодической перезагрузкой кроме скепсиса совет ничего не вызвал. Как бы к реализации данной рекомендации я подходил без особой надежды.

Но поскольку страсть к экспериментам в крови – измерил скорость Интернета в точке установки ещё с одним сотовым оператором. Для моего оборудования, точки установки и пр. Мегафон показал в 5 (!) раз большую скорость, правда с учётом того, что примерно раза в 2 его 30 Гбайтный контракт выходит дороже. Упреждая вопрос про методику испытаний, скажу, что измерял скорость подключаясь по WiFi к контроллеру ноутбуком и уже через контроллер и его модем выходил в Интернет. Второй точкой был Яндекс со своим Интернетометром (ссылка ^[15]). Кстати, если кто-то считает, что операторы отличались уровнем сигнала или стабильностью прохождения пакетов – нет, эти параметры были приблизительно одинаковые настолько, насколько можно так заявлять о радиосигналах.

И проблема исчезла. Совсем. МТС был наказан переводом из состояния основного оператора в резервные, а Мегафон в свою очередь поднял флаг обеспечения объекта каналом связи. Как было в одном из наших советских фильмов: «Ошибки надо не признавать. Их надо смывать … кровью!», просто так заменой SIM-карты не обошлось. На случай возникновения каких-то проблем как я уже сказал в модеме теперь установлено 2 SIM карты, а в суточную диагностику добавлен счётчик доступности сети Интернет. Если периодически (раз в минуту) отправляемый запрос успешен, то минута считается с обеспечением подключения, если нет, то счётчик не прибавляется. Если превышен порог недоступности в 25%, то раз в сутки выполняется принудительная перезагрузка. Правда пока её не было …

 Выводы и планы

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

---

[1] ^[16] Стиль мультипликационный. Нарисуй комнату, в которой есть окно, горшок с цветком, диван с оператором, электронный блок “WB” в шкафу на стене. Промышленный контроллер “WB” должен быть главным объектом. Промышленный контроллер “WB” должен размещаться в настенном шкафу для электричества. На промышленном контроллере должна быть только одна надпись “WB”. Промышленный контроллер должен быть покрашен в цвет RGB=#5cb300. оператор должен сидеть на диване. оператор должен разговаривать с умной колонкой Яндекс станция МИДИ. Цвет RGB=#e1cc4f должен быть основным цветом фона. На корпусе колонки Яндекс станция МИДИ должна быть надпись “MIDI”. За окном должна быть вдалеке видна мультяшная теплица. Яндекс станция МИДИ должна стоять на подоконнике. У оператора в руках должен быть телефон.

[2] ^[17] В бар забегает мужик, подбегает к стойке и говорит:

— Давай, наливай быстрее, пока не началось.

Бармен пожал плечами, наливает, мужик выпивает.

— Давай еще наливай, быстрее, быстрее, пока не началось.

Снова наливает, мужик выпивает.

— Давай, давай, не спи, наливай еще, пока не началось.

— Мужик, ты платить то собираешься?

— Ну вот, начинается.

[3] ^[18] CI/CD (Continuous Integration, Continuous Delivery; непрерывная интеграция и доставка) — это методология автоматизации тестирования и передачи новых модулей разрабатываемого проекта потребителям (как пользователям, так и другим участникам процесса, в т.ч. разработчикам).