WB-MSW-ZIGBEE v.4: Errata

ERRWB-MSWZv40001: Зависание датчика при работе по протоколу Zigbee

Подверженные устройства

Все WB-MSW-ZIGBEE v.4 с прошивкой 1 версии. Версию прошивки надо смотреть в Zigbee-координаторе.

Описание

Датчик может работать нормально, потом вдруг перестаёт реагировать на команды и отправлять данные.

Причины и подробное описание

Проблема затрагивает только радиомодуль устройства и не проявляется при работе по протоколу Modbus RTU.

Запланированное исправление

Исправлено в прошивке 5 версии.

Пути обхода

Обновить прошивку по инструкции.

ERRWB-MSWZv40002: Зависание показаний датчика по протоколу Zigbee

Подверженные устройства

Все WB-MSW-ZIGBEE v.4 с прошивкой до 5-й версии включительно. Версию прошивки надо смотреть в Zigbee-координаторе.

Описание

При работе по Zigbee показания сенсоров датчика могут «застыть» и не меняться.

Причины и подробное описание

Из-за ошибки в прошивке датчик перестаёт считывать значения из сенсоров, притом исправно отдаёт по протоколу Zigbee старые показания, поэтому в логах нет ошибок.

Запланированное исправление

Исправлено в версии прошивки 61. Обновите прошивку.

Пути обхода

Обновить прошивку по инструкции.

ERRWB-MSWZv40003: Не работают ИК-команды по протоколу Zigbee

Подверженные устройства

Все WB-MSW-ZIGBEE v.4 с прошивкой 5-й версии. Версию прошивки надо смотреть в Zigbee-координаторе.

Описание

При работе по Zigbee не работает отправка ИК-команд из постоянной памяти датчика.

Причины и подробное описание

Из-за ошибки в прошивке радиомодуля команды пользователя не отправлялись в микроконтроллер датчика.

Запланированное исправление

Исправлено в прошивке 61-й версии.

Пути обхода

Обновить прошивку по инструкции.

ERRWB-MSWZv40004: Зависание показаний датчика по протоколу Zigbee

Подверженные устройства

Все WB-MSW-ZIGBEE v.4 с прошивкой до 61-й версии включительно. Версию прошивки надо смотреть в Zigbee-координаторе.

Описание

При работе по Zigbee показания сенсоров датчика могут «застыть» и не меняться.

Причины и подробное описание

Из-за зависания очереди обработки UART датчик перестаёт считывать значения из сенсоров, притом исправно отдаёт по протоколу Zigbee старые показания, поэтому в логах нет ошибок.

Запланированное исправление

Исправлено в версии прошивки 62. Обновите прошивку.

Пути обхода

Обновить прошивку по инструкции.

ERRWB-MSWZv40005: Низкий уровень сигнала связи датчика при работе по протоколу Zigbee

Подверженные устройства

Все WB-MSW-ZIGBEE v.4 (ревизия 5.4 с модулем ZigBee — ZSU) с прошивкой 62 версии. Версию прошивки надо смотреть в Zigbee-координаторе.

Описание

При спаривании датчика с координатором наблюдается низкий уровень сигнала связи и нестабильная работа датчика при отдалении от координатора. При работе указанной версии датчика совместно с WB-MSW-ZIGBEE v.4 (с модулем ZigBee — MGM210PA32JIA2) проблема проявляется реже.

Причины и подробное описание

Проблема затрагивает только радиомодуль устройства и не проявляется при работе по протоколу Modbus RTU.

Запланированное исправление

Исправлено в версии прошивки 63. Обновите прошивку.

Пути обхода

Обновить прошивку по инструкции.

ERRWB-MSWZv40006: Не обновляется состояние «Occupancy» датчика при работе по протоколу Zigbee

Подверженные устройства

Все WB-MSW-ZIGBEE v.4 с zigbee2mqtt начиная с версии 1.37.1. Версию zigbee2mqtt можно узнать через командную строку или через веб-интерфейс.

Описание

При использовании zigbee2mqtt начиная с версии 1.37.1 состояние «Occupancy» не меняется. Состояние не определено (Null) или «замирает» предыдущее состояние, которое было до обновления пакета.

Причины и подробное описание

Проблема затрагивает только радиомодуль устройства и не проявляется при работе по протоколу Modbus RTU.

Запланированное исправление

Исправлено в версии zigbee2mqtt 1.39.1 от 1 августа 2024 года.

Пути обхода

Обновите zigbee2mqtt.

ERRWB-MSWZv40007: Активация статусного светодиода приводит к зависанию датчика при работе по протоколу Zigbee

Подверженные устройства

Все WB-MSW-ZIGBEE v.4 с zigbee2mqtt начиная с версии 1.39.0. Версию zigbee2mqtt можно узнать через командную строку или через веб-интерфейс.

Описание

При использовании zigbee2mqtt начиная с версии 1.39.0 активация статусного светодиода ("Activity led") приводит к зависанию датчика при работе по протоколу Zigbee.

Причины и подробное описание

Проблема затрагивает только радиомодуль устройства и не проявляется при работе по протоколу Modbus RTU.

Запланированное исправление

