Типичная история при работе с промышленными датчиками выглядит примерно так. Есть RS485- датчик, нашли документацию с картой регистров. Написали Python-скрипт, который раз в 10 секунд опрашивает Modbus, парсит регистры и пишет строчку в CSV. Через неделю скрипт падает — оказывается, что порт занят другим процессом, или systemd не поднял его после перезагрузки, или датчик не ответил три раза подряд и скрипт завис в ожидании. Чиним, причесываем, добавляем watchdog. Потом понимаем, что CSV — плохая идея и надо куда-то писать данные нормально. Этот путь знаком многим в промышленной инженерии, но есть и другой путь. 

Суть идеи: Telegraf умеет опрашивать Modbus-устройства напрямую — и сразу писать временные ряды в InfluxDB. Никакого промежуточного кода. Grafana строит графики поверх InfluxDB. Весь стек открытый, работает локально, не требует интернета.

ОГЛАВЛЕНИЕ СТАТЬИ:

• Про работу стека

• Как выглядит «делай раз, делай два» при физическом подключении

  • Шаг 0. Убедиться, что датчик вообще отвечает

  • Шаг 1. Конфиг Telegraf — Modbus TCP

  • Шаг 2. Конфиг для Modbus RTU (датчик напрямую по RS485)

  • Шаг 3. Тестовый запуск до перезапуска службы

  • Шаг 4. Grafana — дашборд

• А если несколько датчиков на одной шине

• Что делать с датчиком без документации

• Графический интерфейс NapiConfig — то же самое без консоли

• Выводы и ссылки

Про инструментарий:

• Telegraf — это агент сбора метрик от компании InfluxData. Программа-демон, которая работает в фоне на Linux-хосте, по расписанию читает данные из разных источников и пишет их куда скажешь — в данном случае в InfluxDB. Один из плагинов называется inputs.modbus — он умеет опрашивать Modbus-устройства по TCP или RS-485 напрямую.

• Grafana — это open-source платформа для аналитики, мониторинга и визуализации данных. Она собирает информацию из разных источников (базы данных, облачные сервисы) и отображает в виде графиков и дашбордов.

Дальше — конкретный пример с датчиком DL-303 (температура, влажность, CO, CO2). В качестве железа — компактный ARM-сборщик NAPI-C на RK3308 с предустановленной ОС NapiLinux, там Telegraf и InfluxDB 2.x есть из коробки. Все команды и конфиги работают на любом Linux-хосте с тем же стеком.

Про работу стека

Рассмотрим комплектность такого решения:
Железо:

• Любой Linux-сборщик с портом RS485 и Ethernet. В примере — NAPI-C (RK3308), компактный ARM-компьютер с NapiLinux, где Telegraf и InfluxDB 2.x предустановлены. На любом другом Linux-хосте все команды те же самые.

• Датчик с интерфейсом Modbus RTU (RS485) или Modbus TCP.

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

• Telegraf >= 1.20 (плагин inputs.modbus)

•  InfluxDB 2.x

• Grafana (любая свежая версия)

Для более общего случая, когда ваша ОС не NapiLinux (о ней ниже еще есть раздел) — установите стек вручную или через Docker. Compose-файл с тремя сервисами (telegraf, influxdb, grafana) — это условные 10 минут работы для опытного админа.

Как выглядит “делай раз, делай два” при физическом подключении

Датчик DL-303 подключается по RS-485 двумя проводами к соответствующим клеммам сборщика. Полярность важна — при перепутанных проводах датчик не ответит. На самом датчике через встроенный дисплей выставляются Modbus-адрес (по умолчанию 1), скорость порта (по умолчанию 9600) и параметры 8N1. Запишите эти значения — они понадобятся в конфиге.

На шину RS-485 можно подключить до 32 устройств без дополнительного оборудования. Каждому датчику — уникальный адрес (slave_id). Telegraf опрашивает их последовательно.

Шаг 0. Убедиться, что датчик вообще отвечает

Прежде чем трогать Telegraf, стоит опросить датчик вручную. Для этого подходит modpoll. Если на сборщике уже запущен шлюз mbusd:

modpoll -m tcp -0 -a 1 -r 0 -c 10 127.0.0.1

Флаги здесь важны. -m tcp — транспорт Modbus TCP. -0 включает PDU-адресацию, то есть нумерацию регистров с нуля. -a 1 — Modbus-адрес датчика. -r 0 -c 10 — читать 10 регистров начиная с нулевого.

При успешном ответе вывод будет примерно таким:

