In this guide
You built an ESP32 sensor node and a small web page to view its readings. Then you added a relay, and now the web page needs buttons. Then a second node, and the page needs a device list. Congratulations — you are rebuilding, badly, what Home Assistant already does.
Home Assistant is the open-source smart-home platform that turns "my ESP32 publishes MQTT" into a polished system: auto-discovered devices, history graphs, automations ("turn on the fan when the room crosses 30°C"), and a phone app — with almost no code. For students, it is the fastest route from a working sensor to a demo that looks like a finished product. This guide covers the architecture, the two ways to connect an ESP32 (ESPHome and MQTT), automations, and what to watch out for.
What Home Assistant is
Home Assistant (HA) is a home-automation platform that runs on your own hardware — typically a Raspberry Pi, an old laptop, or a small server. It speaks to devices through integrations: MQTT, ESPHome, Zigbee, Z-Wave, and hundreds of commercial products. Everything appears as entities (a temperature sensor entity, a switch entity) with state and history, and you build automations and dashboards on top.
The student value proposition is leverage: instead of building device management, history storage, a mobile UI, and an automation engine, you get all four by connecting your ESP32 to HA. Your project work goes into the sensing and actuation — the differentiated part — instead of CRUD screens.
Note: Home Assistant is a platform for integrating devices, not a cloud IoT backend for thousands of nodes. For a final-year project with a handful of devices and a demo dashboard, it is ideal. For a 500-node deployment, look at purpose-built IoT platforms instead.
How devices appear: entities and discovery
Every device shows up as one or more entities, each with a state:
| Entity type | Example | State |
|---|---|---|
| sensor | Living room temperature | 27.4 °C |
| binary_sensor | Door contact | on/off |
| switch | Relay | on/off |
| light | LED strip | on/off + brightness |
| number | Thermostat setpoint | 24 |
HA keeps history for every entity automatically — graphs, "when did the door last open," and long-term statistics come free. Discovery means devices can announce themselves so you never hand-configure each one: ESPHome devices appear automatically; MQTT devices announce via discovery messages.
Path 1: ESPHome (the easy road)
ESPHome is a system that generates ESP32/ESP8266 firmware from a YAML configuration file — no C++ required for standard sensors. You describe the hardware, ESPHome builds and flashes firmware that natively talks to Home Assistant with encryption and over-the-air updates built in.
A minimal ESPHome configuration for a temperature node:
esphome:
name: livingroom-sensor
esp32:
board: esp32dev
wifi:
ssid: "your-wifi-ssid"
password: "your-wifi-password"
sensor:
- platform: dht
model: DHT22
pin: GPIO15
temperature:
name: "Living Room Temperature"
humidity:
name: "Living Room Humidity"
update_interval: 60s
Flash this, and the device appears in Home Assistant automatically — temperature and humidity entities, history, done. Adding a relay is a few more lines under switch:. ESPHome supports an enormous sensor list, deep sleep, and OTA updates, all from YAML.
ESPHome is the right choice when your device is a standard sensor/actuator combination and you want reliability over customizability.
Path 2: MQTT (the flexible road)
If your firmware is custom (complex logic, unusual sensors, existing codebase), connect over MQTT using HA's MQTT integration. Your ESP32 publishes state topics and subscribes to command topics, and either you configure the entities manually in YAML or your device sends MQTT discovery messages so entities auto-appear.
The topic conventions:
- State:
home/livingroom/temperature→ sensor entity shows the value. - Command:
home/livingroom/relay/set← HA publishesON/OFFwhen the user toggles the switch. - Availability:
home/livingroom/status→online/offline(your firmware's last-will message) so HA greys out dead devices instead of showing stale data.
MQTT is the right choice when ESPHome cannot express what your firmware does, or when the device must also talk to non-HA systems. The cost is manual entity configuration and more firmware code.
| ESPHome | MQTT | |
|---|---|---|
| Firmware code | YAML config | Full C++ |
| HA setup | Automatic discovery | Manual or discovery messages |
| OTA updates | Built in | You build it |
| Flexibility | Standard components | Unlimited |
| Learning value | Platform skills | Protocol + firmware skills |
Many strong projects use both: ESPHome for simple sensor nodes, MQTT for the one device with custom logic.
Automations: where projects come alive
Automations are trigger → condition → action rules, built in a visual editor or YAML:
- Trigger: temperature sensor crosses 30 °C.
- Condition: time is between 9 AM and 9 PM (optional).
- Action: turn on the fan switch, send a phone notification.
For a student demo, three automations transform a sensor display into a "system": an alert when a threshold is crossed, a scheduled action (lights on at sunset), and a safety rule (turn the heater off if the temperature sensor goes offline — the availability topic makes this possible). Automations are also where you demonstrate thinking: anyone can display a temperature; deciding what the system does about it is engineering.
Dashboards that demo well
HA's Lovelace dashboards are drag-and-drop: entity cards, gauges, history graphs, maps, and button grids. Tips for a demo that lands:
- One dashboard per story: an "overview" for the evaluator with the three most important entities, not all forty.
- History graphs beat live numbers for showing behavior ("here is the room heating up and the fan responding").
- Put automations' effects on the same screen as their triggers so cause and effect are visible together.
Practical considerations
Hardware: a Raspberry Pi 4 runs HA comfortably for a student deployment. Keep the Pi on wired Ethernet if possible — WiFi-only HA hosts add a flaky hop to every automation.
Remote access: HA is designed for local control. For demo-day access from outside, the official cloud remote UI is the safe path; exposing your Pi directly to the internet without understanding the security implications is how student servers get compromised.
Backups: HA has one-click full backups. Take one before demo day and keep a copy off the Pi. SD card failures are the classic HA outage.
Not a cloud backend: if your project brief requires data accessible from anywhere with user accounts, HA plus remote UI covers demos, but a multi-user product needs a different architecture.
ESPHome power features worth knowing
Beyond the basic sensor YAML, ESPHome has features that solve real project problems:
Deep sleep is a first-class citizen: a few lines configure timed wake with sensor readings taken before sleeping, and the device reappears in Home Assistant on each wake. Battery nodes that report hourly become a YAML configuration, not a firmware project. Pair with the availability pattern so dashboards show the node as sleeping rather than broken.
Substitutions and packages keep multi-device projects sane. Define WiFi credentials and common sensor blocks once as substitutions, and split shared configuration into packages imported by each device's YAML. Five sensor nodes become five small files instead of five copies of everything.
Sensor filters handle noisy hardware in configuration: median filters, moving averages, delta filters (only report when the value changed), and heartbeat filters compose in YAML. A jittery ADC reading becomes a clean entity without custom code.
Native API encryption secures the ESPHome-to-Home-Assistant channel with a pre-shared key from YAML — enable it rather than running unencrypted on shared networks.
The honest limit: when your device needs behavior ESPHome cannot express (custom protocols, unusual timing, complex state machines), switch that device to the MQTT path with custom firmware rather than fighting the YAML. A hybrid deployment — ESPHome for standard nodes, custom MQTT for the special one — is a sign of good judgment, not inconsistency.
Common mistakes checklist
- Rebuilding HA's features by hand. If you are writing a history database and a mobile UI, stop and use the platform.
- No availability topic. Dead devices showing stale "normal" values undermine every automation.
- Automations without conditions. A fan that turns on at 3 AM because a sensor glitched is a demo fail — add sanity conditions.
- One giant dashboard. Curate per-audience views; the evaluator sees the story, not the raw entity list.
- WiFi-only HA host. Wire the server; keep wireless for the edge devices.
- No backup before demo day. SD cards fail at the worst moment.
Where to go from here
- ESP32 OTA firmware updates setup — keep deployed ESPHome/MQTT nodes updated without physical access.
- MQTT protocol explained with practical examples — the protocol underneath the MQTT path, including last-will for availability.
- Control Arduino/ESP32 from an Android app over Bluetooth/WiFi — build a custom phone frontend for your devices alongside the Home Assistant dashboard.
- More connected-home builds in the IoT & Embedded branch hub.