ESPHome Native API vs MQTT: Which Should You Use with Home Assistant?

For most ESPHome devices used only with Home Assistant, the Native API is the better default. It gives Home Assistant a direct persistent connection to each ESPHome node, supports encrypted communication, automatic discovery and ESPHome-specific features without requiring an MQTT broker.

MQTT is still extremely useful, but it solves a different architectural problem. It makes sense when an ESPHome device must publish data to several independent consumers, integrate with non-Home-Assistant systems, fit into an existing MQTT infrastructure or expose deliberately designed topics that remain useful outside the ESPHome ecosystem.

The right question is therefore not “Which protocol is better?” but:

Is Home Assistant the main consumer?
→ Native API

Do several independent systems need the same device data?
→ MQTT may be better

Do you specifically need Bluetooth Proxy / Voice Assistant?
→ Native API

Do you already run a broker and design around MQTT topics?
→ MQTT may be better

Native API vs MQTT at a Glance

Feature	ESPHome Native API	MQTT
Home Assistant connection	Direct device → HA	Device → broker → HA
Extra server required	No	Yes, MQTT broker
Default API port	6053	Broker normally 1883 without TLS
Encryption	Native Noise PSK support	Depends on broker/TLS configuration
Automatic HA discovery	Yes	Yes, MQTT discovery
Persistent connection	HA connects directly to each ESPHome node	Both HA and device connect to broker
Retained states	Not MQTT-style retained topics	Yes
Last Will / availability	Direct API connection state	MQTT Birth/LWT support
Bluetooth Proxy	Yes	Requires API for full ESPHome functionality
Voice Assistant	Yes	Requires API for full ESPHome functionality
Home Assistant state subscriptions/actions	Native integration	Possible through topics but less ESPHome-native
Multiple independent consumers	Possible API clients, but HA-centric	Excellent publish/subscribe model
Non-HA integrations	Needs API-aware client	Excellent ecosystem compatibility
ESP-IDF MQTT status in current ESPHome docs	Native path	Still marked experimental
Best default for HA-only device	Native API	Use when architecture needs it

How the Native API Works

With the Native API, Home Assistant connects directly to the ESPHome device over the local IP network.

ESPHome device
      │
      │ TCP / Native API
      │
Home Assistant

Home Assistant maintains a persistent connection. ESPHome pushes sensor updates, binary-state changes and other events as they occur rather than Home Assistant repeatedly polling the node.

The default API port is 6053.

A minimal encrypted configuration is:

api:
  encryption:
    key: !secret api_encryption_key

Current Home Assistant documentation recommends the Noise pre-shared-key encryption method rather than the older API password, which is deprecated.

How MQTT Works

MQTT introduces a broker between the ESPHome device and the consumers.

ESPHome device
      │
      │ publish / subscribe
      ▼
  MQTT broker
   │       │
   │       ├──── Home Assistant
   │       ├──── Node-RED
   │       ├──── database/logger
   │       └──── another application

The ESPHome node publishes states to MQTT topics and subscribes to command topics. Home Assistant connects separately to the broker and discovers or manually defines those MQTT entities.

A minimal ESPHome MQTT configuration is:

mqtt:
  broker: 192.168.1.10
  username: !secret mqtt_user
  password: !secret mqtt_password

ESPHome enables Home Assistant MQTT discovery by default, so normal ESPHome entities can appear automatically without manually creating a state topic for every sensor.

Native API Is Usually Simpler for Home Assistant

For a Home Assistant-only installation, the Native API removes an entire infrastructure layer.

Native API:
ESP32 → Home Assistant

MQTT:
ESP32 → broker → Home Assistant

That means fewer credentials, fewer services to maintain and fewer places where a configuration error can make the node appear unavailable.

It also means ESPHome and Home Assistant understand each other at a richer level than a generic topic/payload protocol.

Native API Supports More ESPHome-Specific Features