Исправлено в версии zigbee2mqtt 1.40.1 от 7 сентября 2024 года.

Пути обхода

Обновите zigbee2mqtt.

ERRWB-MSWZv40008: Не обновляются показания датчиков шума, температуры, влажности и других. Управление зуммером работает

Подверженные устройства

Все WB-MSW-ZIGBEE v.4 партий v5.5T/Z1, v5.5T/Z2, v5.5W/Z, выпущенные с 15 августа по 7 октября 2025 года.

Описание

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

Причины и подробное описание

Изменения в прошивке радиомодуля привели к некорректной инициализации Zigbee-версий WB-MSW4. Так как WB-MSW-ZIGBEE v.4 собираются на базе обычных WB-MSW v.4, сокращённый тест беспроводной части на производстве не позволил выявить проблему.

Запланированное исправление

Ошибка устранена в партиях, начиная с v5.5W/Z2 и новее.

Пути обхода

Обновите прошивку датчиков по OTA до версии 71 и новее:

• инструкция для zigbee2mqtt;
• для другого ПО смотрите его документацию.

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

ERRWB-MSWZv40009: Ложное срабатывание датчика движения

Подверженные устройства

Все WB-MSW-ZIGBEE v.4 партий v5.5A/Z1, v5.5E/Z, v5.5F/Z, v5.5F/Z1, v5.5F/Z1S, v5.5F/ZS, v5.5I/Z, v5.5I/Z1, v5.5I/ZU, v5.5I/Z2, v5.5I/Z2U, v5.5I/Z3, v5.5N/Z, v5.5P/Z, v5.5P/ZU, v5.5R/Z, v5.5T/Z, v5.5T/Z1, v5.5T/Z2, v5.5W/Z, v5.5W/Z1, v5.5W/Z2.

Описание

Один раз в час может ложно срабатывать датчик движения WB-MSW-ZIGBEE v.4.

Причины и подробное описание

С интервалом один раз в час происходит передача данных со всех датчиков по ZIGBEE. В момент передачи радиомодулем потребляется больший ток, в результате чего происходит просадка внутреннего питания, что приводит к возникновению ошибочных значений канала датчика PIR. Может не проявляться при малых расстояниях между приемником и передатчиком.

Запланированное исправление

Ошибка устранена в партиях, начиная с v5.6 и новее.

Пути обхода

Если показания датчика движения критичны, то выполняется бесплатная замена по гарантии.

ERRWB-MSWZv40010: Не изменяются все данные с датчика

Подверженные устройства

Все WB-MSW-ZIGBEE v.4

Описание

В интерфейсе Z2M и в виртуальном устройстве интерфейса WB не отображаются данные c беспроводного WB-MSW-ZIGBEE v.4.

Причины и подробное описание

На плате WB-MSW-ZIGBEE v.4 есть два умных модуля — микроконтроллер который собирает данные с датчиков на плате и беспроводной модуль Zigbee, который получает эти данные от микроконтроллера и отправляет по Zigbee.

Ошибка появляется потому что у микроконтроллера есть только одна линия связи — которая выбирается физическим переключателем на плате: либо для связи с модулем Zigbee, либо для связи по проводной линии Modbus.

При попытках подключения по проводу пользователи меняют значения скорости связи модуля по Modbus. Это изменение может быть произведено двумя способами:

• При поиске в WEBUI нашего контроллера, тогда скорость будет изменена без явного оповещения пользователя.
• Пользователем вручную через использование cli утилиты modbus_client

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

Запланированное исправление

Ошибка возникает из-за изменения настроек пользователем, поэтому исправление не планируется.

Пути обхода

При возврате переключателя в беспроводной режим — нужно обязательно вернуть настройки связи такие же, как на модуле Zigbee (эти настройки можно посмотреть в интерфейсе Z2M). Изменить настройки можно через SSH-консоль контроллера утилитой modbus_client.

Полезные ссылки:

• Утилита «modbus_client»;
• Карта регистров датчика WB-MSW v.4.

Команда для изменения скорости Modbus-устройства, подключенного к порту контроллера:

$ modbus_client --debug -mrtu -b115200 -pnone -s2 /dev/ttyRS485-1 -a1 -t0x06 -r110 96

Здесь:

• -s2 /dev/ttyRS485-1: обращаемся к устройству подключенному к порту RS485-1 контроллера;
• -a1: адрес устройства на шине равен 1;
• -b115200: при связи используем текущую установленную в контроллере скорость 115200 бод;
• -r110: команда записывает в регистр 110 (регистр хранения скорости порта);
• 96: устанавливаем новое значение для скорости, что соответствует 9600 бит/с.

ERRWB-MSWZv40011: Неисправность переключателя между zigbee модулем и RS-485

Подверженные устройства

Все WB-MSW-ZIGBEE v.4 до ревизии 5.6.

Описание

На некоторых устройствах переключатель zigbee / RS-485 не работает.

Причины и подробное описание

Из-за быстрого механического износа контакты переключателя S1 не замыкаются. Поэтому при использовании переключателя режим работы устройства не меняется.

Запланированное исправление

Исправлено в версии v5.6.

Пути обхода

Выполняется гарантийная замена устройства.

