¿Diferencia entre ZigBee y Z-Wave?

He instalado interruptores y enchufes Z-Wave en algunos lugares de mi casa. Sin embargo, cuando compré los dispositivos, noté que había un par de opciones inalámbricas diferentes disponibles en la marca que estaba viendo.

Me gustaría saber algunos de los pros / contras entre los dispositivos Z-Wave y ZigBee. Una comparación como esta publicación sobre cuándo usar WiFi a través de Bluetooth sería increíble.

Por ejemplo, tengo curiosidad por información como si un estilo es potencialmente más favorable en casas con muchas paredes o si uno se presenta mejor en hogares inalámbricos "ruidosos" (por ejemplo, muchos dispositivos inalámbricos / tipos de señal).

Creo que principalmente debe preocuparse una cosa: ¿la solución ZigBee es de 2,4 GHz o 868/908 MHz? El 2.4 GHz penetra menos de ~ 900 MHz a través de las paredes, y el 2.4 GHz comparte el espectro con Wifi, Bluetooth, el horno de microondas, por mencionar algunos. La Z-Wave solo usa la banda de 900 MHz.

Ambas soluciones tienen pilas de red completas, pero no son interoperables, al menos no para aplicaciones como el control de iluminación. Ninguna de las tecnologías es común en los teléfonos móviles y demás, por lo que si desea el control de la aplicación, debe pasar por una puerta de enlace para la tecnología elegida.

Hay algunas cosas que realmente distinguen a Z-Wave y ZigBee entre sí.

Frecuencia

El primero (como observó Eirik M) es la frecuencia con la que operan. Z-Wave opera dentro de la banda ISM de 915 MHz. Esto le proporciona una penetración razonable de los materiales de construcción (mejor que Wi-Fi) y una buena distancia general. El hecho de que pocos dispositivos domésticos utilicen esa banda (ahora que los teléfonos inalámbricos de 900 MHz están menos extendidos) significa que también hay menos interferencia.

ZigBee puede operar a 2.4 GHz o 915 MHz. ¹ 2.4 GHz es una banda ocupada; es donde funcionan los hornos de microondas y Wi-Fi (entre otras cosas). Eso significa que los dispositivos ZigBee de 2.4 GHz están sujetos a más interferencia que los dispositivos Z-Wave y ZigBee de 915 MHz. Tampoco atraviesan las paredes tan fácilmente. (La banda de 2.4 GHz proporciona velocidades de bits más altas, por lo que WiFi vive allí (y también usa la banda de 5 GHz), pero la mayoría de los dispositivos IoT no necesitan transferir muchos datos rápidamente, por lo que el ancho de banda más bajo de los 915 MHz la banda no es un inconveniente).

¹ 915 MHz solo se usa en América del Norte. Aunque 2.4 GHz está disponible en todo el mundo, la banda de frecuencias más bajas de ZigBee varía de una región reguladora a otra. Las diversas bandas se encuentran principalmente en el rango de 700 MHz a 900 MHz, por lo que las declaraciones sobre la banda norteamericana de 915 MHz generalmente también son aplicables a otras regiones.

Franqueza

ZigBee es un estándar abierto, aunque debe unirse a la alianza ZigBee (por una tarifa), si desea vender dispositivos ZigBee. Z-Wave es un estándar propietario con licencia, aunque el protocolo de alto nivel se documenta públicamente. Si desea hacer hardware Z-Wave, debe licenciar la especificación de Z-Wave Alliance y luego hacer que su dispositivo sea probado para cumplir con el estándar. Si compra un dispositivo Z-Wave con una interfaz adecuadamente programable, puede usar el hardware ya licenciado con la especificación de protocolo público para escribir su propio software.

Precio

Debido a la barrera de entrada más baja, los dispositivos ZigBee a menudo pueden ser menos costosos que los dispositivos Z-Wave con la misma funcionalidad. El hardware de IoT del consumidor puede variar ampliamente en precio por muchas otras razones, por supuesto.

Interoperabilidad

Los dispositivos Z-Wave tienden a tener una mejor interoperabilidad en general. Cuando se han lanzado nuevas versiones del estándar Z-Wave, han mantenido la compatibilidad con versiones anteriores; cualquier dispositivo Z-Wave debe poder comunicarse de manera sensata con cualquier otro dispositivo Z-Wave, independientemente de la edad o el fabricante de cada uno. (Obviamente, las nuevas características del protocolo no estarán presentes, pero se preservará la funcionalidad anterior). Las pruebas de interoperabilidad son parte del proceso de cumplimiento de Z-Wave. ZigBee no tiene un régimen de prueba tan riguroso, por lo que a veces sucede que dos dispositivos ZigBee que deberían poder comunicarse entre sí no pueden, debido a fallas de implementación en uno o ambos dispositivos.

