Device Class в Home Assistant: как правильно настроить и почему это важно для умного дома

Home Assistant — одна из самых гибких платформ для управления умным домом, но её мощь раскрывается только при правильной конфигурации. Один из ключевых элементов, который часто упускают новички (а иногда и опытные пользователи), — это device class. От него зависит, как система будет интерпретировать данные с датчиков, какие иконки отобразит в интерфейсе, и даже как будут работать автоматизации.

Представьте: вы подключили датчик температуры, но в интерфейсе он отображается как обычный сенсор без градусов, или ваш датчик движения срабатывает как освещённость. Это типичные проблемы, вызванные неправильным (или отсутствующим) указанием device class. В этой статье мы разберём, что это такое, какие классы существуют, как их назначать в configuration.yaml и YAML-конфигах устройств, а также раскроем нюансы, о которых не пишут в официальной документации.

Что такое Device Class и зачем он нужен

Device class — это метка, которая сообщает Home Assistant, к какому типу относится устройство или сенсор. Она определяет:

• 📊 Формат отображаемых данных (например, °C для температуры, % для влажности).
• 🎨 Иконку в интерфейсе (термометр, лампочка, дверь и т.д.).
• 🤖 Логику автоматизаций (например, триггеры для датчиков движения или открытия окон).
• 📱 Интеграцию с голосовыми помощниками (Google Assistant, Alexa).

Без правильного device class ваш датчик углекислого газа может отображаться как бессмысленное число, а датчик протечки воды — как обычный бинарный сенсор. Более того, некоторые интеграции (например, Energy Dashboard) просто не будут работать без корректных классов.

Официальная документация Home Assistant перечисляет десятки классов, но не всегда объясняет, как их применять на практике. Например, мало кто знает, что класс humidity автоматически добавляет единицу измерения "%", а класс power — "Вт". Это экономит время на ручной настройке.

Основные типы Device Class и их назначение

Все классы в Home Assistant делятся на несколько категорий. Рассмотрим самые востребованные:

Особняком стоят классы для климатического оборудования (например, hvac_mode для кондиционеров) и мультимедиа (например, media_player). Их настройка требует отдельного внимания, так как они влияют на работу панелей управления в интерфейсе.

Как назначить Device Class: пошаговая инструкция

Способы назначения device class зависят от типа устройства и метода его подключения к Home Assistant. Рассмотрим основные сценарии:

1. Через configuration.yaml (для ручной настройки)

Если вы настраиваете устройство через YAML, добавьте параметр device_class в соответствующий раздел. Пример для бинарного сенсора:

binary_sensor:
- platform: mqtt
name: "Датчик движения в коридоре"
state_topic: "home/motion/corridor"
    device_class: motion

Для обычных сенсоров (не бинарных) синтаксис аналогичный:

sensor:
- platform: template
name: "Температура на улице"
unit_of_measurement: "°C"
    device_class: temperature
value_template: "{{ states('sensor.outdoor_temp') | float }}"

2. Через интерфейс Home Assistant (для интеграций с поддержкой UI)

Многие современные интеграции (например, Zigbee2MQTT, ESPHome) позволяют назначить device class прямо в веб-интерфейсе:

1. Перейдите в Настройки → Устройства и службы.
2. Выберите нужное устройство и нажмите Настроить.
3. Найдите поле Device Class (или Тип устройства) и выберите подходящий вариант из выпадающего списка.

3. Для MQTT-устройств

Если ваше устройство общается по MQTT, класс можно задать либо в конфигурации Home Assistant (как в первом примере), либо прямо в топике config (если устройство поддерживает MQTT Discovery):

homeassistant/binary_sensor/pir_1/config:
{
"name": "Датчик движения",
"device_class": "motion",
"state_topic": "home/pir_1/state",
"payload_on": "ON",
"payload_off": "OFF"
}

