Cómo diagnosticar fallos domóticos intermitentes: protocolo TCC paso a paso

Un dispositivo que no funciona nunca es un problema fácil: se sustituye y se acabó. El problema difícil es el que funciona el 95 % del tiempo. La bombilla que una noche de cada diez no responde. El sensor que desaparece del panel un martes y vuelve solo. La automatización que se ejecuta cuatro días y el quinto no.

La reacción habitual es empezar a cambiar cosas: reiniciar el router, resetear el dispositivo, reinstalar la integración, comprar otro aparato. A veces funciona. Casi nunca se sabe por qué, y por eso el fallo vuelve semanas después.

Esta guía no es un catálogo de causas. Es un método para localizar en qué capa de la instalación está el fallo antes de tocar nada. Sirve igual para WiFi, Zigbee, Matter, Thread, Bluetooth o una dependencia de nube, porque lo que cambia entre esas tecnologías es dónde se rompe, no cómo se busca.

¿Qué convierte a un fallo en intermitente?

Un fallo intermitente casi siempre significa una de estas tres cosas, y conviene tenerlas presentes porque orientan toda la búsqueda:

• Hay un margen que se agota. Algo funciona con poco margen —cobertura, batería, tiempo de respuesta, memoria— y cualquier variación lo cruza. No está roto: está justo en el límite.
• Hay un evento periódico. Algo ocurre cada cierto tiempo —una renovación de dirección de red, una reconexión programada, un cambio de canal automático, una caducidad de sesión— y el fallo se sincroniza con ese evento.
• Hay una condición externa. Otro aparato que se enciende, una persona que llega a casa, un servicio del fabricante que se degrada, la temperatura de una habitación.

Ninguna de las tres se descubre sustituyendo el dispositivo. Las tres se descubren observando cuándo falla y qué más falla al mismo tiempo.

¿Por qué reiniciarlo todo destruye la prueba?

Este es el punto que casi ninguna guía menciona y el que más tiempo ahorra. Cuando reinicias el router, el hub y el dispositivo a la vez, y el problema desaparece, no has resuelto nada: has eliminado la única información que tenías. Ya no sabes cuál de los tres estaba fallando, y como el fallo era intermitente, tampoco puedes saber si ha desaparecido o simplemente aún no ha vuelto.

Un reinicio es una herramienta de diagnóstico legítima, pero solo si es uno cada vez y en un orden decidido de antemano. El reinicio múltiple es lo contrario de un diagnóstico: es un borrado de evidencia.

La regla operativa de este protocolo es simple: antes de reiniciar nada, anota qué falla, a qué hora y qué más estaba pasando. Treinta segundos de anotación evitan tres semanas de prueba y error.

Las diez capas donde puede estar el fallo

Una instalación domótica no es un sistema, son diez sistemas apilados. El fallo está en uno de ellos, y todos los de arriba lo reflejan. Por eso el síntoma que ves —«Alexa no responde»— casi nunca está en la capa donde está la causa.

#	Capa	Qué se rompe aquí
1	Alimentación	Fuentes compartidas, enchufes con mal contacto, cortes breves que reinician el aparato sin que lo notes
2	Radio / red física	Cobertura insuficiente, obstáculos, saturación del espectro, distancia al nodo más cercano
3	Direccionamiento	Asignación de direcciones IP, cambios de banda, aislamiento entre clientes
4	Hub o controlador	Coordinador Zigbee, bridge del fabricante, controlador Matter, servidor de Home Assistant
5	Nube	Servicio del fabricante caído, sesión caducada, cuota de API agotada
6	Automatización	Condiciones mal definidas, disparadores solapados, dependencias entre rutinas
7	Firmware	Actualización que cambia el comportamiento, versiones desalineadas entre dispositivo y hub
8	Batería y carga	Tensión suficiente para encender pero no para transmitir
9	Interferencias	Solapamiento entre tecnologías que comparten la banda de 2,4 GHz
10	Evidencia	No es una capa del sistema, es la tuya: sin registro no hay diagnóstico posible

El orden importa. Las capas 1 y 2 son las más baratas de comprobar y las que más fallos intermitentes explican. La capa 4 es la que más gente toca primero, y casi nunca es la culpable.

Árbol de diagnóstico TCC

Seis preguntas, en este orden. Cada una descarta capas enteras. No hace falta responderlas todas: en cuanto una te lleve a una capa probable, salta al protocolo.

