Saltar a contenido

Comparación: ZHA vs Zigbee2MQTT en 2026

Stack Zigbee para HA: las dos opciones soportadas. Para el setup del usuario: quedarse con Z2M (probable opción actual) salvo que se documente un patrón de Z2M-rompe-tras-HA-upgrade ≥ 2x/año. La migración cuesta horas de re-pair y el upside de ZHA (un componente menos) no justifica sin evidencia concreta.

Contexto

Decisión secundaria al lado de Matter vs Zigbee. La pregunta es: dado que mantengo Zigbee, ¿con qué software lo opero? Ambos usan el mismo hardware coordinator, así que la decisión es puramente software.

Contenido

Matriz comparativa

Dimensión ../entities/zha ../entities/zigbee2mqtt
Devices soportados (2026) ~2,000 3,400+
Setup steps 3 8 (incluye Mosquitto)
Componentes a mantener 1 (built-in HA) 3 (HA + Z2M add-on + Mosquitto)
Failure modes HA core down → ZHA down HA, Z2M, Mosquitto independent failures
Update cycle Acoplado a HA core (predecible) Independiente (más rotura potencial)
OTA firmware coverage Limitada Amplia (IKEA, Tuya, Sonoff, Aqara)
Network diagnostics Mapa básico Mapa detallado + LQI + packet logs
Custom device support Quirks (técnicamente exigente) Converters (más accesible)
Soporte de Tuya / Sonoff / OEM Chino Gap Cobertura amplia
Hardware coordinator Mismo (SONOFF, ZBT-1, SkyConnect) Mismo

Verdict del source canónico

Si... Elegí...
Beginner, <20 devices, brands mainstream ZHA
HA Yellow/Green con SkyConnect default ZHA
50+ devices, ecosistema mixto (Tuya/Sonoff/IKEA/Aqara) Z2M
Querés network diagnostics detallados / OTA agresivo Z2M
Queréscapacidad de añadir custom devices vos mismo Z2M

Decisión para el setup del usuario

Estado asumido: el usuario corre Z2M sobre HA Yellow (default para setups con devices mixtos y ESPHome custom).

Recomendación:

  1. Quedarse en Z2M. Razones:
  2. Migración cuesta re-pair de cada device (~horas, según count).
  3. Z2M es el camino donde HA + ESPHome custom + ecosistema mixto co-existe mejor.

  4. El upside de ZHA es "un componente menos", no es "más reliable" — el data del source apoya ZHA en setup time, no en reliability runtime.

  5. Trigger para reconsiderar: si en el próximo trimestre el agente AI (Q10) detecta ≥ 2 incidentes de Z2M / Mosquitto rompiendo tras un HA upgrade, evaluar migración. Hasta entonces, asumirlo estable.

  6. Defensa pragmática: aplicar el ../concepts/ha-pre-update-checklist específicamente al pre-update de Z2M:

  7. Verificar la versión target del Z2M add-on contra changelog antes de update.
  8. Backup database.db + coordinator_backup.json + configuration.yaml del Z2M antes del update.
  9. Smoke test post-update: ping 3-5 devices críticos.

Failure modes específicos a registrar

Para el catálogo (gap abierto):

  • Z2M post-upgrade rompe (YAML schema breaking, MQTT topic structure change). Probabilidad: media-alta históricamente.
  • Mosquitto crash silencioso — devices Zigbee siguen funcionando pero HA no recibe states. Diagnóstico: ver "last seen" vs hora actual.
  • Coordinator pierde devices (algunos devices "missing" tras restart). Solución: rejoin manual o automático según device.

Migration path desde Z2M a ZHA (si en el futuro se decide)

  1. Backup completo del HA (incluye Z2M data).
  2. Documentar el listado de devices Zigbee actuales + sus areas / nombres.
  3. Stop Z2M add-on (no uninstall todavía).
  4. Add ZHA integration → seleccionar coordinator → confirmar.
  5. Re-pair de cada device. Aprovechar para renombrar / reorganizar.
  6. Verificar que todas las automations referencian los nuevos entity IDs.
  7. Después de validar 7 días, uninstall Z2M.

Tiempo estimado: 30 min de "active work" para 20 devices, pero spread sobre días por el caminar físico a cada device.

Relaciones

Citas / evidencia

Abierto / gaps

  • Confirmar el setup actual del usuario (Z2M asumido).
  • Catalogar failure modes específicos de Z2M (gap pendiente).
  • Documentar el procedimiento de coordinator backup automatizado.