Важно: некоторые интеграции (например, Z-Wave JS) автоматически назначают классы на основе модели устройства. В этом случае ручное изменение может привести к конфликтам.

Распространённые ошибки и как их избежать

Даже опытные пользователи иногда сталкиваются с проблемами из-за неверного назначения device class. Вот самые частые ошибки:

⚠️ Внимание: Никогда не используйте класс temperature для датчиков, измеряющих что-то кроме температуры воздуха (например, температуру воды или процессора). Это нарушит работу Energy Dashboard и климатических автоматизаций.

• 🔄 Путаница между бинарными и обычными сенсорами. Например, датчик протечки воды должен иметь класс moisture (бинарный), а не humidity (сенсор).
• ⚡ Несовпадение единиц измерения. Класс power подразумевает ватты (Вт), а energy — киловатт-часы (кВт·ч). Если ваш счётчик отдаёт данные в других единицах, их нужно конвертировать.
• 🚪 Игнорирование состояний "открыто/закрыто". Для классов door, window, garage_door важно, чтобы состояния передавались как on/off или open/closed, иначе иконки будут отображаться некорректно.

Ещё одна распространённая проблема — невидимые сенсоры. Если вы назначили класс, но датчик не появляется в интерфейсе, проверьте:

1. Поддерживает ли выбранный класс отображение в текущей версии Home Assistant (некоторые классы, например aqi для качества воздуха, требуют последних обновлений).
2. Нет ли конфликтов с другими конфигурациями (например, дублирующиеся entity_id).
3. Корректно ли указан unit_of_measurement (для некоторых классов он обязателен).

Продвинутые сценарии: кастомные Device Class и шаблоны

Иногда стандартных классов недостаточно. Например, у вас может быть датчик, который измеряет уровень шума в децибелах, но в Home Assistant нет для этого отдельного класса. В таких случаях можно:

1. Использовать шаблоны для создания кастомных сенсоров

С помощью Template Sensor вы можете назначить любой класс, даже если он не документирован. Пример для датчика шума:

sensor:
- platform: template
name: "Уровень шума в комнате"
unit_of_measurement: "dB"
    device_class: sound  # Неофициальный класс, но работает
value_template: "{{ states('sensor.noise_level') | float }}"

Не все неофициальные классы будут корректно отображаться в интерфейсе, но они позволят фильтровать сущности в автоматизациях по типу.

2. Комбинировать классы с атрибутами

Если класс не полностью описывает ваше устройство, добавьте дополнительные атрибуты. Например, для датчика качества воздуха:

sensor:
- platform: mqtt
name: "Качество воздуха"
state_topic: "home/air_quality"
    device_class: aqi
json_attributes_topic: "home/air_quality/attributes"
value_template: "{{ value_json.pm25 }}"

В этом случае основной класс — aqi, но дополнительные данные (например, уровни PM10, CO₂) будут доступны через атрибуты сущности.

3. Создавать виртуальные устройства с несколькими классами

Например, один физический датчик может предоставлять и температуру, и влажность. В этом случае создайте две отдельные сущности:

sensor:
- platform: mqtt
name: "Температура в гостиной"
state_topic: "home/livingroom/sensor"
    device_class: temperature
unit_of_measurement: "°C"
value_template: "{{ value_json.temperature }}"

- platform: mqtt
name: "Влажность в гостиной"
state_topic: "home/livingroom/sensor"
    device_class: humidity
unit_of_measurement: "%"
value_template: "{{ value_json.humidity }}"

Device Class и автоматизации: нюансы, о которых не говорят

Корректный device class не только влияет на отображение, но и меняет логику работы автоматизаций. Вот несколько примеров:

• 🌡️ Датчики с классом temperature можно использовать в климатических автоматизациях (например, включение обогревателя при падении температуры ниже порога).
• 🚶 Датчики движения (motion) автоматически сбрасываются в состояние off через заданный интервал (по умолчанию 30 секунд), если не поступает обновлений. Это поведение можно изменить в настройках интеграции.
• 🔋 Для классов battery и signal_strength в Home Assistant есть встроенные уведомления о низком уровне заряда или слабом сигнале.