ERRWB-MSWZv40012: Зависание показаний датчика по протоколу Zigbee

Подверженные устройства

Все WB-MSW-ZIGBEE v.4 партий с v5.5I/Z2 по v5.6C/Z13 (все устройства с Zigbee прошивками от 65 до 72 включительно).

Описание

При работе по Zigbee показания сенсоров датчика могут «застыть» и не меняться.

Причины и подробное описание

На плате WB-MSW-ZIGBEE v.4 есть два умных модуля — микроконтроллер который собирает данные с датчиков на плате (GD32) и беспроводной модуль Zigbee, который получает эти данные от микроконтроллера и отправляет по Zigbee. Из-за ошибки в прошивки модуля Zigbee, если GD32 не отвечает на несколько запросов подряд, то Zigbee модуль перестает опрашивать GD32. Отправки команды на запись (к примеру, отправка ИК комманды) или перезагрузка по питанию возобновляет опрос, но не исправляет корневую причину.

Запланированное исправление

Исправлено в прошивке версии 75.

Пути обхода

Обновите прошивку датчиков по OTA до версии 75 и новее:

• инструкция для zigbee2mqtt;
• для другого ПО смотрите его документацию.

ERRWB-MSWZv40013: Обновление по OTA не обновляло основной микроконтроллер (GD32)

Подверженные устройства

Все WB-MSW-ZIGBEE v.4 партий с v5.5W/Z по v5.6С/Z16 с OTA обновлениями до версии 72 включительно.

Описание

При обновлении по OTA, не обновлялся микроконтроллер, который собирает данные с датчиков (GD32). Устройство при этом продолжает штатно работать.

Причины и подробное описание

Начиная с партии v5.5W/Z, сигнатура прошивки GD32 изменилась (с msw5G на msw5Ge), что не было учтено в OTA обновлении.

Запланированное исправление

Исправлено в прошивке версии 75.

Пути обхода

Проблема не влияет на работу устройства. Но если есть необходимость, то обновите прошивку датчиков по OTA:

• инструкция для zigbee2mqtt;
• для другого ПО смотрите его документацию.

ERRMODBUS001: Ответ устройства на адрес 0xFD

Подверженные устройства

Устройства WB-MSW v.4 с версией прошивки до 4.31.7.

Описание

Устройства Wiren Board с расширением «Быстрый Modbus» мешают работать сторонним устройствам на одной шине, если они используют специальные команды, начинающиеся с 0xFD.

Причины и подробное описание

В нашем расширении протокола «Быстрый Modbus» зарезервированный адрес 0xFD используется для специальных широковещательных команд. Если на шине мастер отправит какому-то стороннему устройству осмысленный пакет, начинающийся с 0xFD и командами, не использующимися в расширении протокола «Быстрый Modbus», то устройство Wiren Board отвечает MODBUS_ERR_ILLEGAL_FUNCTION, тем самым мешает обмену с другим устройством. Это происходит из-за ошибки в драйвере шины, при которой пакет с адресом 0xFD начинает обрабатываться как обычный стандартный Modbus пакет.

Пути обхода

Не использовать одну шину для устройств Wiren Board и сторонних устройств.

Запланированное исправление

Исправлено в версии прошивки 4.31.7.

ERRMODBUS002: Ошибка в ответе на сканирование командой 0x46

Подверженные устройства

Устройства WB-MSW v.4 с версией прошивки до 4.31.2.

Описание

Для работы с расширенными командами в быстром Modbus использовалась функция 0x60, которая оказалась в зарезервированном пространстве. Поэтому функция работы с расширенными командами была изменена на 0x46, но для сохранения обратной совместимости устройство может отвечать и на команду 0x60. Проблема была в том, что независимо от того, через какую команду было запрошено сканирование, устройство отвечало командой 0x60. Текущее исправление позволяет отвечать той же командой, которой был произведен запрос (0x46 или 0x60).

Возможные пути устранения

Обновить прошивку до версии 4.31.2.

Запланированное исправление

Исправлено в версии прошивки 4.31.2.

ERRMODBUS003: Неожиданное поведение при записи невалидных значений в некоторые регистры

Подверженные устройства

Устройства WB-MSW v.4 с версией прошивки до 4.31.14.

Описание

При записи значений из диапазона [256 ... 65535] в некоторые регистры происходит отсечение старших 8 битов числа и в итоге в прошивку попадает число по модулю 256. Выглядит это так, что при записи, например числа 257, происходит то же самое, что и при записи числа 1.

Одним из таких регистров является адрес устройства (регистр 128).

Отдельно стоит отметить, что в диапазоне значений, указанных в документации, все регистры работают ожидаемо. Проблема возникает при записи невалидных значений более 255.

Возможные пути устранения

Обновить прошивку до версии 4.31.14.

Запланированное исправление

Исправлено в версии прошивки 4.31.14.

ERRMODBUS004: Ошибка в ответах с битовыми полями

Подверженные устройства

Устройства WB-MSW v.4 с версией прошивки до 4.31.2.

Описание

Ответы с битовыми полями (запросы coil или discrete регистров, управление событиями) возвращали неправильные значения в старших битах.

Возможные пути устранения

Обновить прошивку до версии 4.31.2.

