Мониторинг загрузки станков на основе Zigbee: открытое решение без лишних проводов

Кейс: машиностроительный цех с десятками станков, где загрузка оборудования долгие годы оценивалась «на глаз». Мастер обходил производство и делал заметки в бумажном журнале, но точных данных о том, сколько времени станок реально резал металл, а сколько работал вхолостую, не было.

В статье рассматривается практическое решение на базе беспроводной Zigbee-сети — недорогой и простой мониторинг без прокладки кабелей, построенный на полностью открытом программном стеке.

Проблема традиционных подходов

Главное возражение производственников: «В цехе сильные помехи для Wi-Fi, придётся тянуть слаботочные линии, возможно, останавливать оборудование и привлекать электриков для питания роутеров». Это означает затраты времени и денег еще до первого измерения. Плюс классическая ситуация с проприетарными SCADA-системами: оборудование от одного вендора, ПО от другого, и они работают только в связке, а стоимость обновлений сравнима с начальной интеграцией.

Аппаратная часть: промышленный контроллер и токовые датчики

На каждый станок устанавливается компактный промышленный компьютер на базе NapiLinux (дистрибутив на основе Buildroot), монтируемый на DIN-рейку. В устройство встроен трансформатор тока (CT), который надевается на питающий кабель станка без разрыва цепи. Монтаж одной точки занимает 5–10 минут.

Измеряемые параметры каждого узла:

• ток в диапазоне 0–100 А;
• активная мощность (Вт);
• напряжение (В);
• частота сети (Гц);
• накопленное энергопотребление (кВт·ч).

Частота опроса - 1 Гц, что избыточно для простого определения факта работы станка. Порог срабатывания «вкл/выкл» настраивается индивидуально для каждого станка однократно и в дальнейшем не требует корректировки.

Питание устройства - 220 В от встроенного источника. Кабели передачи данных отсутствуют полностью.

Внутри контроллера для связи вычислительного модуля с датчиком используется Modbus RTU. Пакет modlink опрашивает Modbus-регистры по расписанию и передаёт значения в Zigbee-передатчик через последовательный интерфейс. Прошивка Zigbee-модуля (PTVO, ptvo.info) преобразует произвольные числовые данные в стандартные Zigbee-кластеры ZCL, которые понимает любой координатор Zigbee2MQTT.

Почему Zigbee, а не Wi-Fi или LoRa?

Этот вопрос возникает у большинства читателей.

Wi-Fi 6 выглядит очевидным кандидатом, но промышленный цех - это металлические корпуса, экранирующие перегородки и множественные отражения сигнала. На частотах 2.4 ГГц и 5 ГГц сеть деградирует и работает нестабильно. К тому же Wi-Fi требует управления IP-адресами, аутентификации и дополнительной нагрузки на корпоративную сеть. Для 30-50 датчиков это ещё управляемо, но в перспективе становится проблемой для обслуживания. Дополнительный фактор — возможные требования региональных служб (например, МЧС) отключать Wi-Fi на производственных объектах на длительное время. В некоторых отраслях установка промышленного Wi-Fi требует специального разрешения службы безопасности.

LoRa/LoRaWAN на частоте 868 МГц хорош для датчиков с редкими передачами (раз в минуту и реже) и большими расстояниями. Но частота 1 Гц при десятках устройств создаёт конкуренцию за эфир, а избыточная дальность (до нескольких километров) не нужна в пределах одного цеха.

Zigbee — протокол для энергоэффективных сетей с низкой скоростью передачи данных, широко применяемый в IoT и системах «Умный дом». Он медленный, но надежный.

Ключевые преимущества Zigbee в этом проекте:

• Mesh-топология — каждый узел (маршрутизатор) ретранслирует трафик соседей. Добавление нового датчика усиливает покрытие для всех остальных.
• Энергоэффективность — хотя в данном случае питание стационарное, важна предсказуемость задержек.
• Зрелая экосистема — Zigbee2MQTT поддерживает сотни устройств, обширная документация и активное сообщество.

Zigbee использует тот же диапазон 2.4 ГГц, что и Wi-Fi, но меньшая мощность передатчика и ячеистая сеть компенсируют провалы покрытия. В цехе площадью ~2000 м² сеть из 15-20 устройств работает без дополнительных ретрансляторов, но при необходимости любой маршрутизирующий узел автоматически становится им.

Программный стек: от MQTT до Grafana

Ключевое архитектурное решение — полное отсутствие проприетарного ПО. Весь стек работает в Docker-контейнерах на локальном сервере (или Edge-компьютере в цеху).

Слои системы:

Путь данных:

Станок → FCU3308PZ → Zigbee mesh → координатор Napi-C → Zigbee2MQTT → Mosquitto → Telegraf → InfluxDB → Grafana

Zigbee2MQTT + Mosquitto

Zigbee2MQTT — открытый мост между Zigbee и MQTT. Координатор подключается через USB или UART, а Zigbee2MQTT публикует данные в топики вида:

