Как-то так.
Добюрый день! Извините за длительное ожидание. В экспериментах сама по себе загрузка CPU не повлияла на скорость обновления данных с Wb-MAI6.
Для дальнейшей диагностики проблемы пришлите, пожалуйста, архив с диагностической информацией контроллера. Создание архива описано в документации.
Выше есть мое сообщение, что архив не создавался, чтобы его создать остановил следующие службы: wb-rules, wb-mqtt-serial, wb-gsm, wb-cloud-agent. Загрузка упала до 0,75 avg и архив создался. Не знаю, как устроен архив и что в него попадает, но если надо я попробую ещё раз под нагрузкой создать его. Перед созданием архива повторил манипуляции с WB-MAI6, чтобы если в архиве есть журнал, то могли бы оценить описываемые проблемы.
@dust
хм, не сломалось ли чего на портале, под неавторизованым пользователем тоже можно скачать… посмотрел в другом браузере
Поправил ваше сообщение, удалил видимую ссылку, у меня сохранился доступ к архиву.
1 лайк
Посмотрю еще подробно диагностику, вернусь завтра с рекомендациями. На первый взгляд кажется, что движок правил чем-то сильно загружен.
Вижу, что достаточно много ресурсов поторебляется, но недостаточно диагностического лога. У вас есть возможность дать доступ техподдерке к контролеру? Если да, то:
Пригласите пожалуйста пользователя support@wirenboard.com в организацию на облачном сервисе.
Для этого в настройках организации нажмите кнопку “Пригласить”
И укажите почтовый адрес:
После этого поддержка получит доступ к вашему контроллеру для диагностики.
Не забудьте удалить потом доступ.
готово
Спасибо! Только логин/пароль в ssh у вас не по умолчанию, не могу зайти в консоль. Пришлите, пожалуйста, в личном сообщении или задайте временно по умолчанию.
задал по умолчанию
Спасибо! Контроллер действительно не очень быстро откликается.
Хотел уточнить один момент: я заметил, что значение IN 2 P Resistance обновляется довольно быстро. Правильно ли я понимаю, что после того как вы выставляете потенциометр на новое значение, IN 2 P Resistance сначала продолжает колеблется вокруг старого значения, а к новому приходит только с упомянутой вами существенной задержкой?
Да, всё так, меняется с существенной задержкой. Всё как на видео, которое я выложил выше (WB-MAI6 ускорение измерения сопротивления - #11 от пользователя MaKuT), и зафиксировал в сообщении (WB-MAI6 ускорение измерения сопротивления - #18 от пользователя MaKuT)
Чтобы определить, связана ли проблема с настройками самого модуля или это проблема контроллера, хочу провести проверку. Подготовлю сейчас описание действий, вернусь чуть позже.
Погонял немного сопротивление. Повторяется история. После предыдущих ваших действий начало быстро реагировать, потом всё медленнее и медленнее.
По логам при этом появилось следующее интересное наблюдение: прямая запись в шину через publish влияет на торможение получения данных (см. в логах “INFO: [rule info] strJson = {“params”:{“response_size”:8, …”).
Пока не получен ответ на запрос из шины - идут старые данные, как только ответ получен (см. в логах “INFO: [rule info] name: /rpc/v1/wb-mqtt-serial/port/Load/testRPC/reply, value: {“error”:null, …”), сразу идут обновленные данные.
На этом фоне ещё есть вполне логичное предупреждение
WARNING: [modbus] failed to read 2 input(s) @ 270 of device modbus:143: Serial protocol error: malformed response: invalid crc
Чтобы это всё обнаружить, см логи начиная с 15:21 по сервису wb-rules
Не понятно, кто тупит, но по факту выходит, что ситуацию подвешивает ожидание ответа от нестандартного Modbus-устройства. При этом само устройство отрабатывает сразу как получает команду. Да и отвечает вроде как сразу. А вот что с обработкой ответа от него непонятно. Выглядит так, что тупит WB. И ситуацию исправляет restart wb-mqtt-serial. Сразу начинают идти актуальные данные.
При этом видна ещё одна зависимость - чем дальше по времени от первого запуска publish, тем дольше ожидание ответа.
Проверка, насколько быстро реагирует сам модуль:
- В ssh-консоли остановите wb-mqtt-serial:
service wb-mqtt-serial stop - Проверьте, что считываются регистры параметра “IN 2 P Resistance”:
modbus_client --debug -mrtu -b115200 -pnone -s2 /dev/ttyRS485-2 -a143 -t0x03 -r0x2500 -c2
Ответ должен быть в виде
Opening /dev/ttyRS485-2 at 115200 bauds (N, 8, 2)
[A6][03][15][00][00][02][D9][10]
Waiting for a confirmation...
<A6><03><04><00><05><48><26><8B><22>
SUCCESS: read 2 of elements:
Data: 0x0005 0x4826
Это сырые данные из регистра.
Если их удается считать, попробуйте перевести реостат в крайние положения и посмотреть сразу же, как меняется вывод команды.
Для удобства можно воспользоваться скриптом, который запускается из командной строки и десять раз в секунду опрашивает регистры, конвертирует в десятичное значение и выводит на экран (выход по Ctrl-С):
watch -t -n 0.1 'modbus_client --debug -mrtu -b115200 -pnone -s2 /dev/ttyRS485-2 -a143 -t0x03 -r0x2500 -c2 | \
perl -ne '\''if(/Data:\s*(0x[0-9a-fA-F]+)\s+(0x[0-9a-fA-F]+)/){ \
$n=(hex($1)<<16)+hex($2);\
$d=$n; $d=reverse $d; $d=~s/(\d{3})(?=\d)/$1 /g; $d=reverse $d; \
printf "0x%08X (%s)\n",$n,$d \
}'\'''
Можно вращать потенциометр и смотреть, как быстро реагирует сам модуль на изменение сопротивления:
Ответил, прежде чем увидел ваш ответ. Посмотрю внимательно.
Целиком не запустился скрипт, т.к. такая ошибка
Experimental aliasing via reference not enabled at -e line 2.
Но запустил просто watch - по первой цифре видно, что данные передаются нормально, задержка совсем не велика.
К предыдущему посту - почему решил, что проблема не в нестандартном Modbus-устройстве по возврату данных. Я его перезагрузил. И это ровным счётом ни на что не повлияло при последующей команде на него (само устройство тут же отработало команду). Отключил от шины, проблема всё там же. Перезагрузка wb-mqtt-serial тоже никак не повлияла на ситуацию с задержкой.
Обнуляет ситуацию только перезагрузка контроллера. После перезагрузки всё опять шоколадно, запрос почти сразу ответ, почти сразу обновление данных с MAI6. Так что надо рыть куда-то в сторону trackMqtt.
Да, простите, лишние бекслеши были в конце строк, вот так:
watch -t -n 0.1 'modbus_client --debug -mrtu -b115200 -pnone -s2 /dev/ttyRS485-2 -a143 -t0x03 -r0x2500 -c2 | \
perl -ne '\''if(/Data:\s*(0x[0-9a-fA-F]+)\s+(0x[0-9a-fA-F]+)/){
$n=(hex($1)<<16)+hex($2);
$d=$n; $d=reverse $d; $d=~s/(\d{3})(?=\d)/$1 /g; $d=reverse $d;
printf "0x%08X (%s)\n",$n,$d
}'\'''
А для чего вы используете trackMqtt?
Рекомендую тогда выключить для отладки все правила, посмотреть, как в виджете WB-MAI6 меняется сопротивление, а затем включать правила последовательно и смотреть, начиная с которого начинаются задержки.
Я использую trackMqtt только для того, чтобы считать ответ нестандартного Modbus-устройства.
Опираюсь вот на этот пример: Подключение счетчика Энергомера CE307 R33.145.ОA.N - #17 от пользователя BrainRoot
Чтобы определить, что источник дошёл по назначению. Хотя конечно у меня есть и другие инструменты.
Но нет, проблема не в trackMqtt. Отключил его - не помогло. Всё таки какие-то проблемы с publish. Как эту функцию можно диагностировать? Поиграл с её последними двумя параметрами (было “2, false”). Когда убрал словил аж такую ошибку:
29-08-2025 20:33:53.598 [mosquitto] 1756488833: Client wb-modbus disconnected due to out of memory. 29-08-2025 20:33:53.578 [init.scope] wb-mqtt-serial.service: Main process exited, code=killed, status=4/ILL
Видимо wb-mqtt-serial или modbus плющит. Как только он перегрузился (после вышеуказанных событий), сразу всё забегало (использовал в publish последние 2 параметра “2, true”). Но не на долго. Через 5 минут всё вернулось на круги своя. Т.е. пошли задержки.
Публикация значений в топики - ресурсоемкая задача. Если вы делаете множество публикаций (сотни в секунду), то примерно так все и будет выглядеть: первое время все будет бегать, а потом буферы брокера переполнятся, и все будет еле шевелится. Может, в этом дело?