В последние несколько месяцев появились новые шаблоны и так же улучшение старых в связи вводом расширенного функционала.
Но к сожалению не сохранен принцип уникальности наименования входов/выходов для использования в других системах УД (в частности SprutHub).
Упомяну конкртеные модули в более развернутом виде:
WB-WMAC v.2: вне зависимости от выбранного режима работы на входах F1-5 и S6 в каналы MQTT публикуется топик вида Input Fn, из-за чего не возможно однозначно индифицировать что из себя представляет данный канал: это может быть и дискретных вход, а может быть и датчик протечки. Раньше было однозначно F1 - датчик протечк, S1 - кнопка.
Предлагаю при установке Mode = 5(датчик протечки) публиковать топик вида Input Fn Sensor, тем самым отделим одно от другого.
WB-MR*: был добавлен замечательный функционал по фазному управлению для штор, но топики увы утилизировались уже существующие.
Считаю необходимым изменить их при включении данного режима: K1 -> State K1 (состояние K1), так по идеологии [K]аналы управляемые, а если управление отключено - логично что они становятся статусами, но другие системы “привыкли” что это все же канал управления.
Ко всему прочему теперь нельзя однозначно однозначно идентифицировать режим работы устройства из-за совпадающих топиков при работе в режиме реле.
Понимаю что вышеописанные устройства уже в stable версии и команде крайне не хотелось бы ломать существующие исталляции с возможным наличием правил на этих контроллах.
Добрый день.
Предлагаемое особого смысла не имеет. То есть сейчас как бы не назывались контролы - они все равно используются в скриптах автоматизации “как есть”.
В планах есть фунционал по присваиванию топикам осмысленных наименований, то есть каждому как каналу реле так и входу можно будет дать произвольное понятное имя описывающее его.
Например будет вместо /devices/MR2_33/controls/K1
Не просто можно (и нужно) менять имя устройства, так например /devices/SocketRelay_2floor/controls/K1
Ни имя канала:
/devices/SocketRelay_2floor/controls/ChildRoom
К примеру в том же Home Assistant при использовании какого-то канала указываю его именно требуемым типом устройства, для того чтобы правильно обрабатывалось.
Не очень логичный путь. Реле в “шторном” режиме может управлять водяным краном например - тут зависит от проектировщика-наладчика как именно определять тип отображения каналов.
Хороший функционал, и найдется тот кому он пригодится. Но практика дефолтных значений не куда же не уйдет. В целом нейминг хорош и понятен.
HA отдельная песня, видел wb-engine в котором нечто подобное для этой системы и реализовывается.
Почему не логичный? В режиме шторы остается K1 как статус, в том же СХ на него шаблон с вкл/выкл идет. Пользователь получает кучу каналов, которыми не может управлять.
K всегда были управляемыми каналами, Input были статусами входов.
А в шторном режиме пошло не так, в разрез всего что было принято «до».