1. ¿Falla solo un dispositivo o varios a la vez?
   Solo uno → capas 1, 8 o 2 (ese aparato concreto). Varios a la vez → capas 3, 4 o 9 (algo compartido). Varios de la misma tecnología → capa 4 o 9, casi seguro.
2. ¿Falla también el control local, o solo el remoto?
   Solo remoto → capa 5. Ambos → el problema está por debajo, capas 1 a 4. Esta pregunta separa la mitad del árbol de un solo golpe.
3. ¿Ocurre a horas reconocibles?
   Sí → capa 3 o 6 (eventos periódicos, automatizaciones). No → sigue bajando.
4. ¿Reiniciar el router lo corrige durante un tiempo?
   Sí → capa 3 casi con seguridad. Que se corrija al reiniciar no significa que el router esté defectuoso: significa que algo dependía de un estado que el reinicio limpia.
5. ¿El aparato pierde alimentación aunque sea un instante?
   Si al fallar aparece como recién encendido, con la configuración de arranque o el LED de emparejamiento, es capa 1 y no capa de red. Es el error de clasificación más frecuente.
6. ¿Tienes registro de lo ocurrido?
   No → tu siguiente paso no es arreglar, es registrar. Sí → léelo antes de tocar nada.

Matriz de síntomas: qué observar y qué no concluir

La columna de la derecha es la importante. Casi todos los diagnósticos equivocados nacen de dar por cierta una conclusión razonable que el síntoma no sostiene.

Síntoma	Capa probable	Qué observar	Qué NO concluir
Funciona en local pero no en remoto	5 — nube	Si la app pide iniciar sesión de nuevo; si el fabricante reporta incidencias	Que tu red esté mal. La red local está demostrando que funciona
Falla solo por la noche	3 o 6	Qué eventos programados coinciden con esa franja	Que sea «cosa del router». Puede ser una rutina tuya
Varios sensores de la misma tecnología caen juntos	4 o 9	Si el nodo central sigue en línea; si algo cambió de canal	Que los sensores estén defectuosos. Fallo simultáneo = causa común
Solo falla una automatización	6	Sus condiciones y si otra rutina actúa sobre lo mismo	Que el dispositivo falle. Si responde manualmente, no es él
Se recupera al reiniciar el router	3	Cuánto tarda en volver a fallar; si el intervalo es constante	Que el router esté averiado. Un intervalo regular apunta a un evento periódico
Un sensor desaparece y los demás no	8 o 2	Su distancia al nodo más cercano; desde cuándo lleva la misma pila	Que la pila esté bien porque el aparato enciende. Encender y transmitir piden energías distintas
El dispositivo se ve pero no se controla	3 o 4	Si el descubrimiento funciona y el control no	Que esté emparejado correctamente. Verse y obedecer son dos cosas
Falla con un asistente y con otro no	5 o 6	Qué integración concreta ha dejado de responder	Que el dispositivo esté mal. Si una vía funciona, el aparato está vivo

Protocolo TCC de 15 minutos

Se ejecuta mientras el fallo está ocurriendo, no después. Ese es todo el truco: un fallo intermitente solo se deja diagnosticar en su ventana.

1. Reproduce. Confirma que el fallo está activo ahora. Si ya se ha corregido solo, cualquier cosa que hagas será ruido.
2. Registra la hora. Hora exacta, con minutos. Es el dato que después cruzarás con los registros del sistema.
3. Comprueba la alimentación. ¿El aparato está encendido? ¿Aparece como recién arrancado? ¿Comparte enchufe o regleta con algo que se active en ese momento?
4. Comprueba la conectividad local. ¿Responde desde la app del fabricante en la misma red, sin salir a internet?
5. Comprueba el controlador. ¿El hub, coordinador o servidor sigue en línea? ¿Otros dispositivos suyos responden?
6. Revisa los registros. Antes de reiniciar. Después del reinicio muchos sistemas los rotan y se pierden.
7. Aísla la nube. Prueba el control local puro. Si funciona, ya has descartado seis capas.
8. Compara con otro dispositivo. Uno de la misma tecnología y otro de tecnología distinta. La diferencia entre ambos es la respuesta.
9. Evita el reinicio múltiple. Uno cada vez, empezando por el elemento más pequeño, y anota el resultado de cada uno.
10. Documenta. Aunque no lo resuelvas. La segunda vez que ocurra, tendrás dos puntos y podrás ver el patrón.

Si al llegar al paso 10 no tienes conclusión, no has fracasado: tienes un registro. Dos registros de un fallo intermitente valen más que veinte reinicios.

¿Qué buscar en los registros?