ESPHome’s own MQTT documentation says that if you are connecting to Home Assistant you may prefer the Native API and explicitly notes that the API provides more features than MQTT entity discovery alone.

Examples include:

Bluetooth Proxy integration.
Voice Assistant functionality.
Direct Home Assistant state subscriptions.
ESPHome devices calling Home Assistant actions when permitted.
Tag-scanning integration.
Direct live-log subscription through the integration.

If the project is an ESP32 Bluetooth Proxy, the decision is effectively already made: use the Native API.

See our ESP32 Bluetooth Proxy for Home Assistant guide.

MQTT’s Biggest Strength Is Decoupling

MQTT becomes more attractive when Home Assistant is not the centre of the architecture.

Suppose one outdoor ESP32 publishes:

garden/weather/temperature
garden/weather/humidity
garden/weather/pressure
garden/weather/rain_total

Those topics can be consumed independently by:

Home Assistant.
Node-RED.
InfluxDB or another logger.
A Python application.
A second automation server.
Another microcontroller.

The ESP32 does not need to know which systems consume the data. It just publishes to the broker.

That is the architectural value of MQTT—not that it somehow makes a simple Home Assistant temperature sensor better.

MQTT Retained Messages Are Useful

MQTT can retain the most recent payload on a topic. A consumer that connects later can immediately receive the last retained state rather than waiting for the sensor to publish again.

This is useful for slowly changing values such as:

Temperature.
Tank level.
Energy totals.
Device configuration/discovery.

ESPHome MQTT entities normally use retained messages by default for state publishing, and MQTT discovery messages can also be retained.

The downside is persistence: stale retained discovery messages can create old “ghost” entities that reappear after Home Assistant restarts.

ESPHome provides:

esphome clean-mqtt configuration.yaml

to purge stale discovery messages for a node.

Availability: API Connection vs MQTT Last Will

The Native API knows whether Home Assistant is currently connected to the device.

MQTT normally uses Birth and Last Will and Testament messages:

device connects
→ publishes online

device disappears unexpectedly
→ broker publishes its configured Last Will
→ Home Assistant marks entities unavailable

This is a very robust feature of MQTT because the broker can announce that a client vanished even when the device itself was unable to publish an “offline” message.

What Happens if Home Assistant Is Down?

This is frequently misunderstood.

ESPHome local automations do not require Home Assistant or MQTT. If the firmware contains:

binary_sensor:
  on_press:
    - switch.toggle: relay_1

that local action can continue even if Home Assistant, the API connection or the MQTT broker is unavailable.

The dependency appears when the automation itself needs an external service or state.

Action	HA/API/broker required?
ESPHome GPIO button toggles local relay	No
Local thermostat logic	No
Home Assistant dashboard command via Native API	Yes, HA/API
Home Assistant dashboard command via MQTT	Yes, HA + broker + MQTT
ESP publishes MQTT state for other consumers	Broker required
ESPHome reads a Home Assistant entity through native API	HA/API required

The 15-Minute Reboot Trap When Switching to MQTT

This is one of the most important practical differences.

The Native API has a default reboot_timeout of 15 minutes. If no API client connects during that period, ESPHome can reboot the node as a recovery mechanism.

If you switch a device to MQTT but accidentally leave:

api:

enabled with no Home Assistant/API client using it, the device can reboot every 15 minutes even though MQTT is working perfectly.

ESPHome’s MQTT documentation explicitly warns about this.

Either remove api: completely:

mqtt:
  broker: 192.168.1.10

# no api: block

or deliberately disable its reboot behaviour:

api:
  reboot_timeout: 0s

This same issue appears in our ESPHome Wi-Fi Disconnects and Reconnect Loops guide.

MQTT on ESP-IDF Is Still Marked Experimental

This is particularly relevant in 2026 because ESPHome has moved modern ESP32 variants toward ESP-IDF as the normal framework.

Current ESPHome MQTT documentation still states that MQTT support with ESP-IDF is experimental.

