Настраиваю zigbee мотор для штор подключенный к WirenBoard и хочу его пробросить в Алису
Через интеграцию корректно пробрасывается только положение штор, решил воспользоваться ботом AI WB, он подсказал что для того что бы пробросить кнопки Открыть Закрыть и Пауза надо передавать в Алису 3 умения on_off, но для этого надо исправить /etc/wb-mqtt-alice-devices.conf
Зашел в него исправил то, что мне нужно, записал обратно на WB, первый раз в UI все обновилось и штора пробросилась с нужным умением, изменил еще раз и в UI пропали все устройства, после захода через UI файл wb-mqtt-alice-devices.conf очищается, записываю еще раз файл на WB захожу в UI и опять файл зачищается - как исправить ситуацию?
Добрый день.
Пока не очень понятно - что именно делаете.
Насколько я знаю умений " on_off" для устройства не может быть больше одного.
Если вы создаете прямым редактированием конфига не проходящую валидацию схему - это нельзя считать ошибкой.
Проблема не в том, как сделать умения для штор, а в том что после моих манипуляций пропали все устройства в Интеграции, как вернуть их обратно. У меня есть резервная копия файла wb-mqtt-alice-devices.conf, когда я ее подкидываю в контроллер и захожу в UI в раздел Интеграция, файл очищается.
Перегрузил контроллер, зачистил в файле умение on_off у штор и подкинул заново, вроде восстановились все устройства. Но теперь остается вопрос как шторам сделать умение что бы в интерфейсе Алисы было 3 кнопки, как на примере:
Если смотреть на документацию API Алисы devices.types.openable.curtain | Платформа умного дома Яндекса
то для того что бы появились эти кнопки, надо умения передать вот так
“capabilities”: [{
“type”: “devices.capabilities.on_off”,
“retrievable”: false,
“parameters”: {
“split”: true
}
}]
Как раз это я и пытался сделать, редактируя файл wb-mqtt-alice-devices.conf
AI бот предложил мне вот такой вариант
“capabilities”: [
{
“type”: “devices.capabilities.on_off”,
“retrievable”: false,
“parameters”: {
“split”: true,
“open_action”: {
“set_state_topic”: “Curtains_Childroom/open”,
“payload_on”: 1
},
“close_action”: {
“set_state_topic”: “Curtains_Childroom/close”,
“payload_on”: 1
},
“pause_action”: {
“set_state_topic”: “Curtains_Childroom/stop”,
“payload_on”: 1
}
}
}
]
Но в таком варианте у Алисы в интерфейсе появляется только одна кнопка и она меняет свою иконку но потом сбрасывает обратно ее обротано. А вот как сделать так что бы кнопок в интерфейсе было 3 не понятно
Типично - остановить все сервисы, которые (могут) работать с конфигом, затем провести с ним манипуляции и снова запустить сервисы.
Параметр “split” в настоящее время интеграцией не поддерживается. Есть в планах его добавление.
Надо критично относиться к подсказкам нейросети.
Просто очень странно, вчера когда я первый раз добавил этот код в wb-mqtt-alice-devices.conf и перешел в UI, то устройства все были и после обновления в Алисе, там появились шторы но с одной кнопкой:
При этом когда в Алисе я нажимал эту кнопку (я о кнопке открытия) происходило дерганье контрола open в виртуальном устройстве для штор, но шторы сами не двигались
Читал в документации, что вы разрабатываете новый конвертор wb-mqtt-zigbee для zigbee. На сколько я понимаю отличие будет в том, что при подключении устройства сразу будет добавляться устройство со всеми необходимыми контролами, т.к. сейчас с wb-zigbee2mqtt создается устройство только с не редактируемыми данными и для управления через UI а так же для проброса в Алису требуется создать виртуальное устройство через Правила. Как можно понять с какими контролами будет создано в новом конвертере устройство для моторов
Lilistore TS0601_lilistore (https://www.zigbee2mqtt.io/devices/TS0601_lilistore.html#lilistore-ts0601_lilistore)
Zemismart ZM25R1 (https://www.zigbee2mqtt.io/devices/ZM25R1.html#zemismart-zm25r1)
Обработался
кусок, без неподдерживаемого “split”, думаю.
Да, он уже вполне работает.
Для примера такое:
В z2m управление выглядит так:
В контроллере
Так что типы контролов те же что и в z2m.
То есть то что в z2m выглядит как кнопки (я о Power outage memory) в Вирт. устройстве будет как listbox? а не как 3 pushbutton? и соответственно такие типы контролов в Алису пробросить не получится?
В z2m это тот же enum, просто представленный как button. Смысл тот же - публикация некоторого значения из фиксированного набора.
Ну и можно сделать прослойкуц виртуальным устройством, представив его несколькими pushbutton.
В ЯУД есть Mode | Платформа умного дома Яндекса
В интеграции сейчас доступны только эти: Интеграция контроллера Wiren Board в Дом с Алисой — Wiren Board
То есть если я правильно понял то у моторов как раз что бы получить такие кнопки нужно передать не несколько умений on_off, а умение mode
И в этом случае можно получить кнопки как в родных моторах:
Нет, там же в примере показано что реализуется через “split”.
На текущий момент все возможности - реализованы в HA.
Я правильно понимаю, что виртуальное устройство созданное wb-mqtt-zigbee будет по сути таким же как можно создать через правило и в нем будут правила обработки, могли бы вы скинуть правило которое у вас сформировалось для розетки что вы прислали. Хотел бы посмотреть как реализована обработка
type: “value”,
enum: { … }
и type: “switch”,
Да, верно. Ну и до появления этого пакета я так и делал, просто писал устройства.
Пакет работает на python.
Ну и “правила” не существуют нигде, они же динамически формируются при выполнении (общего) кода.
Кстати, документация тут: wb-mqtt-zigbee/docs at main · wirenboard/wb-mqtt-zigbee · GitHub
А может быть у вас есть пример правила для ВУ, что бы можно корректно обрабатывать (type: “value”, enum: { … }), (type: “switch”) и что бы можно было обеспечить обратную связь при изменении на стороне z2m они передавались в WB, и при изменении на WB была передача в z2m. У меня просто есть еще zigbee диммер и там как раз (type: “value”, enum: { … }), (type: “switch”) и у меня при переключении “switch” начинало циклично вкл/выкл.
На примерах проще разбираться, но из тех примеров что в доках не понял верно это реализовать.
Например:
// ──────────────────────────────────────────────────────────
// Виртуальное устройство с контролом типа value + enum
// ──────────────────────────────────────────────────────────
log.info("Start value + enum")
function makeNewVirtualControl(vdName, nameControl, typeControl){
log.info("GetDevice", getDevice("vdName"))
if (getDevice(vdName) === undefined) {
log.info("Define new")
defineVirtualDevice(vdName, {
title: vdName,
cells: {},
})
}
//Тут проверим есть ли уже контрол и если нет - создадим.
if (!getDevice(vdName).isControlExists(nameControl)) {
log.debug("Контрола "+nameControl+" нет, создаем.")
getDevice(vdName).addControl(nameControl, typeControl);
}
}
var VDEV_NAME = "myEnumDevice";
var CTRL_NAME = "mode";
var CTRL_NAME_RO = "modeRO";
log.info("Define new {} control", CTRL_NAME);
makeNewVirtualControl(VDEV_NAME, CTRL_NAME, {
type: "value",
value: 0,
readonly: false,
enum: {
0: { en: 'off', ru: 'Выкл' },
1: { en: 'Auto', ru: 'Авто' },
2: { en: 'Manual', ru: 'Ручной' }
}
});
log.info("Define new {} control", CTRL_NAME_RO);
makeNewVirtualControl(VDEV_NAME, CTRL_NAME_RO, {
type: "value",
value: 0,
enum: {
0: { en: 'off', ru: 'Выкл' },
1: { en: 'Auto', ru: 'Авто' },
2: { en: 'Manual', ru: 'Ручной' }
}
});
// ──────────────────────────────────────────────────────────
// Правило: реагирует на изменение enum-контрола
// ──────────────────────────────────────────────────────────
defineRule("onModeChanged", {
whenChanged: VDEV_NAME + "/" + CTRL_NAME,
then: function (newValue, devName, cellName) {
log.info("onModeChanged: {}/{} = {}", devName, cellName, newValue);
dev[VDEV_NAME][CTRL_NAME_RO] = dev[VDEV_NAME][CTRL_NAME]
switch (parseInt(newValue, 10)) {
case 0:
log.info("Режим: Выкл");
// TODO: логика для режима «Выкл»
break;
case 1:
log.info("Режим: Авто");
// TODO: логика для режима «Авто»
break;
case 2:
log.info("Режим: Ручной");
// TODO: логика для режима «Ручной»
break;
default:
log.warning("onModeChanged: неизвестное значение {}", newValue);
}
}
});