Ошибка в наименовании устройства WB-UPS-v3

Добрый день.

Настраиваю WB-UPS v3 и заметил, что наименование устройства в mqtt выглядит следующим образом: wb_ups_v3_142/input_voltage
Ожидаемое наименование: wb-ups-v3_142/Input Voltage как у всех других устройств через дефис, а не подчеркивание.

Еще замечено, что у каналов с цифровыми значениями в новых шаблонах, часто стало появляться безликое type=value, когда в conventions есть такие типы как Voltage, Current и прочие, по которым можно определять тип контрола для сторонних интеграций. Возможно ли поменять шаблоны, чтобы они публиковали корректный type в соответствии имеющимися значениями? Со своей стороны могу указать в каких шаблонах отсутствуют правильные type. Например у устройства WB-MAI6, у контрола IN X Voltage указан type=value и units=V, а допустим у MAP6S для напряжения указано type=voltage и отсутствует units.

Алексей, добрый день!

Благодарю за замечание.
Уточню у коллег, с чем связано изменение правил наименования и отсутствие units в шаблонах, после чего вернусь с ответом.

Лучше уточнить, с чем связано отсутствие type, по которому можно идентифицировать, что это за канал, и как его правильно передать в Home Assistant (мне type интересен с точки зрения работы скрипта wb-engine)

Добрый день!

Прошу прощения за долгий ответ.
Указанные вами изменения в шаблонах связаны с изменением нашего стандарта для новых версий устройств.

Для WB-MAP6S актуальной версии прошивки используется новый шаблон, в котором units и type присутствуют.
В соответствии с конвенцией "units" может быть задан только для типа со значением "value".

Я полагаю, что скрипт wb-engine заточен на старые версии шаблонов.

Можно ознакомиться с новым стандартом? Я правильно понял, что теперь у устройств mqtt id будет с подчеркиванием (wb_ups_v3_142) или это опечатка в WB-UPSv3?

В примере я привел устройство WB-MAI6 , у которого отсутствует type. С MAP6S все хорошо как раз.

В MAP6S просто ещё не переделали. Вот актуальная конвенция: GitHub - wirenboard/conventions: Wiren Board MQTT Conventions Обратите внимание, что Specific value type controls устарели и перестанут использоваться со временем. Вместо них теперь value с нужным units — это добавило гибкости.

Он внутренний и большой, вот кусок оттуда про топики:

Основные рекомендации есть здесь в публичном доступе: Как писать шаблоны для сторонних Modbus-устройств — Wiren Board

А чем это мешало или мешает? Наоборот, в том же Home Assistant есть device_class, по которому можно понять, что это за сенсор. В WB раньше было так же, теперь вы предлагаете использовать для этого только units? Получается, что units=V — это всегда voltage, или бывают исключения? Вот здесь список всех возможных units? В целом, можно переделать всё на units.

По поводу наименования: сейчас легко определить, что это за устройство, по его имени в mqtt отделив modbus id, который всегда идёт через подчёркивание (например, wb-led_42). Это нужно, чтобы понять, что type=switch у WB-LED это лампа, а у MR6C обычное реле. Было бы хорошо, если бы имя устройства указывалось напрямую в meta. Тогда можно было бы переименовывать mqtt device_name, как многие хотят.

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

mqtt имя можно изменить. И нередко меняют.
Например, как определить что за устройство wc_pump? А в реальной жизни у меня это mr6.

Если я вас правильно понял, то такая функция есть - вы можете самостоятельно задать имя топика для каждого устройства.
Иногда это удобно, если устройство используется в разных правилах и т.п. и при этом его необходимо заменить (допустим поменялся адрес устройства). Заданное вами имя при этом не поменяется и правила продолжат свою работу без коррекции. Либо просто дать устройству более понятное имя (более функциональное).

Название устройства (заданное вами) отображается в разделе “Устройства” - хоть это и “технический раздел”, т.е. не для конечного пользователя, но все же приятнее видеть понятные имена устройств вместо “модели-адреса”

Не правильно поняли, я знаю что такая функция есть. Речь про то, как узнать через mqtt, что это изначально было wb-led и его надо передать в Home Assistant в виде лампы? Контекст беседы скрипт wb-engine и передача устройств в HA.

Я как автор скрипта про это и пишу, имея лишь mqtt тяжело определить, что это за устройство и как с ним работать. Цель была в пару кликов мышкой передать устройство в HA, пока это работает, а вот новые стандарты ломают это.

Добрый день!

Список возможных значений units приведен в таблице.
По “device_type” в шаблоне можно определить точно что это за устройство WB.

Нету такого поля в mqtt.

Здравствуйте! Похоже, я изначально вас неправильно понял.

