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.