Как сделать датчики полезными, а не просто красивыми цифрами
После видео логично перейти к датчикам. Камера фиксирует то, что уже произошло, «на глаз». Датчик же часто срабатывает раньше: температура ползёт вверх, влажность уходит, воздух «задыхается» — а в зале визуально всё ещё «вроде нормально».
На многих объектах с датчиками повторяется одна и та же история: цифра на экране есть, а пользы от неё мало. График нарисован «для галочки», тревоги шумят по мелочам, а когда датчик перестаёт отправлять данные — система молчит, и оператор продолжает смотреть на вчерашнее значение как на актуальное.
В EAS сенсорный блок создавался не ради красивого слайда, а под реальную эксплуатацию: важно, что видит пост, что попадает в отчёт, и когда система честно говорит: «данные устарели».
Что должно быть у нормального сенсорного контура
Минимум, без которого датчики превращаются в декор:
понятный статус — норма, предупреждение, критично;
привязка к месту на схеме (см. статью 2 — те же метки на плане);
быстрый переход от проблемы к конкретному датчику и его истории;
отчёт за период — не только «сейчас», но и «как шло за смену / неделю»;
отдельный контроль «датчик перестал обновляться» — не путать с «всё спокойно».
Без этого — просто красивые цифры без решений.
«Молчащий» датчик и состояние sensor_stale
В мониторинге EAS есть отдельный тип проблемы — sensor_stale: показания не обновлялись дольше допустимого.
На практике датчик может:
зависнуть прошивкой;
потерять связь с хабом;
отправлять данные редко.
Но система должна это знать, а не показывать старую цифру как свежую.
Пороги по умолчанию настраиваются (предупреждение — около 15 минут, критично — около часа). Смысл один: тишина на проводе не должна выглядеть как «всё в порядке».
На «Схеме (онлайн)» такие датчики автоматически поднимаются в ленту проблем рядом с камерами и СКУД. Оператору не нужно помнить, когда в последний раз мигала температура в подвале.
Мониторинг: график из реальных точек, а не «нарисованный»
Вкладка «Мониторинг датчиков» (группа «Датчики» в боковом меню) — это рабочее место, а не витрина.
Вы выбираете датчик из дерева (подписи человекочитаемые, не только entity_id), период 1 ч / 24 ч / 7 д / 30 д, и смотрите «Историю значения». Под графиком — служебная строка вроде «Точек: N»:
если N большое — кривая построена из накопленной телеметрии;
если ноль — честно пусто, без фальшивой линии.
С 2026 года графики в админке приведены к единому стилю (Chart.js, линии без заливки под кривой — так проще читать несколько рядов, цветовая тема из CSS). На скриншоте это мелочь, но при работе в смену глаза устают меньше.
Мониторинг датчиков: история температуры, счётчик точек телеметрии
Как читать график без инженерного образования
Достаточно простых правил:
линия растёт — значение растёт;
падает — значение падает;
резкий скачок — было нетипичное изменение (открыли дверь, включили обогрев, сбой);
долгая полка без новых точек — возможно, датчик не отправляет данные (см. sensor_stale).
Этого достаточно, чтобы оператор понял: «спокойно» или «надо проверить». Без споров «мне кажется, было жарко».
Как читать график без инженерного образования
Достаточно простых правил:
линия растёт — значение растёт;
падает — значение падает;
резкий скачок — было нетипичное изменение (открыли дверь, включили обогрев, сбой);
долгая полка без новых точек — возможно, датчик не отправляет данные (см. sensor_stale).
Этого достаточно, чтобы оператор понял: «спокойно» или «надо проверить». Без споров «мне кажется, было жарко».
Три кривые на одном полотне
Отдельная картинка — не скриншот админки, а выгрузка тех же трёх температур из telemetry_samples (склад А, офис Б, узел TVOC). Хорошо видно, что линии шумные и живые — как в реальной эксплуатации.
Температура: три кривые из telemetry_samples
Отчёты: график, сводка, выгрузка
Вкладка «Отчёты датчиков» — для смены, руководителя и расследования.
Вы выбираете несколько датчиков, тип показаний («Температура» и др.), период, режим «График», нажимаете «Построить». Появляются легенда, сводная таблица и линии по времени (с агрегацией по корзинам, если точек много — чтобы график не превращался в кашу). При наведении на линию показываются значения в точке. При необходимости — выгрузка в CSV / XLSX с тем же набором данных.
Отчёты по датчикам: три температуры за неделю после нажатия «Построить»
(Три температуры: склад А, офис Б, узел TVOC, период около 7 суток. Если период пуст или выбраны «не те» метрики — интерфейс явно пишет «нет данных», а не рисует пустышку.)
Формат отчёта сделан так, чтобы его можно было переслать без перевода с айтишного: понятно, какой интервал, какие датчики и что было по значениям.
Пример из жизни
Утром в зоне хранения на экране +18 °C — «норма». Ночью датчик перестал обновляться, а система без контроля свежести не подняла тревогу. К обеду проблема уже «на полу», а в журнале нет ни одной точки за ночь.
С sensor_stale и историей в мониторинге сценарий другой: тишина ловится до того, как склад превращается в новость.
Короткий итог
Хороший сенсорный контур — это не только «выше порога — пищать». Это:
живые данные с понятным возрастом;
график, на который можно опереться в споре;
отчёт, который поймёт не только интегратор;
молчание датчика как отдельная проблема, не хуже перегрева.
Тогда датчики работают раньше камеры, а не висят пятой вкладкой «для галочки».
В двух словах
Датчики полезны, когда система объясняет смысл показаний, строит графики из реальной телеметрии и вовремя замечает устаревшие данные.
