Цех узнаёт о сбое тогда, когда линия уже встала, бракованная партия уехала на упаковку, а мастер обходит участки и звонит по рации. Между моментом отклонения и реакцией ответственного проходят минуты и часы — и каждая из них стоит денег. n8n (open-source платформа автоматизации с self-hosted развёртыванием) закрывает этот разрыв: собирает события из MES, 1С и датчиков в единый поток и сам рассылает уведомления о сбоях и отклонениях нужным людям и системам.
Ниже — разбор того, что реально собирается на n8n в производственном контуре. Это не кейс KT.Team, а обзор публичных шаблонов и материалов сообщества n8n со ссылками на источники.
Что собирается на n8n: готовые шаблоны
В библиотеке шаблонов n8n есть workflow «IoT sensor monitoring with GPT-4o anomaly detection, MQTT & multi-channel alerts». Его логика разбирается публично (n8n.io):
- два источника событий — MQTT Trigger (датчики публикуют данные на брокер) и Schedule (пакетный опрос) — сливаются в общий конвейер;
- показания нормализуются (температура, влажность, давление, CO2) и дедуплицируются по SHA256-хешу, чтобы один и тот же замер не дёргал алерты повторно;
- узел проверки сравнивает значения с порогами (в шаблоне: температура −10…50 °C, влажность 20…90 %, CO2 400…2000 ppm) и присваивает уровень — `critical`, `warning` или `normal`;
- узел Switch (Route by Severity) маршрутизирует: `critical` уходит одновременно в Gmail и Slack-канал `#iot-critical`, `warning` — только в Slack `#iot-alerts`, `normal` не порождает уведомлений;
- все замеры пишутся в Google Sheets как историческая база.
Второй базовый шаблон — «Remote IoT sensor monitoring via MQTT and InfluxDB» (n8n.io). Здесь MQTT Trigger подписан на топик брокера Mosquitto, Code-узел приводит payload к JSON, а HTTP Request пишет временной ряд в InfluxDB. Это «сборочный» слой: накопление сырых событий в time-series базу, поверх которой строятся пороговые проверки и алерты.
Как это ложится на MES, 1С и датчики
Источники событий на производстве разнородны, и n8n берёт каждый своим протоколом:
- Датчики и контроллеры — через MQTT Trigger: узел подписывается на топик брокера и читает payload при каждой публикации. Это типовой канал для промышленного IoT и M2M-обмена (oneclickitsolution.com).
- MES / SCADA — через webhook: система POST-ит событие на URL n8n, который дальше обрабатывает и маршрутизирует его. Это рекомендуемый сообществом способ интеграции цеховых систем (oneclickitsolution.com).
- 1С и ERP — через HTTP-запросы к REST/OData-публикации или чтением промежуточной БД (PostgreSQL/MySQL-узлы), откуда n8n тянет счётчики брака, простоев и заказов.
Для производства важна архитектурная аккуратность: n8n не нужно встраивать внутрь MES или 1С и патчить их ядро. Он живёт рядом как отдельный сервис-оркестратор, общается через стандартные протоколы (MQTT, webhook, REST) и потому отчуждаем — его можно заменить или передать другой команде без переписывания учётной системы. Это снижает риск и стоимость сопровождения по сравнению с самописными интеграциями.
Маршрутизация и эскалация
Ценность не в том, чтобы «прислать сообщение», а в том, чтобы прислать нужному адресату с нужной срочностью. Узел Switch по уровню severity реализует это напрямую: критичное отклонение поднимает сразу два канала (например, почта руководителю смены + мессенджер дежурной бригаде), предупреждение — только рабочий чат, штатные значения молчат. В материалах сообщества описано расширение схемы AI-агентом, который оценивает показания относительно порогов, сам присваивает severity и выбирает маршрут эскалации (oneclickitsolution.com). Сверх алерта n8n тем же workflow заводит запись об инциденте в журнал или таблицу — фиксация для разбора и расчёта MTTR.
Бизнес-результат
Что получает производство, а не «что делает инструмент»:
- реакция за секунды вместо ручного обхода — практический разбор production-line сценария на n8n показывает время прохождения workflow порядка 10 секунд и сокращение времени реакции на простой примерно на 90 % (oneclickitsolution.com);
- меньше пропущенных отклонений — постоянный автоматический контроль вместо выборочного человеческого мониторинга;
- разбор по фактам — каждый инцидент уже записан в историческую базу (Google Sheets / InfluxDB / БД) с меткой времени и severity;
- никакого vendor lock-in — self-hosted open-source ядро и стандартные протоколы.
Важная оговорка по цифрам: «~10 секунд» и «−90 %» — это показатели конкретного публичного примера, а не гарантия. Фактический эффект зависит от качества порогов, латентности источников и дисциплины эскалации. Правильный подход — снять baseline текущего времени реакции, затем измерить его после внедрения.
Вывод по бизнес-процессу
Процесс «реакция на производственный инцидент» переразмечается так: событие (датчик/MES/1С) → сбор и нормализация в n8n → пороговая проверка и severity → маршрутизация по каналам с эскалацией → запись в журнал инцидентов. Ручной шаг «человек заметил и сообщил» убирается из критического пути и остаётся только там, где нужно принять решение, а не обнаружить проблему. Это переводит реагирование из реактивного обхода в управляемый, измеримый и отчуждаемый автоматический контур.
