Приветствую, коллеги. Незаметно подобралась осень и можно рассказать о очередных шагах в области автоматизации дачного хозяйства на любительском уровне. Напомню, что это уже третья статья на данную тему. Предыдущие размещаются вот тут – первая, вторая.
В этом номере я расскажу про небольшие работы над ошибками (когда что-то пришлось переделать), новые шаги в области автоматизации, дополнительно установленное оборудование, технологические нюансы и дальнейшие планы. А они растут в прямой аналогии знаменитому изречению Сократа: «Чем больше я знаю, тем больше я понимаю, что ничего не знаю». В моей трактовке звучит как: «Чем больше я делаю, тем больше хочу сделать». Также нужно отметить, что некоторые изображения (в мультипликационном стиле) выполнены с помощью сервиса GigaChat (2023 год) и «Шедеврум».
Точность
Как и анонсировал, начинаю с работы над ошибками. Первое, что достаточно быстро стало неудобным в эксплуатации это ограниченность состояний резервуара с водой (бочки): пустая, полная и ни то ни другое. Поскольку наполнение бочки процесс достаточно долгий и визуальный контроль отсутствует нужно было гадать, а сколько же ещё она будет наполняться? Значит неудобство нужно устранять, благо модуль аналоговых вводов уже есть в наличии и используется для контроля давления в системе. Ой, с этими датчиками как раз была забавная ситуация. Всё-таки эксплуатация это дело живое и постоянно вылезают какие-то приколы. Вот и в один из дней после включения полива буквально «на глазах» в графическом интерфейсе давление падает в ноль! Выезд на объект показал, что у насоса полива на входе забился обратный клапан и он не смог создать давление в системе. Конечно через некоторое время отсутствие расхода воды из резервуара было бы обнаружено, но тут время детекции было буквально мгновенным.
Возвращаемся к проблематике – нужен датчик наполненности бочки, позволяющий с какой-то погрешностью (пусть ±10%) определять уровень воды в резервуаре. Да простят меня экономисты – взял не глядя «Датчик уровня воды SOWAKAM 0-500 м» (ссылка). Интерфейс вполне стандартный для таких устройств –токовый выход 4-20mA, который проходя через резистивную нагрузку формирует пропорциональный измеряемой величине отклик. Было интересно попробовать такое устройство, причём приобрёл сразу с диапазоном в 3 метра, чтобы можно было использовать и для более глубокого резервуара. Датчик, кстати, может измерять и масло, и топливо, и другие жидкости. Это, как говориться, кому интересно.
Подождал, установил, подключил, отъюстировал – все шаги были прозрачными и логичными. На всякий случай пока оставил старую систему полный\пустой для отсечки наполнения и опустошения. Но сам процесс стал гораздо прозрачнее. В перспективе можно подумать о измерении скорости расхода воды, но пока не понятно, зачем. Зато теперь я могу примерно оценивать объём воды при поливе конкретной грядки и можно задавать отсечку полива не только по времени, но и в литрах.
Вы просто посмотрите, какая красота. Насколько чётко выдерживается уклон линии и соответственно считываются значения текущего состояния резервуара. Пришлось немного поработать над отображением этих данных, но результат оказался достоин своих усилий.
Простота
Говорят, что фраза: «Самые простые решения - одновременно самые лучшие!» принадлежит Наполеону Бонапарту. Вот и в части автоматизации дачного хозяйства получены два подтверждения этой мысли.
Во-первых, как было приведено во второй статье, фитолампы в теплице включаются за некий период до восхода Солнца. При этом время восхода, как величина переменная, каждый день запрашивалась в Интернете. Но в комментариях к статье @garageman предложил вместо опроса ресурсов Интернета использовать несколько функций Владимира Агафонкина, опубликованных в статье технической поддержки производителя контроллера (ссылка). Сделано, работает. Плюсом получил независимость хотя бы такой маленькой функции от каналов связи и ощущение, что нахожусь в компании коллег, ратующих за простоту и надёжность. Большое спасибо 😊.
Вторым эпизодом для потенциального упрощения стали особенности эксплуатации беспроводного интерфейса ZigBee. Кстати, несмотря на личную симпатию и достаточно давнее знакомство с этим беспроводным интерфейсом, обратил внимание, что в целом удобство подключения компенсируется периодическими отказами. Вот такой график (см. рисунок ниже) в телеграмм-группу контроллер присылает каждый день в 10 утра. Небольшой голубой прямоугольник отражает факт включения обогревателя в теплице при условии снижения температуры (синяя линия) ниже порогового значения (черная горизонтальная линия). И вот, в один из вечеров датчик почему-то решил «залипнуть» и не присылать больше свои значения. Правда, на этом же графике можно заменить, что и обогреватель почему-то выключился через 30 мин. после события и похоже плавающий дефект не только в данных от датчика.
Справедливости ради отмечу, что дефект далеко не системный и скорее даже можно назвать его сбоем. К примеру, привожу выгрузку за 3 других дня, никаких проблем не просматривается, но звоночек неприятный. Наблюдение будет продолжено, количество беспроводных устройств увеличено для более полной статистики. Предлагаю поделиться в комментариях историями, когда беспроводка подвела – помехи, препятствия и пр…
Пока лично у меня предпочтения склоняются скорее к проводным каналам, поскольку питание к местам развёртывания датчиков или исполнительных элементов всё равно подводить, а уж 2 или 4 провода не так важно. И это банально проще.
Технологии
И вот тут мы подходим к самому необычному для дачи разделу. Речь пойдёт о DevOps, то есть о процессной части разработки и эксплуатации программного обеспечения. С особенностями версионирования, отладки и установки сталкивается любой разработчик и особенно остро эти проблемы встают, когда модернизация ПО проходит спорадически или в команде. Я пока единственный разработчик кода, но уже как минимум 2 раза проводил полную переустановку программного кода и один раз полностью менял конфигурацию периферийного оборудования.
Как говориться, «пока не началось», решил уделить вопросу более детальное внимание.
Скрытый текст
В бар забегает мужик, подбегает к стойке и говорит:
— Давай, наливай быстрее, пока не началось.
Бармен пожал плечами, наливает, мужик выпивает.
— Давай еще наливай, быстрее, быстрее, пока не началось.
Снова наливает, мужик выпивает.
— Давай, давай, не спи, наливай еще, пока не началось.
— Мужик, ты платить то собираешься?
— Ну вот, началось.
А там пошло-поехало и этому предшествовали несколько благоприятных событий:
IT-гигант Яндекс в феврале 2025 года выпустил в эксплуатацию первую версию SourceCraft (ссылка). Отечественная версия платформы для разработки, тестирования и сборки проектов позволяет не зависеть от внешней инфраструктуры, которая как мы поняли, в один момент может оказаться недоступной.
Производитель контроллера WirenBoard включил в состав своего кода поддержку голосового помощника Алиса (ссылка) с использованием интерфейса Node-RED и выпустил версию своего облака Wiren Board Cloud для развёртывания на серверах клиента (ссылка).
Таким образом у меня, как у клиента, появляется возможность выполнять полный цикл удалённой разработки и эксплуатации кода контроллера, включая управление на естественном (русском) языке. Есть правда одно «НО». Всё это требует либо «белого» IP адреса с одной или обеих сторон, либо выделенного сервера в Интернет (с тем же «белым» IP). По какому пути и куда с этим идти решается прямо сейчас, но безусловно все перечисленные функции заслуживают особого внимания.
Первой задачей стала автоматизация рассылки новых версий с помощью worker от SourceCraft. К сожалению, в начале worker не работал на armhf архитектуре, поэтому было заведено issue, который команда SourceCraft быстро обработала и предоставила решение (ссылка).
Оставалось только проверить экспериментальное решение на контроллере, прописав небольшую инструкцию для worker’а в .src.ci.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 часа ночи). Можно конечно ехидствовать, но помогло, сбои полностью прекратились. Дальше действуем как образцовый пользователь – заводим обращение в службу технической поддержки производителя (обращение). Конечно с моим графиком детектирования отказов выявление проблемы заняло немало времени, но в конце концов мне порекомендовали заменить SIM-карту. Исходя из того, что проблема разрешилась периодической перезагрузкой кроме скепсиса совет ничего не вызвал. Как бы к реализации данной рекомендации я подходил без особой надежды.
Но поскольку страсть к экспериментам в крови – измерил скорость Интернета в точке установки ещё с одним сотовым оператором. Для моего оборудования, точки установки и пр. Мегафон показал в 5 (!) раз большую скорость, правда с учётом того, что примерно раза в 2 его 30 Гбайтный контракт выходит дороже. Упреждая вопрос про методику испытаний, скажу, что измерял скорость подключаясь по WiFi к контроллеру ноутбуком и уже через контроллер и его модем выходил в Интернет. Второй точкой был Яндекс со своим Интернетометром (ссылка). Кстати, если кто-то считает, что операторы отличались уровнем сигнала или стабильностью прохождения пакетов – нет, эти параметры были приблизительно одинаковые настолько, насколько можно так заявлять о радиосигналах.
И проблема исчезла. Совсем. МТС был наказан переводом из состояния основного оператора в резервные, а Мегафон в свою очередь поднял флаг обеспечения объекта каналом связи. Как было в одном из наших советских фильмов: «Ошибки надо не признавать. Их надо смывать … кровью!», просто так заменой SIM-карты не обошлось. На случай возникновения каких-то проблем как я уже сказал в модеме теперь установлено 2 SIM карты, а в суточную диагностику добавлен счётчик доступности сети Интернет. Если периодически (раз в минуту) отправляемый запрос успешен, то минута считается с обеспечением подключения, если нет, то счётчик не прибавляется. Если превышен порог недоступности в 25%, то раз в сутки выполняется принудительная перезагрузка. Правда пока её не было …
Выводы и планы
Вот и закончились темы для очередной статьи – всё, что успел сделать из крупного за лето рассказано. Хотя по-прежнему ворота открываются только с портативного радиопульта, калитка пока запирается вручную, а горячую воду я добываю с помощью кипятильника. Но энтузиазм не угас и очень надеюсь, что в не такое далёкое время получится осуществить ещё какие-нибудь интересные сценарии.