Saltar a contenido

Best practices para actualizaciones de Home Assistant

Cuatro reglas que reducen el costo esperado de un upgrade: no ser primero, update incremental, suscribirse a announcement channels, mantener notas. Son cheap to follow y caras de ignorar — los postmortems de upgrade en el foro suelen violar al menos una.

Contexto

Son prácticas culturales más que técnicas. Cada una mueve la distribución de probabilidad de "upgrade rompe" hacia la izquierda. Aplicadas en conjunto, transforman el upgrade de evento crítico a "routine maintenance task" (cita del source).

Contenido

Las 4 reglas

1. No ser el primero

"Wait a few days or a week after major releases for bugs to be discovered and hotfixes released."

Por qué funciona: HA tiene release mensual YYYY.M.0 y a los pocos días suele aparecer YYYY.M.1 con hotfixes. La versión .0 es la que tiene más probabilidad de tener regressions; la .1 o .2 ya filtró los issues más comunes.

Aplicado al setup del usuario: - Para essentials (HAOS Yellow): esperar al menos una semana, o hasta .1. - Para experimental (HA Container externo): se puede aplicar antes — ése es justamente su rol.

2. Update incremental

"Update one component at a time, testing after each major step to isolate problems."

Por qué funciona: si actualizás Core + Supervisor + OS + 5 Add-ons en la misma sesión y se rompe algo, no sabés qué lo rompió y la opción de rollback core-only (ha-rollback-procedure opción B) deja de ser útil.

Orden canónico (subsumido en ha-pre-update-checklist): Core → Supervisor → OS → Add-ons.

Aplicado al setup del usuario: - Hacer un componente por noche, no todo el mismo día. - Después de Core, esperar 24h con monitoreo antes de tocar Supervisor. - Add-ons de uno en uno; el orden interno: primero los menos críticos (ESPHome dashboard), después los críticos (Z2M, Mosquitto).

3. Suscribirse a announcement channels

"Follow Home Assistant Blog, community forums 'Announcements,' or Discord for breaking changes and critical issues."

Por qué funciona: las regressions importantes se reportan en el foro/Discord/blog antes de aparecer en el changelog formal del .1.

Canales mínimos: - Blog oficial: home-assistant.io/blog (RSS). - Foro Announcements: community.home-assistant.io categoría Announcements. - HACS si usás integrations custom.

4. Mantener notas

"Document significant configuration changes related to updates for future reference."

Por qué funciona: los upgrades sucesivos componen. Si supiste que 2026.3.0 rompió X y lo arreglaste vía Y, esa info te ahorra horas cuando 2026.7.0 haga algo parecido.

Implementación recomendada: - Repo git del config + commit message por update aplicado: "Upgrade to 2026.4.2 — broke ESPHome auto-discovery for sensor.X; workaround: re-add manually". - Bonus: hacer queryable este histórico vía Claude Code (Q10 dev tooling) para responder "¿qué upgrade rompió X la última vez?".

Relaciones

Citas / evidencia

  • "Approaching Home Assistant updates with a strategy of preparation, careful execution, and a clear rollback plan transforms them from a potential headache into a routine maintenance task." — ../sources/mastering-ha-updates-rollbacks.

Abierto / gaps

  • ¿Existe un bot público que reporte "X% de usuarios reportó issues con 2026.M.0 en las primeras 72h"? Sería un indicador empírico de "esperar".
  • Plantilla de commit message estandarizada para el upgrade history del repo de configs.
  • Integrar las 4 reglas en un único pre-flight script ejecutable.