Failure mode: sensor stale / device deja de reportar¶

Sexta entrada del catálogo. El más sutil de los failure modes: un device sigue "available" en HA pero no actualiza su state. Las automations basadas en él disparan con datos viejos, o NO disparan cuando deberían. Causa: device crashed, battery muerta, mesh route perdido, MQTT broker no reenvía, recorder no escribe. Casi invisible sin observabilidad.

Cómo se manifiesta¶

sensor.cocina_temperatura mostraba 22°C ayer, sigue mostrando 22°C hoy — pero la cocina cambió.
Automation if motion_garage == "on" then ... no dispara porque el motion sensor no reportó.
HA Statistics muestra "no data" para horas/días en sensores específicos.
Sin observabilidad, el usuario lo descubre solo cuando alguien se queja ("la luz del baño no se prende").

Por qué es el failure mode más insidioso¶

A diferencia de "HA down" (obvio) o "Z2M coordinator failed" (obvio), un sensor stale no rompe nada visible inmediatamente. El device sigue listado, sigue available. Las automations corren "exitosamente" con datos viejos.

Es el caso donde el observatorio gana más — sin él, vivís con sensores zombis durante meses.

Causas comunes¶

Causa	Síntoma específico	Probabilidad
Battery muerta	Last update fue gradualmente menos frecuente, ahora cero	Alta (Zigbee/BLE battery devices)
Mesh route perdido	Sleep device cambió de parent router; parent murió	Media (Zigbee)
MQTT broker reconnect issue	Z2M sigue corriendo pero MQTT no propaga	Media
Device crashed	ESPHome WiFi devices que necesitan reboot manual	Media
State machine stuck en HA	Bug raro de HA core — entity existe en registry pero no recibe updates	Baja
Network partition	El device está vivo pero no llega al hub (WiFi cambió SSID/password)	Baja

Cómo se detecta proactivamente¶

Métrica clave: "last_updated" age¶

Por cada entity crítico, alertar si time() - last_updated > expected_interval * 2.

Cómo:

HA Prometheus exporter expone hass_last_updated_time_seconds. Query:

(time() - hass_last_updated_time_seconds{entity="sensor.cocina_temp"}) > 600

Alerta si > 10 minutos sin update.

LogQL alternativo (si el sensor publica vía MQTT):

absent_over_time({job="zigbee2mqtt", device="sensor_cocina"}[10m])

Healthcheck declarativo por entity¶

Una page de inventario en el repo (docs/critical-sensors.yaml) lista los sensores que el agente monitorea con su intervalo esperado:

critical_sensors:
  - entity: sensor.cocina_temperatura
    expected_interval_s: 300   # 5 min
    alert_threshold_s: 900     # 15 min sin update = alerta
  - entity: binary_sensor.entrada_motion
    expected_interval_s: 60    # 1 min en mesh activo
    alert_threshold_s: 300
  - entity: sensor.living_humedad
    expected_interval_s: 300
    alert_threshold_s: 1800    # más tolerante (humedad cambia lento)

El agente lee este YAML, query Prometheus / HA states, alerta.

Cómo se recupera¶

Caso A — Battery muerta¶

Identificar device (HA UI o LogQL).
Reemplazar batería.
Re-pair si el device no se asocia automáticamente.
Verificar que la batería duraba ~1-2 años — si murió en 3 meses, hay problema (frequency too high, sensor defectuoso, batería de baja calidad).

Caso B — Mesh route perdido (Zigbee)¶

Z2M UI → device → "Force re-pair" o "Refresh".
Si no funciona: power cycle del device (sacar batería, esperar 10s, reinsertar).
Si persiste: ver si hay un router intermedio caído (otro device line-powered de Zigbee).

Caso C — MQTT broker reconnect¶

docker logs mosquitto para ver errors.
Restart Mosquitto.
Z2M typically se re-conecta automáticamente.

Caso D — Device crashed (ESPHome / WiFi device)¶

Power cycle físico.
Si reproducible: investigar firmware bug, considerar update OTA.

Cómo se previene¶

Battery management¶

Alertar al 30% battery (no esperar al 10%).
Lista en repo: docs/battery-inventory.md con device + battery type + last replaced + expected next.
El agente puede generarlo de las métricas Prometheus mensualmente.

Mesh health¶

Z2M tiene bridge/networkmap — visualización de la mesh. Re-correr quarterly y comparar contra previo. Si un device cambió de parent múltiples veces, hay problema de signal.
Mantener routers (line-powered Zigbee devices) en puntos estratégicos para no tener single-point-of-failure de mesh route.

Pre-deployment validation¶

Antes de "promote" cualquier sensor nuevo al essentials tier: 1. Setup en twin. 2. Monitorear last_updated por 30 días. 3. Si reporta consistente → promote.

Lo que el agente AI hace¶

Acción	¿Autónomo?
Alertar cuando un critical_sensor pasa el threshold	Sí desde mes 1
Force re-pair via Z2M API (sleep device perdido)	Sí desde mes 3
Power cycle de ESPHome device (si tiene power switch remoto)	Sí desde mes 6
Reemplazar batería	Nunca — humano físico
Cambio en `critical_sensors.yaml` (agregar/quitar sensors)	Pide approval

Relaciones¶

Sexta entrada del catálogo (1=stuck HAOS, 2=hw cutoff, 3=Z2M coord, 4=HACS, 5=DB bloat, 6=sensor stale).
Apoya: q5-observability-stack-v1 (todo el stack está para detectar este caso).
Apoya: q10-ai-tooling-strategy-v1 (el agente vive monitoreando esto).

Abierto / gaps¶

Patrón concreto de docs/critical-sensors.yaml con schema validado.
Cómo el agente puebla automáticamente docs/battery-inventory.md de las métricas Prometheus.
¿Hay un add-on de HA que ya hace "alert on stale entity"? Sin source canónico, probable que sí.