Как это включить? debug: true в конфиге? Непосредственно для одного устройства дебаг не включается, а глобально создается огромная нагрузка процессом rsyslog и systemd так что все просто виснет.
Вот так было на старой версии 1.61. Как видно, 10 ошибок за 12 часов:
# cat /var/log/messages | grep "modbus:141" | tail -n 10
Apr 13 23:09:07 wirenboard-A4WP2ZIO serial: ModbusRTU::ReadRegisterRange(): failed to read 3 input(s) @ 32 of device modbus:141: Serial protocol error: request timed out
Apr 14 00:36:46 wirenboard-A4WP2ZIO serial: ModbusRTU::ReadRegisterRange(): failed to read 3 discrete(s) @ 0 of device modbus:141: Serial protocol error: request timed out
Apr 14 03:06:23 wirenboard-A4WP2ZIO serial: ModbusRTU::ReadRegisterRange(): failed to read 4 holding(s) @ 0 of device modbus:141: Serial protocol error: request timed out
Apr 14 03:36:29 wirenboard-A4WP2ZIO serial: ModbusRTU::ReadRegisterRange(): failed to read 4 coil(s) @ 0 of device modbus:141: Serial protocol error: request timed out
Apr 14 04:50:56 wirenboard-A4WP2ZIO serial: ModbusRTU::ReadRegisterRange(): failed to read 3 input(s) @ 32 of device modbus:141: Serial protocol error: request timed out
Apr 14 06:57:31 wirenboard-A4WP2ZIO serial: ModbusRTU::ReadRegisterRange(): failed to read 1 input(s) @ 121 of device modbus:141: Serial protocol error: request timed out
Apr 14 07:36:41 wirenboard-A4WP2ZIO serial: ModbusRTU::ReadRegisterRange(): failed to read 4 holding(s) @ 0 of device modbus:141: Serial protocol error: request timed out
Apr 14 08:33:12 wirenboard-A4WP2ZIO serial: ModbusRTU::ReadRegisterRange(): failed to read 3 input(s) @ 32 of device modbus:141: Serial protocol error: request timed out
Apr 14 09:19:44 wirenboard-A4WP2ZIO serial: ModbusRTU::ReadRegisterRange(): failed to read 4 coil(s) @ 0 of device modbus:141: Serial protocol error: request timed out
Apr 14 09:38:20 wirenboard-A4WP2ZIO serial: ModbusRTU::ReadRegisterRange(): failed to read 3 input(s) @ 32 of device modbus:141: Serial protocol error: request timed out
А вот так стало после обновления до 2.11.0~feature+less-logs+17+d3de92e:
Apr 14 12:43:21 wirenboard-A4WP2ZIO wb-mqtt-serial[9260]: INFO: [serial client] device modbus:141 is connected
Apr 14 12:43:34 wirenboard-A4WP2ZIO wb-mqtt-serial[9260]: WARNING: [modbus] failed to read 3 discrete(s) @ 0 of device modbus:141: Serial protocol error: request timed out
Apr 14 12:55:51 wirenboard-A4WP2ZIO wb-mqtt-serial[9260]: WARNING: [modbus] failed to read 3 discrete(s) @ 0 of device modbus:141: Serial protocol error: request timed out
Apr 14 13:01:11 wirenboard-A4WP2ZIO wb-mqtt-serial[9260]: WARNING: [modbus] failed to read 3 discrete(s) @ 0 of device modbus:141: Serial protocol error: request timed out
Apr 14 13:08:28 wirenboard-A4WP2ZIO wb-mqtt-serial[9260]: WARNING: [modbus] failed to read 3 discrete(s) @ 0 of device modbus:141: Serial protocol error: request timed out
Apr 14 13:11:07 wirenboard-A4WP2ZIO wb-mqtt-serial[9260]: WARNING: [modbus] failed to read 3 discrete(s) @ 0 of device modbus:141: Serial protocol error: request timed out
Apr 14 13:16:47 wirenboard-A4WP2ZIO wb-mqtt-serial[9260]: WARNING: [modbus] failed to read 3 discrete(s) @ 0 of device modbus:141: Serial protocol error: request timed out
Apr 14 13:17:17 wirenboard-A4WP2ZIO wb-mqtt-serial[9260]: WARNING: [modbus] failed to read 4 coil(s) @ 0 of device modbus:141: Serial protocol error: request timed out
Apr 14 13:17:40 wirenboard-A4WP2ZIO wb-mqtt-serial[9260]: WARNING: [modbus] failed to read 4 holding(s) @ 0 of device modbus:141: Serial protocol error: request timed out
Apr 14 13:19:26 wirenboard-A4WP2ZIO wb-mqtt-serial[9260]: WARNING: [modbus] failed to read 4 coil(s) @ 0 of device modbus:141: Serial protocol error: request timed out
Если расскажете как включить дебаг для одного устройства - пришлю с диагностикой.
Сделал. Конфиг MAP12H вернул на дефолтный, т.к. ругается на собственные типы данных и не запускается, на всех шинах poll_interval = 10
А для чего это сделано?
Давайте поставим вопрос иначе: какие параметры надо прописать в шаблоны устройств или в конфиге wb-mqtt-serial, чтобы нагрузка вернулась к прежнему уровню версий 1.х? Ибо 30% нагрузка на 12 устройствах - совершенно неприемлемо. А если будет 20-30 устройств - все вообще повиснет?
странный вопрос. wb-mqtt-serial опрашивает устройства так часто, как позволяет пропусная способность шины, чтобы у вас были наиболее актуальные данные. Максимальная частота опроса регулируется значением poll_interval. Просто в драйвере 1.x при вашем наборе устройств из-за неоптимальной работы эта настроенная максимальная частота не достигалась.
Поставьте poll_interval для порта в 1000, например: так каждый регистр будет опрашиваться не чаще, чем раз в секунду.
Нет, т.к. опросы сейчас ограничены пропускной способностью RS-485. Если немного упростить, то количество запросов в секунду и нагрузка на CPU не зависят от количества устройств в конфиге.
виснет - это в смысле вы по ssh не можете подключиться? Или просто медленно работает?
Судя по вашему логу, за 10 минут было несколько ошибок, так что включить это достаточно минут на 10 - нам хватит информации.
Я уже пробовал это в самом начале - и писал раньше:
Т.е. все равно в 2 раза нагрузка выше.
Да и в моих кастомных шаблонах и так многие регистры установлены в poll_interval 1000 или даже 10000, но вот некоторые регистры нужно опрашивать почти мгновенно для соотв. скорости реакции на датчики движения, например, или нажатие клавиш.
Видимо, я не так понял ваш вопрос. Если вопрос был в том, как снизить нагрузку до приемлимого уровня, то ответ - увеличить poll_interval.
Да, wb-mqtt-serial 2.7.1 медленнее, чем старый wb-mqtt-serial 1.61.0. Мы это знаем и планируем когда-нибудь заняться оптимизацией. Приоритет не очень высокий, потому что 15% загрузки процессора - это более чем приемлимая нагрузка.
Если для вас эти 8% разницы по какой-то причине принципиальны, то рекомендую пока использовать старую версию.
В моем случае нагрузка всей системы увеличивается примерно на 30%: около 50% на старой версии, и порядка 75-80% с новой. Насколько это критично? Ну, если бы до обновления было 10%, а стало 40% - да, это не критично. Но когда было 50%, а стало 80% - это уже критично, т.к. практически не остается запаса на выполнение каких-то скриптов или запросов из исторической базы - во время их выполнения CPU упрется в “полку”, а это уже скажется на отзывчивости и быстродействии движка правил.
Такая же ситуация описана и в этой ветке - наглядно, с графиком. У меня все в точности аналогично. Другие скорее всего просто еще не обновлялись.
А в чем тогда преимущество новой версии? Может, надо было сначала оптимизировать, а потом выкладывать обновление? У меня нет возможности заниматься глубоким бета-тестированием и ставить тестовые сборки, снимать дебаги - контроллер постоянно в работе и это доставляет много неудобств. Почему бы вам самим не собрать тестовый стенд с аналогичным наборот устройств? Тем более, есть уже 2 темы.
А пока да, я откатился на старую версию.
работа через systemd, удобное логгирование, автоматический перезапуск
отсутствие огромных задержек между опросами регистров, шина используется гораздо эффективнее, максимальный период опроса каналов увеличился
обработка ошибок записи регистров и setup-значений
определение неподдерживаемых устройством регистров: они опрашиваются только первый раз, а больше не опрашиваются
поддержка Modbus TCP
поддержка протоколов датчиков НЕВА и Энергомера
поддержка пользовательских шаблонов
поддержка широковещательных адресов для некоторых протоколов
улучшена поддержка битовых масок
Новый wb-mqtt-serial вышел в районе сентября, так что это не уже 2 темы, а всего 2 темы за полгода.
Мы долго разрабатывали и в ближайшие недели внедрим разделение на стабильные и тестовые релизы, чтобы тестировать новые версии исключительно на добровольцах. Другое дело, что “новый” wb-mqtt-serial не такой уж и новый, и с ним это вряд ли бы сработало.
Просто большинство не обновляет ПО, если все работает, ничего не глючит и не требуется новый функционал… А те, кто купили контроллер с уже предустановленной новой версией, думают, что так и должно быть.
В силу определенных обстоятельств на одном объекте пришлось возвращать контроллер к заводским настройкам, сейчас процессор грузится до 70%, при старте и все 100% с одной шиной, на которой 4 счетчика WB-MAP12E. Desired poll interval (ms) = 20 (пробывал 1000/10000) без результатно.
Если сделать enable еще 2 шины которые сидят на serial over tcp, на которых еще 4 счетчика WB-MAP12E то процессор грузится до 100%. Для данных шин Desired poll interval (ms) - 1000 (пробывал и 10 сек без результатно.)
Провел эксперимент - оставил только одну шину (остальные удалил) и в единственной шине только 1 счетчик. Загрузка процессораа составила в среднем 18-20%. С двумя уже 70%, причем не важно какой счетчик добавлял 2 или 3.
Ну не могут два устройства так нагибать контроллер!
что порекомендуете?
Попутный вопрос судя по информации последняя стабильная версия wb-mqtt-serial (2.31.0), почему она не устанавливается при обновлении?
Позвольте полюбопытствовать (ибо опасаюсь вляпаться в это сам) - а фактический интервал опроса меняется? Т.е. если в терминале подписаться на нужные топики, значения валятся чаще/реже, или с неизменной скоростью? Помнится, приходилось интервалы подкручивать индивидуально, кое-где демон их игнорил, только сейчас не припомню, где конкретно.
не заметил существенной разницы, при 20 конечно по чаще, при 1000 чуть реже, но не кратно секунде. При 10 000 не раз в 10 секунд, а когда как и через 15 сек может и через 2 секунды.
Вот скрин с другого объекта, там тоже wb-mqtt-serial 2.7.1 устройств порядка 15 на всех шинах, но такой загрузки не наблюдаю. На данном объекте нет счетчиков WB-MAP остается только гадать и ждать комментариев и рекомендаций от WB.
Это можно долго ждать.
Может, сцабака в 57600? Я на некоторых узлах имею и больше железа, и 2.х демон (по причине редкой неустранимой ошибки в 1.х), но завалить проц выше 30% пока не доводилось. При этом еще и десяток правил ворочаются там.
Верю. Но - оно точно надо?
У меня везде 9600 за глаза и уши. С одним особо капризулечным датчиком - 4800. Ведь опрос имеет две стороны - и непосредственно теребление шины, и запись значения в очередь. Не думаю, что контроллер eMMC столь мудро закеширован, что не наваливает забот о диске на систему: это всего лишь флешка, а не серверный массив.
Зы. А что еще за iridium server, верхний в топе? Зачем он тут? Краем уха о нем слышал, это ж альтернативная WB система, довольно тяжелая для совместного проживания на не самом могучем железе.
Порой заказчик требует чтобы все было по максимуму начитавшись интернета, не вникая в детали. Проще скорость поменять чем что-то доказывать. Тем не менее перевел на 9600 - нагрузка уменьшилась до 80-90%, но это все равно много.
Iridium mobile если коротко это SCADA для бытовой автоматизации + шлюз для объединения устройств работающих на различных протоколах
