@UI-Team Та же проблема, и стоит добавить деталей для команды UI, потому что, думаю, это шире, чем одно устройство.**Идентичный симптом.** Внедрили UP Air Quality на нашей консоли. UI Protect показывает полную картину. Home Assistant вытаскивает из него 23 сущности, и ни одна не несёт данных о качестве воздуха — contact, moisture, motion, temperature, humidity и illuminance все висят в unavailable. Ни CO2, ни PM, ни VOC, ни AQI, ни vape index нигде.**Это пробел в схеме, а не баг с заполнением.** Стоит сказать это чётко, чтобы это не ушло в триаж как "поля не заполняются". В определении Integration API Protect 7.2.105:- `sensorStats` содержит ровно три объекта измерений — `light`, `humidity`, `temperature`. Нигде нет поля для PM, CO2, VOC, AQI, NOx или vape index.- `sensorFeatureFlags` — это закрытый набор ключей возможностей: `temperature`, `humidity`, `light`, `motion`, `waterLeak`, `open`, `tamper`, `smoke`. Качества воздуха среди них нет, так что устройство даже не может заявить об этой возможности.Нуллы — это не пустые поля качества воздуха. Там нет самих полей качества воздуха, которые могли бы быть пустыми.**Тем временем продукт движется, а API — нет.** Protect 7.2.98 добавил NOx в метрики Air Quality в приложении, а 7.2.105 добавил новые фильтры событий сенсоров в Find Anything. То есть это активно развивается в консоли, пока поверхность Integration API для этого остаётся на нуле. Вот это и трудно планировать — не то, что функция незрелая, а то, что она зреет где-то, куда мы не можем дотянуться.**И разрыв скоро станет ещё шире.** Анонсированное семейство endpoints SuperLink включает сенсоры качества воздуха. Каждый из них — ещё одно внедрённое устройство с богатыми данными в консоли и ничем в API.**У пути алертов та же проблема, слоем выше.** Даже если бы поля появились завтра, payload вебхука Alarm Manager — это name, trigger key, MAC устройства и timestamp. Ни значения сенсора, ни пересечённого порога, ни серьёзности, ни ссылки на событие. То есть внешней системе могут сказать, что *какой-то* сенсорный алерт сработал, но не каким было показание и насколько всё плохо. Для качества воздуха это разница между "записать в лог" и "эвакуировать помещение", и её нельзя выразить. Любой триггер качества воздуха, добавленный в Alarm Manager, унаследует это, если payload тоже не вырастет.**Ещё одна вещь, о которой команда UI может не знать.** Внедрение сенсора, реле, брелока или Alarm Hub переключает Alarm Manager из Local в Global mode, и arm profiles перестают быть доступны на Integration API в Global mode. Нижестоящие интеграции теряют возможность arm/disarm как побочный эффект.Так что текущая структура стимулов реально перевёрнута: **чем больше сенсоров Protect вы внедряете, тем меньше поверхности Integration API у вас остаётся.** Внедрите сенсор качества воздуха — и вы не получите данных о качестве воздуха *и* потеряете arm/disarm на API. Это читается как непреднамеренное взаимодействие, а не как решение, и это делает линейку сенсоров и API фактически взаимоисключающими для всех, кто строит поверх.**Почему важна срочность.** uiprotect — на котором работает Home Assistant — заявил, что новая функциональность в первую очередь нацелена на публичный API, что они ожидают, что публичная аутентификация по ключу станет единственным поддерживаемым путём, и что PR, добавляющие новую функциональность в приватный API, будут закрываться. Всё, что не мигрирует на публичную поверхность, перестаёт быть достижимым вообще, по графику, который задаёт сторона потребителя, а не Ubiquiti. Такие пробелы, как этот, не остаются в виде "пока используйте приватный API". Они становятся постоянными.**Конструктивное предложение, раз форма уже есть.** `sensorFeatureFlags` использует паттерн `channelCount` на каждую возможность. Возможность `airQuality` аккуратно в него встраивается, с измерениями рядом с существующими тремя в `sensorStats`. Аддитивное изменение в рамках устоявшегося паттерна — ни нового ресурса, ни нового endpoint, ни новой поверхности аутентификации.Добавлю вес к запросу вместо голого +1: мониторинг вейпинга и качества воздуха в школах, туалетах, арендных объектах и общих помещениях — один из самых быстрорастущих сегментов в этой категории, и это почти целиком кейс *алертинга и интеграции*, а не дашборда. Никто не разворачивает vape-сенсор, чтобы смотреть на график. Его разворачивают, чтобы получить сообщение. Сегодня ничего из этого не построить для тех, кому нужно, чтобы алерт покинул консоль Protect.