Wbio-di-wd-14

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

здравствуйте, в очередной раз беда с боковым модулем. на скрине виден модуль wbio-di-wd-14, с адресом 150:2, на картинке видно что все его входы включены, но это не так! к модулю подключены выключатели (звонкового типа с механической блокировкой-для управления жалюзи), через сценарий в спрутхабе этими выключателями открываются/закрываются жалюзи. я уже обращался к вам с этой проблемой , но решение найдено не было. диагностический архив приложил. модуль wbio-di-wd-14 подключен к wb-mge v.2.

ещё смущает постоянно повторяющаяся ошибка в системном журнале-i2c i2c-2: mv64xxx_i2c_fsm: Ctlr Error – state: 0x7, status: 0x0, addr: 0x60, flags: 0x1.

Добрый день! Прошу сделать следующее:

1. Сфотографировать выключатель звонкового типа
Нужно несколько фотографий: общий план (как выключатель установлен, видна вся панель или место монтажа) и укрупнённый вид — спереди (маркировка, тип) и сзади или со снятой клеммной колодкой (схема подключения контактов: NO/NC/COM). По фото станет ясно, какой именно контакт задействован и не является ли он нормально замкнутым (NC).

2. Сфотографировать модуль 150:2
Нужно несколько фотографий: общий план (модуль в составе щита, видно его положение и соседние устройства) и укрупнённый вид клеммной колодки — крупно, чтобы было видно, к каким клеммам подключены провода и подключена ли клемма iGND.

3. Подключение iGND
Проверьте мультиметром: есть ли на клеммах IN1–IN14 модуля 150:2 напряжение ~5 В относительно клеммы iGND при разомкнутом выключателе? Если да — iGND подключён правильно, и нужно проверять полярность выключателей. Если нет (~0 В) — iGND не подключён или соединён неправильно.

4. Схема подключения
Уточните, куда идёт второй провод от выключателей — на iGND модуля или на что-то другое (например, на плюс питания или на общий провод щита)?

С подключением проводов нет проблем, в нормальном состоянии всё работает правильно-держишь одну клавишу-штора поднимается, держишь другую -штора опускается, между клавишами механическая блокировка. Но , примерно раз в неделю случается какой-то сбой (как раз во время такого сбоя создан диагностический архив), и все входы WBIO-DI-WD-14 оказываются включены. Я уверен это какой-то программный сбой, в ошибку всегда уходит один и тот же блок (150:2). Вы в диагностическом архиве ничего странного не обнаружили?

Как можете прокомментировать ошибки в системном журнале?

Забыл сказать, это состояние лечится перезагрузкой модуля mge v2 (к нему подключается модуль WBIO-DI-WD-14 150:2) по питанию.

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

При рестарте службы wb-mqtt-serial модуль 150:2 (WBIO-DI-WD-14) периодически пропускается в ходе инициализации: служба не записывает регистры конфигурации и не переходит к опросу этого модуля, хотя соседние модули того же WB-MGE (150:1, 150:3–150:6) инициализируются штатно. После этого MQTT-топики входов 150:2 остаются в последнем известном состоянии — «все входы = 1» — и не обновляются до следующего успешного подключения.

Вероятная причина — кратковременная перегрузка TCP-канала к WB-MGE в момент рестарта: модуль не успевает ответить в отведённый таймаут и пропускается. Это подтверждается предупреждением «Register read rate limit is exceeded» на порту 192.168.30.50:23, которое фиксируется сразу после каждого рестарта.

Обесточивание модуля на 20–30 секунд перезагружает его, после чего при следующем опросе wb-mqtt-serial видит устройство и инициализирует корректно — отсюда и эффект временного исправления.

Отдельно по записям в системном журнале вида:

i2c i2c-2: mv64xxx_i2c_fsm: Ctlr Error — state: 0x7, status: 0x0, addr: 0x60, flags: 0x1

Эти записи с описанной проблемой не связаны. Они появляются на внутренней шине i2c-2 контроллера и относятся к периодическому опросу embedded controller (EC) по адресу 0x60 — компонента, который присутствует не на всех ревизиях платформы. Когда EC недоступен, драйвер шины фиксирует ошибку в журнале, однако на работу WBIO-модулей, wb-mqtt-serial и MQTT-брокера это никак не влияет. Эти записи носят исключительно информационный характер и не требуют каких-либо действий с вашей стороны.

Прежде чем мы передадим информацию о найденном баге разработчикам, просим вас обновить программное обеспечение контроллера, прошивку WB-MGE v.2 и прошивки модулей WBIO до актуальных версий. Это важно: баги значительно проще воспроизвести и исправить на актуальной версии прошивки, и не исключено, что часть поведения уже изменилась в новых релизах. На контроллере сейчас установлен релиз wb-2507, актуальный стабильный релиз — wb-2602.

Обновление ПО контроллера — через веб-интерфейс (Настройки → Обновление ПО) или по SSH:

apt update && apt upgrade

Прошивки модулей обновляются через wb-cli. Для устройств за WB-MGE потребуется socat-переброс порта — инструкция: Обновление прошивки Modbus-устройств Wiren Board — Wiren Board

Если после обновления проблема повторится — пожалуйста, соберите новый диагностический архив в момент сбоя и приложите к этому обращению, мы передадим баг-репорт разработчикам.

По-моему боковые модули я обновлял из вэб-интерфейса Wirenboard, в настройках драйвера serial устройств. Попробую обновиться на новый релиз.

Добрый день, Сергей. Прошу обновить, как модули, так и прошивку контроллера, не сочтите за занудство )))

Обновил контроллер до актуального релиза.

На интересующем меня модуле (который сбоит) установлены актуальные последние версии загрузчика и прошивки (как я понимаю). Буду смотреть.

Вот фото щита, в котором стоит этот модуль. Подскажите, на mge v2 нужно обновлять прошивку, если да , то как мне это сделать?

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

Опять в ошибке модуль 150:2.

На фото модуль 150:1.

А, это 150:2.

Диагностический архив приложил.

Добрый день. Документация MGE v2 этот процесс не описывает, поэтому обновлять не будем.

Добрый день.

Благодарю за проделанные шаги.

Я считаю, что тут может быть причастно либо поведение wb-mqtt-serial, либо дефект конкретного экземпляра модуля (тот самый 150:2). Скажите, а есть возможность поменять местами 150:1 и 150:2? Судя по диаг. архиву и фотографиям, это одинаковые 14канальные модули. Этот шаг позволит сузить область поисков для решения задачи.

Да, я уже менял их местами. Правда , это было давно, не помню конкретно. Попробую ещё раз, потом напишу.

Что в этом случае произошло - сбои переместились на адрес 150:1 (то есть ушли за физическим устройством) или остались на адресе 150:2?

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