Saltar a contenido

Estrategia Q4 — testing de smart home (v1)

Primera síntesis de Q4 + el gap "digital twin" registrado por el usuario. Cinco capas de testing, de la más barata a la más profunda, aplicadas a HA configs + Z2M + ESPHome. La pieza central: el twin del mini-PC sirve como integration test environment, no como replica de prod.

Contexto

Sin tests, ni el agente AI ni el humano pueden confiar en un upgrade o un cambio. Con tests, "no tinkering" deja de depender de la fe en que las cosas funcionen tras un cambio. Esta página define qué tests valen la pena en cada nivel y cómo se ejecutan en el setup propuesto.

Contenido

Las 5 capas

Capa 1 — Static checks (yamllint, prek, ha check-config)

  • Costo: gratis, segundos.
  • Cubre: errores sintácticos, indentación, referencias rotas en YAML.
  • Cuándo corre: pre-commit hook + CI en cada push.

Capa 2 — Unit tests de automations (pytest + hass-mock)

  • Costo: medio (requiere armar fixtures + mocks).
  • Cubre: ¿la automation se dispara cuando esperamos? ¿la acción correcta?
  • Cuándo corre: CI en cada PR.
  • Stack: pytest + hass-mock o pytest-homeassistant-custom-component.

Ejemplo conceptual: 

async def test_motion_light_triggers(hass: HomeAssistant):
    # arrange: setup mock state
    hass.states.async_set("binary_sensor.motion_cocina", "off")
    hass.states.async_set("light.cocina", "off")

    # act: trigger
    hass.states.async_set("binary_sensor.motion_cocina", "on")
    await hass.async_block_till_done()

    # assert
    assert hass.states.get("light.cocina").state == "on"

Capa 3 — Integration tests en twin (MQTT injection + real Z2M sintético)

  • Costo: alto (requiere armar el twin).
  • Cubre: ¿el stack completo (Z2M → MQTT → HA → automation → light command) funciona end-to-end?
  • Cuándo corre: trigger manual o agente AI antes de promover cambios al essentials.
  • Stack: mini-PC con HA Container + Mosquitto separado del prod + script que publica MQTT messages sintéticos.

Ver gap "Digital twin via MQTT injection" en gaps.md (página por crear).

Capa 4 — Smoke tests post-deploy

  • Costo: bajo (script bash + curl).
  • Cubre: ¿los essentials siguen vivos tras un cambio?
  • Cuándo corre: cron cada N minutos + tras cada deploy.
  • Stack: Gatus + scripts custom que prueban "luz cocina toggleable", "sensor entrada reporta", etc.

Capa 5 — Multi-agent review (Dan Malone pattern)

  • Costo: medio (1 hora de tokens + tiempo del usuario para revisar reports).
  • Cubre: dead code, security, anti-patterns, duplicate IDs, entity mismatches.
  • Cuándo corre: quarterly (cron mensual o vía agente).
  • Stack: 5 agentes paralelos con prompts especializados. Ver ../sources/dan-malone-ai-patterns-ha.

Mapping a la trayectoria del agente

Cruzar con q10-ai-tooling-strategy-v1 mes-por-mes:

Mes Tests obligatorios Tests opcionales
1 Capa 1 + Capa 4 (smoke tests básicos) —
2-3 + Capa 2 unit tests Capa 5 review manual
4-6 + Capa 3 twin integration Capa 5 quarterly review
6+ Todas —

Pipeline CI propuesta (GitHub Actions)

name: HA tests
on: [push, pull_request]
jobs:
  static:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: |
          yamllint .
          prek run --all-files
          # ha check-config requires ha binary; skipped or via docker
  unit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
      - run: |
          pip install pytest pytest-homeassistant-custom-component
          pytest tests/

Capa 3 (integration) NO va en CI público — corre en el mini-PC porque requiere el twin físico.

Aplicación específica a Zigbee

Las automations que dependen de devices Zigbee son las más frágiles post-upgrade. Cobertura recomendada:

  1. Snapshot tests del state esperado tras cada upgrade (capa 2).
  2. Integration test con MQTT injection que reproduce "device X reporta off, automation Y debería disparar Z" (capa 3).
  3. Smoke test post-upgrade que pinguea los 5-10 devices más críticos vía MQTT o HA REST API (capa 4).

Aplicación específica a ESPHome

  • OTA testing: antes de flashear firmware nuevo, build local + check con esphome compile (esto ya lo hace ESPHome CLI; agregar a CI).
  • Snapshot del state esperado: para devices custom, después del flash el agent verifica que las entities esperadas aparecen en HA.
  • Rollback automático: ESPHome ya soporta dual-bank firmware; si el device no reporta en N min post-flash, rollback automático.

Relaciones

  • Implementa: Q4 (testing) v1.
  • Habilita: Q10 (el agente usa estos tests como gates antes de promover cambios).
  • Resuelve parcialmente: gap "digital twin" (capa 3).
  • Apoya: ha-upgrade-reliability-strategy (smoke tests post-upgrade).

Citas / evidencia

Abierto / gaps

  • Page concreta techniques/digital-twin-via-mqtt-injection (capa 3 detallada).
  • Patrón concreto de hass-mock + pytest aplicado a YAML real del usuario (no del HA core).
  • Repo público de tests-de-automations-de-usuario para usar como referencia.
  • Recorder replay testing — usar 7 días de history del Yellow como integration test temporal.