Определять тип модуля WB через MQTT и на основе этого относить его к категории «освещение», на мой взгляд, не совсем надёжный подход.
Например, если взять не WB-LED, а релейный модуль из линейки WB-MR, то он может использоваться в самых разных сценариях. Более того, на одном и том же модуле разные каналы могут выполнять совершенно различные функции.

Чтобы точно определять категорию устройства, в MQTT-иерархию стоит добавить дополнительные признаки (категории), по которым можно однозначно идентифицировать назначение устройства для быстрой передачи данных в HA.
Нужно продумать, каким образом лучше реализовать эту структуру и какая схема будет наиболее удобной. Как вы это видите?

Здравствуйте!
Буду признателен за обратную связь.

Добрый день, надо обдумать.

Когда я делал ремонт два года назад, столкнулся с тем, что добавлять устройства в HA вручную это трудно и неудобно. Поэтому пришла идея сделать скрипт, прослойку между WB и HA, использующий только данные из MQTT. Пришлось использовать то, что было на тот момент, за основу было взято название устройства из MQTT и имя управляющего канала. (По хорошему wb-mqtt-serial мог бы уметь создавать описание устройств для HA, как например это делает zigbee2mqtt)

Например для WB-LED получился такой конфиг, в режиме CCT нужно передать несколько весьма специфических настроек, чтобы HA корректно обрабатывал это как лампу с возможностью менять температуру. Чтобы это сработало должно совпасть имя устройства из MQTT и название канала в данном примере CCT1.

Один из вариантов переделки оставить старый type и добавить работу с units (также хочу посмотреть за счет чего вы ускорили работу UI в wb-mqtt-serial и применить у себя). Как быть с моделями устройств пока не понятно, можно взять за основу название каналов без привязки к устройствам (они достаточно уникальны от устройства к устройству), но тут тоже непонятно как будут обстоять дела с шаблонами и вашими планами по их обновлению, уже сейчас я вижу что в старых название было в читаемом виде на английском языке и дополнительно указывался перевод на русский, а в новых шаблонах техническое название канала и два перевода.

Может быть у вас есть идеи или мысли по этому поводу?

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

Давайте мы возьмём чуть паузу и хорошо подумаем внутри. Мы прямо сейчас экспериментируем с пробросом наших устройств в HA и наверняка столкнёмся с теми же проблемами о которых говорите вы, а значит нам придётся их решать.

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

Ну решение “в лоб” - выделить отдельную meta на само устройство с его типом, ну или(и) вообще названием (сигнатурой). Так же меты можно раскидать по каналам с описанием и типами, что бы из всего этого можно было “собрать” устройство “на той стороне”.

Интересно. Вы пошли по пути через HACS, вижу также через MQTT собираете информацию об устройствах и каналах управления. Поставил посмотреть, пока еще не учитываете тип сенсора и нет возможности добавить только нужный канал от устройства, мне кажется со стороны HA меньше гибкости на самом деле, правда более детально с этой стороны не изучал.

Ну и в таком виде лампой пользоваться точно не получится:

Должно быть так:


Очень рекомендую посмотреть со стороны MQTT Discovery (например light.mqtt), идеально чтобы wb-mqtt-serial правильно готовил топики с учетом интеграции с HA, например чтобы учитывать доступность устройства, пришлось городить такую конструкцию:

availability:
  - topic: /devices/wb-led_2/controls/RGB Strip
    value_template: '{{ False if value == '''' else True }}'
    payload_not_available: false
    payload_available: true
  - topic: /devices/wb-led_2/controls/RGB Strip/meta
    value_template: '{{ False if value == '''' else True }}'
    payload_not_available: false
    payload_available: true
  - topic: /devices/wb-led_2/controls/RGB Strip/meta/error
    value_template: '{{ True if value == '''' else False }}'
    payload_not_available: false
    payload_available: true

Зачем так много: когда устройство становится доступным, WB просто удаляет топик /error, как это отследить со стороны HA я не нашел, поэтому приходится еще “следить” за топиками канала и meta.

А вот если бы WB учитывал особенности HA и имел топик availability c содержимым online/offline , то тогда конфигурация стала намного проще, например (я как-то спрашивал про это, был не понят и поэтому пришлось городить конструкцию выше):

availability:
  - topic: /devices/wb-led_2/controls/RGB Strip/meta/availability

Почему MQTT Discovery, да банально в мире Zigbee очень много разновидностей устройств и zigbee2mqtt умеет их все передавать через MQTT Discovery, с этой стороны уже все придумали. Уже все готовое есть, как работать с термостатами шторами и прочим, надо только иметь топики в формате который MQTT Discovery понимает нативно, иначе придется делать посредника на wb-rules (для штор например HA передает команду текстом open/close, а со стороны WB ждут нажатие на switch)

Добрый день!

Благодарю вас за предложения по улучшению интеграции с Home Assistant.
Ваша идея добавлена в список пожеланий и будет рассмотрена командой разработчиков в рамках дальнейшего развития проекта.