Интересно как…
Правилами …
Или может поправят логику в интеграции …
Я сейчас ещё “бодаюсь” с обработкой button
Свойство “Точность”, а должно быть “Шаг” и УДЯ тогда должен прибавлять или отнимать.
Либо должно быть еще отдельно поле “Шаг” отдельно от Range
И как понять каким способом изменена уставка?
Хочется от WB получить внятный ответ, а то они делают интеграцию, а как УДЯ работает не знают)
Или пришло ±2, или конкретнон значение
Подожду ответ от WB, потом делать что-то
Хм, ценно, благодарю!
Попробую проверить (уже завтра), что-то мне кажется что в канал “значения” писать поправки не особо логичное поведение.
Вам всегда пожалуйста, обычно стараюсь не напрягать лишний раз тех поддержку, только когда совсем “припрет”, если есть возможность посмотрите мою тему Обработка нажатий Zigbee кнопки и интеграция ее в Яндекс Алису, может у вас будет какое-то решение по этому вопросу … заранее благодарю
Пробую; вот чуть переделал тестовое виртуальное устройство, разрешил ему более широкий диапазон темперратур.
Сам скрптик
defineVirtualDevice("AC-test1", {
title: {en: "AC-test1", ru: "AC-test1"},
cells: {
"enable": {
type: "switch",
value: false,
order: 1
},
temperature: {
type: "range",
value: 23,
min: -3,
max: 30,
units: "deg C",
order: 2
},
Mode: {
type: "value",
value: 0,
readonly: false,
order: 3,
enum: {
0: { en: "Off", ru: "Выключен" },
1: { en: "Cooling", ru: "Охлаждение" },
2: { en: "Dry", ru: "Осушение" }
}
}
}
});
Ну и подписываюсь на топик температуры (у меня debian trixie уже):
mosquitto_sub -v -t '/devices/AC-test1/controls/temperature/#'
<>
/devices/AC-test1/controls/temperature 15
/devices/AC-test1/controls/temperature/on -1
/devices/AC-test1/controls/temperature -1
/devices/AC-test1/controls/temperature/on 1
/devices/AC-test1/controls/temperature 1
Нда… Реализация - ну, так себе.
Ладно бы со знаком публиковал, строкой.
Вот например у меня значение (текущее) “2”. Если Яндекс публикует “-1” - то понятно, уменьшить на 1. Если Яндекс публикует “1” - то что делать? Ставить 1? Увеличивать до 3?
Но - если диапазон комнатный - проблем не возникнет.
В общем если диапазон заведомо в стороне от допустимых уставок - еще один скрипт, который подписывается на значение топика и при получении (корректировок) - выставляет топик в соответствии с ними.
А так - посоветуюсь с разработчиками.
Я себе поправил скрипты, теперь не даёт записывать в уставку -1/1. Если не поправят, то с этим костылем пока сойдёт
Ещё небольшое уточнение, касаемо по аналогии с громкостью, хотелось бы когда нажимаешь в приложении УДЯ в карточке устройства volUp/Down получать 1/-1, а когда двигаешь ползунок range, тогда значение из range, а не как сейчас происходит, что я описал выше
У меня так и есть, в настройках Алисы в WB задаешь точность 1 (хотя по факту это шаг)
Если прибавить/ убавить прилетает 1/-1, если ползунок двигать, все нормально, прилетает значение в пределах мин/ Макс с шагом 1
Я выкрутился с командой Прибавь/ Убавь. Работает
Как то так:
defineVirtualDevice (“Termostat”, { //Виртуальное устройство Термостат
title:“Termostat”,
cells: {
"Setpoint": { //Уставка температуры
title: {en: 'Setpoint', ru: 'Задание'},
type:"range",
value: 20,
max: 30,
min: 16,
order: 1,
readonly : false,
},
"Setpoint_Tmp":{ //Уставка температуры промежуточная
title: {en: 'SP Tmp', ru: 'Врем.Значение'},
type:"value",
value: 20,
order: 2,
readonly : true,
},
}
});
defineRule ("Termostat_setpoint ", { //уставка температуры
whenChanged: [“Termostat/Setpoint”],
then: function (newValue, devName, cellName) {
if (newValue <=2) {dev\["Termostat/Setpoint_Tmp"\] = dev\["Termostat/Setpoint_Tmp"\] + newValue;
} else {dev\["Termostat/Setpoint_Tmp"\]=dev\["Termostat/Setpoint"\] }
var Temp = dev\["Termostat/Setpoint_Tmp"\];
if (Temp <= dev\["Termostat/Setpoint#min"\]) {Temp = dev\["Termostat/Setpoint#min"\]}
if (Temp >= dev\["Termostat/Setpoint#max"\]) {Temp = dev\["Termostat/Setpoint#max"\]}
dev\["Termostat/Setpoint"\] = Temp;
}
});
У меня осталось одно непонимание, как быть с кондиционером…пока голову ломаю
Вот вот…у меня он по Zigbee…позже опишу что и как, может сможете помочь
В версии 0.13.0 появилось.
Оно в unstable пока. На днях будет в testing.
Ну, тут небольшая разница - все равно скорее всего нужен промежуточный скрипт.
Ждем описания.
Жду когда будет в стабильном
Коллеги, убил 2 дня в упор чтобы разобраться и все настроить, очень классная интеграция но понятно дело сыровата еще.
Вот Саммари Клод кода по результатам тестирования интеграции, возможно будет полезно.
Отчёт по wb-mqtt-alice (клиент v0.13.2) — баги и предложения
Окружение: WB6 (1 ядро, 512MB), wb-mqtt-alice-client v0.13.2, ~21 устройство
в интеграции (свет/диммеры/шторы/кондиционер/термостат/датчики). Все баги
воспроизведены на живой системе 2026-07-05.
Баги
1. Относительные range-команды не обрабатываются (критично для UX)
devices.capabilities.range в протоколе Яндекса может прийти с
"state": {"value": 10, "relative": true} («прибавь яркость», «убавь на 10»).
Клиент нигде не читает флаг relative (grep -rn relative wb/mqtt_alice/ —
0 совпадений) и публикует дельту в MQTT как абсолютное целевое значение:
«прибавь яркость» при яркости 60% выставляет яркость 10%.
Предлагаемый фикс (проверен локальным патчем): в
sio_alice_handlers._handle_single_device_action извлекать
cap["state"].get("relative", False); в
device_registry.forward_yandex_to_mqtt при relative=True для range читать
текущее значение топика (уже есть read_topic_once), прибавлять дельту и
клэмпить по parameters.range.min/max.
2. Утечка потоков и дедлок в read_topic_once (device_registry.py)
asyncio.wait_for(asyncio.to_thread(subscribe.simple, ...), timeout=...):
если у топика нет retained-сообщения, subscribe.simple блокируется навсегда;
таймаут отменяет только корутину — поток остаётся висеть. Дефолтный
ThreadPoolExecutor на 1-CPU машине = 5 воркеров, поэтому 5 «пустых» топиков
подряд (например, устройства с capability без retained-состояния) навсегда
вешают все последующие to_thread, включая query-путь. Воспроизводится
стабильно: серия get_device_current_state по устройствам, у части
capability которых нет retained — процесс замирает.
Фикс: paho subscribe.simple с собственным таймаутом/msg_count через
client.loop(timeout), либо один разделяемый подписчик вместо
поток-на-чтение.
3. on_off жёстко шлёт “1”/“0”
Устройства с текстовыми enum-контролами (шторы: OPEN/CLOSE/STOP, zigbee
system_mode: heat/off) нельзя привязать к on_off без самописного
wb-rules-адаптера. Предложение: опциональные mqtt_value_on/mqtt_value_off
в параметрах capability.
4. Мелочь: спам «No mode mapping for mqtt_value_match=‘off’»
Когда контрол режима имеет значение, сознательно не входящее в словарь
(выключенность покрыта отдельным on_off), лог засоряется warning’ами.
Предложение: понизить до debug или дать явный ignore-список значений.
Предложения (фичи)
- Галочки «отдавать в Алису» у комнат и устройств в homeui: сейчас
интеграция выгружает всё сконфигурированное; хочется выборочно исключать
устройства/комнаты из выгрузки, не удаляя их из конфига. - Поддержка relative из коробки (см. баг 1) — это штатные голосовые
сценарии «прибавь/убавь/приоткрой». - Валидация против словаря Яндекса при сохранении конфига: клиент
принимает несуществующие/неподходящие instance у mode/toggle и это
всплывает только кривыми лейблами в приложении Яндекса. - Подсказка про смену type: Яндекс фиксирует тип устройства при создании;
«Обновить список устройств» тип не меняет — нужно удалить и переоткрыть
устройство в приложении. Стоит написать это в UI рядом с выбором типа. - Кнопка «форсировать пуш состояний»: после пересоздания устройства на
стороне Яндекса его кэш состояния может протухнуть — относительные команды
(«холоднее» для temperature_k, вычисляется на сервере Яндекса из последнего
репорта) отбиваются с «устройство этого не умеет», при этом до контроллера
запрос не доходит. Сейчас лечится только рестартом клиента.