Сколько RAM нужно для Zigbee2MQTT

MAATRIX

Zigbee2MQTT снимает главную боль умного дома на Zigbee — зависимость от фирменного хаба, который завтра может прекратить обновляться или потребовать облачную подписку: один USB-адаптер и один Node.js-процесс превращают радиосеть Zigbee-устройств в обычные MQTT-топики, понятные Home Assistant, Node-RED или любому другому потребителю. Вопрос в том, что документация проекта не даёт чёткой цифры по памяти, а сам процесс на первый взгляд лёгкий — и это создаёт ложное ощущение, что хватит любого дешёвого тарифа, пока рядом не встанут Home Assistant, MQTT-брокер и база истории, которые вместе едят память быстрее, чем кажется. Разберём, сколько весит сам Zigbee2MQTT и что реально нужно закладывать под весь стек.

Сколько RAM нужно Zigbee2MQTT: короткий ответ

Сам процесс Zigbee2MQTT — это Node.js-приложение, которое держит в памяти карту сети (список устройств, их состояние, таблицу маршрутизации через роутеры-ретрансляторы) и обрабатывает входящий/исходящий MQTT-трафик. В покое, сразу после запуска с двумя-тремя десятками устройств, он занимает 80-150 МБ — заметно меньше, чем у Home Assistant Core, потому что нет ни recorder, ни движка автоматизаций, ни системы интеграций.

Ориентир для контейнера Docker на VPS (без учёта соседних сервисов):

Важная оговорка: цифры выше — ориентир по опыту эксплуатации, а не результат формального бенчмарка, и точное потребление у вас может отличаться в зависимости от версии Node.js, модели адаптера и того, сколько устройств шлют состояние часто (датчики энергопотребления в разы «шумнее» обычного выключателя). Дальше — из чего конкретно складывается расход.

Из чего складывается расход памяти

Три компонента дают основной вклад, и они растут не одинаково с числом устройств.

Node.js runtime и сама карта сети. Любой процесс Node.js стартует с базовым потреблением 40-60 МБ только на V8-движок и стандартные модули, ещё до загрузки логики Zigbee2MQTT. Поверх этого приложение держит в памяти объект сети: список устройств, их последнее известное состояние (яркость, температура, батарея), и таблицу маршрутизации — какие устройства-роутеры ретранслируют сигнал каким конечным узлам. На сети до полусотни устройств это прибавляет условно 20-40 МБ, дальше рост нелинейный: чем больше роутеров и глубже mesh-топология, тем чаще пересчитывается таблица маршрутов при переподключении устройств.

Веб-фронтенд (zigbee2mqtt-frontend). Встроенная панель с картой сети, списком устройств и логами — удобная штука для диагностики, но она держит собственный веб-сервер и WebSocket-соединения с браузерами, которые к ней подключены. Каждая открытая вкладка с картой сети в реальном времени добавляет заметный, хотя и небольшой, расход — если фронтенд не нужен постоянно (управляете всем через Home Assistant), его можно отключить в конфиге и сэкономить 20-30 МБ плюс избавиться от лишнего открытого порта.

Логирование и очередь MQTT-сообщений. По умолчанию Zigbee2MQTT пишет подробный лог в файл и в консоль, а при debug-уровне логирования объём вывода растёт на порядок — на активной сети с частыми датчиками движения это не столько занимает RAM напрямую, сколько создаёт постоянную дисковую нагрузку и разрастающиеся лог-файлы, которые стоит ротировать. Сама очередь исходящих MQTT-сообщений в памяти небольшая, но при обрыве связи с брокером (перезапуск контейнера Mosquitto, сетевой сбой) сообщения накапливаются в буфере до восстановления соединения — на секунды-десятки секунд это не критично, но при длительном обрыве стоит учитывать.

Zigbee2MQTT vs ZHA: зачем отдельный процесс, если Home Assistant умеет сам

Если у вас уже стоит Home Assistant, встроенная интеграция ZHA (Zigbee Home Automation) кажется логичным выбором — не нужен отдельный контейнер и MQTT-брокер, координатор Zigbee подключается напрямую к Home Assistant Core. По расходу памяти ZHA действительно немного экономичнее: нет накладных расходов отдельного Node.js-процесса и MQTT-транспорта между двумя сервисами.

Но у Zigbee2MQTT есть практические преимущества, ради которых люди сознательно идут на лишние 100-150 МБ: более широкий список поддерживаемых устройств и координаторов (включая менее популярные китайские адаптеры), независимость от Home Assistant — сеть Zigbee продолжает работать и логировать состояние, даже если Home Assistant упал или перезапускается на обновление, и удобная веб-панель для диагностики проблем с конкретным устройством без захода в Home Assistant вообще. Для установок, где Zigbee-сеть — это не просто «пара лампочек», а десятки датчиков, от которых зависит охранная сигнализация или отопление, эта развязка стоит лишней сотни мегабайт памяти: одна точка отказа (Home Assistant) не тянет за собой другую (саму радиосеть). Подробнее о самом Home Assistant и его собственном расходе памяти — в статье сколько RAM нужно для Home Assistant.

