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

MAATRIX

Вопрос «сколько RAM нужно для ESPHome» на самом деле состоит из двух разных вопросов, и их легко перепутать. Один — про сам чип ESP8266/ESP32, у которого память фиксирована в железе и ничем не наращивается. Второй — про сервер, на котором крутится ESPHome Dashboard и компилируется прошивка из вашего YAML-конфига, и вот тут выбор ресурсов полностью в ваших руках. Разберём оба случая честно, с конкретными цифрами под разные сценарии.

Сколько памяти у самих ESP8266/ESP32

Каждый чип — законченная система с фиксированным объёмом SRAM. Часть этой памяти съедает Wi-Fi/BT-стек ещё до того, как ваш YAML-конфиг что-то сделал, так что "доступно для конфига" всегда меньше заявленного объёма.

Точные цифры "свободно" зависят от версии ESPHome, включённых компонентов (Bluetooth Proxy, mDNS, веб-сервер на самом устройстве, шифрование API) и того, сколько entities вы описали в YAML — это ориентир, а не гарантия, замерять стоит на своей прошивке через logger при отладке "Out of memory" перезагрузок. Если плата поддерживает PSRAM, включите её явно:

esp32:
  board: esp32-s3-devkitc-1
  framework:
    type: esp-idf

psram:
  mode: octal
  speed: 80MHz

Что реально грузит память на сервере

ESPHome — это Python-приложение (пакет esphome), которое рисует Dashboard и вызывает PlatformIO для компиляции. Именно компиляция C++ — самая тяжёлая по памяти операция, а не сам веб-интерфейс.

• Dashboard в простое (открыта веб-панель, ничего не собирается) — обычно укладывается в 150-300 МБ.
• Сборка на фреймворке Arduino (классический вариант для ESP8266/ESP32 без BLE/Zigbee) — как правило, укладывается в 300-700 МБ на процесс сборки, но это ориентир: зависит от размера конфига и количества компонентов.
• Сборка на фреймворке esp-idf (нужна для Bluetooth Proxy, Zigbee, продвинутых возможностей ESP32-S3/C3) — заметно тяжелее: esp-idf собирает десятки внутренних библиотек параллельно, и пик может ощутимо превышать сборку на Arduino, особенно при высоком значении -j (число параллельных потоков компиляции).
• Первая сборка под новую плату качает toolchain (компилятор gcc-xtensa или gcc-riscv, библиотеки) — это нагрузка на диск (сотни МБ на кэш PlatformIO), не на RAM, но диск стоит заложить с запасом.

Если видите в логах контейнера просто Killed без внятной ошибки компилятора — в 9 случаях из 10 это OOM killer, а не баг в вашем YAML.

Сколько VPS нужно под разные сценарии

Ядра важнее, чем кажется: компиляция C++ хорошо параллелится, и на 1 vCPU esp-idf-сборка может занимать заметно больше времени, чем на 2-4, при том же объёме RAM. Если собираете прошивки редко (раз в неделю обновили конфиг датчика) — минимальный тариф оправдан. Если у вас "флот" из полусотни устройств и вы гоняете сборки в CI при каждом коммите YAML — экономия на RAM обернётся упавшими джобами и потерянным временем на диагностику.

Docker Compose: ESPHome на VPS

Официальный образ проще всего поднять через Compose с ограничением памяти, чтобы контейнер не устраивал сюрпризов соседям по серверу:

services:
  esphome:
    image: ghcr.io/esphome/esphome
    container_name: esphome
    restart: unless-stopped
    network_mode: host
    volumes:
      - ./config:/config
      - ./platformio-cache:/root/.platformio
    environment:
      - USERNAME=admin
      - PASSWORD=change-me
    mem_limit: 2g

network_mode: host нужен для mDNS-обнаружения устройств и удобной OTA-заливки — без него Dashboard не увидит устройства в локальной сети автоматически. Кэш PlatformIO вынесен в отдельный volume: без него каждая пересборка заново качает toolchain, и это лишняя нагрузка на диск и сеть.

Важная честная оговорка: если ESPHome работает на удалённом VPS, а ваши ESP-устройства сидят дома за роутером, VPS физически не находится в одной сети с устройствами — OTA-обновление "по воздуху" напрямую не дойдёт. Рабочие варианты: (1) собирать прошивку в облаке, скачивать .bin и заливать по USB вручную; (2) поднять VPN между VPS и домашней сетью (например WireGuard), тогда mDNS и OTA будут работать почти как в локалке — про это подробнее в статье про IoT-устройства и VPN. Первая заливка новой платы в любом случае обычно делается по кабелю — это ограничение самого протокола OTA, а не сервера.

Как сэкономить RAM и ускорить сборку

• Не запускайте несколько сборок параллельно на слабом тарифе — очередь в Dashboard существует не просто так, esphome может собирать по несколько устройств сразу, если дать команду через CLI/скрипт, и на 1-2 ГБ RAM это гарантированный OOM.
• Используйте Arduino-фреймворк там, где не нужны BLE Proxy, Zigbee или специфичные esp-idf-компоненты — сборка ощутимо легче.
• Сохраняйте кэш PlatformIO между перезапусками контейнера (volume, как в примере выше) — пересборка "с нуля" каждый раз лишняя.
• Заведите 1-2 ГБ swap как подстраховку от редких пиков, но не как основной ресурс: компиляция на swap резко замедляется, это спасение от падения, а не от медленной сборки.
• Мониторьте docker stats во время сборки хотя бы первые несколько раз после смены фреймворка или добавления тяжёлого компонента — так вы увидите свой реальный пик, а не чужой ориентир из статьи.

ESPHome вместе с Home Assistant

Чаще всего ESPHome живёт не сам по себе, а рядом с Home Assistant — тот забирает устройства через интеграцию ESPHome API и управляет автоматизациями. Если планируете держать оба сервиса на одном VPS, требования по RAM складываются: под Home Assistant отдельно стоит закладывать от 1,5-2 ГБ (подробный разбор — в статье сколько RAM нужно для Home Assistant), плюс память под сборки ESPHome сверху. На практике для связки "HA + ESPHome + периодические esp-idf-сборки" комфортный минимум — 4 ГБ, с запасом под всплески — 6-8 ГБ.

Если ещё не разворачивали Home Assistant на сервере, пошаговая установка есть в статье как установить и настроить Home Assistant на VPS, а готовый файл для связки в контейнерах — в статье Home Assistant в Docker Compose.

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