La llegada de Matter, junto con Thread, al mundo de la domótica, más que despejarme dudas, me ha hecho tener más a la hora de replantearme, o no, mi actual montaje. Una de las decisiones más importantes en el montaje de tu ecosistema domótico es la elección del hub y sus protocolos domóticos, porque va a determinar el código y el canal que vas a poder usar. Veamos el abanico de posibilidades que tenemos a nuestro alcance. ¿Te apuntas?
Protocolos, códigos y canales
Un protocolo es un
Wikipedia
conjunto de reglas y convenios que se utilizan para comunicarse entre dispositivos en una red de computadoras. Un protocolo define cómo se van a intercambiar los datos entre esos dispositivos, qué formato tendrán esos datos y cómo se van a verificar esos datos para asegurarse que se reciben correctamente.
Si recuerdas el primer artículo de esta serie, entre los elementos que intervienen en la comunicación había un emisor, un receptor y un mensaje. El emisor remite al receptor un mensaje para que éste actúe en consecuencia. Ese mensaje se envía por un canal, y contiene datos que deben ser entendidos por el receptor, es decir, debe seguir un código aceptado por ambos.
Convendrás conmigo en que si tú y yo nos comunicamos en castellano, usaremos un mismo código. Pero un mensaje escrito enviado por carta (canal) no se transcribe de la misma forma que si es enviado, por ejemplo, en morse, por radiofrecuencia (canal). Al final obtenemos un mensaje en castellano, porque usamos el mismo código pero, debido al canal, ese mensaje debe convertirse a pulsos electromagnéticos, si lo enviamos por radiofrecuencia o, directamente, a caracteres escritos por tu puño y letra. Por tanto, el canal también requiere formalizar un código.
Así pues, existen protocolos domóticos para manejarnos con el canal y su código.
Estándares inalámbricos relativos al canal
Opciones
En el mundillo de las telecomunicaciones tenemos distintos estándares de protocolos domóticos de canal; además, y lo más importante, existen distintos tipos de redes de dispositivos/computadoras según su escala. En esta tabla te muestro algunos (e permito alguna licencia para simplificar):
| Estándares/Tipos red | IEEE 802.11 | IEEE 802.15 | Otros |
|---|---|---|---|
| WLAN | WiFi, LiFi | ||
| HR-WPAN | UWB | ||
| MR-WPAN | Bluetooth | Infrarrojos(IrDa) | |
| LR-WPAN | Zigbee, Thread | Z-Wave, NFC |
Es importante entender la clasificación en 2 grandes tipos de protocolos de red:
- WLAN: Wireless local area network, cuyo objetivo es extender en movilidad las redes redes cableadas con conectividad al exterior (Intenet).
- WPAN: Wireless personal area network, cuyo objetivo es conectar dispositivos personales a corta distancia, a pocos metros de distancia, sin necesidad de intemediarios y sin conectividad directa al exterior, de forma eficiente energéticamente. Podemos subdividirlo, y es importante, en:
- HR-WPAN (High rate WPAN), WPAN de baja alta.
- MR-WPAN (Mediu rate WPAN), WPAN de baja velocidad media.
- LR-WPAN (Low rate WPAN), WPAN de baja velocidad.
No debe de ser por casualidad que todos los protocolos WPAN se encuentran bajo el mismo paraguas del estándar de la IEEE.
And the winner is?
Cuando hablamos de canal en protocolos domóticos hay 2 factores importantes a tener en cuenta:
- La velocidad de transmisión (de datos) por ese canal
- El alcance que ese canal nos va a dar
Fíjate en las siguiente tabla de velocidades y distancias:
| Protocolo | Velocidad (mbps) | Alcance máx. (m) |
| Zigbee | 0,25 | 16,00 |
| Z Wave | 0,04 | 16,00 |
| WiFi n | 112,80 | 13,50 |
| Thread | 0,25 | 12,00 |
| Bluetooth LE | 1,00 | 10,00 |
NOTA: datos aproximados obtenidos en mi casa con mis dispositivos. Para Thread son teóricos, pues no tengo dispositivos de este tipo. Para Zigbee y Z-Wave ya no podía alejarme más físicamente, pero seguramente podría sumarles 10 metros más. La WiFi la da, en este caso práctico, la basura de router de operadora.
Está claro: vamos a por WiFi, ¿no? Tenemos un alcance adecuado y una velocidad que despeina al más engominado, pero a veces lo obvio no es la mejor solución. Debemos observar otros factores: escalabilidad del tamaño de la red, consumo energético, tolerancia a fallos, dificultad en la gestión de gran cantidad de dispositivos, falta de un modelo de comunicación interoperable de dispositivo a dispositivo, etc; todo ello me lleva a optar por alguno de los más «debiluchos».
No digo que WiFi no valga; de hecho tengo dispositivos WiFI; lo que digo es que para IoT no es lo más adecuado. Me explico:
- WiFi es una tecnología ampliamente adoptada y que tienes, seguro, en tu hogar. Esto significa que los dispositivos IoT que utilizan WiFi pueden integrarse fácilmente en estas redes existentes, sin un hub, pero WiFi no se diseñó para IoT.
- Tu router aguanta un número limitado de clientes; en domótica ese número crece mucho y el router, normalmente, no es capaz de gestionarlos y falla o desconecta dispositivos (lo digo por experiencia propia, que contaré algún día).
- Los dispositivos por WiFi consumen una cantidad no despreciable de energía; es altamente recomendable que vayan alimentados con la red eléctrica.
- La WiFi transmite por un canal. Tantos dispositivos compartiendo una misma frecuencia y un mismo canal se entorpecen. Dado que en IoT, y la WiFi, se usa la frecuencia de los 2,4GHz (excepto Z Wave) te recomiendo que el resto de dispositivos (tablet, portátil, TV, etc) usen la de 5GHz.
- ¿Usarías un cañón para matar moscas? Un sensor de temperatura envía mensajes de escasos bytes de tamaño. Una peli en streaming sí consume un importante caudal que hay que medir en megabytes. La WiFi tiene más sentido para consumir contenido.
- Una WiFi presenta una conexión en topología de estrella, y si te has leído el artículo sobre extensión de la red entenderás lo importante que es, en IoT, usar una topología de tipo mesh. Sí, sé lo que estás pensando, y tienes razón, que si pones puntos de acceso WiFi mesh lo has solucionado. Vale, pero es que eso ya lo tienes con otros protocolos que no sean WiFi y sin tener que comprar nodos mesh.
- Cualquier dispositivo IoT WiFi “chinorris” que te compres se conecta a tu red… que no la tienes segmentada, ¿verdad? Ahí tienes una importante posible brecha de seguridad.
A todo lo dicho sobre WiFi, aclarar que hay una excepción importante: las cámaras de vigilancia. Éstas necesitan protocolos más capaces que LR-WPAN y, muchas veces usan WiFi o algún protocolo propietario al estilo de WiFi (vía su propio hub, como no).
De los protocolos domóticos «debiluchos» parece que Bluetooth LE (low energy) es la opción adecuada por ancho de banda, mientras que Z-Wave lo es por alcance, pero… sí, siempre hay algún «pero»: no todos los dispositivos Bluetooth LE permiten topología mesh (es en estrella), y Z-Wave es un protocolo propietario, el único que no usa la banda de los 2.4GHz -evitas interferencias-, sus dispositivos son más caros, no es capaz de manejar simultáneamente tantos dispositivos como Zigbee y sólo permite 4 saltos en la malla entre emisor y receptor.
Vaaaale, pues dicho esto, parece que me decanto por Zigbee y Thread que, por ser de tipo WPAN, son protocolos específicamente diseñados (como Z-Wave) para IoT.
Conclusión
Optar por un protocolo domótico u otro nos va a condicionar la arquitectura final del tinglado IoT y lo que podremos o no hacer, y el elemento sobre el que pivota toda tu domótica es el hub, con lo que su elección adecuada es fundamental.
Un dispositivo ZigBee no es compatible con otro Z-Wave o WiFi o lo que sea. Al elegir dispositivos IoT debes contemplar la compatibilidad entre protocolos; que se entiendan entre ellos requiere usar bridges con tu hub o hubs multiprotocolo o apostar por el matrimonioThread y Matter (ya lo veremos en el próximos episodios).
Que yo descarte WiFI, Z-Wave o lo que sea, no significa que debas hacerlo tú; no hay una máxima que diga que esto es mejor que aquello. Podría darse el caso de que el dispositivo que necesitas sólo exista con ese protocolo y, si lo necesitas, ¿quién soy yo para inducirte a no comprarlo? Cada uno tiene unas necesidades y son ellas las que deben guiar tu elección, no yo.
En próximos capítulos nos adentraremos en Zigbee y Thread (con Matter) pero, como ves, hemos reducido bastante las opciones (según mi propio criterio, que no tiene que coincidir con el tuyo).