Además de eso, ZigBee admite varios perfiles diferentes que comparten el mismo protocolo subyacente pero utilizan diferentes detalles de comunicación. (Esto es algo análogo a dos API HTTP diferentes;. Tanto el uso de HTTP como medio de transporte, pero la API de Google Maps no va a ser muy útil si usted está hablando con los servidores de GitHub) La mayor parteLos dispositivos IoT ZigBee usan el perfil de Automatización del hogar, pero eso no suele estar documentado en el dispositivo, por lo que puede encontrarse con problemas inesperados. Como ejemplo, las luces Philips Hue usan ZigBee, pero lo hacen de una manera deliberadamente inoperable, por lo que debe usar el Puente Philips Hue para controlarlas. (Compare eso con Z-Wave: el proceso de certificación de Z-Wave requiere que las bombillas Z-Wave utilicen las clases de control estándar y, por lo tanto, pueden ser manejadas por cualquier controlador Z-Wave compatible).

La ZigBee Alliance se encuentra actualmente en el proceso de desarrollar una nueva iteración del protocolo ZigBee llamado ZigBee 3.0. Parece que parte del objetivo de la nueva especificación será aumentar la interoperabilidad entre los dispositivos ZigBee. Sin embargo, tendremos que ver cómo va eso. Sin embargo, todavía no parece haber un calendario para la finalización del nuevo estándar.

Similitudes

Mientras escribí lo anterior, pensé que mencionaría algunas cosas que ZigBee y Z-Wave tienen en común que los diferencian de otros protocolos utilizados para dispositivos IoT.

ZigBee y Z-Wave son redes de malla. A diferencia de WiFi y Bluetooth, donde cada dispositivo necesita ver el controlador, los dispositivos Z * están bien siempre que haya alguna ruta de comunicación entre ellos, otros dispositivos Z * en la misma red y el controlador. (Los dispositivos Z-Wave solo se combinarán con dispositivos Z-Wave, y los dispositivos ZigBee con un perfil particular solo se combinarán con otros dispositivos ZigBee con ese perfil, por supuesto).

ZigBee y Z-Wave son protocolos de múltiples proveedores. A pesar de lo mencionado anteriormente en la sección "Apertura", tanto ZigBee como Z-Wave tienen dispositivos disponibles de una variedad de compañías que a menudo compiten entre sí. (por ejemplo, las compañías que fabrican interruptores de luz Z-Wave incluyen GE, Aeotec, Linear, DragonTech y otras). Muchos otros protocolos relacionados con IoT son silos de una sola compañía (por ejemplo, Lutron Caséta); Si bien pueden tener puertas de enlace que permiten que otros sistemas los controlen, solo los dispositivos de esa compañía pueden unirse a la red.

Como un tipo de software, y un tipo de pila de protocolos, tiendo a ver esto de manera diferente a lo que tú piensas.

Para mí, estos protocolos son cosas de "bajo nivel" ( capa 1 y 2 del modelo de capa OSI 7 ).

No me importa particularmente el consumo de energía, a menos que el dispositivo funcione con batería o con energía solar. En mi vida profesional, puedo dejar decisiones sobre el hardware, que, si está listo para usar, tiende a dictar la elección del protocolo de Capa 2, a los encargados del hardware. En mi vida privada, elijo por precio, soporte (el tamaño de la comunidad y la disponibilidad de foros es muy importante) y una mejor comprensión de las especificaciones

Tiendo a buscar la funcionalidad del sistema en general. Por ejemplo, para redes de malla , hay algunas excelentes soluciones de ZigBee.

Por ejemplo, ¿algunas señales funcionan mejor a largo alcance y otras mejor en entornos "ruidosos"?

Para largo alcance, no puedo recomendar Flutter con un alcance de 1 km / media milla, en lugar de 100 m.

Cuesta solo US $ 20, y aquí hay una imagen para darle una idea de la gama

Los entornos ruidosos no son mi especialidad (se lo dejo a los encargados del hardware, lo siento), pero es posible que desee analizar cosas como el límite de Shannon , que es un software, en lugar de hardware, enfoque al ruido (también, corrección de errores hacia adelante , etc)

Como dije, esos protocolos son cosas de "bajo nivel" para mí, como desarrollador de aplicaciones (tipo de capa 3, en realidad, que es un poco más bajo).

Sí, es importante que considere ese tipo de cosas, pero muchos simplemente dirán "Lo sé, iré con Raspberry PI (o lo que sea)" y aceptarán lo que sea que ofrezca.

Después de eso, al desarrollar su aplicación, debe decidir qué protocolo de nivel superior usar. Generalmente, a menos que su servidor dicte un protocolo particular, tiene tres opciones principales:

• Use TCP y desarrolle un protocolo propietario.
• Use HTTP (S) y desarrolle una interfaz RESTful (vaya a AJAX si desea asincrónico, sin bloqueo, por ejemplo, si tiene subprocesos múltiples). A menos que tenga muchas transacciones, tenga un tiempo crítico o las operaciones de su servidor demoren mucho tiempo, puede salirse con la suya con una interfaz de bloqueo.
• Elija uno de los muchos "estándares" de IoT. Solo recomendaría esto si su dispositivo proporciona un fuerte soporte para un protocolo en particular, o si su servidor lo exige.

Espero haber entendido su pregunta correctamente. ¿Quizás pueda decirnos si está más orientado al hardware o software, y si desarrollará solo para el dispositivo IoT, o también para el servidor, o tal vez esta sea solo una pregunta general (que no se recomienda)?