ZedIoTContact us
IoT Protocols and Interoperability

ESPHome vs OpenMQTTGateway for Home Assistant Bridge Devices

Use ESPHome when known sensors, actuators, and Modbus registers should become native Home Assistant entities. Use OpenMQTTGateway when BLE, RF, IR, and serial traffic ...

Published Jul 23, 2026Updated Jul 23, 2026
IoT Protocols and InteroperabilityIoT Tools and PlatformsESP32ESPHomeHome AssistantLocal Smart HomeMQTTOpenMQTTGatewayProtocol Bridge
ESPHome vs OpenMQTTGateway for Home Assistant Bridge Devices

ESPHome and OpenMQTTGateway are not competing on a single feature checklist. Choose ESPHome when a bridge node must turn a known set of sensors, relays, Modbus registers, or infrared actions into stable Home Assistant entities and keep some logic on the node. Choose OpenMQTTGateway when one node must receive heterogeneous BLE advertisements, 315/433 MHz RF, IR, or serial data and publish it through MQTT.

The decisive difference is the modeling direction. ESPHome starts with the entities and automations that belong to a specific node. OpenMQTTGateway starts with the protocols that must be captured and normalized into MQTT. The former behaves like configurable device firmware; the latter behaves like a multi-protocol collection gateway.

Primary goal Better default Cost you accept
Native Home Assistant entities, low-latency updates, node-local logic ESPHome Per-device YAML, component configuration, and firmware builds
BLE, RF, IR, and other protocols converging on MQTT OpenMQTTGateway Broker, topics, discovery, and decoder boundaries become operational concerns
RS485 or Modbus registers mapped directly to entities ESPHome Register addresses, types, scaling, and polling must be maintained accurately
Central discovery of many broadcast sensors OpenMQTTGateway Coverage depends on decoder libraries and the selected radio hardware
Fixed control nodes plus long-tail wireless sensors in one site Use both Names, ownership, upgrades, and failure domains must be explicit

This is an operating-model decision, not an absolute capability matrix. Both projects can touch MQTT, BLE, IR, and RF. Choosing the wrong primary model usually creates a growing layer of custom topics, template entities, lambdas, or private firmware patches.

ESP32 bridge node, RS485 adapter, and wireless gateway installed in a home utility cabinet

1. Decide whether the bridge is entity-first or protocol-first

Home Assistant classifies the ESPHome integration as local push. Home Assistant keeps a connection to each node through the ESPHome Native API, so the node can push state changes and receive commands directly. For a bridge device, this means sensors, switches, numbers, selects, and availability already have defined meanings before Home Assistant sees them. The upper layer does not first need to interpret a generic MQTT payload.

OpenMQTTGateway takes a different path. It converts BLE, RF, IR, LoRa, or serial signals into MQTT and can use Home Assistant MQTT Discovery to create devices and entities. This model works well when protocol inputs are numerous, device brands are inconsistent, and broadcast data needs to reach more than one consumer. The gateway's first responsibility is to receive and normalize messages; automation remains behind the broker.

flowchart TD

A("What is the bridge node's primary job?"):::slate --> B("Model known devices and entities"):::blue
A --> C("Aggregate wireless or serial protocols"):::orange
A --> D("Both responsibilities are required"):::violet

B --> E("Prefer ESPHome"):::cyan
C --> F("Prefer OpenMQTTGateway"):::green
D --> G("Split nodes or define a strict dual-stack boundary"):::violet

E --> H("Native API / local logic / Modbus entities"):::blue
F --> I("MQTT / BLE advertisements / RF / IR"):::orange
G --> J("Shared naming, observability, and failure isolation"):::slate

classDef blue fill:#EAF4FF,stroke:#3B82F6,color:#16324F,stroke-width:2px;
classDef cyan fill:#E9FBF8,stroke:#14B8A6,color:#134E4A,stroke-width:2px;
classDef orange fill:#FFF3E8,stroke:#F08A24,color:#7C3F00,stroke-width:2px;
classDef violet fill:#F4EDFF,stroke:#8B5CF6,color:#4C1D95,stroke-width:2px;
classDef green fill:#ECFDF3,stroke:#22C55E,color:#14532D,stroke-width:2px;
classDef slate fill:#F8FAFC,stroke:#64748B,color:#1F2937,stroke-width:2px;