text
zigbee2mqtt/станок-01/current → 12.4
zigbee2mqtt/станок-01/power → 2720

Каждое устройство отображается в веб-интерфейсе Zigbee2MQTT с указанием статуса, качества сигнала (LQI) и времени последнего обновления - это важно для диагностики.

Mosquitto — лёгкий MQTT-брокер с минимальной конфигурацией (порт 1883, опционально TLS).

Telegraf

Подписывается на MQTT-топики через плагин inputs.mqtt_consumer и передаёт данные в InfluxDB. Если база временно недоступна, буферизует данные и отправляет после восстановления.

InfluxDB 2.x

Оптимальное хранилище для временных рядов. Поддерживает политики хранения (автоматическое удаление старых данных) и агрегацию через Flux-запросы.

Пример запроса для расчета машинного времени за смену (порог тока 5 А):

flux
from(bucket: "machines")
|> range(start: -8h)
|> filter(fn: (r) => r._measurement == "mqtt_consumer" and r._field == "current")
|> filter(fn: (r) => r.topic =~ /станок-01/)
|> map(fn: (r) => ({ r with value: if r.value > 5.0 then 1.0 else 0.0 }))
|> aggregateWindow(every: 1m, fn: mean)
|> sum()

Результат - количество минут работы за 8 часов.

Grafana

Финальный слой визуализации с типовыми панелями:

• Stat-панель — текущий статус станка с цветовой индикацией.
• Time series — графики тока или мощности за смену.
• Bar gauge — загрузка в процентах по всем станкам.
• Heatmap — тепловая карта загрузки по дням и часам.

Алерты настраиваются через Alerting → Alert rules (например, отклонение тока от среднего на 20%). Уведомления — в Telegram, Email или webhook.

Стек технологий и лицензии

Все компоненты, кроме прошивки самого устройства, имеют открытый исходный код. Данные локальны —  нет облачной зависимости и абонентской платы.

Результаты внедрения

Сразу после запуска система показала:

1. Три из двенадцати станков не выключались после смены — на графике был виден ток холостого хода. Операторы просто оставляли оборудование включенным. Суммарный перерасход электроэнергии оказался значительным.
2. Реальная загрузка отличалась от плановой — пик нагрузки приходился на первые три часа смены, затем шел спад. Это позволило перестроить подачу заготовок и распределение операторов, увеличив фактическое машинное время без закупки нового оборудования.
3. Система предотвратила аварию — на одном из станков аномально вырос ток при неизменной нагрузке. Grafana отправила алерт, механики обнаружили изношенный подшипник. Плановая замена заняла 2 часа вместо длительного аварийного простоя.

Масштабирование и расширение

Zigbee — сеть легко масштабируется: новый датчик автоматически встраивается в mesh-топологию, конфигурация Zigbee2MQTT обновляется без перезапуска.

FCU3308PZ поддерживает Modbus RTU/TCP, что позволяет подключать любые стандартные датчики — давления, температуры, вибрации, расхода охлаждающей жидкости. Все данные попадают в общую систему.

Для интеграции с ERP или MES используются MQTT-топики, доступные любому сервису в сети (Node-RED, Python-скрипты, микросервисы).

Практические нюансы при внедрении

• Радиопомехи — промышленные частотные преобразователи, сварочное оборудование и двигатели создают помехи на 2.4 ГГц. Металлический корпус FCU3308PZ даёт экранирование, а mesh компенсирует потери пакетов. При стабильно низком LQI рекомендуется добавить промежуточный маршрутизирующий узел.
• Синхронизация времени — обязательное использование NTP на координаторе и сервере для корректности временных рядов.
• Порог срабатывания — ток холостого хода сильно различается у станков. Порог «работает/не работает» калибруется для каждого типа оборудования индивидуально (однократная настройка).
• Хранение данных — при частоте 1 Гц и 20 датчиках получается 20 точек/сек (1.7 млн/сутки). InfluxDB легко справляется, но рекомендуется настроить политики хранения: raw-данные (секундные) — неделя, агрегированные (минутные) — год, часовые — бессрочно.

Выводы: почему решение работоспособно на других предприятиях

Система решает три ключевые задачи:

• Разворачивается без кабельных работ.
• Не привязывает к конкретному вендору.
• Стоимость принципиально ниже проприетарных SCADA-решений.

Данные остаются на предприятии, стек поддерживается инженером, знакомым с Linux и Docker. Mesh-топология Zigbee обеспечивает отказоустойчивость - потеря одного узла не обрывает остальные. Открытый протокол MQTT на выходе координатора позволяет интегрировать любые downstream-системы.

Ключевые преимущества:

• Vendor-unlock — все компоненты (кроме прошивки) с открытым исходным кодом.
• Расширяемость — через Modbus подключаются любые дополнительные датчики.
• Локальность данных — хранение на сервере предприятия, без облаков и подписок.
• Масштабируемость — добавление новых станков без остановки системы.

FCU3308PZ производится в России, PTVO — прошивка для Zigbee, остальное — стандартные open source проекты.