Как настроить MQTT в умном доме без хаоса

MQTT для умного дома — это “шина” обмена сообщениями: устройства публикуют состояния и события в топики, а Home Assistant, Node-RED и другие сервисы подписываются и реагируют. Чтобы всё работало стабильно, заранее задайте структуру топиков, правила QoS/retained и включите базовую безопасность на брокере.

Оглавление

Зачем MQTT и что важно знать

MQTT полезен, когда у вас несколько “контуров” (например, Zigbee2MQTT + ESPHome/Tasmota + автоматика в Node-RED): компоненты слабо связаны, их можно менять независимо, а данные идут через единый брокер.

Минимум терминов, которые реально пригодятся:

  • Broker (брокер) — сервер MQTT (часто Mosquitto).
  • Client (клиент) — устройство/программа, подключённая к брокеру.
  • Topic (топик) — путь сообщения (home/kitchen/light/power/state).
  • Retained — брокер хранит последнее значение топика и отдаёт новому подписчику сразу.
  • LWT (Last Will) — сообщение “offline”, которое брокер опубликует, если клиент пропал.

Топики, payload, QoS и retained: практические правила

Главная цель — чтобы в дереве MQTT было понятно: где команда, где состояние, где доступность.

Рекомендуемый шаблон топиков

Выберите один префикс (например, home/) и придерживайтесь схемы:

  • home/<zone>/<device>/<entity>/state — состояние (что сейчас)
  • home/<zone>/<device>/<entity>/set — команда (куда “пишут” управляющие системы)
  • home/<zone>/<device>/availability — доступность (online/offline)

Пример:

  • home/kitchen/ceiling_light/power/state → ON
  • home/kitchen/ceiling_light/power/set → OFF
  • home/kitchen/ceiling_light/availability → online

Сразу договоритесь об именах zone/device: это экономит время при миграциях, отладке и настройке прав (ACL).

Payload: проще — лучше

  • Для реле/лампы: ON/OFF (без JSON).
  • Для датчиков: JSON уместен, если значения идут “пакетом”: {"temperature":23.4,"humidity":41,"battery":87}

QoS и retained: короткая шпаргалка

Как выбирать QoS и retained в умном доме

Тип данныхQoSRetainedЗачем
Телеметрия (часто, не критично)0нетменьше трафика и задержек
Состояния (вкл/выкл, режим)1дановый подписчик сразу узнаёт текущее состояние
События (кнопка, движение как “событие”)1нетсобытие не должно “всплывать” позже
Доступность (availability/LWT)1обычно даUI быстрее показывает online/offline

Не включайте retained “на всё подряд”. Самая частая причина “призрачных” сущностей и странных автозапусков — сохранённые старые сообщения там, где должны быть только события.

Mosquitto + Home Assistant: подключение и безопасность

Mosquitto: минимальный набор настроек

В домашнем сценарии достаточно придерживаться принципов (не обязательно усложнять конфиг сразу):

  1. Запретить анонимный доступ.
  2. Создать пользователей (отдельные учётки для Home Assistant, Zigbee2MQTT, Node-RED, датчиков).
  3. Включить ACL, чтобы клиент мог читать/писать только нужные ветки.
  4. По необходимости: TLS (если MQTT доступен не только в доверенной локальной сети).

Практичная логика прав:

  • Zigbee2MQTT: запись в zigbee2mqtt/#, чтение команд (если используете).
  • Home Assistant: чтение home/#, запись в home/#/set и discovery-ветку.
  • Датчики: запись только в свои .../state и .../availability, без доступа к чужим .../set.

Home Assistant: Discovery и “порядок” в сущностях

Home Assistant умеет:

  • работать с MQTT-сущностями вручную;
  • автоматически добавлять устройства через MQTT Discovery (удобнее в эксплуатации).

Чтобы discovery не превращался в мусор:

  • используйте один discovery prefix и не меняйте его без нужды;
  • если устройство удалили/переименовали — очищайте старые retained discovery-сообщения (иначе “призраки” вернутся после перезапуска).

Хорошая практика: разделяйте “боевые” топики home/... и служебные топики discovery. Так проще делать бэкап/очистку и понимать, что генерирует Home Assistant, а что — устройства.

Частые ошибки

  • Смешали команды и состояния: публикуют управление в .../state, а устройство слушает .../set (или наоборот).
  • Retained на событиях: кнопка “нажата” сохраняется и срабатывает позже.
  • Одинаковый client_id у двух клиентов: они выкидывают друг друга с брокера.
  • Нет LWT/availability: UI показывает offline/unknown, автоматика ведёт себя непредсказуемо.
  • Слишком частые публикации (10+ раз/сек) без смысла: рост нагрузки и задержки.

FAQ

Нужен ли MQTT, если уже есть Home Assistant?
Не обязателен, но сильно помогает, когда появляются Zigbee2MQTT/Tasmota/самописные устройства или вы хотите связать HA с внешней логикой (например, Node-RED) без “склейки” интеграций.

Где лучше держать брокер — вместе с Home Assistant или отдельно?
Для простоты можно на том же сервере. Отдельно — удобнее для независимых обновлений и диагностики. В любом случае важнее: пароли, ACL и ограничение доступа по сети.

MQTT 3.1.1 или MQTT 5?
Для большинства домашних сценариев достаточно 3.1.1. MQTT 5 полезен дополнительными опциями, но стабильность чаще упирается не в версию, а в дисциплину топиков, retained и правах доступа.