root@napi-rk3308b-s:~# modpoll -m tcp -0 -a 1 -r 0 -c 10 127.0.0.1
modpoll 3.11 - FieldTalk(tm) Modbus(R) Master Simulator
 
Protocol configuration: MODBUS/TCP, FC3
Slave configuration...: address = 1, start reference = 0 (PDU), count = 10
 
-- Polling slave...
[0]: 0
[1]: 815
[2]: 3881
[3]: 2639
[4]: 7950
[5]: 1124
[6]: 5223
[7]: 0
[8]: 0
[9]: 0

По документации на DL-303 (или прямо по дисплею датчика — у него есть встроенный экран) расшифровываем регистры:

Значение 2639 в регистре 3 — это 263.9, то есть 26.39 C при scale=0.1. Регистр 4 в этой документации не используется, регистр 5 — точка росы.

Если modpoll вернул данные — датчик отвечает. Если нет — проблема в физике (провода A/B, полярность, терминирование) или в адресе. Разбираемся там, потом идем к Telegraf.

Шаг 1. Конфиг Telegraf — Modbus TCP

Создаем файл /etc/telegraf/telegraf.d/dl303.conf. На NapiLinux шаблон можно загрузить через веб-интерфейс NapiConfig — раздел «Датчики» -> «Управление датчиками» -> «Загрузить шаблон». На любом другом хосте это просто текстовый файл. 

Полный конфиг с секцией output:

## DL-303 (CO, CO2, температура, влажность) — Modbus TCP

[[inputs.modbus]]

  name = "DL-303"

  slave_id = 1

  timeout  = "1s"

  # mbusd слушает на 127.0.0.1:502

  controller = "tcp://127.0.0.1:502"

  input_registers = [

{ measurement="DL-303", name="CO",   byte_order="AB", data_type="UINT16", scale=1.0, address=[0] },

{ measurement="DL-303", name="CO2",  byte_order="AB", data_type="UINT16", scale=1.0, address=[1] },

{ measurement="DL-303", name="Humidity", byte_order="AB", data_type="UINT16", scale=0.1, address=[2] },

{ measurement="DL-303", name="Temp", byte_order="AB", data_type="UINT16", scale=0.1, address=[3] },

{ measurement="DL-303", name="DewPoint", byte_order="AB", data_type="UINT16", scale=0.1, address=[5] },

  ]

[[outputs.influxdb_v2]]

  urls     = ["http://127.0.0.1:8086"]

  token    = "ВАШ_ТОКЕН"

  organization = "myorg"

  bucket   = "sensors"

Пройдемся по полям, которые вызывают вопросы чаще всего.

• byte_order = "AB"  — Порядок байт big-endian. Стандарт для большинства Modbus-устройств. Если значения выглядят бессмысленно — попробуйте "BA". Правильный порядок всегда есть в паспорте датчика.

• data_type = "UINT16"  — Беззнаковое 16-битное целое. DL-303 отдает данные именно так. Для датчиков с отрицательными значениями нужен INT16. Некоторые устройства отдают float — тогда FLOAT32 или FLOAT32-IEEE, и address принимает два регистра: address = [3, 4].

• scale  — Множитель, применяется к сырому значению. Для Humidity и Temp ставим 0.1, потому что датчик умножает значение на 10 перед записью в регистр.

• address = [N]  — PDU-адрес регистра, считается с нуля. Если документация использует нотацию 40001, 40002 (Modbus-нотация) — вычтите 1 и уберите ведущую цифру 4.

Шаг 2. Конфиг для Modbus RTU (датчик напрямую по RS485)

Если шлюза RTU -> TCP нет и датчик подключен физически к порту RS-485 сборщика, меняем секцию подключения:

[[inputs.modbus]]
 
  name 	= "DL-303"
  slave_id = 1
  timeout  = "1s"
 
  controller    	= "file:///dev/ttyS3"   # RS485-порт на NAPI-C
  transmission_mode = "RTU"
  baud_rate     	= 9600
  data_bits         = 8
  parity        	= "N"
  stop_bits     	= 1
 
  # input_registers — те же, что в TCP-варианте
  input_registers = [
	{ measurement="DL-303", name="CO",   	byte_order="AB", data_type="UINT16", scale=1.0, address=[0] },
	{ measurement="DL-303", name="CO2",      byte_order="AB", data_type="UINT16", scale=1.0, address=[1] },
	{ measurement="DL-303", name="Humidity", byte_order="AB", data_type="UINT16", scale=0.1, address=[2] },
	{ measurement="DL-303", name="Temp", 	byte_order="AB", data_type="UINT16", scale=0.1, address=[3] },
	{ measurement="DL-303", name="DewPoint", byte_order="AB", data_type="UINT16", scale=0.1, address=[5] },
  ]

