Сегодня к ряду наблюдал три странных поведения ПО контроллера. Поскольку я затрудняюсь определить прямую связь и непосредственно проблему, то описываю что было и как.
Утром стал работать с правилами, с файлом AlarmsList.js, где одно виртуальное устройство с несколькими десятками ячеек. Один раз сохранил файл - всё ок. Второй раз сохранил - никакой реакции в веб-интерфейсе. Обновил страницу - список файлов правил не грузится. Пустой экран с кружочком вечной загрузки. Перешёл на другую страницу с виджетами - контролы этого виртуального устройства пропали. Через несколько минут вроде появились. Выполнил эту процедуру повторно - тот же эффект.
Перезагрузил контроллер через ssh reboot. Далее какое-то время поработал с правилами, сбоев не было, хотя именно AlarmsList.js больше не пересохранял.
Под вечер отвалился один из датчиков 1-wire, подключенный напрямую к контроллеру по 1-wire интерфейсу. Если быть точнее, то в разделе Каналы MQTT в его топике в статусе было Ошибка: r. Ну ок, такое иногда бывает по этим датчикам, но они быстро оживают. А этот нет, минут 10 прошло - тишина. Но показания в графе Значение регулярно обновляется… Ну думаю, ладно, может он изредка обновляется, а так помехи и постоянно ошибка… Однако после перезагрузки проблема ушла - показания появились, статус ОК, и до текущего времени датчик не отваливался. Хм. Перезагрузка была проведена в пункте ниже после разборок со следующей проблемой, т.е. отдельно я не перезагружал.
Пока я разбирался с показаниями зависшего датчика, я обратил внимание, что перестал переключаться дискретный выход. Чётко как я уже описывал и обращался в теме далее:
Снял диаг архив, скачал файл libwbmqtt, как просили в теме, и выполнил systemctl stop wb-mqtt-gpio&& rm /var/lib/wb-mqtt-gpio/libwbmqtt.db &&systemctl restart wb-mqtt-gpio. Перезагрузил контроллер.
Пока вроде всё работает. Что за фигня и не будет ли завтра такого - не понятно.
Здравствуйте! Простите, пожалуйста, за задержку с ответом.
Спасибо за подробное описание!
Пока не увидел каких-то конкретных ошибок, связанных с тем поведением, что вы описываете, но заметил, что очень много ошибок при обмене данными на портах /dev/ttyMOD3 и /dev/ttyRS485-1.
Можете описать, что у вас и как физически подключено к контроллеру?
Добрый день! На MOD3 висит шина с преобразователями частоты, они обычно отключены и при пуске сначала включаются контактором.
На 1 шине висят WB устройства, там обычная витая пара с терминальным сопротивлением на конце.
Спасибо! По портам картина понятна и, похоже, это не объясняет все наблюдавшиеся проблемы.
Если частотники чаще находятся в выключенном состоянии, имеет смысл реже их опрашивать (увеличить poll_interval). На ttyRS485-1 есть редкие ошибки, но их не очень много.
Единой точки отказа, из которой следовали бы все описанные проблемы, я не вижу. Я бы начал с того, что чаще всего проявляется прямо сейчас. Это то, что связано с wb-mqtt-gpio – или всё-таки датчики температуры до сих пор работают нестабильно? Какая ситуация на сегодня?
Как только заметите очередную неисправность (одного типа), пожалуйста, сразу снимайте диагностический архив – так мы увидим состояние системы именно в момент сбоя.
Первое, что больше всего волнует - почему дискретный выход перестал переключатся из правил. Так же, как и в прошлой теме, он оживал, если его переключать из веб интерфейса нажатием на его контрол-переключатель. Какое общее количество выходов пострадало тогда - сказать сложно, но в этот раз это был другой выход.
Диагностический архив был снят именно в этот момент. Но оставить как есть я тоже не мог, там отопление и иные функции завязаны, не понятно к чему бы привело, пока разбирались бы.
Ну и вторым пунктом шли проблемы с сохранением правил. Складывалось впечатление, что файл с ними подвисал.
С датчиками это наверное самое меньшее, потому что я подумываю перейти на другое устройство измерения температур, во всяком случае тех датчиков, которые с длинными шлейфами.
Я думаю, я понял, как решить проблему при сохранении правил. Похоже, у вас воспроизводится изветчный нам баг, котоорый исправлен testing-релизе и ожидается в stable в конце этого месяца.
Чтобы не ждать и не переходить на тестинг, можно установить фикс:
Бльшое обсуждение ошибки можно посмотреть вот в этой теме.
Возможно, этот же фикс решит проблему с невозможностью управления дискретными выходами из движка правил, только из веб-интерфейса (тут я менее уверен, хотя симптомы кажутстя похожими). Попробуйте!
Добрый вечер! Спасибо, справился, помогло в части сохранения правил. Сначала я таки рискнул и пересохранил тот самый файл, и он действительно подвис. Затем выполнил обновление и проблема с сохранением ушла.
Что касается выхода, то ладно, будем наблюдать. Может я сделаю автотестирование этого момента, посмотрим.
В общем, я попутно решил обновить модули (чтобы избавиться от индикаторов новой версии, хотя по факту ничего нового в них не было особо). И решил нажать обновление через админку. У одного модуля прокатило норм, у второго вылезло такое сообщение.
Тема знакомая, иду в поиск, ищу в статусе загрузчика … НЕТУ. Иду в SSH, тоже нету …
Ввожу всё что знаю и умею:
Спойлер
root@wirenboard-AM75Z4F3:~# wb-mcu-fw-updater update-bl /dev/ttyRS485-1 -a84
Will find serial port settings for (/dev/ttyRS485-1 : 84; response_timeout: 0.20)... (elapsed: 00:03)
2025-10-08 20:58:30,319 Has found serial port settings: SerialSettings(baudrate=115200, parity='N', stopbits=2)
2025-10-08 20:58:32,208 bootloader (mr6cG 84 on /dev/ttyRS485-1):
2025-10-08 20:58:32,210 Is actual: 1.4.9 -> 1.4.9 (mr6cG 84 /dev/ttyRS485-1)
2025-10-08 20:58:32,213 Done
root@wirenboard-AM75Z4F3:~# wb-mcu-fw-updater recover /dev/ttyRS485-1 -a 84
Will find bootloader port settings for (/dev/ttyRS485-1 : 84; response_timeout: 0.20)... (elapsed: 00:19)
2025-10-08 21:00:18,740 Device (84 /dev/ttyRS485-1) is not in bootloader mode! Check connection or slaveid/port
root@wirenboard-AM75Z4F3:~# wb-mcu-fw-updater recover /dev/ttyRS485-1 -a 84
Will find bootloader port settings for (/dev/ttyRS485-1 : 84; response_timeout: 0.20)... (elapsed: 00:02)^C
root@wirenboard-AM75Z4F3:~# wb-mcu-fw-updater recover /dev/ttyRS485-1 -a84
Will find bootloader port settings for (/dev/ttyRS485-1 : 84; response_timeout: 0.20)... (elapsed: 00:05)^C
root@wirenboard-AM75Z4F3:~# wb-mcu-fw-flasher -d /dev/ttyRS485-1 -a84 --get-device-info
/dev/ttyRS485-1 opened successfully.
Trying to probe (84 /dev/ttyRS485-1) at bootloader params...
^C^[[C^[[D
^C
root@wirenboard-AM75Z4F3:~# service wb-mqtt-serial stop
root@wirenboard-AM75Z4F3:~# wb-mcu-fw-flasher -d /dev/ttyRS485-1 -a84 --get-device-info
/dev/ttyRS485-1 opened successfully.
Trying to probe (84 /dev/ttyRS485-1) at bootloader params...
Failed to connect (84 /dev/ttyRS485-1) at bootloader settings: Connection timed out
root@wirenboard-AM75Z4F3:~# wb-mcu-fw-updater recover /dev/ttyRS485-1 -a 84
Will find bootloader port settings for (/dev/ttyRS485-1 : 84; response_timeout: 0.20)... (elapsed: 00:19)
2025-10-08 21:05:50,211 Device (84 /dev/ttyRS485-1) is not in bootloader mode! Check connection or slaveid/port
root@wirenboard-AM75Z4F3:~# service wb-mqtt-serial start
root@wirenboard-AM75Z4F3:~#
И тут то до меня доходит, что модуль то живой и откликается… в устройствах он не красный, правила тоже не видят ошибок по нему (у меня есть контроль всех модулей и выдача аварий)…
А ещё ведь интересно - под красной надписью вылезаеть его текущая версия.
В общем, нажал крестик на этой красной надписе - всё исчезло, работает норм)
Снова сбой. На этот раз с другим выходом и другим gpio модулем, подключённым так же по wbio к контроллеру. Попытка записи 1 провалилась.
приложен диагностический архив, доступен только сотрудникам поддержки
(496,8 КБ)
Журнал логов показал следующее:
В 23.42.14 попытка записать 1 в дискретный выход, она не удалась, процесс зациклился. Через некоторое время что-то там Москито поругался.
Потом в 23.42.44 установился мой флаг ошибки, цикл завершился неудачей.
В 23.42.49 перезапустился сервис gpio.
Далее я сбросил свою ошибку и операция выполнилась повторно без проблем.
Замечу, что перед опытной включения выхода никаких других действий скрипит не выполнял и выходы не щёлкал. (Если быть точнее, то по tcp ip была отправлена команда на включение лампочки в удаленном щите, но скорее всего она даже не дошла туда на момент управления выходом, да и в целом лампочка не должна была создать критических помех.)
С одной стороны вижу, что много сообщений i2c i2c-2: sendbytes: NAK bailout в dmesg, которые возникают при ошибке ядра при общении с боковыми модулями. Я бы для начала выключил бы контроллер, разъединил всю цепочку восьми боковых модулей, подключенных непосредственно к контроллеру, визуально осмотрел контакты и подключил бы модули заново.
С другой стороны я наблюдаю что в этот период времени, который вы проиллюстрировали скриншотами, у вас падает и перезапускается wb-mqtt-gpio: wb-mqtt-gpio.service: Main process exited, code=killed, status=4/ILL. Тут я не вижу совпадений по времени с “NAK bailout”, правда.
Скажите, в вашем правиле сообщения “Включен "WaterPower": wb-gpio/EXT1_R3A6” пишутся при попытке изменить состояние, или при опросе?
Пока две гипотезы у меня: первая – контакты, вторая – нестабильное поведение wb-mqtt-gpio при большой нагрузке. Давайте сначала попробуем исключить первую.
При попытке изменить состояние. Он считывает текущее состояние, и если оно не совпадает с требуемым, то производится запись и выводится эта надпись в лог. Поэтому по дублированию этой надписи можно сделать вывод, что запись не произведена. Если всё ок, то запись однократна.
Понял, спасибо! То есть вот большое количество сообщений означает, что на самом деле не было включено, и соотвтетственно, мноогократно отправлялить i2c-команды на модуль.
Ага. Плюс в прошлые разы, сейчас не пробовал, срабатывал такой способ: стоит в веб-интерфейсе этот выход передернуть вручную, то он и из правил сразу оживал.
Это, да, выглядело как проблема с подключением к MQTT-брокеру: веб-интерфейс постоянно держит соединениt с брокером, а у движка правил – сбой. Потому что если бы в этот момент была проблема именно у wb-mqtt-gpio, то он бы и через веб-интиерфейс не включил.
Ну как сказать - вопрос то никуда не делся. Только проблема проявляется достаточно редко, пока возразить нечего. А так конечно - зависающие изредка выходы напрягают. Я сделал скрипт ловушку, буду отслеживать.
Спасибо, понял! А что ловит скрипт?
А процедуру “рассоединить – посмотреть на контакты – соединить” получилось сделать?
Хочется определить, что может быть причиной сбоев на i2c-шине (у вашего контроллера восемь с небольшим месяцев гарантии).
Скрипт ловит попытку более 3 раз подряд включить или выключить выход.
Я пока только попробовал их пошевелить, проверить, что все друг к другу стоят, но не увидел пока ничего. Возможно попробую сниму, но по опыту работы с электроникой - вряд ли что-то увижу. Если только их разобрать. А так - контакты и контакты. При наличии возможности гляну.