That does not mean it never works. It means a new Home Assistant-only design should not add MQTT without a reason when the Native API is the better-supported direct integration path.

It is especially relevant for newer devices such as ESP32-C6 where ESPHome requires ESP-IDF.

Native API Latency

Home Assistant describes the Native API as a lightweight bidirectional protocol optimised for microcontrollers, using persistent connections and push updates for near-real-time state changes and command execution.

For a button, motion sensor or relay, there is no broker hop:

ESP32 ↔ Home Assistant

MQTT is also fast enough for normal home automation, but the message path includes the broker:

ESP32 → broker → Home Assistant
Home Assistant → broker → ESP32

In a healthy local network, both can feel instantaneous. Do not choose between them because somebody claims a meaningless universal “5 ms vs 20 ms” benchmark—the architecture and features matter much more.

Security

Native API

ESPHome directly supports encrypted Native API communication using a 32-byte base64-encoded pre-shared key.

api:
  encryption:
    key: !secret api_encryption_key

This is easy to deploy and should be used on normal Home Assistant installations.

MQTT

MQTT security depends on the broker architecture: authentication, permissions, network segmentation and TLS where appropriate.

A broker with one shared username/password for every IoT device is easy to configure but gives much broader access than a well-designed broker using per-device ACLs.

MQTT can therefore be extremely secure, but the security design belongs to the broker infrastructure rather than being automatically solved by the protocol.

Discovery

Both methods offer automatic Home Assistant discovery, but they work differently.

Native API discovery

Home Assistant can discover ESPHome nodes and add them through the ESPHome integration. It then connects to the device directly.

MQTT discovery

ESPHome publishes configuration payloads under Home Assistant’s MQTT discovery namespace, normally:

homeassistant/...

Home Assistant uses those messages to create the entities.

MQTT discovery is flexible and standards-based, but retained discovery data also means configuration cleanup matters when entities are renamed or removed.

Can You Run Native API and MQTT Together?

Yes. ESPHome supports running both.

A useful hybrid configuration is:

api:
  encryption:
    key: !secret api_encryption_key

mqtt:
  broker: 192.168.1.10
  username: !secret mqtt_user
  password: !secret mqtt_password

  discovery: false
  discover_ip: true

In this arrangement, Home Assistant uses the Native API for the ESPHome integration while MQTT remains available for custom topic publishing or other consumers. Disabling MQTT entity discovery avoids creating duplicate Home Assistant entities.

ESPHome’s current MQTT documentation even supports MQTT-based device discovery that tells Home Assistant where the ESPHome Native API device is located.

But Do Not Run Both Without a Reason

Running both protocols adds:

More compiled firmware.
More network connections.
More credentials.
More failure modes.
Potential duplicate discovery/entities.
More confusing troubleshooting.

If the only reason is “MQTT sounds more professional”, it is adding complexity rather than capability.

When MQTT Is Clearly the Better Choice

You already operate a mature MQTT architecture.
Multiple automation systems consume the same device data.
You want stable custom topic names independent of Home Assistant.
Another embedded device subscribes directly to the ESPHome data.
You use Node-RED or custom services as equal peers rather than extensions of HA.
Retained messages are useful to the architecture.
You deliberately want broker-based decoupling.

When Native API Is Clearly the Better Choice

Home Assistant is the primary/only controller.
You want the simplest installation.
You use Bluetooth Proxy.
You use ESPHome Voice Assistant features.
You need direct Home Assistant state subscriptions.
You want per-device encrypted communication without running a broker.
You are using a modern ESP-IDF ESPHome build and have no specific need for MQTT.

Example: Simple Room Sensor

A temperature/humidity sensor used only by Home Assistant should normally use:

api:
  encryption:
    key: !secret api_encryption_key

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

Adding Mosquitto, MQTT credentials and discovery topics does not make the sensor better.

Example: Workshop Telemetry Bus