Запланированное исправление

Исправлено в версии прошивки 4.31.2.

ERRMODBUS005: Ошибка чтения разных coil-регистров за один запрос

Подверженные устройства

Устройства WB-MSW v.4 с версией прошивки до 4.31.5.

Описание

Если несколько разных coil-регистров расположены подряд по адресам (например, 2 и 3 в WB-MSW и WB-MWAC или 3 и 4 в WB-LED), то при чтении их одним запросом возвращались некорректные значения.

Возможные пути устранения

Обновить прошивку до версии 4.31.5.

Запланированное исправление

Исправлено в версии прошивки 4.31.5.

ERRMODBUS006: Ответы на запросы с неверным битом четности

Подверженные устройства

Устройства WB-MSW v.4 с версией прошивки до 4.31.10.

Описание

Устройство отвечало на запросы, в которых указан неверный бит четности, хотя должно игнорировать такие запросы.

Возможные пути устранения

Обновить прошивку до версии 4.31.10.

Запланированное исправление

Исправлено в версии прошивки 4.31.10.

ERRMODBUS007: Потеря событий при одновременной передаче событий двумя устройствами на одной шине

Подверженные устройства

Устройства WB-MSW v.4 с версией прошивки до 4.37.1.

Описание

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

Причины и подробное описание

В быстром Modbus передача событий устроена так. Мастер отправляет запрос событий. Все устройства с накопленными событиями участвуют в арбитраже. Устройство, выигравшее арбитраж, отвечает, а проигравшие молчат до следующего запроса.

После того, как событие сгенерировано, оно ждёт отправки. После того, как устройство сформировало кадр и положило его на шину, событие считается отправленным, и в следующем запросе мастера, в котором подтверждается приём пакета от этого устройства, устройство удаляет такие события из своей очереди. Это штатный механизм «подтверждения приёма событий».

Дефект состоял в том, что переход события из состояния «ожидает отправки» в состояние «отправлено» происходил у устройства слишком рано — фактически в момент получения запроса событий от мастера, до того как был известен результат арбитража. Если устройство выигрывало арбитраж, всё шло штатно. Если устройство проигрывало арбитраж, его пакет не уходил на шину вовсе, но внутри устройства события уже были помечены как отправленные. Когда мастер при последующих циклах опроса в очередной раз отправлял подтверждение, относящееся к этому устройству, оно срабатывало и на эти псевдо-отправленные события, и они удалялись из очереди устройства, никогда не доходив до мастера.

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

Например, к контроллеру на одну шину подключены два реле. Одновременно замыкаются входы обоих реле. При этом состояние входов (выходов) одного реле в веб-интерфейсе отображается корректно, тогда как у второго часть событий потеряется. Состояние второго реле будет отображаться как до момента замыкания, несмотря на то, что физически переключение произошло.

Пути обхода

Временно сделать событийные регистры обычными — в шаблоне устройства установить значение поля sporadic в false. Таким образом, регистры будут опрашиваться с установленным временным интервалом, как и обычные регистры.

Запланированное исправление

Исправлено в версии прошивки 4.37.1.

ERRMODBUS008: Неожиданное поведение при приеме длинных кадров запросов

Подверженные устройства

Устройства WB-MSW v.4 с версией прошивки до 4.37.2.

Описание

При приеме кадра длиной более 265 байт (максимальная длина кадра Быстрого Modbus) устройство зависает и перезагружается, также в отдельных случаях возможна потеря настроек.

Причины и подробное описание

Алгоритм приема не учитывает возможность поступления некорректного удлиненного кадра запроса, из-за чего происходит переполнение буфера приема, данные в соседних с буфером ячейках памяти устройства портятся, что приводит к зависанию и перезапуску по watchdog-таймеру. В отдельных случаях при поступлении очень больших кадров данных (более ~500 байт) также портятся настройки, и после перезапуска устройство переходит на стандартные параметры связи (9600-8N2, адрес 1).

Пути обхода

• Не отправлять на устройство запросы длиной более максимальной допустимой, регламентированной спецификациями протоколов Modbus RTU и Быстрый Modbus (265 байт).

• Не подключать устройство к шине, на которой могут передаваться не-Modbus сообщения или сообщения с длиной более 265 байт.

Запланированное исправление

Исправлено в прошивке версии 4.37.2.

ERRMODBUS009: Неожиданное поведение при чтении регистров вблизи адреса 0xFFFF в режиме непрерывного чтения

Подверженные устройства

Устройства WB-MSW v.4 с версией прошивки до 4.37.2.

Описание

При включенном режиме непрерывного чтения при чтении регистров вблизи адреса 0xFFFF (с его достижением или переходом через него) устройство зависает и перезагружается.

Причины и подробное описание

Алгоритм непрерывного чтения не учитывает возможное переполнение счетчика адреса регистра (разрядность 16 бит), из-за чего при чтении регистра с адресом 0xFFFF счетчик переполняется и алгоритм зацикливается, что приводит к перезагрузке устройства по watchdog-таймеру.

Пути обхода

При включенном режиме непрерывного чтения не отправлять команды на чтение регистров с диапазоном адресов, включающим 0xFFFF. У всех устройств Wiren Board в принципе отсутствуют действующие регистры с адресом 0xFFFF.

