Не работает облако, ошибки в обновлении

1

Ну не знаю как такое возможно… За оперативность в обмене контроллера конечно 5+. Но вот достал я новый контроллер из коробки, подключил его к ПК для настройки, сразу же настроил MobaXterm, и что ?! К облаку подключения нет, выдает ошибки, пробовал исправить по инструкции, не помогло. Выполнил обновление apt update && apt upgrade && reboot, не помогло. В добавок выскочила такая ошибка dcdc4: disabling. И что теперь делать - опять ковыряться в мозгах этого чудо девайса ?! по адресу 10.200.200.1 интерфейс открывается, но с трудом, половина страниц не загружается. Ни прошивку ни диагностический файл скачать не получается. Дом уже неделю сидит на простой ардуинке и она справляется.

Screenshot (11)
Screenshot (11)805×589 16.9 KB

Screenshot (10)
Screenshot (10)731×173 6.76 KB

Screenshot (9)
Screenshot (9)862×608 17.4 KB

[com COM9] (2026-01-24_134448) Debug consol.log (106,7 КБ)

3

Здравствуйте! Сегодня выходной день, поэтому сотрудники техподдержки ответят вам в рабочий день.
Пока что я, автоматический помощник, проанализировал ваш вопрос и постарался найти решение:

Судя по описанию, у вас новый контроллер Wiren Board (по интерфейсу и логам, вероятнее всего WB7/WB8), на котором:

  • облако не добавляется («Ссылка не действительна»),
  • сервисы обновления/диагностики в веб‑интерфейсе были недоступны,
  • интерфейс по 10.200.200.1 грузится рывками,
  • в логе консоли есть dcdc4: disabling.

Ниже – что можно проверить самому до ответа инженеров.

1. Проверить базовое состояние контроллера

Через консоль (MobaXterm, root@wirenboard):

dmesg | grep -i dcdc
journalctl -u wb-hwconf-manager --no-pager -n 50
df -h
free -m
top -b -n1 | head -n 20

Сделайте скриншот или сохраните вывод в файл и приложите в тему. Нас интересует:

  • нет ли массовых ошибок по питанию/SD‑карте;
  • не забит ли rootfs (df -h – раздел / должен быть свободен хотя бы на 30–40%);
  • нет ли процесса, который нагружает CPU на 100% (это объяснит «затыки» веб‑морды).

dcdc4: disabling сам по себе обычно не критичен – это сообщение о выключении одного из DC/DC после инициализации и не мешает работе[1].

2. Проверка сети и доступа к облаку

  1. Убедитесь, что контроллер имеет доступ в интернет:

    ping -c 4 8.8.8.8
ping -c 4 support.wirenboard.com

    Если пинг до IP есть, а до доменов – нет, проблема в DNS (проверьте /etc/resolv.conf, настройки роутера).

  2. Проверьте, что время и дата верные:

    date
timedatectl

    Если дата сильно «уехала», облако и HTTPS‑сертификаты могут не работать. Временно установите вручную:

    date -s "2026-01-24 15:00"

    затем снова попробуйте облако. Позже желательно настроить NTP по инструкции[2].

3. Обновления и репозитории

Вы уже делали apt update && apt upgrade, но судя по скрину сервис обновления прошивки был «недоступен». Такое бывает, если:

  • неудачно отработал один из wb‑скриптов,
  • или в момент захода в раздел «Система» ещё не поднялись нужные сервисы.

Проверьте состояние репозиториев и наличие ошибок:

