Странно, в папке с конфигом лежал какой-то файл типа *old, с оригинальной рабочей конфигурацией, а вы говорите что конфиг восстановить не получится.
Обновление прошивки контроллера Wiren Board 8.5 — Wiren Board
Здесь как-то недостаточно информации по поводу того, какой вариант выбирать и чем они отличаются.
Добрый день!
Прошу сообщить с какого релиза обновлялись.
Пригласите пожалуйста пользователя support@wirenboard.com в организацию на облачном сервисе.
Для этого в настройках организации нажмите кнопку “Пригласить”
Добавил приглашение. Я сейчас доступен через чат tg в течение 4х часов, если это необходимо
В какой директории вы нашли этот файл?
ssh запаролен - не могу посмотреть.
Сейчас проблема на шине RS-485-1? Какие устройства подключены?
В какой директории вы нашли этот файл?
Он был там же, где и конфиг serial. У него имя было кажется wb-mqtt-serial.conf.ucf-old
wb-mqtt-serial.conf.ucf-old (14,8 КБ)
Этот конфиг работал до обновления.
Сейчас проблема на шине RS-485-1? Какие устройства подключены?
Да. Все те, которые в конфиге.
Кстати говоря, релиз на устройствах не обновлял. Может в этом проблема?
Автоскан:
| 23-06-2025 01:02:09.771 | WARNING: </dev/ttyRS485-1 115200 8 N 2>: closed due to repetitive errors |
|---|---|
| 23-06-2025 01:02:04.760 | WARNING: </dev/ttyRS485-1 115200 8 N 2>: closed due to repetitive errors |
| 23-06-2025 01:01:59.749 | WARNING: </dev/ttyRS485-1 115200 8 N 2>: closed due to repetitive errors |
| 23-06-2025 01:01:54.737 | WARNING: </dev/ttyRS485-1 115200 8 N 2>: closed due to repetitive errors |
| 23-06-2025 01:01:49.722 | WARNING: </dev/ttyRS485-1 115200 8 N 2>: closed due to repetitive errors |
| 23-06-2025 01:01:44.711 | WARNING: </dev/ttyRS485-1 115200 8 N 2>: closed due to repetitive errors |
| 23-06-2025 01:01:39.698 | WARNING: </dev/ttyRS485-1 115200 8 N 2>: closed due to repetitive errors |
| 23-06-2025 01:01:34.694 | WARNING: </dev/ttyRS485-1 115200 8 N 2>: closed due to repetitive errors |
| 23-06-2025 01:01:29.675 | WARNING: </dev/ttyRS485-1 115200 8 N 2>: closed due to repetitive errors |
| 23-06-2025 01:01:24.667 | WARNING: </dev/ttyRS485-1 115200 8 N 2>: closed due to repetitive errors |
| 23-06-2025 01:01:19.654 | WARNING: </dev/ttyRS485-1 115200 8 N 2>: closed due to repetitive errors |
| 23-06-2025 01:01:14.616 | WARNING: </dev/ttyRS485-1 115200 8 N 2>: closed due to repetitive errors |
| 23-06-2025 01:01:09.604 | WARNING: </dev/ttyRS485-1 115200 8 N 2>: closed due to repetitive errors |
| 23-06-2025 01:01:04.591 | WARNING: </dev/ttyRS485-1 115200 8 N 2>: closed due to repetitive errors |
| 23-06-2025 01:00:59.581 | WARNING: </dev/ttyRS485-1 115200 8 N 2>: closed due to repetitive errors |
| 23-06-2025 01:00:54.595 | WARNING: [serial device] device </dev/ttyRS485-1 115200 8 N 2> modbus:130 is disconnected |
Добрый день!
Нет, со старыми прошивками устройства должны были работать.
Одно WB-MR6C вручную добавил. У вас на порту была скорость 115200, как выставил 9600 – устройство нашлось.
Автопоиск тоже все увидел:
Пробуйте использовать свой конфиг. Коллеги подсказали, что он появляется при обновлении через apt.
Интересно… я правильно понимаю, что все устройства нашлись на 9600? Дело в том, что они до обновления были на 112500…
Непонятная история…
Устройства нашлись, но нашлись через медленное сканирование.
О чем говорит красная ошибка в заголовке?
Мой конфиг заработал. Вопрос вроде бы и решён, но какая была проблема я так до конца и не понял)
Обнаружил множественные ошибки линии связи в логах, включая CRC и более важную (при старте службы wb-mqtt-serial):
ERROR: [serial] File: /etc/wb-mqtt-serial.conf error: Validation failed.
config.txt (15,4 КБ)
Как узнать, в какой строчке ошибка валидации? логи неинформативны.
Переделывать весь конфиг заново неохота.
Приложите, пожалуйста, диагархив.
Создание архива описано в документации.
Наверное, вам будет удобнее зайти через облако самим вживую посмотреть? доступ еще открыт
Кстати говоря, мне кажется после апдейта мой старый конфиг нормально не заехал - например, “потерялись” имена устройств как минимум. Я еще подумал когда выбирал, что теоретически, при апдейте могли поменять формат хранения конфига?
Буду признателен, если сможете восстановить мой старый конфиг…
И еще - в ходе тестов я включал для опроса разные параметры, такие как “Напряжение питания”, “аптайм” и т.д. Выбрал период, не обратив внимание, что там миллисекунды, поставив число 1))) только в дебаг режиме увидел, что конфиг парсер ругается, что ожидает не менее 10мс число. Было бы неплохо хотя бы на веб-форме написать, что не рекомендуется ставить менее 10мс, или сделать окно “вы уверены?”…
Похоже эт самое… Сканирование почему-то работало только медленно, оно крутилось кажется, минут 20. Я решил, что все устройства найдены. Применил всем скорость 115200 и сохранил. Потом в логах вижу множественные ошибки CRC. Короче, решил еще раз посканировать - и нашлось одно устройство, которое осталось на 9600… Я уже несколько раз обращал внимание, что после применения новой скорости как-то не все устройства принимают новую скорость…
Думаю, ошибки CRC были связаны с устройствами с разной скоростью.
Остался вопрос за малым - как восстановить конфиг… Я не рядом с контроллером и семья рискует остаться без света))
Для теста выключил все устройства на шине. Оставил только одно, параметры “Напряжение питания”, “аптайм” и т.д. включил в режиме “в порядке очереди”. Увидел в веб-интерфейсе, что значение температуры, напряжения быстро-быстро меняетя, по всей видимости, загружаая канал или возможно, требуя от самого реле слишком частой и быстрой отдачи данных и это вызывает таймауты и ошибки CRC. Может быть такое?
Похоже, быстрый модбас не очень применим для этих точек, т.к. уж очень часто меняютя показания. Одно из решений - это “загрубить” изменения температуры\напряжения внутри модулей, чтобы снизить “шумящую” нагрузку на канал данных. Т.е. для температуры достаточно например, 0.1. Но есть особенность - температура МК как раз пляшет 34.9-35.0)))
Куда залезть под капот, чтобы посмотреть, как там себя ведет трафик и как чувствует себя устройство?
Добрый день!
Настоятельно не рекомендую выполнять удалённо потенциально опасные действия — такие как работа с конфигурацией, обновление системы и другие операции, способные вызвать перезагрузку или потерю связи. Это может привести к аварийной ситуации и потерю доступа к контроллеру.
Что касается быстрых откликов:
Если используется опрашивать в порядке очереди, то устройства опрашиваются в последовательное каждое по очереди. Сейчас у вас, вероятно, шина не загружена, поэтому и отклик максимальный.
Если нет необходимости в высокой частоте опроса, можно увеличить интервал, например, установить время опроса 200 мс и выше.
посмотреть, как там себя ведет трафик и как чувствует себя устройство?
Прошу уточнить, что именно вы ожидаете увидеть? Это поможет точнее дать рекомендации.
хотел попытаться оценить, насколько сильно включение опции " опрашивать в порядке очереди" загрузит процессор и сеть. Есть основания полагать, что " опрашивать в порядке очереди" для очень быстро меняющихся показаний (температура и напряжение) значительно увеличивает трафик\нагрузку на драйвер.
Меня смущает наличие двух процессов wb-mqtt-serial (белый и зеленый) в htop, которые едят 12% процессора каждый при 1 включенном модуле.
Часть модулей в шкафу, другая часть модулей на 2 этаже, длина линии порядка 25 метров. Оконечного резистора нет. Я не знаю, может быть у меня и до этого были ошибки CRC, просто не обращал внимание, т.к. модули “не краснели”. Понаблюдаю с 1 модулем, отпишусь.
UPD1 Сделал эксперимент: оставил на шине только одно устройство с галкой “опрашивать устройство” с включенным опросом температура\напряжение с частотой 1с. Все равно идут ошибки CRC.
UPD2 Сейчас выключил опрос температура\напряжение, понаблюдаю…
UPD3: оставил одно устройство, все равно идут ошибки CRC.
Еще одна гипотеза: в самом устройстве предыдущей конфигой был задан режим работы входов\выходов по маппинг-матрице. А в текущей “онлайн” конфиге выбран режим “не задано”. Не может ли быть такое, что драйвер быстрого модбаса в WB контроллере выполняет задачи опроса “по-своему” (не зная о режиме маппинг), а в это время модуль реле с внутренней конфигой отрабатывает их “по своему” и пакеты “сталкиваются”, вызывая ошибки CRC?..
UPD4 выключил опрос реле, включил опрос диммера, у него в конфигурации было настроено только режим RGBW и скорость.
При сохранении и запуске опрос в логах увидел “Failed to write:***\ illegal data address”…
Может, с какими-то шаблонами что-то случилось?.. Что-то где-то старое, а что-то новое?
Остается еще доступный вариант удалить всю конфигу и просканировать заново и добавить устройства заново, но мне придется тогда придется вручную разбирать файл конфигурации, а это довольно муторно, т.к. в конфиге заданы числовые значения для регистров настройки режимов…
UPD5 Failed to write:***\ illegal data address" по адресу 416. Это режим работы входов. Режим появился начиная с прошивки 3.5.0. У меня 3.4.1.
Похоже, wb-mqtt-serial пытается писать в регистр, которого нет)))
Похоже, разные версии драйвера wb-mqtt-serial по-разному совместимы с предыдущими прошивками.
Какой план апгрейда прошивок WB в таком случае? что обновлять первым, что вторым? Сначала контроллер, потом модули и т.д… Я обновил контроллер по документации, но там не было речи, что модули со старыми прошивками могут вызвать ошибки связи))
И да, повторю вопрос - можно ли мою конфигу до обновления как бы “восстановить”?.. Я полностью вставлял предыдущую конфигу в текущий файл wb-mqtt-serial, мне показалось, она “завелась” но как-то странно. (в предыдущей конфигурации устройствам были заданы имена, в конфигурации после апдейта WB имена не отображаются). У меня под подозрением что формат конфигурации wb-mqtt-serial был изменен после апдейта а я ему подсунул “старый” конфиг.
Вынесу UPD отдельно:
на линии только 1 WB-LED. Обновил прошивку модуля. Ошибка в логе по адресу 416 ушла.
Осталась ошибка после сохранения конфиги Failed to read 270 адреса “invalid CRC”.
По мануалу:
270-271 0x010E - 0x010F Input RO u32 Серийный номер
Появляется с периодичностью примерно в 3 минуты.
PS включены параметры опрашивать температура платы\мощность и другие в разделе диагностики модуля.
Добрый день!
Можете, пожалуйста, прислать свежий диагностический архив?
Предварительно проблема выглядит как физическая — ошибки CRC чаще всего указывают именно на это.
Рекомендую проверить подключение на соответствие правилам прокладки шины RS-485.
Обратите внимание: терминаторы обязательны, особенно при повышении скорости обмена. Чем выше скорость, тем чувствительнее шина к помехам.
Попробую при возможности поставить терминатор.
Все что написано выше - да, часть ошибок ушла, потому что в прошивках моих устройств не были регистры, которые появились в новых прошивках wb-mqtt-serial. Было бы неплохо видеть в мануалах “таблицу совместимости” для прошивок, чтобы было понятно, что для определенных прошивок WB необходимо устанавливать “нужные” прошивки для модулей.
Остались некоторые ошибки в CRC error 1 раз в минуту, вынес в отдельную тему
Каким образом контролировать качество каналов связи? - Без категории - Wiren Board Support
Обычно адресация старых регистров не изменяется при добавлении новых.
Не понимаю как новые регистры могли повлиять на возникновение ошибок. Можете привести пример в каком устройстве с этим столкнулись?
Вам удалось вернуть все подключенные устройства в строй?
Да, я же описал. Обновил WB, но не обновил модули. Появилась ошибка:
Failed to write:***\ illegal data address" по адресу 416.
Я пишу: “Это режим работы входов. Режим появился начиная с прошивки 3.5.0. У меня 3.4.1.”
Все верно, адресация старых не поменялась, добавились новые, посыпались ошибки в логах. Не увидел либо нет в руководстве по апгрейду необходимости обновлять и прошивки модулей тоже вместе с контроллером.
Вам удалось вернуть все подключенные устройства в строй?
Устройства работают, но я не знаю как восстановить прежнюю конфигу, она как-то не заехала (как будто применилась не вся - имена и настройки поведения входов\выходов не заехали). Теперь не знаю что делать, заново конфигурить, но это хлопотно.
