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