If one board must perform critical control while continuously scanning many broadcast devices, splitting the responsibilities is usually safer than loading every component onto one ESP32. Radio scanning, decoding, and MQTT reconnection compete for CPU time, memory, and wireless airtime. Relay or Modbus control benefits from more predictable timing and failure behavior.

2. The practical boundary across BLE, IR, RF, serial, and Modbus

2.1 BLE: control known devices or collect many advertisements

ESPHome's Bluetooth Proxy lets Home Assistant extend Bluetooth coverage through an ESP32. It fits environments where Home Assistant already understands the target devices and the immediate problem is bringing Bluetooth connectivity closer to them. The node remains part of Home Assistant's device model, and diagnosis stays centered on the ESPHome node and integration.

OpenMQTTGateway is stronger when the job is scan, decode, and forward. Its documentation describes BLE decoding through Theengs Decoder and publishing the resulting data to MQTT. If a site has many temperature sensors, tire-pressure monitors, beacons, or other advertising devices, and Node-RED, OpenHAB, or a custom service also needs the data, an MQTT aggregation boundary is easier to reuse.

The BLE decision should therefore not be reduced to a device-count comparison. When Home Assistant is the only upper layer and tight device control matters, ESPHome Bluetooth Proxy is the more direct path. When multiple consumers need shared advertisement data, OpenMQTTGateway gives the cleaner boundary.

2.2 IR and RF: a fixed action node or a long-tail protocol entrance

ESPHome's remote receiver and transmitter components fit known remotes, known protocols, and fixed actions. A developer can put learned codes, transmit actions, local conditions, and Home Assistant entities in the same YAML configuration. For an air conditioner, fan, projector screen, or a small set of 433 MHz outlets, the action-to-entity mapping stays easy to inspect.

OpenMQTTGateway is a better fit when IR and 315/433/868/915 MHz RF should be centralized. It uses upstream libraries such as RCSwitch, Pilight, and IRRemoteESP8266, then exposes received or transmitted data through MQTT. When a site contains many legacy devices from different vendors, or engineers need to observe unknown RF traffic before adding decoders, the protocol-gateway model avoids rebuilding a dedicated entity node for every discovery step.

The boundary still matters. A gateway cannot make an unverified RF decoder reliable. Conversely, deploying a complete MQTT gateway for two fixed IR actions can add more infrastructure than the problem requires.

2.3 Serial and Modbus: forwarding bytes is not the same as modeling a device

ESPHome's modbus_controller can expose coils, discrete inputs, holding registers, and input registers as sensors, switches, numbers, selects, and other entities. For meters, heat pumps, inverters, HVAC controllers, and RS485 sensors, this creates a short path from a register map to Home Assistant.

OpenMQTTGateway's serial gateway can send and receive serial data through MQTT, and it can split JSON received over serial into MQTT topics. That solves message transport. It does not automatically model Modbus addresses, byte order, scaling, data types, or polling policy. If Node-RED or a custom service must still parse those semantics, the design has moved the protocol model from the bridge node to the server.

For Modbus, the decision is clear: use ESPHome for a small, known set of devices that should become Home Assistant entities. Use OpenMQTTGateway only when a custom serial stream must first enter a general data bus and the team already owns the server-side parser.

3. Dependency and operations models create the real difference

Operational dimension ESPHome OpenMQTTGateway
Primary upper-layer connection Home Assistant Native API, with MQTT also available MQTT broker as the central boundary
Configuration unit YAML, components, and firmware per node Gateway build, WebUI/runtime configuration, topics, and decoders
State model Predefined Home Assistant entities Protocol messages enter MQTT, then discovery or consumers interpret them
Failure domain Individual node and its Home Assistant connection Gateway, network, broker, discovery, and consumer chain
Extension path Add components, lambdas, or external components Add protocol modules, decoders, or MQTT consumer logic
Data reuse across systems Possible through MQTT, but not the shortest default Natural for multiple MQTT consumers

ESPHome's main cost is configuration sprawl. As node count grows, the team must govern packages, secrets, board differences, entity naming, and OTA rollout. OpenMQTTGateway's main cost is message governance. Topic structure, retained messages, availability, broker permissions, discovery payloads, and decoder versions become production assets.

If Home Assistant is the only consumer, adding a broker can create a shared failure domain that brings little value. If a site already treats MQTT as its event backbone, forcing every protocol through a Home Assistant-specific connection reduces reuse. The bridge should fit the existing control plane rather than introduce a parallel one.

