Не работает быстрый modbus на WB7

Добрый день!
Имеется инсталляция на WB7 Pro. (7.4.3M/2GI 1D/N-2GI)

Контроллер достаточно нагружен.
Используются 4 линии rs485 (2 через расширители MOD), KNX шина. Шина со шлюзами ONOKOM.
На каждой линии в среднем по 20 устройств.

Также уточню что установлен сервер IRIDI, Spruthub и практически в холостую работающий Nodered.

На контроллере реализовано управление светом, шторами, климатом, защиты от протечки.
Правила и виртуальные устройства в основном созданы средствами WB Rules, а также сценариями Spruthub по MQTT.

В целом все замечательно работает , кроме скорости отклика на входы с подключенными выключателями.

Т.е. по факту не работает “быстрый Modbus”. Также скорее всего из-за этого в конфигураторе не отображаются возможность обновления прошивок устройств. Причем иногда (примерно в 5% случаях) выборочно появляется на одном из 2- устройств предложение обновления. но при следующем подключении снова никаких кружочков нет.

Временно на нескольких десятках каналов поставил скорость опроса в 200мс. Но из-за этого идут пропуски и скорее всего также из-за этого идет сильная нагрузка сервисом serial

Прикладываю диагностический архив, а также скрин нагрузки процессов.
diag_output_AYNYCBNV_2025-05-05-06.33.46.zip (158,6 КБ)

Добрый день!
Рекомендую отключить режим отладки, так как он сильно нагружает систему. После этого проверьте, как изменилась скорость реакции на выключатели.

Отключается в настройках Serial:
изображение

Если после отключения проблема сохранится — пришлите новый диаг-архив.

Действительно, был включен опрос. Отключил. вернул опросы всех каналов на “очередь” Стало гораздо лучше. Не прям моментально. но по ощущениям в 500 мс укладывается. Но опять же - ощущается какое то непостоянство. Иногда грубо 50 мс иногда 500.
Можно как то в логах проверить какая реальная задержка происходит?

Добрый день!
Хорошо, что удалось улучшить скорость опроса — высокая нагрузка на контроллер действительно может существенно её замедлять.

Рекомендую провести дополнительную проверку с нужными топиками и замерить время отклика:

mosquitto_sub -t "/devices/#" -v | ts

Также, думаю, будет полезна данная статья о быстром Modbus — в ней описаны способы повышения производительности опроса устройств.

Если правильно понял, то средняя задержка 300мс.

Добрый день!
Да, всё верно. Можно также поставить опрос в порядке очереди менее важных параметров — это позволит разгрузить шину и повысить общую скорость отклика по важным контролам.

Вообще при Быстром Модбасе на нескольких десятках входах задержка должна быть минимальна и 300 мс «в среднем» это много. Картинка из документаци — реальный эксперимент с парой десятков устройств у которых замыкали автоматом входы.

Скорее всего кто-то на шине «тупит» и драйвер ждёт тайматут при обращении к нему. нет устройств, которые физически отключены, но есть в настройках? Попробуйте оставить на шине только устройства Wiren Board и проверьте.

1 лайк

Конкретно на этом порту, где используются связки входов с реле расположено только щитовое оборудование WB. Но уточню, что на соседнем порте rs485 есть. например. MWAC того же ID. как и реле.

На самой обсуждаемой шине 18 стандартных реле и диммеров WB + 4 модуля R1G-16, подключенного через расширитель MIOv2 также через этот порт rs485. Может в этом дело?

Смущает то, что не показывает возможность обновления устройств.

Добрый день!
Обновление работает по другому механизму и обычно не связано с внутренними настройками контроллера.
Проблемы с обновлением чаще всего вызваны неустойчивым интернет-соединением или плохим качеством связи — например, временная потеря DNS, нестабильность канала или таймауты при загрузке пакетов.

“Не показывает” - это в веб интерфейсе нет уведомления о наличии обновления?
Недавно было обсуждение этого - разработчики нашли ошибку и обещали вскоре поправить в stable (Обновление устройств, подключенных через шлюз MIO-E v2)

1 лайк

Добрый день!
Затерялась тема, удалось ли решить вопрос?

Добрый день!

Если считать 300мс нормой - то вопрос решен. Т.к. никаких “тупящих” или отсутствующих устройств на шине больше нет.

Но судя по сообщению от Александра, скорость должна быть выше…

Добрый день!

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

Добрый день!
Давайте не будем закрывать тему, попробуем найти в чём причина, если вы согласны?

В общем сейчас выяснил следующее. На порту RS485-2 подключен шлейф из шлюзов ONOKOM. Которые прилично нагружают шину.

Ранее спрашивал что зависимость обработок правил основанных на откликах никак не зависит от соседних портов. Но вышло так что когда я отключил опрос этого порта - правила стали работать практически мгновенно. при этом отклики показывает в районе 100 мс
diag_output_AYNYCBNV_2025-05-16-06.58.20.zip (311,6 КБ)

Если включить опрос шлюзов - то по логам отклики остаются такие же короткие но реле включаются с заметной задержкой.

Добрый день,
Мне потребуется некоторое время, что бы проанализировать информацию.

Добрый день!

Проверьте, пожалуйста, чтобы параметр sporadic в шаблоне устройства был установлен true.

Подробнее об этом можно прочитать в документации.

Добрый день, удалось ли решить вопрос?

Добрый день! не совсем понял о каком шаблоне речь? Устройства же все штатные и по стоковым шаблонам работают

Добрый день!

У каждого штатного устройства действительно есть свой шаблон.