Latencia real por protocolo domótico: Zigbee vs Matter vs WiFi vs Z-Wave (con datos reales)

Por el equipo TCC · Actualizado mayo 2026 · Cómo analizamos

Hay una pregunta que aparece constantemente en foros y grupos de domótica: «¿cuánto tarda en responder un interruptor Zigbee comparado con uno WiFi?. La respuesta habitual es vaga: «Zigbee es más rápido». Pero eso no es suficiente para tomar decisiones de instalación.

En este artículo documentamos la latencia real de cada protocolo domótico principal —Zigbee, Matter, WiFi y Z-Wave— con datos medidos en condiciones reales, no en laboratorio. Y más importante: explicamos cuándo la latencia importa de verdad y cuándo es un argumento de marketing que no cambia nada en el día a día.

Por qué la latencia importa (y por qué a veces no importa nada)

La latencia domótica es el tiempo entre que pulsas un botón o se activa un sensor y el dispositivo ejecuta la acción. Parece simple, pero en la práctica hay tres tipos de latencia que se acumulan:

• Latencia de protocolo: el tiempo que tarda la señal en viajar del dispositivo al hub o coordinador.
• Latencia de procesamiento: el tiempo que tarda el hub en procesar la señal y decidir qué hacer.
• Latencia de cloud: si la automatización pasa por servidores externos, añade 200-800ms adicionales según la carga del servidor y la calidad de la conexión.

Un interruptor WiFi que parece «lento» puede estar tardando 50ms en el protocolo y 600ms en el cloud. Eliminar la dependencia cloud —algo que Home Assistant hace por diseño— cambia la experiencia de forma radical independientemente del protocolo.

Dicho esto: hay situaciones donde la latencia del protocolo sí importa. La iluminación sincronizada con audio o vídeo, los sensores de movimiento para encender luces sin pausa perceptible, o los sistemas de alarma son casos donde 100ms de diferencia se notan.

Zigbee — el protocolo de referencia para baja latencia local

Zigbee es consistentemente el protocolo con menor latencia en instalaciones locales. Los valores medidos en instalaciones reales con coordinador SONOFF Dongle Plus o Conbee III conectado a Home Assistant oscilan entre 20 y 80ms desde el evento hasta la ejecución de la automatización.

El rango de variación depende principalmente de dos factores: la distancia al coordinador (y si la señal va directa o a través de nodos repetidores) y la carga del sistema en el momento del evento. En redes bien diseñadas con 15-30 dispositivos, la latencia se mantiene estable en el rango bajo.

Dónde falla Zigbee: la latencia se dispara cuando el coordinador está sobrecargado (redes de 80+ dispositivos en hardware modesto), cuando el canal 2.4GHz tiene interferencias WiFi —un problema que documentamos en detalle en nuestra investigación sobre routers españoles que rompen Zigbee— o cuando los paquetes tienen que atravesar múltiples saltos en una malla mal configurada.

En esos escenarios, la latencia de Zigbee puede subir a 200-400ms, borrando completamente su ventaja sobre WiFi local.

Z-Wave — latencia comparable a Zigbee, con menor interferencia

Z-Wave opera en la banda de 868MHz en Europa, alejada completamente del ruido WiFi de 2.4GHz. Esto le da una ventaja estructural en entornos con mucha contaminación electromagnética: la latencia es más estable y predecible que Zigbee en esas condiciones.

Los valores medidos en instalaciones con hub Fibaro o Aeotec Z-Stick en Home Assistant están en el rango de 30-100ms, ligeramente superior a Zigbee en condiciones ideales pero mucho más consistente en entornos problemáticos.

El problema de Z-Wave en España: el coste por dispositivo es significativamente mayor que Zigbee, el ecosistema es más pequeño y los hubs tienen menos opciones económicas. Para la mayoría de instalaciones domésticas españolas, Zigbee ofrece mejor relación rendimiento/coste salvo en casos específicos de interferencias severas.

WiFi local (sin cloud) — mejor de lo que su reputación indica

WiFi tiene fama de ser el protocolo «lento» de la domótica. Es una simplificación injusta. El problema real de WiFi no es la latencia del protocolo —que en local puede ser tan buena como Zigbee— sino la dependencia cloud que la mayoría de dispositivos WiFi introducen por defecto.

Un dispositivo Shelly con firmware estándar controlado directamente via API local o vía Home Assistant sin cloud tiene latencias de 30-80ms. Un enchufe Tapo controlado por la app oficial de Tapo con el servidor de TP-Link como intermediario puede tardar 400-1200ms según la carga del servidor.

La diferencia no es el protocolo WiFi. Es la arquitectura. Esto explica por qué un usuario con dispositivos WiFi en Home Assistant local puede tener una experiencia más rápida que otro con Zigbee barato mal configurado.

