Q6 — Custom from-scratch evaluado y descartado¶
Tras evaluar el espacio de alternativas serias a HA en 2026, la conclusión es: no hay viable. SHC y smarthomeNG existen pero tienen adopción tiny y faltan Zigbee nativo / madurez. Construir desde cero llevaría años. La decisión correcta es HA hardeneado + observabilidad + agente, no éxodo. Q6 queda cerrado como decisión negativa.
Contexto¶
El usuario inicialmente planteó "custom from-scratch" como Plan B si HA hardeneado fallaba. Era razonable considerarlo. Tras research, queda claro que no es viable. Esta página documenta por qué para que no se re-abra la pregunta en futuras sesiones.
Contenido¶
Alternativas evaluadas¶
| Alternativa | Por qué se evaluó | Por qué se descarta |
|---|---|---|
| smarthomeconnect (mhthies) | El más activo en Python alternative | Sin Zigbee nativo, 13 stars, 1 maintainer |
| smarthomeNG (gap, no ingerido en detalle) | Otro framework Python | Similar SHC — tiny community |
| openHAB | Mature, JVM-based | Out of scope per CLAUDE.md del usuario (excluido); además JVM = más complejidad operativa |
| Hubitat | Local-first commercial | Out of scope per CLAUDE.md |
| Apple Home / Matter-native | Cero tinkering | Out of scope per CLAUDE.md; además insuficiente para devices complejos |
| Custom desde cero | Control total | Años de esfuerzo, equivalente a startup |
El argumento "no hay alternativa viable"¶
- HA tiene 2M+ hogares activos. Effecto network: cada bug que vos encontrás, otros mil lo encontraron también; cada device nuevo del mercado, alguien escribió la integration.
- El ecosistema Zigbee + ESPHome + Matter en HA es único. Recrear esto en cualquier alternative = años.
- El stack de AI oficial (ha-ai-2025-09) hace que migrar fuera de HA cueste el AI también.
- HA tiene MCP integration nativo: el agente AI del Q10 strategy ya tiene API standard.
El argumento "no hace falta"¶
El dolor inicial del usuario era "HA rompe en upgrades". Las páginas ha-upgrade-reliability-strategy + q10-ai-tooling-strategy-v1 + el catálogo de failure modes cubren ese dolor sin tener que reemplazar HA.
Si Q2 (upgrade reliability) hace su trabajo, Q6 no es necesario.
Cuándo Q6 se re-abriría (criterios objetivos)¶
Sólo bajo estas condiciones, todas simultáneas:
- Q2 strategy aplicada estrictamente durante 6+ meses.
- ≥3 upgrade-rotos catastróficos (essentials caídos > 1 hora) en ese período.
- Agente AI estable mes 6+ no resolviendo automáticamente las roturas.
- HA core team haciendo cambios institucionales que rompen el modelo del usuario (ej. forzando cloud).
En ese escenario, evaluar: - Fork de HA mantenido por la comunidad (existirá si pasa lo anterior). - Stay-on-version old + parches manuales (degraded mode). - Build de orquestador propio dedicado a essentials únicamente, dejando HA Container para experimental (split architecture).
Hasta entonces: no investigar más Q6. Es ruido sobre la meta "no tinkering".
Relaciones¶
- Cierra: Q6 como decisión negativa.
- Apoyada por: ../sources/smarthomeconnect-readme (representante del espacio).
- Reemplaza la necesidad de Q6: ha-upgrade-reliability-strategy + q10-ai-tooling-strategy-v1 + catálogo de failure modes.
Citas / evidencia¶
- 13 stars de SHC vs 2M+ hogares HA — diferencia de escala determinante.
- "no production users referenced" — SHC README.
Abierto / gaps¶
- Documentar postmortems públicos (si existen) de gente que salió exitosamente de HA — para validar la conclusión empíricamente. Probable que sean raros.
- Re-evaluar en 12 meses: el espacio "Python alternative" puede madurar si HA introduce decisiones controversiales.