No hace falta saber leer registros técnicos para sacarles partido. Basta con buscar el minuto que anotaste y ver qué palabra aparece cerca. Cada familia de mensajes apunta a una capa distinta:

Lo que aparece	Qué suele significar	Capa
Tiempo de espera agotado (timeout)	El destino no contestó a tiempo. Puede ser cobertura o saturación, no necesariamente caída	2 o 5
Reconexión (reconnect)	Se perdió el enlace y volvió. Si se repite con periodicidad, hay un evento cíclico detrás	3
No disponible (unavailable)	El controlador dejó de ver la entidad. Muy distinto de que el aparato esté apagado	4
Reintento (retry)	El sistema ya estaba compensando el problema antes de que tú lo notaras	2 o 4
Autenticación	Sesión caducada o credencial revocada. Casi siempre nube	5
Firmware / versión	Comprueba si el fallo empieza justo después de una actualización	7
Dirección IP / concesión	Renovación de dirección. Si el fallo cae ahí, tienes la causa	3
Coordinador / bridge	El nodo central de la malla tuvo un incidente. Todo lo que cuelga de él lo refleja	4

Si usas Home Assistant, el registro del sistema es el punto de partida natural; cómo llegar hasta ahí en una instalación española está en la guía de instalación real de Home Assistant.

Un consejo que ahorra horas: no busques errores, busca coincidencias de hora. Un registro siempre tiene mensajes de aviso; lo relevante es el que cae en tu minuto.

¿Cómo se comporta cada tecnología cuando falla?

El método es el mismo para todas. Lo que cambia es qué mirar en la capa 2 y en la 4. Estas son las diferencias mínimas que necesitas, sin convertir esto en cinco guías distintas.

• WiFi. Los fallos intermitentes suelen venir de cobertura al límite, del salto entre puntos de acceso o de la gestión de direcciones del router. Si tienes un router de operador, empieza por ahí: el comportamiento por defecto de muchos de ellos rompe la domótica de forma característica, y lo tratamos en detalle en la guía de dispositivos que se desconectan del router.
• Zigbee. Es una malla: los dispositivos con alimentación permanente repiten la señal, los de pila no. Un fallo que aparece al retirar o mover un enchufe suele ser una malla que ha perdido un repetidor. Comparte banda con el WiFi, así que el solapamiento de canales es causa habitual.
• Matter. Depende del descubrimiento en red local y de que el controlador mantenga su vínculo con el dispositivo. El síntoma típico —se ve pero no obedece— es de capa 3, no del aparato. Si además notas retardos crecientes antes del fallo, conviene contrastar con la latencia real de cada protocolo.
• Thread. Necesita al menos un router de frontera activo. Si ese equipo se reinicia o se apaga, toda la red Thread se degrada aunque los dispositivos estén perfectos.
• Nube. No la controlas. Lo único accionable es saber cuánta funcionalidad depende de ella, y ese es el argumento a favor de mover lo crítico a control local.

Si has segmentado la red o estás pensando en hacerlo, ten en cuenta que eso añade una capa más de posibles fallos: qué se rompe exactamente al separar los dispositivos está desarrollado en la guía sobre aislar los dispositivos IoT de tu red.

¿Qué te dice el reloj?

El patrón temporal es la pista más barata y la más ignorada. Antes de comprobar nada, mira cuándo ocurre.

Patrón	Hacia dónde apunta
Solo de noche, a hora parecida	Evento programado: mantenimiento del router, rutina propia, cambio automático de canal. Caso resuelto paso a paso en interruptor que se desconecta de noche
Cada X horas, con intervalo regular	Caducidad periódica: concesión de dirección o sesión con vencimiento
Justo después de reiniciar algo	Orden de arranque: un elemento se levanta antes que aquel del que depende
Desde una actualización	Firmware. Comprueba también si el hub y el dispositivo quedaron en versiones desalineadas
Al encender otro aparato	Alimentación compartida o interferencia. Microondas, transformadores y regletas saturadas son sospechosos clásicos
Al salir o entrar de casa	Automatización por presencia, no fallo de red
Al moverte de habitación	Salto entre puntos de acceso: el dispositivo o el móvil cambian de nodo y pierden la sesión
Solo en verano, o solo con calor	Temperatura sobre electrónica al límite. Es más frecuente de lo que parece

Siete casos y cómo se resuelven

A. Un dispositivo WiFi desaparece y vuelve solo