Имя порта зависит от платформы:

•  /dev/ttyS3 — NAPI-C (RK3308)

•  /dev/ttyUSB0 — USB-адаптер RS485 на любом хосте

•  /dev/ttyAMA0 — Raspberry Pi (аппаратный UART)

Параметры порта (baud_rate, data_bits, parity, stop_bits) должны точно совпадать с тем, что выставлено на датчике. Если хоть один параметр не совпадает — данных не будет, и Telegraf запишет ошибку в лог. Это самая частая причина, почему «датчик молчит».

Даже при прямом RS485-подключении удобнее запустить mbusd и работать через Modbus TCP. Тогда можно параллельно отлаживать через modpoll, не останавливая Telegraf.

Шаг 3. Тестовый запуск до перезапуска службы

Запускать telegraf в тестовом режиме — хорошая привычка. Он выполнит опрос датчика один раз и выведет результат в stdout без записи в базу:

telegraf --config /etc/telegraf/telegraf.d/dl303.conf --test

При успешном опросе вывод будет примерно таким:

> DL-303,host=napi-rk3308b-s CO=0,CO2=815,Humidity=38.81,Temp=26.39,DewPoint=11.24 1718012345000000000

Это Line Protocol — то, что Telegraf запишет в InfluxDB. Реальные числа в выводе означают, что конфиг рабочий. Добились чистого вывода — перезапускаем службу:

systemctl restart telegraf

Теперь про типичные ошибки при тесте:

• connection refused  — шлюз mbusd не запущен или неверный адрес в поле controller.

• i/o timeout  — датчик не отвечает. Проверяем slave_id, параметры порта, полярность проводов A/B.

• invalid character  — синтаксическая ошибка в TOML. Смотрим на кавычки и лишние пробелы.

• connection reset by peer  — при RTU — скорость или параметры порта не совпадают с датчиком.

Шаг 4. Grafana — дашборд

После того, как данные пошли в InfluxDB, подключаем Grafana. Data Sources -> Add data source -> InfluxDB, Query Language: Flux. URL, токен и организация — те же, что в конфиге Telegraf.

Простейший Flux-запрос для графика температуры:

from(bucket: "sensors")
  |> range(start: -1h)
  |> filter(fn: (r) => r._measurement == "DL-303")
  |> filter(fn: (r) => r._field == "Temp")

Добавьте панель для каждого поля (CO2, Humidity, DewPoint) — дашборд готов. Для DL-303 разумно сразу поставить алерт на CO2 > 1000 ppm и CO > 50 ppm — это нормы по СанПиН для рабочих помещений. Grafana уведомит по email, Telegram или любым другим каналом.

Готовые JSON-шаблоны дашбордов для распространенных датчиков, включая DL-303 можно взять: github.com/lab240/telegraf-grafana-configs.

А если несколько датчиков на одной шине

RS-485 поддерживает до 32 устройств на сегмент без дополнительного оборудования. Каждому датчику нужен уникальный slave_id на шине и уникальное measurement в конфиге. Удобнее всего разложить по отдельным файлам в telegraf.d/ — Telegraf подберет все автоматически при рестарте:

/etc/telegraf/telegraf.d/
  dl303-room1.conf	# slave_id=1, measurement="DL-303-room1"
  dl303-room2.conf	# slave_id=2, measurement="DL-303-room2"
  pressure.conf   	# slave_id=3, measurement="PressureSensor"
 
## Датчик 1
[[inputs.modbus]]
  name 	= "DL-303-room1"
  slave_id = 1
  controller = "file:///dev/ttyS3"
  ...
 
## Датчик 2
[[inputs.modbus]]
  name 	= "DL-303-room2"
  slave_id = 2
  controller = "file:///dev/ttyS3"
  ...

Telegraf опрашивает датчики последовательно — один запрос, один ответ. Если 10 датчиков x 500 мс timeout = 5 секунд на цикл, то интервал опроса в 1 секунду нереалистичен. При большом числе устройств увеличивайте timeout или interval.

Что делать с датчиком, если он без документации

Так бывает: датчик на руках, написано только «Modbus RTU, 9600 8N1, адрес 1», а документации нет. Алгоритм простой.

1. Опросить первые 30-40 holding-регистров подряд.

   modpoll -m tcp -0 -a 1 -r 0 -c 40 127.0.0.1
   

2. Сравнить вывод с тем, что показывает датчик на дисплее или в родном ПО.

