Контроллер WB6 не реагирует на изменение периода опроса устройств на "ttyRS485-1"

Здравствуйте.
Какое оборудование: WB6 (Firmware version=202012280122 ), настенный универсальный датчик MSW v3 (HW=4.9.1, FW=4.6.1 (изначально, после покупки изменена на последнюю ветки stable на момент середины декабря 2020 года);

Что делал: Пытался в вэб-интерфейсе изменить периодичность опроса линии RS-485 контроллером, согласно указанию в инструкции путём изменения параметра “Desired poll interval (ms)” как у порта, так и в настройках устройства (там же где требуется указать адрес и тип устройства) - MSW v3 подключенного к контроллеру, поскольку данные в контроллере обновляются для моего случая медленно (примерно, раз в 20…120с), индикатор на корпусе датчика “status”, при этом мигает редко - его индикация, очень похожа на индикацию обращения/ответа к/от датчика ;

Что получилось: контроллер изменяет этот параметр (ставил значение как больше так и меньше того, которое по-умолчанию) но периодичность изменения параметров осталась прежней (смотрел в веб-интерфейсе контроллера и путём обращения к MQTT-топикам датчика MSW v3). Притом, если подключить датчик к преобразователю RS-485<>Ethernet (нашлась MOXA 5230) и начать опрашивать по ModbusRTU, то данные в регистрах обновлялись быстро (совпадало с частотой опроса с помощью ПО эмулирующего работу “Modbus-Master” устройства), индикатор “status” на корпусе датчика MSW v3 мигает часто, видимо, показывая обращения к датчику или ответы датчика на запросы.

Вопрос: почему контроллер не меняет периодичность опроса, хоть и происходит смена параметров в вэб-интерфейсе?

Добрый день.
Как я понимаю - проблема в том что данные обновляются недосточно часто?
Какая версия wb-mqtt-serial установлена?

dpkg -s wb-mqtt-serial

От версии зависит куда пишутся логи.

Version: 2.6.3

Запускаем

journalctl -u wb-mqtt-serial --no-pager

можно использовать grep для фильтрации. Есть ли ошибки обмена? Много?
Если на порту настроено много отсутствующих, например, устройств - то контроллер будет ждать их ответа.

Есть отсутствующие на линии устройства которые запланированы к подключению, в логах много ошибок вида:

Сводка

WARNING: [modbus] failed to read 7 coil(s) @ 5100 of device modbus:7: Serial protocol error: request timed out

А каким образом это влияет на обмен данными с датчиком MSW v3?
Контроллер поочерёдно опрашивает все указанные в [/etc/wb-mqtt-serial.conf] устройства и только когда очередь дойдёт до устройства на связи его данные будут обновлены и в web-интерфейсе? И есть ли смысл скопировать текущие настройки этого порта (потому что устройства будут подключены позднее), удалить все устройства из конфигурации этого порта RS-485, выполнить описанные где-то в этой ветке действия, после этого попробовать подключить датчик MSW v3 и осмотреть на вкладке “devices” на предмет частоты обновления показаний?

На обмен влияет тем что происходит ожидание ответа.
Удалять - не надо, достаточно отключить (снять галочку “enable” в веб интерфейсе.

ну и удаление из mqtt - необязательно.

1 лайк

Здравствуйте.
Предложенное решение помогло - после описанных вами ранее действий скорость обновления данных заметно выросла. В логе (journalctl -u wb-mqtt-serial --no-page) по-прежнему продолжают “сыпаться” ошибки вида:

Сводка

WARNING: [modbus] failed to read 1 input(s) @ 283 of device modbus:18: Serial protocol error: request timed out

но обновление данных в web-интерфейсе контроллера происходит на несколько порядков быстрее.

Добрый день.
Насчет ошибок - можно увеличить таймаут в настройках порта и посмотреть - если ошибки стали возникать реже - то дело в нем, если так же - то надо проверять физические соединения.

Здравствуйте.
Эти ошибки возникают из-за отсутствия устройств на линии - их ещё не смонтировали.

Тогда - просто отключаем их в настройках. Смонтируют - можно включить.

Но они уже отключены в настройках (файл с настройками порта RS-485-1 контроллера, к которому запланировано подключать датчики и модули):

Сводка

{
“path”: “/dev/ttyRS485-1”,
“devices”: [
{
“slave_id”: “1”,
“device_type”: “WB-MSW v.3”,
“enabled”: false
},
{
“slave_id”: “2”,
“device_type”: “WB-MSW v.3”,
“enabled”: false
},
{
“slave_id”: “3”,
“device_type”: “WB-MSW v.3”,
“enabled”: false
},
{
“slave_id”: “4”,
“device_type”: “WB-MSW v.3”,
“enabled”: false
},
{
“slave_id”: “5”,
“device_type”: “WB-MSW v.3”,
“enabled”: false
},
{
“slave_id”: “6”,
“device_type”: “WB-MSW v.3”,
“enabled”: false
},
{
“slave_id”: “7”,
“device_type”: “WB-MSW v.3”,
“enabled”: false
},
{
“slave_id”: “8”,
“device_type”: “WB-MSW v.3”,
“enabled”: false
},
{
“slave_id”: “9”,
“device_type”: “WB-MSW v.3”,
“enabled”: false
},
{
“slave_id”: “10”,
“device_type”: “WB-MSW v.3”,
“enabled”: false
},
{
“slave_id”: “11”,
“device_type”: “WB-MSW v.3”,
“enabled”: false
},
{
“slave_id”: “12”,
“device_type”: “WB-MSW v.3”,
“enabled”: false
},
{
“slave_id”: “13”,
“device_type”: “WB-MSW v.3”,
“enabled”: false
},
{
“slave_id”: “14”,
“device_type”: “WB-MSW v.3”,
“enabled”: false
},
{
“slave_id”: “15”,
“device_type”: “WB-MSW v.3”,
“enabled”: false
},
{
“slave_id”: “16”,
“device_type”: “WB-MSW v.3”,
“setup”: [
{
“address”: 40282,
“title”: “asd”,
“value”: 1
}
],
“poll_interval”: 1
},
{
“slave_id”: “17”,
“device_type”: “WB-MSW v.3”,
“enabled”: false
},
{
“slave_id”: “18”,
“device_type”: “WB-MSW v.3”
},
{
“slave_id”: “19”,
“device_type”: “WB-MSW v.3”,
“enabled”: false
},
{
“slave_id”: “20”,
“device_type”: “WB-MSW v.3”,
“enabled”: false
},
{
“slave_id”: “21”,
“device_type”: “WB-MSW v.3”,
“enabled”: false
},
{
“slave_id”: “22”,
“device_type”: “WB-MSW v.3”,
“enabled”: false
},
{
“slave_id”: “23”,
“device_type”: “WB-MSW v.3”,
“enabled”: false
},
{
“slave_id”: “24”,
“device_type”: “WB-MSW v.3”,
“enabled”: false
},
{
“slave_id”: “25”,
“device_type”: “_P03_3-Modbus”,
“enabled”: false
}
],
“baud_rate”: 9600,
“parity”: “N”,
“data_bits”: 8,
“stop_bits”: 2,
“poll_interval”: 10,
“enabled”: true
}

18 - не отключен. Если его фактически нету - то и будет записывать ошибку.

1 лайк

Да, верно.
Спасибо за помощь и уточнения в решении вопроса)

1 лайк