Zigbee2MQTT или ESPHome: что выгоднее и когда

MAATRIX

Когда собираешь умный дом, рано или поздно упираешься в развилку: брать готовые Zigbee-устройства и городить Zigbee2MQTT, или паять свои датчики и реле на ESP32 под ESPHome. В интернете обычно советуют «и то, и другое», что технически верно, но не отвечает на вопрос — а с чего начать именно вам. Разберём разницу по железу, деньгам и реальным сценариям, без религиозных споров.

Это разные вещи, а не конкуренты

Zigbee2MQTT — это мост между Zigbee-сетью и MQTT-брокером. Он не работает сам по себе: нужен физический Zigbee-координатор (USB-стик вроде Sonoff Zigbee 3.0 или CC2652), сам софт Zigbee2MQTT, MQTT-брокер (обычно Mosquitto) и что-то, что читает данные из MQTT — чаще всего Home Assistant. То есть вы покупаете готовые устройства (розетки, датчики, лампы Aqara, IKEA, Xiaomi) и подключаете их к своей сети через координатор.

ESPHome — это генератор прошивок. Вы пишете YAML-конфиг, ESPHome компилирует из него бинарник и заливает на плату ESP32/ESP8266/ESP32-C3. Прошивка сама умеет отдавать состояние по нативному API Home Assistant (или по MQTT, если явно указать) — никакого отдельного координатора не нужно, устройство просто сидит в вашем Wi-Fi.

Отсюда первый честный вывод: если вы хотите готовые датчики «из коробки» — вам нужен Zigbee2MQTT. Если хотите контролировать железо и логику до последнего пина — ESPHome. Дальше — детали, которые обычно всплывают уже после покупки.

Требования к железу и серверу

Цифры RAM — ориентир, у вас будет отличаться в зависимости от числа устройств и версии софта; для точных прикидок у нас есть отдельный разбор сколько RAM нужно для Zigbee2MQTT и сколько RAM нужно для ESPHome.

Ключевая асимметрия — строка про физическое расположение. Zigbee2MQTT жёстко привязан к USB-устройству: если координатор воткнут в мини-компьютер дома, а Home Assistant крутится на облачном VPS, вам нужен проброс USB по сети (USB/IP, или готовые решения вроде usbip-контейнеров) — это добавляет точку отказа и задержку. Вариант проще: держать сам Zigbee2MQTT на локальной машине рядом с координатором, а на VPS — только Home Assistant, бэкапы, VPN-доступ извне и мониторинг. ESPHome от этой проблемы свободен в принципе: плата подключается по Wi-Fi, а дашборд компиляции можно держать хоть на сервере в другой стране — устройству всё равно, откуда прилетела прошивка.

Когда выгоднее Zigbee2MQTT

Zigbee2MQTT выигрывает, когда вам нужно быстро закрыть типовые задачи готовыми устройствами:

• Датчики открытия дверей/окон, движения, протечки — покупные Zigbee-версии стоят вменяемо и не требуют пайки.
• Розетки и выключатели с сертификацией — важно, если это реальная электросеть, а не макетная плата.
• Большая экосистема: сотни поддерживаемых моделей Aqara, IKEA Tradfri, Xiaomi, SONOFF, Tuya Zigbee — драйверы уже написаны сообществом, конфигурировать почти ничего не нужно.
• Батарейные устройства с реальной автономностью в месяцы — Zigbee проектировался как low-power протокол для таких задач, у DIY ESP-решений на батарейках такой экономии добиться сложнее без отдельной инженерной работы по глубокому сну.

Минус — вы платите за готовое решение и зависите от производителя устройства: если модель снята с продажи или драйвер в Zigbee2MQTT отстаёт от прошивки, чинить нечем, кроме как ждать апдейта или менять устройство.

Когда выгоднее ESPHome

ESPHome оправдан, когда типового устройства просто не существует или оно вас не устраивает:

• Нестандартные датчики: комбинация «температура + СО2 + освещённость» на одной плате под конкретный корпус.
• Управление сложной логикой прямо на устройстве — например, ESPHome умеет выполнять автоматизации локально, без обращения к Home Assistant, что критично, если сеть моргает, а свет должен включаться всегда.
• Интеграция нестандартной периферии: RS485-счётчики, самодельные диммеры, дверные замки на нестандартных драйверах — если для железки есть библиотека под ESP-IDF/Arduino, её почти всегда можно завернуть в ESPHome-компонент.
• Полный контроль над прошивкой без вендор-лока: конфиг лежит у вас в git, компилируется локально или в облаке, не зависит от чужих серверов.

Плата за гибкость — время. Пайка, отладка, иногда самостоятельная докрутка YAML под нестандартный компонент. Для человека, который хочет «поставить датчик протечки за вечер», это не то решение.

Совместимость с Home Assistant

Оба варианта интегрируются с Home Assistant, но по-разному, и это не мелочь.

