Добрый день.
На контроллере Wiren Board 8 перестал работать поиск устройств в WebUI.
Что проверено:
-
wb-device-manager запущен.
-
wb-homeui-backend запущен.
-
WebUI при нажатии кнопок реально публикует MQTT RPC:
-
bus-scan/Start/...
-
bus-scan/Stop/...
-
При этом поиск устройств не запускается нормально, а wb-device-manager пишет:
-
В ряде случаев при остановке сервиса есть:
-
State 'stop-sigterm' timed out. Killing.
-
Task was destroyed but it is pending!
-
упоминание Build & publish overall bus scan state
-
wb/device_manager/bus_scan_state.py:237
-
Обновили:
-
wb-homeui-backend
-
wb-mqtt-homeui
-
wb-mqtt-serial
-
Переустановка wb-device-manager, рестарты сервисов, очистка /tmp/wb-device-manager не помогли. Так же не помогло и обновление на новую прошивку 2606.
-
RS-485 отдельно проверяли. На текущий момент линия выглядит чистой: в wb-mqtt-serial нет invalid crc, invalid packet, request timed out. То есть проблема сейчас не похожа на текущую грязную шину, а именно на зависшее состояние bus-scan в wb-device-manager.
приложен диагностический архив, доступен только сотрудникам поддержки
(474,8 КБ)
Помогите восстановить контроллер, пожалуйста.
Thinking
Search uploaded documents
Found 5 uploaded document excerpts for ‘wb-device-manager bus-scan already processing stop-sigterm timeout’
Здравствуйте! Я — автоматический помощник техподдержки Wiren Board.
Сейчас выходной — я постараюсь помочь сразу, а в ближайший рабочий день
инженеры посмотрят тему и ответят.
По логам похоже не на «грязную» RS-485, а на зависание самого wb-device-manager в состоянии bus-scan: запросы /rpc/v1/wb-device-manager/bus-scan/Start/... уже считаются «processing», а при остановке сервис не успевает корректно завершиться и его приходится убивать по timeout.
Что можно проверить сейчас:
-
Посмотреть, не остался ли зависший скан в MQTT/RPC-состоянии
mosquitto_sub -v -t '/rpc/v1/wb-device-manager/#' -C 50
И параллельно попробовать запуск поиска из WebUI один раз.
-
Остановить только сервис и запустить его в отладке в консоли
systemctl stop wb-device-manager
wb-device-manager -d
После этого снова нажать поиск устройств и посмотреть, на чём именно он «залипает» до появления already processing.
-
Проверить, нет ли старого зависшего процесса/дочернего потока
ps -ef | grep wb-device-manager
journalctl -u wb-device-manager -n 200 --no-pager
-
Если проблема воспроизводится даже на новой прошивке и после переустановки пакетов, это уже похоже на внутреннее состояние/баг wb-device-manager; тут лучше приложить в тему:
journalctl -u wb-device-manager -n 200 --no-pager- вывод запуска в отладке
wb-device-manager -d
- результат
mosquitto_sub по /rpc/v1/wb-device-manager/#
По найденным фрагментам у меня нет точной инструкции, как «сбросить» именно это состояние без риска, поэтому дальше уже лучше дождаться инженеров в рабочий день — они посмотрят ваш архив диагностики и, если нужно, подскажут безопасный обходной шаг.
Примечание: я — ИИ, а не человек; в моих ответах возможны неточности.
Инженеры посмотрят тему в ближайший рабочий день. Если хотите ускорить —
приложите диагностические данные.
Я не понял почему, но всё заработало… )))
теперь у меня вопрос: что это было? )))
После запуска wb-device-manager -d вручную поиск устройств ожил.
Добрый день!
Для диагностики проблемы пришлите, пожалуйста, архив с диагностической информацией контроллера. Создание архива описано в документации.
