Z2m: No converter available for

В предыдущей серии перешли на wb-mqtt-zigbee в связи с чем словили ложные срабатывания при штатной проверке доступности устройства.т.к lastseen запускает обработку, а action остался старым. Ранее защита выглядела очисткой события после обработки:

dev[“ChaildsRoomWrlsSwitch/action”] = “”

при следовании примеру

publish(“zigbee2mqtt/ChaildsRoomWrlsSwitch/set”, JSON.stringify({ action: “–” }), 2, false);

ошибка: 2026-04-25 09:13:59] e[31merrore[39m: z2m: No converter available for 'action' on 'ChaildsRoomWrlsSwitch': ("--")

Что я делаю не так? )

Здравствуйте! Я автоматический помощник техподдержки Wiren Board. Сейчас выходной — я попробую помочь сразу, а в ближайший рабочий день инженеры посмотрят тему и ответят.
Я проанализировал ваш вопрос и постарался найти возможное решение:
Если потребуется дополнительное уточнение, приложенную информацию прошу направить нажав ответить на мое крайнее сообщение


Судя по сообщению:

z2m: No converter available for 'action' on 'ChaildsRoomWrlsSwitch': ("--")

проблема в том, что в zb2m/wb-mqtt-zigbee для этого устройства нет конвертера для значения action: "--" — то есть такого значения в принципе не предусмотрено его описанием (exposes/конвертерами). Вы этим publish’ем не «сбрасываете» action, а пытаетесь отправить заведомо неизвестное действие.

В старой схеме вы просто чистили MQTT-топик в Wiren Board (dev[".../action"] = "") — это локальная логика контроллера. В z2m/wb-mqtt-zigbee вы уже обращаетесь к самому устройству/абстракции устройства, а не к локальному состоянию.

Что можно сделать

  1. Не отправлять action: "--" вообще
    Если задача — защититься от ложных срабатываний при проверке доступности (last_seen), то корректный путь — не трогать action в сторону устройства, а работать только с локальным состоянием в WB-правиле:

    • Локально «сбрасывать» своё внутреннее состояние правила после обработки события.
    • Игнорировать повторные action, которые совпадают с предыдущим и пришли в пределах тайм-окна, если они были инициированы не действием пользователя, а проверкой.

    То есть вместо:

    publish("zigbee2mqtt/ChaildsRoomWrlsSwitch/set", JSON.stringify({ action: "--" }), 2, false);
    

    используйте, например, локальную переменную в правиле wb-rules:

    var lastAction = "";
    
    defineRule("handle_switch", {
      whenChanged: "zigbee2mqtt/ChaildsRoomWrlsSwitch/action",
      then: function (newValue, devName, cellName) {
        if (newValue === lastAction) {
          // например, игнор, если хотите отсекать "повторы"
          return;
        }
    
        // обработка нового действия
        lastAction = newValue;
    
        // а тут просто дополнительно нигде не используете lastAction,
        // пока не придёт реально новое событие
      }
    });
    

    Смысл: вы перестаёте воспринимать last_seen как триггер для action в вашей логике, а ограничиваетесь только собственным фильтром.

  2. Проверить, какие действия реально поддерживает устройство
    В интерфейсе z2m (или в топике zigbee2mqtt/ChaildsRoomWrlsSwitch в exposes) можно увидеть перечень допустимых значений для action (например: single, double, hold и т.п.). Отправка любого другого значения (включая -- или "") будет приводить к ошибке “No converter available for ‘action’…”.

    То есть «обнулить» action через publish нельзя, если это не предусмотрено для данного устройства.

  3. Если нужен именно сброс в MQTT-топике
    Тогда можно не трогать z2m, а работать с виртуальным устройством в WB:

    • в правиле создаёте собственный топик/устройство, например wb-rules/ChaildsRoomWrlsSwitch_action_clean,
    • туда копируете action при обработке,
    • после выполнения сценария пишете туда "".
      Вся дальнейшая логика автоматики завязывается на этот «очищаемый» виртуальный топик, а не на «сырое» значение из z2m/wb-mqtt-zigbee.

Почему пример из wiki не подходит для вашего случая

В документации пример с publish("zigbee2mqtt/<dev>/set", JSON.stringify({ ... })) предназначен для управления устройством (включить/выключить, задать яркость и т.п.)[1].
Поле action у кнопок/переключателей обычно read-only, его нельзя «насильно» менять через /set, поэтому конвертер и не находит такую операцию.


Если пришлёте:

  • модель устройства (из zigbee2mqtt/<dev> или из UI z2m),
  • фрагмент вашего правила wb-rules, где вы используете last_seen и action,

можно будет предложить более точную схему фильтрации/«сброса» событий.


Примечание: Я — искусственный интеллект, а не сотрудник-человек. В моих ответах возможны неточности.


  1. Подключение устройств Zigbee к контроллеру Wiren Board — Wiren Board ↩︎

пока так
trackMqtt(“zigbee2mqtt/ChaildsRoomWrlsSwitch”, function(obj) {
// 1. Проверяем, что сообщение не пустое
if (!obj.value) return;
try {
    var payload = JSON.parse(obj.value);
    var action = payload.action;

    // Это отсечет ложные срабатывания от last_seen и других параметров
    if (!action) return;

    if (action == "1_single") {
        dev["wb-led_102/RGB Strip"] = !dev["wb-led_102/RGB Strip"];
        dev["wb-led_102/Channel 4"] = !dev["wb-led_102/Channel 4"];
        if (dev["wb-mrwm2_175/K2"] == false) {
            dev["wb-mrwm2_175/K2"] = true;
        }
    }
    
    if (action == "3_single") {
        dev["wb-led_102/RGB Strip"] = !dev["wb-led_102/RGB Strip"];
        dev["wb-led_102/Hue Changing"] = !dev["wb-led_102/Hue Changing"];
        if (dev["wb-mrwm2_175/K2"] == false) {
            dev["wb-mrwm2_175/K2"] = true;
        }
    }

    if (action == "2_single") {
        dev["wb-mr6cu_220/K4"] = !dev["wb-mr6cu_220/K4"];
    }

    if (action == "4_single") {
        dev["wb-mr6cu_220/K5"] = !dev["wb-mr6cu_220/K5"];
    }

} catch (e) {
    // Обработка случая, если в топик прилетел не JSON
    log.error("Error parsing MQTT JSON for switch:", e);
}

});

Здравствуйте! Я автоматический помощник техподдержки Wiren Board. Сейчас выходной — я попробую помочь сразу, а в ближайший рабочий день инженеры посмотрят тему и ответят.
Я проанализировал ваш вопрос и постарался найти возможное решение:
Если потребуется дополнительное уточнение, приложенную информацию прошу направить нажав ответить на мое крайнее сообщение


Вы сейчас работаете уже напрямую с топиком zigbee2mqtt/ChaildsRoomWrlsSwitch и сами парсите JSON, то есть полностью обошли проблему с «сбросом» action в /set — это как раз корректный путь для z2m.

Что в вашем текущем решении:

trackMqtt("zigbee2mqtt/ChaildsRoomWrlsSwitch", function(obj) {
  if (!obj.value) return;
  try {
    var payload = JSON.parse(obj.value);
    var action = payload.action;

    // Это отсечет ложные срабатывания от last_seen и других параметров
    if (!action) return;

    if (action == "1_single") {
      ...
    }
    ...
  } catch (e) {
    log.error("Error parsing MQTT JSON for switch:", e);
  }
});

Что вы сделали правильно

  1. Отбрасываете сообщения без action
    if (!action) return; — как раз то, что нужно, чтобы игнорировать обновления last_seen и прочих полей, которые приходят без действия.

  2. Не пытаетесь писать в /set поле action
    Тем самым исчезает ошибка No converter available for 'action', потому что вы больше не отправляете неподдерживаемое значение "--".

  3. Логика «сброса» теперь локальная
    Вы не «обнуляете» action в устройстве/z2m, а просто обрабатываете событие и больше к нему не возвращаетесь, пока не придёт новый action. Это по сути аналог вашего старого dev[".../action"] = "", только без вмешательства в z2m.

Можно чуть улучшить

Если хотите дополнительно защититься от повторов (например, когда устройство по какой-то причине присылает одно и то же action несколько раз подряд), можно добавить локальную память:

var lastAction = "";

trackMqtt("zigbee2mqtt/ChaildsRoomWrlsSwitch", function(obj) {
  if (!obj.value) return;
  try {
    var payload = JSON.parse(obj.value);
    var action = payload.action;

    if (!action) return;

    // игнорируем точный повтор
    if (action === lastAction) return;
    lastAction = action;

    if (action == "1_single") {
      ...
    }
    ...
  } catch (e) {
    log.error("Error parsing MQTT JSON for switch:", e);
  }
});

Но это уже опционально — в большинстве случаев достаточно вашей текущей схемы.


Если увидите, что какие‑то конкретные action всё равно «стреляют» при ping/обновлении статуса, пришлите, пожалуйста, пример реальных payload’ов из zigbee2mqtt/ChaildsRoomWrlsSwitch (пара сообщений с разными ситуациями), тогда можно будет точечно подправить фильтрацию.


Примечание: Я — искусственный интеллект, а не сотрудник-человек. В моих ответах возможны неточности.

Добрый день.
Как я понимаю вы используете конвертор wb-mqtt-zigbee и при этом работаете непосредственно с zigbee2mqtt. Записываете а топик action несуществующее (невозможное) для устройства значение и получаете ошибку.
А какого поведения ожидаете?

Добрый день!

Давайте честно. wb-mqtt-zigbee не умеет же менять. А zigbee2mqtt несколько другой. Ожидаю.. скажем некой наследственности между идеями wb-rules/wb-mqtt-zigbee и wb-zigbe2mqtt…. А то 100500 нюансов… неочевидных и раскиданных по документации. Вот если бы в уаомянутом примере появилась фраза про то что слать надо не абы что а исключительно то, что есть в устройстве, это пошло бы на пользу..

Спасибо LLM за наводку, это была хорошая идея.

А на чем основано это утверждение?
Для примера:


Он же: