ESPHome

Original Article ↗ Hacker News Discussion ↗

Overall sentiment & use cases

  • Very strong enthusiasm: many run tens of ESPHome devices for temperature, humidity, soil moisture, air quality, sump/septic monitoring, sump pits, rain tanks, weather stations, smart desks, time clocks, and HVAC control.
  • Common pattern: “rescues” projects where people lost motivation to write their own firmware; YAML + OTA + logging make the last 20% easy.
  • ESPHome is used both with Home Assistant and standalone (e.g., MQTT-only, custom PHP dashboards, Hubitat).

Architecture, configuration & capabilities

  • Devices are defined in YAML which is compiled into firmware; any config change triggers a recompile and OTA flash. Most say this is fast and painless; at least one commenter finds it slow and would prefer a single universal firmware reading JSON at runtime.
  • Supports on-device automation via triggers/actions and C/C++ snippets; good for more complex control loops, IR remotes, climate control, and custom logic.
  • Many components exist (sensors, relays, climate controllers, PID/bang-bang thermostats, Modbus, RS‑485 via UART, deep sleep, PoE/Ethernet, capacitive touch, Bluetooth proxy, voice assistant, media player).

Integration & ecosystem

  • Deep integration with Home Assistant is praised, including automatic discovery and “update all” firmware management via the ESPHome web UI.
  • Also used with Zigbee2MQTT, Node-RED, custom backends, and other hubs.
  • ESPHome is now owned by the Open Home Foundation; goal stated as privacy, choice, sustainability.

Hardware, power & networking

  • ESP32 is the default; ESP8266 still used but described as aging and less recommended for new designs.
  • Cheap dev boards from AliExpress/Amazon are common; some prefer slightly pricier, better-designed boards (narrow width, PSRAM, PoE-capable modules, M5Stack) or official vendors.
  • Power options include USB phone chargers, PoE boards, lithium cells with TP4056 modules, boards with built-in charging, and deep-sleep for long battery life. Low-power outdoor/battery design is considered non-trivial.
  • Main transport is Wi-Fi; Ethernet is supported via extra PHY chips or PoE boards. Mesh and Zigbee/Thread/Matter are repeatedly requested; current mesh options via raw Wi-Fi/BLE are mentioned but not integrated at ESPHome level. Range for garden/outdoor sensors is a recurring pain point.

Limitations, pain points & criticism

  • Some find docs and component discovery confusing, especially for advanced peripherals and Home Assistant-side setup.
  • Firmware size/partition limits and provisioning overhead on some chips (e.g., ESP32-C3 with BLE provisioning) are concerns.
  • A few users explicitly dislike the “large opaque binary + YAML” model and wish for a lighter framework or better runtime configurability.
  • Requests include: better power management, more PoE devices, Zigbee/battery focus, easier reuse across many similar custom devices, Ethernet provisioning, and clearer support status for non-Espressif MCUs.