Запланированное исправление

Исправлено в прошивке версии 4.37.2.

ERRMODBUS010: Некорректная валидация запроса и некорректная обработка неверных запросов

Подверженные устройства

Устройства WB-MSW v.4 с версией прошивки до 4.37.2.

Описание

В ряде случаев устройство может успешно или некорректно обрабатывать синтаксически неверные запросы, возвращать неверный код исключения или ограничивать максимальное количество регистров в запросе.

Причины и подробное описание

Алгоритм некорректно валидирует запрос и обрабатывает следующие случаи:

1) Запросы на чтение нулевого количества регистров успешно обрабатываются и возвращают ответ с нулевым количеством данных (только заголовок и CRC). Согласно спецификации Modbus, такой запрос должен возвращать исключение 0x03 (ILLEGAL_DATA_VALUE).

2) Единый лимит в 125 регистров для всех функций чтения и записи регистров — при превышении лимита устройство возвращает исключение 0x02 (ILLEGAL_DATA_ADDRESS). Согласно спецификации Modbus, для разных функций разные лимиты количества регистров (чтение битовых значений — 2000, чтение аналоговых регистров или регистров хранения — 125, запись coil-регистров — 1968, запись регистров хранения — 123). При превышении лимита устройство должно возвращать исключение 0x03 (ILLEGAL_DATA_VALUE).

3) Поле количества байт (Byte Count) в запросах множественной записи (коды функций 0x0F и 0x10) не проверяется, запросы обрабатываются без проверки. Согласно спецификации Modbus, в случае несоответствия поля Byte Count количеству регистров устройство должно возвращать исключение 0x03 (ILLEGAL_DATA_VALUE).

4) Функция записи одиночного coil-регистра не валидирует записываемое значение, в coil-регистр записывается старший бит из значения запроса. Согласно спецификации Modbus, устройство должно принимать только значения 0x0000 и 0xFF00, а для всех остальных значений возвращать исключение 0x03 (ILLEGAL_DATA_VALUE).

5) Структурно некорректные запросы с верным CRC (например, запросы с увеличенной длиной) обрабатываются в обычном режиме. Согласно общепринятой конвенции, устройство должно игнорировать такие запросы и не пытаться их обрабатывать.

6) Структурно корректные запросы, но увеличенной длины (от 257 до 265 байт) корректно обрабатываются. Согласно спецификации Modbus, кадры длиной более 256 байт не являются корректными Modbus-кадрами, а значит должны игнорироваться.

Пути обхода

Отправлять устройству только структурно корректные запросы, соответствующие спецификации Modbus.

Запланированное исправление

Исправлено в прошивке версии 4.37.2.

ERRMODBUS011: Некорректное поведение при отправке неверного запроса настройки событий Быстрого Modbus

Подверженные устройства

Устройства WB-MSW v.4 с версией прошивки до 4.37.2.

Описание

При обработке команды настройки событий Быстрого Modbus (EVENT_CTRL, cmd=0x46, sub_cmd=0x18) с некорректными полями длины возможны некорректная настройка уведомлений о событиях и ответ непредсказуемой длины.

Причины и подробное описание

Алгоритм при обработке команды настройки событий Быстрого Modbus не валидирует поле размера и поле длины внутреннего блока данных, из-за чего при некорректных значениях в полях длины устройство может обрабатывать данные за пределами фактически принятого кадра. В связи с этим могут наблюдаться следующие проблемы:

1) Некорректная настройка уведомлений о событиях, из-за чего могут спонтанно меняться приоритеты/маски событий

2) Ответ на команду настройки событий может быть непредсказуемой длины

Пути обхода

Отправлять только корректные команды Быстрого Modbus, соответствующие спецификации протокола.

Запланированное исправление

Исправлено в прошивке версии 4.37.2.

ERRMIR06: Проблемы при работе с ИК-приёмопередатчиком

Подверженные устройства

Все WB-MIR v2, WB-MSW с ИК с прошивкой до 4.29.7 включительно

Описание

В указанных прошивках наблюдается ряд проблем при использовании функционала ИК-приемопередатчика:

1. При работе с банками ИК-команд (запись, редактирование) с поочередным использованием coil и holding регистров значения в них могли рассинхронизироваться и ИК-модуль мог «зависнуть» и более не отвечать на команды.
2. При активной команде с одним банком можно установить в «1» coil регистры других банков.
3. Значение в регистре воспроизведения команды сбрасывалось в «0» сразу после начала воспроизведения, а не по окончании команды.
4. При записи в ROM слишком длинной команды (больше максимальной длины) запись не производилась, однако при записи в RAM записывалось столько данных, сколько могло поместиться. Из-за этого могли быть сложности с записью длинных команд в ROM.

Причины и подробное описание

Ошибка в прошивке.

Запланированное исправление

Исправлено в версии прошивки 4.29.8 от 14 июня 2023 года, обновите прошивку устройства.

Пути обхода

Если вы не можете обновить прошивку устройства, то ошибку можно обойти:

