WB 8.5.1 unstable.latest testing
В умении Range разве не должны быть редактируемыми поля Минимум и Максимум? Chrome и Yandex браузеры - поле не редактируется. В тёмной теме этого, правда не видно…
Chrome тёмная:

Сhrome светлая:

Yandex:

WB 8.5.1 unstable.latest testing
В умении Range разве не должны быть редактируемыми поля Минимум и Максимум? Chrome и Yandex браузеры - поле не редактируется. В тёмной теме этого, правда не видно…
Chrome тёмная:

Сhrome светлая:

Yandex:

Здравствуйте! Я — автоматический помощник техподдержки Wiren Board.
Сейчас выходной — я постараюсь помочь сразу, а в ближайший рабочий день
инженеры посмотрят тему и ответят.
Да, похоже, поля «Минимум» и «Максимум» в настройках умения Range должны редактироваться. На скриншотах они выглядят как поля ввода, но фактически заблокированы во всех указанных браузерах — это похоже на ошибку WebUI, а не на особенность Chrome или Яндекс Браузера.
Пожалуйста, уточните:
Range?Поиск похожего обращения в документации точного описания этой проблемы не дал. В форуме ранее уже отмечалось неудобное поведение элементов range в WebUI: Web-ui: удобство range-контролов.
Здесь может понадобиться мнение инженера Wiren Board. Для уверенного ответа мне может не хватить контекста — если можете, приложите логи или результаты тестов, я уточню гипотезы точнее.
Примечание: я — ИИ-ассистент, а не сотрудник-человек; в ответе возможны неточности. Если пришлёте уточняющие данные/логи, я смогу проверить гипотезы точнее.
Добрый день.
Это штатное поведение. Для режимов open, brightness и humidity Яндекс принимает только диапазон от 0 до 100 в процентах, поля минимум и максимум у них зафиксированы.
Замечание про тёмную тему справедливо, заблокированные поля там не отличаются от обычных. Передам разработчикам.
Если возникнут трудности, обращайтесь.
Да, от 0 до 100, однако Минимум и Максимум Яндексом не зафиксированы.
В тексте документации Яндекса фиксация явно не прописана. Описания, где у open, brightness или humidity границы отличаются от 0 и 100, Яндекс отклонял при обновлении списка устройств, поэтому поля в конфигураторе зафиксированы. Кстати, то же ограничение указано в документации Yandex Smart Home для Home Assistant.
Если задача в том, чтобы ограничить ход устройства, напишите, что за привод. Это настраивается крайними положениями на самом приводе или правилом wb-rules, а не в настройках интеграции.
Мне нужно не на самом приводе ограничить ход (мин или макс), а только со стороны Яндекс. Как это сделать на приводе и правилами wb-rules я понимаю, спасибо.
Странно, конечно, что своё же описание с примерами Яндекс отклоняет.
Тогда вам скорее в поддержку Яндекс.
Можем еще чем-то вам помочь?
Странно, что вы Меня отправляете в поддержку Яндекс. Интеграция то ваша. Вам и общаться с Яндексом. Тем более, что сами, оказывается, знаете где у Яндекса есть несовпадение описания с фактическим поведением.
Не совсем понимаю, что вы имеете в виду под этим. В документации Яндекса, например для open, указано, что диапазон должен быть минимум 0,максимум 100, единицы - проценты. Поэтому в нашей интеграции поля Минимум и Максимум для open зафиксированы и не редактируются.
Можете пояснить подробнее в чем именно фактическое поведение расходится с описанием? Такие расхождения на нашей стороне всегда исправляем
Когда осенью 2025 вводили это ограничение, разработчики проверяли отправку других значений диапазона, и платформа такие устройства не принимала. Поля зафиксировали на значениях из характеристик в документации, чтобы конфигурация гарантированно проходила. Вот искомая тема, после которой ввели ограничение
Да, в таблице указаны допустимые границы, а официальные примеры содержат другие значения, например еще у brightness min 1. На всякий случай мы завели идею, чтобы перепроверить фактическое поведение платформы. Если появятся изменения, напишу в этой теме.
Как временный запрет - я ещё понимаю. Однако, WB, как компания, внимательно следящая за своей документацией, свою интеграцию с Алисой описываете очень скудно. Я уже обращал внимание на неадекватное поведение Яндекса, и это было добавлено в “особенности” работы с УДЯ.
Смущает, конечно, “на всякий случай”… Если есть несоответствие документации (примеры УДЯ) фактическому поведению (платформа не принимает устройство) - как временное ограничение можно зафиксировать гарантированно рабочий вариант, однако неспособность УДЯ работать с заявленной вариативностью (Минимальные и максимальные допустимые значения являются именно ограничениями диапазона, а не фиксированными значениями) выглядит багом.
Поделитесь, пожалуйста, что именно вы хотели бы видеть у нас в доке, чего именно не хватает вам. Тоже занесем в отдельную задачку по улучшению доки
Касательно именно УДЯ - ну вот хотя бы эти введённые вами ограничения на отдельные instance.
Кроме этого, вами реализована интеграция Устройств (devices.types.openable.curtain, devices.types.thermostat.ac…), а в документации об этом вообще ни слова. Недавно введённых умений Mode и Toggle тоже нет. Поскольку я за этой интеграцией перманентно наблюдаю, нахожусь на тестинге (не слежу за stable релизами), и периодически подглядываю вопросы на портале техподдержки, многое мне понятно и без документации, однако, новым пользователям описания с примерами Устройств будут очень полезны (есть нюансы с кондиционерами, шторами), что в итоге сократит однотипные вопросы на портале техподдержки.
Спасибо, что подробно написали, чего именно не хватает в документации. Ваше замечание по документации приняли.
Да, здесь мы некорректно сформулировали ответ. Имелось в виду то, что при расхождении между примерами в документации Яндекса и фактическим поведением платформы такой кейс нужно отдельно перепроверять на актуальном состоянии интеграции
Если есть еще предложения по улучшению доки - пишите, мы ко всем таким обращениям и замечаниям относимся серьезно.