Почему датчик показывает "неизвестно" и чем это отличается от нуля

В карточке датчика иногда появляется "неизвестно", и здесь особенно легко ошибиться с автоматизацией. Подмена отсутствующего показания нулём создаёт вполне определённое значение, которого устройство не передавало. Прежде чем строить условие, полезно выяснить, какие состояния интеграция вообще умеет сообщать.

Что объявляет интеграция

В Google SensorState описаны количественные измерения и качественные состояния. При объявлении возможностей каждого сенсора указываются числовой вариант, описательный вариант или оба сразу, причём при наличии обоих предпочтение отдаётся числу. Для описательных значений задаётся список состояний, а для числовых указывается единица rawValueUnit. Текущий ответ содержит соответствующие поля.

Состояние unknown предусмотрено, когда сенсор не возвращает значение. Наборы возможностей различаются по типам: углекислый газ описывается числом в частях на миллион, PM2.5 и PM10 измеряются в микрограммах на кубический метр. Для протечки в этой схеме перечислены словесные состояния, числовой вариант не предусмотрен. Общая надпись "датчик" в каталоге не раскрывает этих различий.

Документация определяет формат обмена с интеграцией Google Cloud-to-cloud. Она сама по себе не подтверждает метод измерения внутри конкретного прибора, его точность или доступность всех этих данных в стороннем приложении. Эти сведения нужно брать из документации модели и используемого подключения.

Как возникает ошибка в бытовом правиле

Рассмотрим редакционный пример без привязки к конкретному устройству. Владелец хочет показывать напоминание при определённом показании сенсора, а приложение временно перестаёт получать данные. Если обработчик записывает вместо отсутствующего числа ноль, график рисует резкое улучшение, хотя измерения в этот момент не было. Такой график скрывает разрыв связи.

Для интерфейса полезно хранить само значение вместе с единицей и признаком его доступности. Если платформа предоставляет время последнего обновления, выводите и его. Один и тот же показатель может оставаться видимым после потери связи, поэтому наличие числа на экране ещё не говорит о свежем измерении. Способ проверки актуальности зависит от конкретной интеграции.

Проверка карточки до настройки сценария

Сравните данные фирменного приложения с тем, что показывает выбранная домашняя платформа. Проверьте название показателя, единицу и доступные состояния. Разницу между ppm и микрограммами на кубический метр нельзя исправить заменой подписи: эти единицы относятся к разным физическим величинам.

Затем посмотрите, что происходит при временной недоступности прибора в безопасных условиях. Зафиксируйте, сохраняется ли старое число, появляется ли unknown и возвращается ли обновление после восстановления связи. Для такой проверки подходят информационные бытовые сценарии, проводить её на системе, от которой зависит безопасность людей, без соответствующей процедуры не следует.

Правило с уведомлением должно отдельно обрабатывать недоступные данные и проверяемое показание. Конкретные пороги выбирают по назначению прибора и подтверждённым требованиям, документация формата API таких порогов для квартиры не задаёт. Сохраните описание поля и единицу рядом с настройкой автоматизации, чтобы поздняя замена сенсора не меняла смысл условия незаметно.

Источник и права

Исходник: Smart Home SensorState Trait Schema, Google, документация Google Home Developers. Язык оригинала: английский. Режим: сокращённый перевод и редакционная адаптация. Использованы разделы Device ATTRIBUTES, Supported Sensors, Device STATES.

Текст оригинала опубликован по Creative Commons Attribution 4.0 International. Материал переведён на русский, сокращён и перестроен; программные примеры и тестовые задания опущены, добавлены пояснения и бытовые ситуации редакции. Адаптацию подготовило издание команды sentibox. Google и участники OpenThread не проверяли и не одобряли эту публикацию. Оригинальная схема редакции также доступна по CC BY 4.0.