Suppose a workshop ESP32 publishes power, temperature and machine-state data that must be consumed by Home Assistant, Node-RED and a custom Python logger.

MQTT becomes much more natural:

workshop/compressor/pressure
workshop/compressor/running
workshop/panel/temperature
workshop/power/kw

No consumer owns the ESP32. They all subscribe to the broker.

Example: Smart Irrigation Controller

For our ESP32 Smart Irrigation Controller, I would use Native API if Home Assistant is the only supervisory system.

Valve sequencing, pump delays and rain shutdown remain local in ESPHome. Home Assistant sends high-level commands through the API.

If a separate farm-management system and data logger also need all irrigation states, MQTT becomes more attractive.

Migration: MQTT to Native API

For a normal ESPHome configuration, migration can be straightforward:

Add an encrypted api: block.
Upload firmware.
Add/discover the device in Home Assistant through the ESPHome integration.
Move automations/dashboards to the Native API entities if necessary.
Remove MQTT from the node.
Clean stale retained MQTT discovery messages if old entities keep returning.

Entity IDs may not be identical between the MQTT and Native API versions, so verify automations before deleting the old entities.

Migration: Native API to MQTT

Install/configure a reliable MQTT broker.
Add the MQTT integration to Home Assistant.
Add the ESPHome mqtt: block.
Decide whether MQTT discovery should remain enabled.
If removing Native API, remove api: completely or set its reboot timeout to zero during transition.
Verify availability and retained-state behaviour.
Update Home Assistant automations if entity IDs change.

Common Problems

Symptom	Likely cause / first check
MQTT node reboots every 15 minutes	Unused Native API still enabled with default reboot timeout
Duplicate entities in HA	Native API + MQTT discovery both exposing same components
Old MQTT entity keeps returning	Retained discovery payload; run clean-mqtt
MQTT entities all unavailable	Broker/device connection or LWT availability state
API device pingable but unavailable	Port 6053/firewall/API issue
Bluetooth Proxy does not work through MQTT	Use Native API
MQTT ESP-IDF issue	Current ESPHome docs still mark this support experimental
Node works locally while HA is down	Expected if automation is entirely inside ESPHome
Custom app needs sensor states	MQTT may simplify multi-consumer access
Home Assistant-only project feels overcomplicated	Remove MQTT and use Native API

Which Should You Use in 2026?

Use ESPHome Native API by default when Home Assistant is the centre of the system.

It is the direct ESPHome/Home Assistant integration path, supports encrypted local communication, persistent push updates and ESPHome-specific features such as Bluetooth Proxy and Voice Assistant without requiring another server.

Use MQTT when the broker architecture itself solves a real requirement. It is excellent for decoupling devices from consumers, feeding several systems and building a broader IoT message bus.

The practical decision is:

Home Assistant-only ESPHome device
→ Native API

Multi-system / broker-centric architecture
→ MQTT

Need both for a specific reason
→ Run both, but disable duplicate MQTT discovery

Do not add MQTT simply because it used to be the standard way to connect DIY Wi-Fi sensors to Home Assistant. ESPHome’s Native API exists specifically to make that direct integration simpler and richer.

Related ESPHome and Home Assistant Guides

ESPHome Wi-Fi Disconnects: Fix Reconnect Loops and Offline ESP32 Nodes — API reboot timeouts, RSSI and network troubleshooting.
ESP32 Bluetooth Proxy for Home Assistant — a major use case for the Native API.
ESP32 Smart Irrigation Controller — practical separation of local ESPHome logic and HA supervisory logic.
ESPHome pulse_meter vs pulse_counter — utility-meter integration with Home Assistant.

Official Resources

ESPHome Native API — encryption, port, reboot timeout and Home Assistant communication.
ESPHome MQTT Client — broker setup, discovery, retained messages and MQTT availability.
Home Assistant ESPHome Integration — direct API architecture and supported functionality.
Home Assistant MQTT Integration — broker setup, discovery, Birth/LWT and availability.