4. Three deployment patterns that hold up over time

4.1 One ESPHome bridge for known, stable, modelable devices

A common design is ESP32 plus an RS485 transceiver, or ESP32 plus an IR receiver and transmitter. Every register, switch, or action has a name in the configuration, and Home Assistant receives entities directly. This works when the device inventory is stable, automations depend on explicit states, and faults must be traced to a specific entity quickly.

It stops fitting when protocol inputs keep growing and most devices only broadcast data. Adding a custom configuration for every long-tail device turns an entity-oriented node into a general gateway without giving it a clean gateway architecture.

4.2 One OpenMQTTGateway node for heterogeneous protocol collection

A typical design uses ESP32 with BLE and a CC1101/RF module, or BLE plus IR. The gateway publishes signals to a broker. Home Assistant receives devices through MQTT Discovery while other systems subscribe to the same data. It fits sites with many passive sensors, diverse protocols, and more than one data consumer.

It is a weaker fit when the node owns safety-related or strongly deterministic local control. As the path adds topics, a broker, and consumers, the design also needs permissions, offline behavior, command confirmation, and auditability. Successful discovery is not proof of control reliability.

4.3 A hybrid site with one primary responsibility per node

The most maintainable hybrid is usually not one board running every responsibility. Separate critical control from long-tail collection. Let ESPHome nodes own relays, Modbus, and fixed IR actions. Let OpenMQTTGateway nodes own BLE advertisements and diverse RF reception. Home Assistant can unify automation above them while each node keeps an independent upgrade and rollback path.

The tradeoff is a higher device count. In return, the failure boundary becomes clearer: a radio-scanning problem should not delay refrigeration control, and broker maintenance should not remove basic behavior from a local control node.

5. When neither project is the right primary answer

  • Certified reliability or safety interlocks: an ESP32 bridge should not replace a safety PLC, hardwired protection, or a validated controller.
  • Thread or Zigbee coordination: use a mature Thread Border Router, ZHA, or Zigbee2MQTT path rather than treating a BLE/RF gateway as a universal coordinator.
  • Large fleet lifecycle management: hundreds or thousands of nodes require platform-level inventory, certificates, telemetry, staged OTA, and rollback rather than only home-automation node management.
  • Complex transactions or strict timing: multi-step handshakes, bus arbitration, or vendor state machines may require dedicated firmware or a Linux gateway.
  • Dependencies the team cannot operate: do not add a broker merely because a gateway supports many protocols, and do not put everything in ESPHome YAML if no one will maintain per-node configurations.

6. A pre-build checklist for bridge nodes

  1. List all upper-layer consumers: Home Assistant only, or also Node-RED, a custom platform, and a data store.
  2. Separate control protocols from collection protocols. Control needs confirmation and offline policy; collection prioritizes coverage and decoding.
  3. Decide where the device model lives: firmware entities, MQTT discovery, or server-side parsing.
  4. Define offline behavior independently for the node, Home Assistant, and the broker. Reconnection alone is not a complete resilience policy.
  5. Run one node for an extended period under realistic scanning, memory, Wi-Fi, and reconnection load before cloning the deployment.
  6. Standardize names, topics, entity IDs, firmware versions, and rollback procedures to prevent duplicate entities and stale retained messages.

If the first four items are unclear, choosing firmware is premature. Bridge projects usually fail because nobody decided who owns modeling, commands, and offline behavior—not because one firmware lacks one more protocol.

Conclusion

ESPHome is better for turning known hardware into devices Home Assistant can understand and control directly. OpenMQTTGateway is better for converting heterogeneous wireless or serial signals into MQTT streams that multiple systems can consume. ESPHome offers a clear entity model, tight Native API integration, and an obvious place for local logic. OpenMQTTGateway offers broad protocol entrances, strong support for broadcast sensors, and a reusable message-bus boundary.

The shortest decision rule is: start from the Home Assistant entities you need and choose ESPHome; start from the protocols you need to collect into MQTT and choose OpenMQTTGateway. When both goals exist, separating critical control from long-tail collection is usually easier to operate than building one universal ESP32 gateway.

Related reading:

References

Need to turn this technical path into a working product?

ZedIoT can help evaluate device access, firmware, gateway, platform, AI workflow, deployment, and support boundaries for your project.