Вопрос по конвенции mqtt топиков
В описании сказано
Каждый «канал» («контрол») имеет «подтопик» /meta/error, в котором содержится информация о наличии ошибок взаимодействия с устройством. Ошибки получения данных (чтения) обозначаются символом r, ошибки записи — w.
Пример ошибки получения данных:
/devices/wb-w1/controls/28-0115a48fcfff/meta/error r
Это здорово, но в нормальном состоянии топика meta/error НЕТ
А это значит, что если я подключаюсь к mqtt из HomeAssistant но не могу полностью использовать встроенный функционал availability, т.к. топика нет, то HA считает сразу что unavailable
Из вариантов только плодить промежуточные binary sensor в который загонять этот meta/error и потом его использовать как availability для нужного топика. Оверхед.
Помечу бы в нормальном состоянии не иметь meta/error разным “f” (false) или просто пустому значению, но чтобы сам топик был при этом?
Search uploaded documents
Found 5 uploaded document excerpts for ‘mqtt availability meta/error Home Assistant’
Здравствуйте! Я — автоматический помощник техподдержки Wiren Board.
Сейчас выходной — я постараюсь помочь сразу, а в ближайший рабочий день
инженеры посмотрят тему и ответят.
По документации meta/error — это именно признак ошибки, и в нормальном состоянии топик может отсутствовать. Для MQTT-конвенции это ожидаемо: у meta/error нет значения false, а наличие/неналичие топика используется как состояние ошибки. В найденной документации также указано, что при ошибке в топике лежит последний корректный controls/... value, а сам meta/error становится ненулевым/непустым.
Для Home Assistant это действительно неудобно, если вы хотите использовать availability напрямую. Обычно делают один из вариантов:
использовать отдельный MQTT-топик как availability, который всегда публикуется драйвером/правилом;
в HA настроить availability на другой стабильный признак, а meta/error использовать только как индикатор ошибки;
сделать промежуточное правило wb-rules, которое публикует online/offline или 0/1 в отдельный топик.
Если хотите, я могу сразу набросать минимальное wb-rules-правило под ваш случай: какой у вас объект — один контрол, целое устройство или группа топиков?
Примечание: я — ИИ, а не человек; в моих ответах возможны неточности.
Инженеры посмотрят тему в ближайший рабочий день. Если хотите ускорить —
приложите диагностические данные.
Как вариант можно в текущий топик /meta, т.к. там json добавить поле со статусов, ОК или не ок…
Этот топик есть всегда же…
А пока немного несогласованно и прямолинейно не использовать ((((
у меня уже всё сконфигурировано на yaml файлах, олдскульно и хардкорно
а вы предлагается похоронить что есть и настроить с нуля
и всё ради того чтобы с вашей стороны не передавать в mqtt состояние объекта и держать его постоянно, что вообщем то логично, но к сожалению нет (((
Топик meta контрола — retained и существует всё время, пока контрол есть в системе. Он и даёт стартовое «online». А meta/error гасит сущность при ошибке чтения.
topic: “/devices/wb-w1/controls/28-00001128e596/meta”
value_template: “{{ ‘online’ if value else ‘offline’ }}”
topic: “/devices/wb-w1/controls/28-00001128e596/meta/error”
value_template: “{{ ‘offline’ if value else ‘skip’ }}”
Три момента, почему конфиг именно такой:
availability_mode: latest (это значение по умолчанию) — решает последнее пришедшее сообщение.
Порядок важен: meta первым, error вторым. Mosquitto отдаёт retained-сообщения в порядке подписки, поэтому при старте HA в ошибочном состоянии error придёт вторым и перекроет meta.
skip — не опечатка. Пустой error приходит последним при удалении контрола, поэтому online в этом шаблоне оживлял бы сущность в момент пропажи датчика. Несовпавшее с online/offline значение HA игнорирует — решает meta.
к сожалению, не работает у меня
в нормальном состоянии, когда всё читалось - было доступно
в какой то момент похоже пролетела проблема и сенсор стал недоступен и всё, в доступное состояние уже не вернулся (((
и объясните мне дураку, зачем удалять топик meta/error? как я понимаю перед удалением его значение очищается - этого достаточно и пусть с пустым значением себе живёт
ну если не хочется ломать конвенцию, то в json который просто в meta живёт, путь появляется доп атрибут когда проблема и он может даже удаляться, это уже решит все проблемы для нативного механизма HA
причину такой упёртости в вашей стороны я не понимаю (((
Нельзя ломать то что описано в конвенции. За десяток лет ее существования много кода уже работает. Если мы (внезапно) изменим механизм работы, даже просто будем “пробел” хранить в топике вместо null - то у кого-нибудь сломается работа..
так я предлагаю вариант чтобы не ломать - в топике meta в json поле error добавить, оно по сути будет дублировать топик meta/error и может так же появляться и пропадать, но это уже позволит корректно в HA доступность получать!