3. Значение 265 при температуре 26.5 C на экране — это регистр с scale=0.1. Значение 4587 при давлении 458.7 гПа — тоже scale=0.1. По таким совпадениям определяем, какой регистр что означает.

4. Учесть масштаб (scale) — часто датчик отдает значение умноженное на 10 или 100.

5. Для датчиков с float: некоторые устройства упаковывают 32-битный float в два соседних регистра.

Тогда в конфиге:

{ measurement="MySensor", name="Pressure", byte_order="ABCD",
  data_type="FLOAT32-IEEE", scale=1.0, address=[3,4] }

Byte_order для float бывает ABCD, DCBA, BADC — перебираем до осмысленного значения.

Графический интерфейс NapiConfig — то же самое без консоли

Весь путь выше пройден через SSH и текстовый редактор. На NapiLinux того же результата можно добиться из веб-интерфейса NapiConfig. Он открывается на порту 443, собран на Vue и FastAPI, ставить отдельно ничего не нужно — интерфейс уже в системе. Три частые операции при работе с датчиками собраны в одном месте. Это правка конфига Telegraf, проверка опроса и просмотр графиков, и все три не требуют консоли и памяти на пути к файлам.

Правка конфига Telegraf. Каждый датчик — это отдельный файл в telegraf.d. В NapiConfig он открывается в редакторе с подсветкой TOML. Правятся те же поля, что в шагах выше — slave_id, controller, адреса регистров, scale, — только без vim по SSH. Рядом кнопки теста и сохранения.

Отладка опроса. Кнопка «Тест» прогоняет telegraf --test на текущем конфиге и показывает результат в окне — строку Line Protocol с реальными значениями, лог Telegraf и код возврата. Это ровно проверка из Шага 3, но вывод идет в интерфейс, а не в stdout. Ошибка в scale, неверный slave_id, молчащий датчик — все увидите, службу перезапускать не надо.

Графики из базы. Раздел «Графики» читает ряды прямо из InfluxDB и строит их по выбранному регистру. Есть выбор поля, временной диапазон и множитель, так что форму сигнала по сырому значению регистра видно без запуска Grafana. Для быстрой проверки «данные идут и выглядят осмысленно» этого хватает. Grafana остается, скажем так, на своем месте — там, где нужны постоянные дашборды и алерты.

Заодно в NapiConfig есть страница Modbus-шлюза — тот самый мост RTU в TCP через mbusd из Шага 0, настраивается мышкой. Плюс управление сетевыми интерфейсами, службами systemd, просмотр логов и веб-терминал SSH на случай, если консоль все-таки понадобится.

Полный разбор стека с нуля есть на Хабре в статье Александра Фролова «Собираем метрики с датчиков через Modbus и Telegraf». Автор ставит Telegraf, InfluxDB и Grafana на разное железо — Raspberry Pi, Orange Pi, Repka Pi и модуль Front Control Compact, — подключает датчики XY-MD02 и PZEM-016 по RS485, разбирает настройку InfluxDB, срок хранения данных и работу через NapiConfig, все с командами mbpoll и скриншотами веб-интерфейса.
Статья А.Фролова будет полезной точкой входа, если стек поднимается вручную, а не на NapiLinux.

Выводы

Весь путь от подключенного датчика до рабочего дашборда:

1. Физически подключить RS485, убедиться через modpoll что датчик отвечает.

2. Написать конфиг Telegraf — 15-20 строк TOML.

3. Прогнать telegraf --test, убедиться что значения на выходе реальные.

4. Перезапустить службу, добавить панели в Grafana.

Telegraf берет на себя опрос, буферизацию и запись в базу. При потере связи с датчиком он записывает ошибку в лог и продолжает работать — следующий опрос будет через заданный интервал (по умолчанию 10 секунд). При восстановлении связи данные идут дальше без какого-либо вмешательства.

Стек (Telegraf + InfluxDB + Grafana) одинаково работает на ARM-сборщике в цеху и на x86-сервере в серверной. Данные локальны, лицензий нет, сообщества активны.

Хелп:

• Веб-страница с диаграммами подключения
  https://napiworld.ru/software/sensors/telegraf-modbus/

• Шаблоны конфигов Telegraf и дашборды Grafana для разных датчиков: github.com/lab240/telegraf-grafana-configs

• Документация плагина modbus:  github.com/influxdata/telegraf/blob/master/plugins/inputs/modbus/README.md
  

Если будут вопросы по статье, реализациям или требуется дополнительная информация, просьба писать мне в ЛС.