Zigbee2MQTT публикует состояния в MQTT-топики, а Home Assistant подписывается на них через интеграцию MQTT (обычно с автообнаружением через homeassistant/ топики — Zigbee2MQTT включает его по умолчанию). Если MQTT-брокер упал, Home Assistant теряет свежие данные, пока брокер не поднимется — лишняя точка отказа в цепочке.

ESPHome изначально писался под нативную интеграцию: устройство само регистрируется в Home Assistant по протоколу ESPHome API, без посредников. Меньше звеньев — меньше что может сломаться. MQTT в ESPHome можно включить вручную, если вы уже строите MQTT-инфраструктуру и хотите унификации, но по умолчанию он не нужен.

Если вы уже развернули Home Assistant, у нас есть пошаговая инструкция как установить Home Assistant на VPS — оба продукта из этой статьи обычно ставятся рядом с ним, а не вместо.

Стоимость владения на дистанции

Разовая цена входа обманчива, честнее сравнивать в пересчёте на «одна точка данных в доме» на горизонте пары лет.

Zigbee-координатор — разовая покупка (условно один раз на всю сеть, независимо от числа устройств). Дальше каждое устройство — это цена конкретной модели в магазине: датчик протечки, розетка, лампа — готовые, с гарантией, без вашего времени на пайку. Из минусов — вы платите наценку производителя и иногда переплачиваете за бренд ради совместимости с экосистемой.

ESP32-плата стоит ощутимо дешевле одного фирменного Zigbee-датчика, но к ней добавляется корпус, датчики-компоненты, паяльник и время на сборку и отладку. Экономика включается на масштабе: если нужно 20 одинаковых самодельных датчиков температуры в теплице — ESPHome с одним отлаженным YAML-конфигом и мультизаливкой прошивок выйдет заметно дешевле, чем 20 покупных Zigbee-датчиков. Для одного-двух устройств экономии почти нет, а времени уйдёт больше.

Отдельная статья расходов — сервер. Оба продукта легковесные и не требуют мощного VPS: небольшого тарифа с 1–2 ГБ RAM достаточно и для Zigbee2MQTT с MQTT-брокером, и для дашборда ESPHome, особенно если они делят машину с Home Assistant. Разница в цене сервера между сценариями «только ESPHome» и «Zigbee2MQTT + MQTT + Home Assistant» на практике небольшая — экономить на этом не стоит, лучше сразу взять тариф с запасом на будущие датчики.

Развёртывание на сервере: практическая разница

Для Zigbee2MQTT типовой docker-compose требует проброса USB-устройства в контейнер:

services:
  zigbee2mqtt:
    image: koenkk/zigbee2mqtt
    restart: unless-stopped
    volumes:
      - ./data:/app/data
      - /run/udev:/run/udev:ro
    devices:
      - /dev/ttyACM0:/dev/ttyACM0
    environment:
      - TZ=Europe/Moscow
    ports:
      - "8080:8080"

Если ваш координатор физически воткнут не в тот сервер, где крутится Docker, devices: в compose-файле работать не будет — Docker не пробрасывает USB по сети сам. Тут либо держите Zigbee2MQTT на машине с координатором (мини-ПК, Raspberry Pi, локальный сервер), либо настраивайте USB/IP отдельно — это рабочий, но не тривиальный вариант, который стоит проверять на тестовом стенде, прежде чем полагаться на него в проде. Готовый разбор с типовыми конфигами есть в статье Zigbee2MQTT в Docker Compose.

ESPHome в развёртывании проще — никакого проброса устройств не нужно, дашборд компиляции работает как обычный веб-сервис:

services:
  esphome:
    image: ghcr.io/esphome/esphome
    restart: unless-stopped
    network_mode: host
    volumes:
      - ./config:/config
    environment:
      - TZ=Europe/Moscow

network_mode: host здесь нужен, чтобы дашборд видел устройства в локальной сети для OTA-обновлений и логов по mDNS — если сервер в облаке, а платы дома, придётся либо заводить VPN между ними, либо заливать первую прошивку по USB-кабелю, а дальнейшие апдейты гонять через прямой IP платы. Подробный гайд по установке — ESPHome в Docker Compose, а частые проблемы после первого запуска разобраны в статье про типичные ошибки ESPHome на сервере.

Комбинированный подход: не выбирать одно

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

• Zigbee2MQTT закрывает типовые точки: двери, окна, движение, розетки, климат-контроль по готовым сертифицированным устройствам.
• ESPHome закрывает нестандартные узлы: полив по датчикам влажности почвы, управление воротами с концевиками, самодельная вентиляция с ПИД-регулированием — там, где готового Zigbee-устройства просто не производят.
• Оба сходятся в одном Home Assistant, который уже занимается автоматизациями, историей и уведомлениями — не дублируйте эту логику отдельно в MQTT-скриптах и ESPHome-автоматизациях, если можно централизовать.

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

Частые вопросы