1. Использовать только один интерфейс: либо coil, либо holding регистры для работы с банками ИК-команд.
2. Сначала завершать работу с одним банком, затем начинать работу с другим (это должны быть разные Modbus-запросы).
3. Оценивать время выполнения команды и выполнять временную задержку на стороне клиента.
4. Записать длинную команду можно так: выполнить запись в RAM, считать данные и записать из ROM через редактирование банка.

ERRMIR07: Большое время ответа на команду стирания всех ИК-банков

Подверженные устройства

Все WB-MIR v2, WB-MSW с ИК с прошивкой до 4.29.10 включительно

Описание

При записи «1» в coil-регистр 5000 (стирание всех ИК-команд из ROM памяти) ответ устройства приходит с большей задержкой, чем при записи других регистров. Время ответа может достигать ~250 мс для устройств на микроконтроллерах STM. Из-за этого возможны проблемы при работе с устройством через драйвер wb-mqtt-serial, т.к. стандартный таймаут для ответа устройства, указанный в шаблоне, 1 мс. Проявляется это как ошибки обмена после нажатия на кнопку (или записи в MQTT-топик) «Reset all ROM»/«Стереть все команды в ROM».

Причины и подробное описание

Ошибка в прошивке.

Запланированное исправление

Исправлено в версии прошивки 4.29.11 от 25 июля 2023 года, обновите прошивку устройства.

Пути обхода

Если вы не можете обновить прошивку устройства, то ошибку можно обойти следующими способами:

• увеличить таймаут ответа устройства до 500 мс
• не использовать регистр coil 5000, а стирать каждый банк памяти поочередно путём установки первых двух регистров в нули через редактирование банка
• записывать новую команду в банк сразу, без предварительного стирания банка

ERRWB-MSWv30011: Влияние ИК-передатчика на показания датчиков движения и освещенности

Подверженные устройства

Устройства WB-MSW v.3, WB-MSW v.4 с версией прошивки до 4.29.7 включительно

Описание

При передаче ИК-команд показания датчиков освещенности и движения кратковременно увеличиваются.

Запланированное исправление

Исправлено в версии прошивки 4.29.8 от 14 июня 2023 года.

ERRWB-MSv20006: Переполнение показаний относительной влажности при околонулевой влажности воздуха

Подверженные устройства

Все устройства с датчиком SHT40 с прошивкой до 4.31.3 включительно:

• WB-MS v.2 начиная с партии v4.3A/T (выпуск с 09.2022)
• WB-MSW v.3 начиная с партии 4.19 (выпуск с 12.2021)
• все WB-MSW v4

Описание

Датчик SHT40 может отдавать показания влажности, которые после пересчёта в проценты могут оказаться меньше нуля или больше 100 %. Документация на датчик предписывает проверять значение влажности и приводить его к диапазону от 0 до 100 %. Однако из-за ошибки в прошивке такой проверки не было. Из-за этого при околонулевой влажности воздуха значение в регистре относительной влажности могло быть около 650 %.

Возможные пути устранения

• обновить прошивку до 4.31.4
• на стороне клиента принимать регистр относительной влажности как знаковый s16 и приводить значение регистра к диапазону от 0 до 100 % при выходе за пределы диапазона.

Запланированное исправление

Проблема исправлена в прошивке 4.31.4 от 11 декабря 2023 года. Значение в регистре относительной влажности теперь строго от 0 до 100 %.

ERRWB-MSWv30012: Ошибка при чтении нескольких диапазонов coil-регистров за один запрос

Подверженные устройства

Устройства WB-MSW v.3, WB-MSW v.4 с версией прошивки до 4.31.4 включительно

Описание

Из-за ошибки в библиотеке Modbus, если включен режим непрерывного чтения (записано 1 в регистр 114) и выполняется запрос на чтение coil-регистров, например, с адреса 0 по 11 за один запрос, то в ответе от устройства валидное значение будет иметь только первый coil-регистр в запросе. Значение остальных регистров будет равно 0 и не соответствовать действительности. При этом чтение coil-регистров по одному работает корректно.

При работе с контроллером Wiren Board это вызывало неожиданное поведение работы светодиодов: их можно было включить через web-интерфейс на вкладке «Устройства», но уже нельзя было выключить. Текущее состояние светодиодов отображалось некорректно.

Запланированное исправление

Исправлено в прошивке версии 4.31.5 от 25 января 2024 года, обновите прошивку устройства.

ERRWB-MSWv30013: Неверное значение регистра пользовательской температурной компенсации после стирания EEPROM

Подверженные устройства

Проблеме потенциально подвержены все устройства, которые:

• вышли с производства с прошивкой от 4.29.0 до 4.31.10 включительно;
• были повторно проверены на производстве, подвергались стиранию EEPROM или настроек связи вручную, подвергались переустановке адреса на программаторе адресов.

Это ревизии:

• MSW v3 LORA — v4.22I/L и далее (даты производства 04.2023 - 05.2023);
• MSW v3 — v4.22I/5, v4.22I/6;
• MSW v4 LORA — все ревизии;
• MSW v4 — все, кроме отгруженных после 08.11.24.

Не подвержены проблеме: TH и M исполнения (партии xxx/TH и xxx/M)