Hipótesis: cobertura al límite o cambio de banda. Comprobación: ¿está siempre en el mismo sitio de la casa? ¿coincide con alguien usando el WiFi intensamente? Descarta: que el aparato esté defectuoso, si en otra ubicación aguanta. Siguiente paso: capa 2, y después capa 3.

B. Varios sensores Zigbee caen a la vez

Hipótesis: coordinador o malla, nunca los sensores. Comprobación: ¿los que caen cuelgan del mismo repetidor? ¿se ha movido o desenchufado algún dispositivo con alimentación permanente? Descarta: pilas agotadas: no se agotan seis a la vez. Siguiente paso: capa 4, después capa 9. Este patrón está documentado a fondo en el seguimiento de qué falla en Zigbee después de 90 días.

C. Un dispositivo Matter aparece pero no responde

Hipótesis: el descubrimiento funciona y el control no, es decir, capa 3. Comprobación: ¿responde desde otro controlador? ¿cambió algo en la configuración de red recientemente? Descarta: que el emparejamiento se haya perdido: si lo ves, sigue emparejado. Siguiente paso: capa 3, después capa 4.

D. La automatización falla pero el control manual funciona

Hipótesis: capa 6, en exclusiva. Comprobación: ¿se ejecutó y no tuvo efecto, o no llegó a ejecutarse? Son dos problemas distintos. ¿hay otra rutina actuando sobre lo mismo? Descarta: cualquier hipótesis de red: el aparato acaba de obedecer. Siguiente paso: revisa condiciones y solapamientos antes que nada.

E. Solo falla el control desde fuera de casa

Hipótesis: capa 5. Comprobación: ¿la app pide iniciar sesión otra vez? ¿falla también con otro asistente? Descarta: problemas de red local, que están demostrando funcionar. Siguiente paso: esperar y comprobar el estado del servicio. Aquí el diagnóstico correcto suele terminar en «no es tuyo». Un ejemplo completo de esta cadena, aplicado a climatización, está en por qué un split deja de responder a los comandos de voz.

F. La pila parece correcta pero el dispositivo cae

Hipótesis: capa 8. Una pila puede tener tensión suficiente para encender el aparato y no para sostener una transmisión, sobre todo con frío. Comprobación: ¿cae siempre al enviar, nunca en reposo? ¿lleva más de un año? Descarta: que esté bien porque el indicador se enciende. Siguiente paso: sustituir la pila es aquí una prueba legítima y barata.

G. Todo empezó tras una actualización

Hipótesis: capa 7. Comprobación: ¿la fecha del primer fallo coincide con la de la actualización? ¿se actualizó el dispositivo, el hub o la app? Descarta: la casualidad, pero también la certeza: la coincidencia temporal es un indicio fuerte, no una demostración. Siguiente paso: comprobar si dispositivo y controlador quedaron en versiones compatibles.

Dónde parar

Hay un punto en el que diagnosticar deja de ser diagnóstico. Este protocolo se detiene aquí, sin excepciones:

• No se manipula ningún dispositivo con tensión presente. Si hay que abrir un mecanismo, primero se corta y se comprueba que está cortado.
• No se toca el cuadro eléctrico ni se puentea ninguna protección. Un magnetotérmico que salta es información, no un obstáculo.
• No se abren fuentes de alimentación ni transformadores.
• Si el fallo intermitente afecta a varios circuitos, o coincide con que salte una protección, deja de ser un problema de domótica y pasa a ser un problema eléctrico: corresponde a un instalador.

Si el diagnóstico apunta a la instalación eléctrica de la vivienda, el criterio de dónde termina el bricolaje está desarrollado en la guía sobre dónde instalar un módulo domótico.

Y hay un último punto de parada, menos peligroso pero igual de importante: cuando el coste de seguir buscando supera el de convivir con el fallo o sustituir la pieza. Un sensor de doce euros que falla una vez al mes no merece seis horas de investigación. Un fallo que tira la calefacción entera, sí.

La posición de TCC

La mayoría de los fallos intermitentes que hemos visto en instalaciones reales no estaban en el dispositivo que daba el síntoma. Estaban una o dos capas más abajo: una pila al límite, un repetidor que alguien desenchufó, una renovación de dirección a las cuatro de la mañana, un servicio del fabricante degradado.

Por eso el orden importa más que el conocimiento técnico. Alguien que se hace las seis preguntas del árbol y anota la hora llega antes a la causa que alguien que sabe mucho de protocolos y empieza reinstalando la integración.

Si al terminar sigues sin causa, no vuelvas a empezar: espera al siguiente fallo con el protocolo preparado. La segunda observación es la que casi siempre lo resuelve.