apt update
grep -i wirenboard /etc/apt/sources.list.d/* -n

Если есть красные ошибки 404/Temporary failure resolving, сохраните вывод и приложите в тему.

4. Нестабильный веб‑интерфейс

Чтобы понять, подвисает ли сам контроллер или только nginx/Node‑часть:

  1. Откройте параллельно ssh и выполните:
    tail -f /var/log/nginx/error.log
journalctl -u wb-webui -f
  2. В это время обновляйте тяжелые страницы веб‑интерфейса. Если в логах посыпятся ошибки (например, out of memory, bad gateway и т.п.) – скопируйте и приложите.

Также посмотрите, не забит ли логами /var/log:

du -sh /var/log/*

Если какой‑то лог занимает сотни мегабайт, напишите об этом.

5. Облако: «Ссылка не действительна»

Сообщение обычно означает:

  • токен/ссылка уже была использована с другим устройством или устарела;
  • либо контроллер не может достучаться до облака и запрос подтверждения «ломается» по пути.

Проверьте:

  1. В личном кабинете облака удалите этот контроллер, сгенерируйте новую ссылку/QR.

  2. На контроллере:

    systemctl status wb-cloud-agent.service
journalctl -u wb-cloud-agent --no-pager -n 100

    Если там есть явные ошибки подключения — приложите вывод.

  3. Повторите привязку по свежей ссылке.

Инструкции по облаку[3] помогут свериться с шагами.

6. Возможный аппаратный дефект / SD‑карта

Так как это уже второй контроллер подряд с аномальным поведением, стоит исключить проблемы с носителем:

  1. Выполните быструю проверку карты:

    dmesg | grep -i mmc
smartctl -a /dev/mmcblk0  # если доступно

  2. Если будут постоянные ошибки I/O, mmc timeout и т.п. – высока вероятность брака SD‑карты или самой платы. В этом случае:

    • ни перепрошивка, ни обновление проблему не решат;
    • сохраните полные логи (dmesg, journalctl -b, вывод тестов) и дождитесь инженеров – это поможет оперативно принять решение по замене.

7. Что ещё хорошо приложить к теме

Чтобы инженеры в будни быстро помогли, соберите максимум данных:

  1. Выводы команд из пунктов 1–6 в текстовых файлах.
  2. Содержимое /etc/wb-release:
    cat /etc/wb-release
  3. Уточните, какая модель контроллера (WB7, WB8, WB8.5), как он подключен к интернету (Ethernet через какой роутер, есть ли VPN/прокси, фильтрация трафика).

Если что‑то из команд не выполняется или даёт ошибку, просто скопируйте текст ошибки в ответ. По этим данным будет понятно, это программный сбой или действительно аппаратная проблема, и в будний день смогут либо предложить восстановление, либо сразу оформить повторную замену.

Примечание: Я — искусственный интеллект, а не человек. В моих ответах могут быть неточности.

  1. https://wirenboard.com/wiki/WB_7_Troubleshooting (аналогичные сообщения в dmesg обычно игнорируются) ↩︎

  2. https://wirenboard.com/wiki/Time_synchronization ↩︎

  3. Wiren Board Cloud — удалённое администрирование — Wiren Board ↩︎

5

Все сделал как смог. Логи прикладываю. Смог сбросить контроллер до заводских настроек с перепрошивкой. Не уверен в его корректной работе, можно ли его в таком состоянии ставить в систему ?! К облаку подключился только когда подключил кабель от роутера.

[com COM9] (2026-01-27_103334) debug consol.log (606,3 КБ)

приложен диагностический архив, доступен только сотрудникам поддержки
(157,5 КБ)

приложен диагностический архив, доступен только сотрудникам поддержки
(154,9 КБ)

8

Откровенно говоря я не понимаю зачем (для чего) нужно было в процессе шесть раз выключать контроллер долгим нажатием кнопки питания.

Так, в каком состоянии? То есть чем работа отличается от ожидаемого?

9

Тем что работа отличается от ожидаемого, а именно:

  1. не устраивает эта запись - wirenboard-AW5YHHOG login: [ 33.766629] dcdc4: disabling;
  2. при загрузке первого правила ошибка - Error listing the configs: MQTT RPC request timed out MqttTimeoutError;
  3. далее контроллер завис;
  4. диагностический файл не скачивается;
  5. тем что есть какая то проблема, а какая никто не говорит

Screenshot (12)
Screenshot (12)645×293 28.2 KB

И это я достал новый контроллер из коробки, включил, обновил и на этом все…
действительно, что меня должно устраивать ?!

[com COM9] (2026-01-28_002921) debug consol.log (177,3 КБ)

10

А чем?
То есть - считаете что этот преобразователь должен работать? Но почему?

Какого правила? Покажите пожалуйста, если сложное - то опишите как оно должно работать.

Вот тут интересно. “Завис” - что пошло не так?

  • пинг перестал возвращаться?
  • ответ веб-интерфейса?
  • Еще что-то?

Что выводится при его, архива, формировании?

Предлагаю разобраться по порядку. Собственно контроллер - он ничем от того компьютера за которым работаете не отличается.

Я наблюдаю аномальное потребление памяти wb-rules. Что именно выполняется?

11

Прошу прощения за эмоции, разобрался, от загруженного правила зависал контроллер. Пока работает в штатном режиме.

12

Да не за что, у нас цель - понять есть ли баги.

Рекурсивный вызов (цикл) скорее всего?

13

да