Фермер включил полив. В системе появилась команда, затем подтверждение, что её приняли. Что теперь проверить, чтобы спокойно заняться другой работой?
В хозяйстве ответ обычно шире экрана. Есть ли подача воды. Дошла ли она до нужного места. Меняются ли условия так, как ждали. Поэтому в Fermozavr DIY мы учимся проверять результат действия. Начинается это с простого вопроса: какое наблюдение покажет, что все работает как надо?
Ниже один учебный пример — запуск полива. Дальше речь о том, что уже умеет программа, и о том, как устроена проверка.
Что видно в журнале после команды
В платформе уже есть цепочки. Они связывают входные данные, условия и действия. Для исполнительного устройства может быть сформирована команда. Сохранённый ход обработки разбирают в разделе «Журнал работы».
В этом примере мы открываем нужную запись. Смотрим, какое условие проверяла программа и какой шаг выбрала дальше. Потом переходим к сведениям о связанной команде. Так становится понятнее практический вопрос: почему система решила запустить действие?
В подробностях может встретиться ACK - это подтверждение команды. Журнал различает ответ программного клиента устройства и отметку из консоли. Человек видит, какой ответ получила программа.
Саму работу полива проверяют отдельными наблюдениями. Даже принятое подтверждение ещё не говорит, пошла ли вода. Поэтому следующий шаг — решить, чего именно ждём после запуска.
Реальный экран журнала с искусственными записями из изолированного demo. Штатное пояснение о реальном выполнении описывает назначение раздела; все показанные события и ACK здесь синтетические. Насос не запускался; ACK не подтверждает физический результат.
Выбрать признаки результата
Для полива можно смотреть два разных наблюдения. Первое: появился ожидаемый расход. Второе: спустя подходящее время изменились условия в нужном месте, например показание почвенного датчика.
У каждого признака своя часть задачи. Расход помогает проверить, движется ли вода. Реакция почвы позволяет смотреть дальше по пути полива. Если один признак есть, а другого нет, у пользователя уже есть повод для более точного осмотра.
Тогда можно проверить распределение воды, линию полива и место, где стоит датчик. По одному несовпадению программа ещё не выбирает причину за человека. Зато заданная проверка помогает понятно увидеть, где искать.
Срок ожидания тоже зависит от процесса. Расход и изменение в почве приходят с разной задержкой. Если дать им одно случайное окно, полезный результат может оказаться слишком ранним или слишком поздним. Сначала формулируют ожидание для каждого наблюдения. Потом подбирают пригодное измерение и время проверки.
Где попробовать это в Fermozavr DIY
Для такой подготовки есть отдельная страница учебной обратной связи. Её открывают из раздела учебных проверок и выбирают пример насоса.
Здесь задают условия для расхода и изменения среды, допустимое время ожидания и свежесть наблюдений. Готовых агрономических порогов программа не подставляет: числа зависят от выбранного комплекта и от задачи. Учебные значения нужны, чтобы проверить логику.
Дальше вводят искусственные наблюдения и запускают локальную проверку. В результате видны состояния отдельных условий. Если признаков несколько, их можно разбирать вместе и при этом видеть, какой именно этап получил подходящие данные.
Так удобно обсудить будущую работу ещё до монтажа. Может выясниться, что для нужной проверки вообще нет источника данных. Или ожидаемый эффект описан слишком неопределённо. Такие вопросы лучше закрыть, пока готовят комплект.
Страница считает учебный результат в браузере. Насос она не запускает и с действующей цепочкой управления не связана. Сценарий можно разбирать, не трогая оборудование.
Учебная проверка полива на искусственных данных: окно истекло, подходящих наблюдений нет. Расчёт выполняется в браузере и не управляет насосом.
Пройти три варианта одного запуска
Начнём с благополучного учебного случая. Для команды заданы пригодные наблюдения: расход появился в отведённое время, ожидаемое изменение среды тоже есть. После проверки видно, что введённые данные удовлетворяют условиям модели.
Теперь меняем только вторую часть. Расход есть, а подходящего наблюдения в почве нет. Расход остаётся отдельным признаком, подтверждённым в модели. Следующий этап требует внимания. В настоящем хозяйстве это повод проверить путь воды и само измерение, а не повторять запуск без разбора.
В третьем варианте нужные данные вообще перестали приходить. Тогда важно не смешать два разных положения: «условие не выполнено» и «его нечем проверить». На странице для пропущенных, устаревших и неверных значений предусмотрены разные состояния. Человек видит, на каком основании разбор остановился.
Так один пример заранее готовит несколько решений. Подходящие наблюдения есть — продолжать контроль. Есть несоответствие — проверять нужную часть системы. Данных нет — выяснять, что случилось с источником измерения. Пока это логика будущего сценария, а не уже включённая автоматическая политика оборудования.
Почему важно время наблюдения
Представим, что перед этим запуском по той же линии уже шла вода. В журнале есть хорошее показание расхода. Новой команде нужно новое основание. Иначе она получит подтверждение от предыдущей работы.
В учебной модели наблюдения относятся к конкретной команде и проверяются по времени. Значение, полученное до неё, не закрывает ожидание после запуска. Если смотрим, вырос ли показатель, нужна подходящая исходная точка для сравнения.
Для человека это обычная проверка. Чтобы сказать «после включения стало иначе», нужно знать, как было до включения, и убедиться, что следующее наблюдение относится к нужному времени. Такой порядок бережёт от совпадения, которое выглядит убедительно, но к этой команде не относится.
Дальше этот подход нужно связать с настоящими источниками данных. Потребуется знать, когда датчик измерил значение, когда оно пришло и насколько ему можно верить. Учебная модель заранее показывает, какие сведения должен передавать узел.
Что делать, если время вышло
У каждого ожидаемого результата должен быть понятный срок проверки. Если подходящих данных нет, хозяину важно узнать об этом вовремя и перейти к следующему действию.
На учебной странице можно задать окно ожидания и посмотреть результат после его окончания. Можно описать и предлагаемую реакцию на неудачу. Сейчас это часть расчёта: даже выбранное предложение остановки само оборудование не выключает.
Для настоящего полива решение остановить, повторить или позвать человека зависит от схемы и защит. Его нужно испытывать на конкретном комплекте. Самостоятельная реакция системы должна появляться вместе с проверенными пределами работы насоса и с возможностью вмешаться человеку.
Что работает сейчас и что проверяем дальше
В Fermozavr DIY есть команды, журнал работы и отдельная учебная проверка обратной связи. Она помогает описать признаки результата, разобрать наблюдения и увидеть, каких данных не хватает. Результат можно сохранить локальным файлом. Ввод на странице после перезагрузки не остаётся.
Учебный расчёт ещё не подключён к настоящим датчикам и к исполнительным цепочкам. В журнале программы тоже возможны пробелы. Поэтому выполненное условие в модели и запись о принятой команде не подтверждают, что полив физически прошёл.
Дальше нужно собрать пригодные источники измерений и проверить выбранный сценарий на стенде. «Мастер прошивок» уже помогает связать состав комплекта со схемой и BOM — перечнем деталей. Аппаратные профили ещё требуют испытаний. Для обратной связи особенно важно заранее предусмотреть те входы и датчики, на которые проверка опирается.
Что войдёт в локальный пакет, а что останется на сервере
Когда система участвует в работе оборудования, место выполнения становится частью дела. Что будет, если пропадёт интернет? Где останется история? Как хозяин узнает, что какое-то звено недоступно?
Как функции Fermozavr DIY распределятся между локальной системой и сервером, ещё не решено. Сейчас есть работающая серверная платформа, прежняя локальная станция и отдельные расчёты в браузере. Этот опыт помогает выбирать устройство системы. Возможности будущего пакета он ещё не определяет.
Предстоит описать, от чего зависит каждая функция: получение данных, проверка условия, команда, обратная связь, журнал и оповещение. Потом проверить их, когда связь пропадает. Только после этого можно уверенно сказать, что доступно в хозяйстве без внешнего соединения и для чего нужен сервер.
Linux-установщик проходит проверку качества. Windows и macOS — следующие этапы. Окончательный состав и доступность функций определим по результатам работы.
Для фермера весь путь должен сложиться в ясную последовательность. Увидел основание для действия. Понял решение программы. Проверил, что изменилось. Знает, куда обратиться, если пошло не так. Ради этого мы соединяем в Fermozavr DIY измерения, правила, команды и историю.
Если полив у вас уже работает, расскажите через страницу участия, как вы проверяете результат запуска. Какого показания хватает сразу, что смотрите позже и когда идёте к оборудованию? Такой пример поможет выбрать следующий сценарий для проверки на стенде.
