Периодически (несколько раз в час) соединение обрывается, в логах:
Jul 19 15:20:54 wirenboard-AKUR4GWC wb-mqtt-serial[3243715]: WARNING: [register handler] failed to write: <modbus-tcp:1:holding: 384>: Serial protocol error: socket closed
Jul 19 15:20:54 wirenboard-AKUR4GWC wb-mqtt-serial[3243715]: WARNING: [serial client] <modbus-tcp:1:holding: 384> register write cancelled: port is not open
Ошибка повторяется регулярно на протяжении нескольких часов (15:20, 16:02, 16:11, 16:27, 16:35, 16:50, 17:00), пинг до устройства при этом стабильный, оба устройства в одной локальной сети.
Похоже, проблема не ограничена testing-веткой — прикладываю лог, чтобы помочь в диагностике. Могу собрать и прислать диагностический архив контроллера, если это поможет — подскажите, актуальна ли ещё эта проблема и нужна ли доп. информация.
Чтобы понять, кто закрывает TCP-сессию — сам шлюз или опрос со стороны контроллера, — прогоните запись в тот же регистр напрямую, в обход wb-mqtt-serial.
Отановите опрос):
systemctl stop wb-mqtt-serial
Проверьте через modbus_client запись в регистр несколько сотен раз циклом (modbus_client --debug -mtcp -p502 192.168.1.1 -a1 -t0x06 -r385 100):
for i in {0..500}; do echo $i; modbus_client --debug -mtcp -p502 192.168.1.1 -a1 -t0x06 -r385 100; done
Верните опрос обратно:
systemctl start wb-mqtt-serial
Если шлюз будет возвращать ошибки, то приложите их.
при включенном опросе
выполнил for i in {0..100}; do echo $i; modbus_client --debug -mtcp -p502 -a1 -t0x03 -r385 -c1 -o5000 192.168.1.1; done
на 3 попытке вышла ошибка
То, что при остановленном опросе ошибок нет, говорит о том, что со связью всё в порядке — на физическом уровне и с самим шлюзом проблем нет.
Остаётся проверить версию, что шлюз могут одновременно опрашивать несколько клиентов. Чтобы понять, есть ли посторонний клиент в обычной работе (а не только во время ручного теста), помогите, пожалуйста, с двумя вещами:
Воспроизведите исходную проблему в чистом режиме — только контроллер, без параллельных запросов с ПК и без открытой фирменной утилиты Arlight. Если в таком режиме обрывов нет, а свет и группы работают штатно — значит, причина была именно в конкурирующем подключении.
Проверьте, не обращается ли к шлюзу что-то ещё помимо контроллера: открытая веб-панель или утилита Arlight, второй контроллер, SCADA, сторонняя интеграция. Такой клиент и будет ронять сессию контроллера.
Ещё один момент по архиву: шлюз подключён к контроллеру не напрямую, а через общую сеть. Видно, что контроллер и шлюз (192.168.1.1) находятся в одной подсети 192.168.1.0/24, где есть роутер (шлюз по умолчанию 192.168.1.254). Причём сам контроллер подключён к этой сети сразу двумя интерфейсами одновременно — по кабелю (eth0, 192.168.1.250) и по Wi-Fi (wlan1, 192.168.1.251). Оба в одной подсети.
Чтобы полностью исключить влияние сетевого оборудования, предлагаю на время диагностики подключить шлюз напрямую в порт контроллера отдельным кабелем — без роутера и коммутатора между ними, задав статические адреса в отдельной маленькой подсети (например, контроллер 192.168.10.2, шлюз 192.168.10.1). Тогда к шлюзу гарантированно будет обращаться только контроллер, и никакой сторонний клиент до него не дотянется.
Если в чистом режиме обрывы всё же останутся — напишите, и мы продолжим разбор уже на нашей стороне.
Вчера вечером удалил устройство Arlight DALI-LOGIC-LITE-PS-x1, сохранил настройки, добавил его обратно. Ошибки ушли из логов. Пока полет нормальный. Наблюдаю дальше.
Почему это помогло у меня только догадки, может вы поясните магию этого действия?