Особое внимание стоит уделить бинарным сенсорам. Их классы определяют, какие триггеры доступны в автоматизациях. Например:

• Класс door позволяет использовать триггеры "открыто" и "закрыто".
• Класс smoke добавляет возможность отправки экстренных уведомлений.
• Класс occupancy (наличие человека) часто используется для управления освещением.

⚠️ Внимание: Если вы используете класс garage_door, убедитесь, что ваш датчик поддерживает состояние "открывается/закрывается" (opening/closing), а не только "открыто/закрыто". В противном случае панель управления в интерфейсе будет работать некорректно.

Для энергетических классов (power, energy) Home Assistant автоматически рассчитывает статистику потребления, которая отображается в Energy Dashboard. Однако если ваш счётчик сбрасывается (например, раз в месяц), необходимо настроить параметр state_class: total_increasing, чтобы система правильно учитывала данные:

sensor:
- platform: mqtt
name: "Потребление электроэнергии"
state_topic: "home/energy/meter"
    device_class: energy
    state_class: total_increasing
unit_of_measurement: "kWh"

Device Class в интеграциях: что нужно знать

Разные интеграции по-разному работают с device class. Вот что важно учитывать:

1. Zigbee2MQTT

В Zigbee2MQTT классы назначаются в файле configuration.yaml или через веб-интерфейс. Особенности:

• 🔹 Поддерживаются не все классы (например, нет aqi для качества воздуха).
• 🔹 Для некоторых устройств (например, Xiaomi) классы назначаются автоматически, но не всегда корректно.
• 🔹 Чтобы переопределить класс, используйте параметр device_class в конфигурации устройства.

2. ESPHome

В ESPHome классы указываются прямо в коде прошивки. Пример для датчика температуры:

sensor:
- platform: dht
temperature:
name: "Температура"
      device_class: "temperature"
humidity:
name: "Влажность"
      device_class: "humidity"

Важно: в ESPHome классы чувствительны к регистру! Всегда используйте нижний регистр (например, temperature, а не Temperature).

3. Z-Wave JS

Эта интеграция обычно назначает классы автоматически на основе Z-Wave Command Class. Однако иногда требуется ручная корректировка. Например, датчики Fibaro Door/Window Sensor могут определяться как opening вместо door. Чтобы исправить это:

1. Откройте файл конфигурации Z-Wave JS.
2. Найдите раздел с вашим устройством.
3. Добавьте параметр device_class с нужным значением.

Для устройств Aeotec (например, Aeotec Multisensor 6) может потребоваться дополнительная настройка параметров sensor_type в конфигурации узла.

4. Modbus

При работе с Modbus классы назначаются вручную в configuration.yaml. Особенность: если ваш счётчик электроэнергии отдаёт данные в формате 0.01 кВт·ч, не забудьте умножить значение на 100, чтобы получить корректные показания:

sensor:
- platform: modbus
name: "Электроэнергия"
    device_class: energy
state_class: total_increasing
unit_of_measurement: "kWh"
scale: 0.01
address: 1000

FAQ: ответы на частые вопросы

homeassistant:
customize:
sensor.my_tuya_sensor:
device_class: temperature

sensor:
- platform: template
name: "Средняя температура в доме"
    device_class: temperature
unit_of_measurement: "°C"
value_template: >-
{{ (states('sensor.livingroom_temp') | float +
states('sensor.bedroom_temp') | float) / 2 | round(1) }}

sensor:
- platform: mqtt
name: "Расход воды"
    device_class: water
    state_class: total_increasing
unit_of_measurement: "m³"

homeassistant:
customize:
sensor.my_custom_sensor:
device_class: my_custom_class