MQTT-брокер: Mosquitto рядом добавляет к бюджету

Zigbee2MQTT без MQTT-брокера не работает — это его единственный канал связи с внешним миром, поэтому Mosquitto (самый распространённый выбор) почти всегда стоит на том же сервере. Хорошая новость — Mosquitto один из самых лёгких сервисов, которые вообще можно развернуть: в состоянии покоя с несколькими клиентами (Zigbee2MQTT, Home Assistant, может быть Node-RED) он держит 10-30 МБ, и даже при десятках тысяч сообщений в сутки от активной сети датчиков рост памяти почти незаметен — MQTT-брокер не хранит историю сообщений сам по себе, только текущие retained-сообщения и список подписок.

Минимальный docker-compose для связки:

services:
  zigbee2mqtt:
    container_name: zigbee2mqtt
    image: koenkk/zigbee2mqtt
    restart: unless-stopped
    volumes:
      - ./data:/app/data
      - /run/udev:/run/udev:ro
    devices:
      - /dev/ttyUSB0:/dev/ttyUSB0
    environment:
      - TZ=Europe/Moscow
    mem_limit: 300m

  mosquitto:
    container_name: mosquitto
    image: eclipse-mosquitto:2
    restart: unless-stopped
    volumes:
      - ./mosquitto/config:/mosquitto/config
      - ./mosquitto/data:/mosquitto/data
    ports:
      - "1883:1883"
    mem_limit: 100m

devices: /dev/ttyUSB0 — путь к USB-адаптеру Zigbee-координатора (CC2652, ConBee II, Sonoff Zigbee 3.0 Dongle и похожие), он должен быть проброшен в контейнер напрямую, монтирования через сетевой прокси USB здесь не работают так же надёжно. Явный mem_limit на оба сервиса дисциплинирует: если что-то пойдёт не так (утечка в логах, зависшее переподключение), Docker перезапустит конкретный контейнер вместо того, чтобы отдать его на откуп OOM killer, который может выбрать жертвой совсем другой процесс на сервере.

Что происходит при нехватке памяти

На сервере с 256-512 МБ без запаса типичный сценарий поломки — обновление самого Zigbee2MQTT или npm-зависимостей внутри контейнера: процесс пересборки временно требует больше памяти, чем работа в штатном режиме, и на этом моменте память заканчивается. Проверить факт такого убийства процесса:

dmesg | grep -i "killed process"
docker inspect zigbee2mqtt --format='{{.State.OOMKilled}}'

Второй, более частый в повседневной эксплуатации симптом — не полный OOM, а деградация при активном свопинге: устройства продолжают откликаться, но с заметной задержкой в несколько секунд между нажатием кнопки в интерфейсе и реакцией лампы или розетки, а карта сети в веб-фронтенде обновляется рывками. Если Zigbee2MQTT стоит рядом с Home Assistant на одном сервере, важно понимать: чаще всего память ест не сам Zigbee2MQTT (он стабильно лёгкий), а recorder Home Assistant, который пишет каждое изменение состояния каждого Zigbee-датчика в свою базу — при активной сети с датчиками движения и энергопотребления это может быть заметный источник роста. Как правильно рассчитать своп под такую комбинированную нагрузку — в материале сколько оперативной памяти закладывать с запасом, общие принципы работы с лимитами контейнеров — в статье лимиты CPU и памяти в Docker.

Практическая конфигурация VPS

Для отдельного контейнера Zigbee2MQTT с Mosquitto, без Home Assistant на том же сервере (например, если управляете всем через собственные MQTT-скрипты или Node-RED) — достаточно 512 МБ-1 ГБ RAM и 1 vCPU. Нагрузка на процессор минимальна и приходится на короткие пики при переподключении устройств или обновлении прошивки координатора, диска хватит 5-10 ГБ под систему, образы контейнеров и логи.

Если Zigbee2MQTT стоит рядом с полноценным Home Assistant (типичная связка для большинства домашних инсталляций) — считайте память по сумме компонентов, а не по самому тяжёлому из них: Zigbee2MQTT (100-150 МБ) + Mosquitto (30-50 МБ) + Home Assistant Core с recorder и десятками интеграций (400-900 МБ) дают комфортный минимум от 2 ГБ с запасом на рост числа устройств и обновления. Пример конфигурации Zigbee2MQTT (data/configuration.yaml) с базовыми параметрами:

homeassistant: true
permit_join: false
mqtt:
  base_topic: zigbee2mqtt
  server: mqtt://mosquitto:1883
serial:
  port: /dev/ttyUSB0
frontend:
  port: 8080
advanced:
  log_level: info
  network_key: GENERATE

permit_join: false по умолчанию — правильная настройка безопасности, включайте разрешение на подключение новых устройств только на время сопряжения, а не постоянно. log_level: info вместо debug в продакшене экономит и место на диске, и лишнюю дисковую нагрузку от постоянной записи подробных логов. Готовый docker-compose со всем стеком Home Assistant + Zigbee2MQTT + Mosquitto разобран в статье Home Assistant в Docker Compose: готовый файл — там же пример с явными лимитами памяти на каждый контейнер.

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