Limitación real de WiFi: la saturación del punto de acceso. En instalaciones con 30+ dispositivos WiFi domóticos más los dispositivos personales de la casa, el router puede empezar a introducir latencia variable y desconexiones. Zigbee y Z-Wave, al usar su propia radio y formar malla, no compiten con el tráfico WiFi del hogar.

Matter sobre WiFi vs Matter sobre Thread

Matter es un estándar de aplicación que puede correr sobre diferentes transportes. En la práctica doméstica española en 2026, Matter se implementa principalmente sobre WiFi. Matter sobre Thread —el transporte de baja latencia diseñado específicamente para domótica— requiere un Border Router compatible y tiene penetración muy baja fuera de los ecosistemas Apple (HomePod mini, Apple TV 4K) y Google (Nest Hub 2ª gen).

Matter sobre WiFi: la latencia es equivalente a WiFi local bien configurado, entre 40 y 120ms en condiciones normales. La ventaja de Matter no es la velocidad: es la interoperabilidad entre ecosistemas y la ejecución local sin cloud obligatorio.

Matter sobre Thread: cuando funciona correctamente, la latencia se reduce a 15-50ms, comparable al mejor Zigbee. El problema es que «cuando funciona correctamente» tiene más asteriscos de los que los fabricantes admiten. Nuestra documentación sobre Matter en 2026: qué prometió y qué funciona detalla las limitaciones reales del protocolo en instalaciones domésticas españolas.

Bluetooth LE y Zigbee 3.0 — el caso especial de los sensores

Para sensores de temperatura, humedad y presencia que reportan datos periódicamente —no en tiempo real— la latencia del protocolo es irrelevante. Lo que importa es el intervalo de reporte y la duración de batería.

Bluetooth LE (usado por sensores Xiaomi, Govee, SwitchBot) tiene latencias de protocolo de 10-30ms, pero muchos sensores BLE solo reportan cada 30-60 segundos para conservar batería. Comparar su «latencia» con Zigbee no tiene sentido en ese contexto.

Tabla comparativa — latencia real por protocolo y escenario

Qué protocolo elegir según el caso de uso

Iluminación reactiva (cine, sincronización AV, presencia inmediata)

Zigbee local o Matter/Thread si tienes Border Router. La diferencia entre 20ms y 80ms es perceptible en sincronización de luz con audio. WiFi local también funciona bien si los dispositivos están en el mismo segmento de red y el router no está saturado.

Interruptores y enchufes de uso general

La latencia no importa para este caso de uso. Un interruptor que tarda 150ms en responder al pulsar es indistinguible de uno que tarda 50ms. Cualquier protocolo local sirve. El criterio de elección debería ser ecosistema, coste y compatibilidad con tu hub, no latencia.

Sensores de movimiento para automatizaciones de luz

Aquí sí importa, pero no tanto como parece. La mayoría de usuarios que perciben «lag» en sus automatizaciones de presencia tienen el problema en el umbral de detección del sensor o en la lógica de la automatización, no en el protocolo. Un sensor PIR Zigbee bien configurado con timeout corto parece más rápido que un sensor más preciso mal configurado.

Automatizaciones complejas multi-dispositivo

La latencia acumulada en cadenas largas de automatización (sensor activa → hub procesa → dispositivo A actúa → condición evaluada → dispositivo B actúa) puede ser notable con cualquier protocolo si el hub está en hardware lento. La latencia del protocolo es el menor de los factores.

La conclusión que nadie quiere escuchar

La latencia del protocolo es el factor menos importante en la experiencia domótica del día a día. Lo que realmente determina si tu sistema se siente rápido o lento es, en orden de impacto:

1. Local vs cloud. Un sistema local con cualquier protocolo es consistentemente más rápido que uno cloud con el mejor protocolo.
2. Hardware del hub. Home Assistant en Raspberry Pi 3 con una instalación grande puede introducir más latencia que el protocolo en sí. En hardware dedicado (HA Green, HA Yellow, NUC) el procesamiento es imperceptible.
3. Calidad de la instalación de red. Interferencias WiFi, cobertura Zigbee incompleta, malla mal diseñada.
4. El protocolo en sí. Solo importa de forma práctica en casos de uso específicos: sincronización AV, sensores de movimiento para presencia, alarmas.

Comprar dispositivos Zigbee más caros «porque son más rápidos» sin tener un coordinador local y una instalación bien diseñada es gastar dinero en el factor equivocado. Y mantener dispositivos WiFi cloud «porque ya los tengo» cuando podrías pasarlos a control local es renunciar a una mejora de experiencia real por el motivo equivocado.

La guía de instalación real de Home Assistant en un piso español entra en detalle sobre cómo construir ese sistema local que cambia la ecuación completa: Home Assistant en un piso español: instalación real, errores reales y lo que nadie te explica.