Также проблеме подвержены все WB-MSW v.3 и WB-MSW v.4 с установленным CO2 датчиком, если выполнялось обновление прошивки на версии от 4.29.0 до 4.31.10 со сбросом EEPROM (wb-mcu-fw-updater ... --restore-defaults или wb-mcu-fw-flasher -e).

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

Список серийных номеров потенциально уязвимых устройств

Если серийный номер вашего WB-MSW попал в список, выполните одно из следующих действий:

• запишите «0» в регистр 245 вручную: modbus_client -mrtu -pnone -s2 /dev/ttyRS485-1 -b9600 -a1 -t6 -r245 0 (подставьте нужный порт, адрес и скорость).
• в шаблоне конфигурации устройства в разделе Параметры воздуха / Компенсация самонагрева (°C) укажите значение 0.

Описание

Из-за ошибки в прошивках от 4.29.0 до 4.31.10 включительно при старте устройства с пустой EEPROM и установленным CO2 датчиком (это может быть как первое включение устройства, так и включение после сброса EEPROM или настроек связи) через 4 секунды ошибочно запускался алгоритм миграции температурной компенсации, предназначенный для корректного обновления со старых версий. Из-за этого в регистре пользовательской температурной компенсации оказывалось значение -70 вместо значения 0 и датчик завышал показания на 0.7 градуса. Чтобы первое включение прошло корректно, нужно в первые 4 секунды работы прошивки записать какие-либо настройки связи (например, адрес, отличный от 1) и перезагрузить устройство. После этого при следующих включениях алгоритм уже не запускается и в регистре пользовательской компенсации будет значение 0.

Большинство произведенных устройств не подвержено проблеме, т.к. производственный стенд успевал за 4 секунды сделать первые проверки, записать адрес и перезагрузить устройство.

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

В итоге датчик завышал показания на 0.7 градуса. Необходимо вручную записать в регистр 245 значение 0.

Для того, чтобы убедиться, что температурная компенсация имеет верное значение, нужно прочитать регистр 245: там должен быть 0. Также можно в шаблоне конфигурации устройства в разделе Параметры воздуха / Компенсация самонагрева (°C) указать значение 0.

Запланированное исправление

Исправлено в прошивке версии 4.31.11 от 5 ноября 2024 года. Стирание EEPROM с установкой прошивки 4.31.11 не портит регистр 245.

Однако подверженные проблеме устройства необходимо исправить вручную: записать значение 0 в регистр 245.

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

• добавили в производственный стенд проверку значения регистра 245: там должен быть 0 после окончания всех проверок;
• ускорили повторную проверку;
• в прошивке полностью убрали алгоритм миграции для новых устройств (для которых не существовало старых прошивок).

ERRWB-MSv20007: Ошибка при обновлении прошивки устройства

Подверженные устройства

Некоторые устройства WB-MS и WB-MSW.

Описание

В процессе обновления любым способом, кроме wb-mcu-fw-flasher, случайным образом может возникнуть ошибка обновления, после чего устройство остается в режиме загрузчика. Т.е. индикатор Status моргает стабильно раз в секунду и устройство не отвечает на запросы.

Запланированное исправление

В настоящее время причина проблемы не определена.

Пути обхода

Выполнить обновление актуальной версией прошивки через wb-mcu-fw-flasher, для этого:

• Узнайте сигнатуру прошивки устройства
• Выполните обновление согласно инструкции

ERRWB-MSWv40001: Ошибка в прошивке датчиков CO2 NS8

Подверженные устройства

Все устройства с датчиком NS8.

Ревизии:

MSW v4: v5.5B/7, v5.5L, v5.5L/1, v5.5H/1, v5.5H/2, v5.5H/3, v5.5M, v5.5M/3, v5.5R/2, v5.5R/3, v5.5T, v5.5T/1, v5.5T/2

MSW v4 Zigbee: v5.5I/Z1, v5.5I/Z, v5.5I/Z2, v5.5N/Z, v5.5P/Z, v5.5R/Z

Не подвержены проблеме: MSW v4 без датчика CO2 и с датчиком CO2 не NS8.

Описание

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

После возникновения ошибки датчик CO2 перестает передавать данные.

Причины и подробное описание

В прошивке производителя датчика CO2 NS8 была обнаружена ошибка, при которой он перестаёт отправлять данные. Ошибка возникает в процессе калибровки датчика. После подачи команды на калибровку запускается алгоритм и происходит запись данных в EEPROM. Весь процесс занимает от 1 до 15 секунд, из которых всего 200 миллисекунд занимает запись в EEPROM. Если в момент записи произойдет отключение питания, есть вероятность, что в EEPROM будут записаны некорректные данные, что приведет к ошибке.

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

Пути обхода

Обеспечить стабильное и бесперебойное питание.

На этапах установки и отладки оборудования не отключать его во время калибровки (в том числе при автокалибровке).

Если была запущена калибровка вручную, отключение питания рекомендуется производить не менее чем через 15 секунд после подачи команды.

Замена по гарантии.

Запланированное исправление

Исправлено в прошивке датчика NS8 с версии 1.03D. Если датчик уже перестал передавать данные, то обновление прошивки не поможет. В этом случае производится замена по гарантии.

