Transport choice: why ha-paneld is on MQTT — and what we found evaluating ESPHome and Matter

[maxlyth]

ha-paneld pairs a panel to Home Assistant over MQTT auto-discovery. Before committing to that for v1.0, I evaluated the two obvious alternatives — the ESPHome native API and Matter — and went as far as building and testing a complete, working ESPHome transport. This is a write-up of what I found.

I'll be upfront: I consider this mostly settled — MQTT stays. But I'd genuinely like to hear counter-arguments, especially a strong case against MQTT or a concrete ESPHome/Matter advantage I've under-weighted.

MQTT (current)

• Vendor-neutral, an OASIS standard with a stable, documented contract; HA's discovery + LWT availability model is mature and battle-tested.
• Costs a broker dependency — but HA ships Mosquitto as a one-click add-on, so for the target user it's already there.
• The main objection I hear is perception ("MQTT feels old-fashioned"), which isn't a technical argument. If there's a substantive one, I want it.

ESPHome native API — built, tested, not adopted

I built a full transport-agnostic implementation and round-tripped 20 entities across every type ha-paneld exposes, verified against real HA. It's published so this isn't hand-waving:

• Proof-of-concept release: https://github.com/maxlyth/ha-paneld/releases/tag/v0.8.0-esphome-poc
• Branch: https://github.com/maxlyth/ha-paneld/tree/spike/esphome-api

What the exercise taught me:

1. No third-party stability contract. The native API is co-developed by ESPHome and HA in lockstep; aioesphomeapi's .proto is the de-facto source, not a spec a third party can pin to. Co-opting it for a device that isn't running ESPHome firmware means riding a moving target maintained for a different purpose.
2. No concrete win. The PoC showed no measurable latency or panel-resource improvement over MQTT. The one real upside is no broker (direct TCP to HA) — which didn't outweigh the maintenance risk of (1).

So: a proven, working alternative — kept published precisely so that if a compelling reason emerges, switching is a known quantity rather than a leap.

Matter — parked, not rejected

Architecturally the "right" device-independent protocol, but for this use case:

• IPv6-dependent, which is fragile on a lot of real home LANs.
• Strongly associated with Apple/Google/Alexa even though it doesn't require them — a turn-off for many HA users.
• HA's own Matter stack is mid-migration (python-matter-server → a JS implementation) and unsettled.
• A Matter panel would surface as a separate device from the discovery device that holds the controls/sensors, fragmenting the integration.

A Matter PoC may be a future side experiment, but it's not on the v1.0 path.

Where this lands

MQTT is the primary transport through v1.0. ESPHome is a tested fallback kept on the shelf. Matter is parked.

What I'm asking for: push back. The most useful replies are a strong argument against MQTT, real ESPHome/Matter latency or resource numbers that contradict the PoC, a stability guarantee on the ESPHome API I've misread, or a deployment pattern where the broker dependency genuinely hurts.

[maxlyth]

Panel Assistant 1.0 no longer uses MQTT. Panels now talk to Home Assistant over one native connection for the dashboard, updates, voice and settings, so this discussion is out of date. Closing it; please start a new discussion for anything about the 1.0 connection.