В прошивке WB-MSW с версии 4.33.0 можно обновить прошивку датчика CO₂ NS8.

Устройства, отгруженные после 26.08.2025 уже имеют актуальную прошивку NS8.

ERRWB-MSWv40002: Ошибка в процессе обновления прошивки CO2-датчика NS8

Подверженные устройства

Все устройства с датчиком NS8 и прошивкой от 4.33.0 до 4.34.0 включительно.

Описание

Если обновление прошивки датчика NS8 будет прервано и не возобновлено в течение 60 секунд, датчик может перестать отвечать на запросы без возможности восстановления.

Причины и подробное описание

После 60 секунд бездействия (не отправляются следующие блоки данных прошивки), датчику NS8 отправляется команда на переход в прошивку. Но т.к. прошивка не была до конца загружена, датчик после получения этой команды становится неработоспособен.

Пути обхода

Не прерывать процесс обновления прошивки NS8. Если процесс всё же был прерван — возобновить его в течение 60 секунд. При возникновении данной проблемы — замена по гарантии.

Запланированное исправление

Исправлено в прошивке 4.34.1 от 29 августа 2025 года.

ERRWB-MSWv40003: Зависание устройства после многократного включения питания

Подверженные устройства

• WB-MSW v.4 партий от v5.5X/5 (прошивка 4.34.1) до v5.6C/1 (прошивка 4.35.2) включительно
• WB-MSW-ZIGBEE v.4 партий 5.6A/Z — 5.6A/Z6 и 5.6C/Z — 5.6C/Z3

Описание

Через 150-200 циклов включения питания устройство может остаться в зависшем состоянии, бесконечно перезагружаясь в загрузчик. Это можно понять по отсутствию связи с прошивкой и постоянному миганию светодиода.

Причины и подробное описание

В прошивке было обнаружено несколько особенностей, которые сами по себе не являются критическими проблемами, но в совокупности привели к тому, что при определенном расположении файлов во FlashFS устройство не могло выполнить дефрагментацию и перезагружалось по watchdog:

1. При выполнении сброса настроек через регистр 65402 в файловой системе появлялись лишние записи об удаленных файлах, что само по себе не влияло на работу устройства, но существенно увеличивало время дефрагментации.
2. При каждом старте прошивки в файловой системе записывалась копия файлов настроек и состояния устройства, что также приводило к росту количества файлов и увеличению времени дефрагментации.
3. В ходе выполнении дефрагментации watchdog не сбрасывался и при большом количестве файлов это приводило к перезагрузке устройства в процессе дефрагментации файловой системы.

Пути обхода

1. Обновить прошивку до 4.35.3. Это можно сделать в том числе из зависшего состояния (см. ниже). Для ZigBee датчика обновите прошивку до 75 версии.
2. При невозможности обновления прошивки:
   • если прошивка работает — выполнить переход в загрузчик через регистр 129, затем подождать 2 минуты — устройство перейдет обратно в прошивку. При этом выполняется дефрагментация, а т.к. ФС ещё не полностью заполнена — выполняется успешно. В итоге из ФС удаляются файлы-пустышки и устройство продолжит работать нормально без ограничения по числу перезагрузок
   • если прошивка не работает — выполнить сброс настроек из загрузчика (wb-mcu-fw-flasher с ключом -w или записать 1 в регистр 1002). Карту регистров загрузчика можно посмотреть здесь. Это удалит настройки устройства, включая ИК-команды, и выполнит дефрагментацию ФС, удалив все файлы, кроме калибровок

Обновление прошивки устройства из зависшего состояния

Есть несколько способов:

1. Через веб-интерфейс (Найти устройство → Поиск устройств в режиме загрузчика → Настроить как текущее).
2. Командой wb-mcu-fw-updater recover.
3. Командой wb-mcu-fw-flasher без ключа -j.

Запланированное исправление

Исправлено в прошивке 4.35.3 от 10 марта 2026 года.

ERRWB-MSWv40004: Ошибка измерения температуры и влажности из-за самонагрева

Подверженные устройства

• WB-MSW v.4 партий от v5.1A до v5.7A
• WB-MSW-ZIGBEE v.4 партий от v5.2B/Z1 до v5.6C/Z

Описание

В подверженных устройствах значительный самонагрев платы, из-за чего выдаются завышенные показания температуры и заниженные показания относительной влажности воздуха.

Причины и подробное описание

В MSW v.4 была применена новая микросхема преобразователя питания, которая имеет низкий КПД на малых нагрузках. На этот её недостаток не обратили внимания. Результатом стал самонагрев датчиков существенно выше расчётного:

	Ошибка показаний температуры, °C
Питание	24 В	12 В
WB-MSW	0.5	0.1
WB-MSW + VOC	0.9	0.5
WB-MSW + CO2	0.9	0.4
WB-MSW + CO2 + VOC	1.1	0.5

Пути обхода

Задать настройку компенсации самонагрева датчика в соответствии с приведённой выше таблицей путём настройки в веб-интерфейсе или записью в регистр 245 (в регистр записывается умноженное на 100 значение необходимой компенсации).

Запланированное исправление

Исправлено начиная с партии v5.7B.