Différence entre ZigBee et Z-Wave?


10

J'ai installé des interrupteurs et des prises Z-Wave à quelques endroits autour de ma maison. Cependant, j'ai remarqué lors de l'achat des appareils qu'il y avait quelques options sans fil différentes disponibles dans la marque que je regardais.

Je serais curieux de connaître certains des avantages / inconvénients entre les appareils Z-Wave et ZigBee. Une comparaison comme celle-ci sur le moment d'utiliser le WiFi via Bluetooth serait incroyable.

Par exemple, je suis curieux de savoir si un style est potentiellement plus favorable dans les maisons avec de nombreux murs ou si l'on convient mieux dans les maisons sans fil "bruyantes" (par exemple, de nombreux appareils sans fil / types de signaux).



Réponses:


9

Je pense qu'il y a principalement une chose à laquelle vous devez vous soucier: la solution ZigBee est-elle 2,4 GHz ou 868/908 MHz? Le 2,4 GHz pénètre moins de ~ 900 MHz à travers les murs, et le 2,4 GHz partage le spectre avec le Wifi, Bluetooth, le four à micro-ondes, pour n'en citer que quelques-uns. Le Z-Wave utilise uniquement la bande 900 MHz.

Les deux solutions ont des piles réseau complètes, mais elles ne sont pas interopérables, du moins pas pour des applications telles que le contrôle de la lumière. Aucune des technologies n'est courante dans les téléphones mobiles et autres, donc si vous voulez contrôler les applications, vous devez passer par une passerelle pour la technologie choisie.


13

Il y a quelques choses qui distinguent vraiment Z-Wave et ZigBee les unes des autres.

La fréquence

Le premier (comme l'a noté Eirik M) est la fréquence sur laquelle ils opèrent. Z-Wave fonctionne dans la bande ISM 915 MHz. Cela lui donne une pénétration raisonnable des matériaux de construction (meilleure que le Wi-Fi) et une bonne distance globale. Le fait que peu d'autres appareils domestiques utilisent cette bande (maintenant que les téléphones sans fil 900 MHz sont moins répandus) signifie qu'il y a aussi moins d'interférences.

ZigBee peut fonctionner à 2,4 GHz ou 915 MHz. 1 2,4 GHz est une bande occupée; c'est là que le Wi-Fi et les fours à micro-ondes (entre autres) fonctionnent. Cela signifie que les appareils ZigBee 2,4 GHz sont soumis à plus d'interférences que les appareils Z-Wave et ZigBee 915 MHz. Ils ne traversent pas aussi facilement les murs. (La bande 2,4 GHz donne des débits binaires plus élevés, c'est pourquoi le WiFi y vit (et utilise également la bande 5 GHz), mais la plupart des appareils IoT n'ont pas besoin de transférer beaucoup de données rapidement, donc la bande passante inférieure de la 915 MHz le groupe n'est pas un inconvénient.)

1 915 MHz n'est utilisé qu'en Amérique du Nord. Bien que 2,4 GHz soit disponible dans le monde entier, la bande de fréquences inférieure de ZigBee varie d'une région de réglementation à l'autre. Les différentes bandes se situent principalement dans la plage de 700 MHz à 900 MHz, de sorte que les déclarations concernant la bande nord-américaine de 915 MHz sont généralement applicables à d'autres régions également.

Ouverture

ZigBee est un standard ouvert, bien que vous deviez rejoindre l'alliance ZigBee (moyennant des frais), si vous souhaitez vendre des appareils ZigBee. Z-Wave est une norme propriétaire sous licence, bien que le protocole de haut niveau soit documenté publiquement. Si vous souhaitez créer du matériel Z-Wave, vous devez obtenir une licence pour les spécifications de la Z-Wave Alliance, puis faire tester la conformité de votre appareil à la norme. Si vous achetez un appareil Z-Wave avec une interface programmable appropriée, vous pouvez utiliser le matériel déjà sous licence avec les spécifications du protocole public pour écrire votre propre logiciel.

Prix

En raison de la barrière inférieure à l'entrée, les appareils ZigBee peuvent souvent être moins chers que les appareils Z-Wave avec la même fonctionnalité. Le prix du matériel IoT grand public peut varier considérablement pour de nombreuses autres raisons, bien sûr.

L'interopérabilité

Les appareils Z-Wave ont généralement une meilleure interopérabilité. Lorsque de nouvelles versions de la norme Z-Wave ont été publiées, elles ont conservé une compatibilité descendante; tout appareil Z-Wave doit pouvoir communiquer de manière sensible avec tout autre appareil Z-Wave, quel que soit l'âge ou le fabricant de chacun. (De toute évidence, les nouvelles fonctionnalités de protocole ne seront pas présentes, mais les anciennes fonctionnalités seront conservées.) Les tests d'interopérabilité font partie du processus de conformité Z-Wave. ZigBee n'a pas un programme de tests aussi rigoureux, il arrive donc parfois que deux appareils ZigBee qui devraient pouvoir se parler ne puissent pas, en raison de défauts d'implémentation dans l'un ou les deux appareils.

En plus de cela, ZigBee prend en charge un certain nombre de profils différents qui partagent tous le même protocole sous-jacent mais utilisent des détails de communication différents. (Ceci est quelque peu analogue à deux API HTTP différentes; les deux utilisent HTTP comme transport, mais l'API Google Maps ne sera pas très utile si vous parlez aux serveurs de GitHub.) La plupartLes appareils IoT ZigBee utilisent le profil Home Automation, mais ce n'est généralement pas documenté sur l'appareil, vous pouvez donc rencontrer des problèmes inattendus. Par exemple, les lampes Philips Hue utilisent ZigBee, mais le font de manière délibérément inutilisable, vous devez donc utiliser le pont Philips Hue pour les contrôler. (Contrairement à Z-Wave: le processus de certification Z-Wave nécessite que toutes les ampoules Z-Wave utilisent les classes de contrôle standard et, par conséquent, puissent être gérées par n'importe quel contrôleur Z-Wave conforme.)

La ZigBee Alliance est actuellement en train de développer une nouvelle itération du protocole ZigBee nommée ZigBee 3.0. Il semble qu'une partie de l'objectif de la nouvelle spécification sera d'augmenter l'interopérabilité entre les appareils ZigBee. Nous devrons cependant voir comment cela se passe. Il ne semble pas encore y avoir de calendrier pour la finalisation de la nouvelle norme.

Similitudes

Tant que j'ai écrit ce qui précède, je pensais mentionner quelques points communs à ZigBee et Z-Wave qui les différencient des autres protocoles utilisés pour les appareils IoT.

ZigBee et Z-Wave sont tous deux des réseaux maillés. Contrairement au WiFi et au Bluetooth, où chaque appareil doit voir le contrôleur, les appareils Z * sont corrects tant qu'il existe un chemin de communication entre eux, les autres appareils Z * du même réseau et le contrôleur. (Les appareils Z-Wave ne seront maillés qu'avec des appareils Z-Wave, et les appareils ZigBee avec un profil particulier ne seront maillés qu'avec d'autres appareils ZigBee avec ce profil, bien sûr.)

ZigBee et Z-Wave sont tous deux des protocoles multifournisseurs. Nonobstant le contenu de la section «Ouverture» ci-dessus, ZigBee et Z-Wave ont tous deux des appareils disponibles auprès de diverses sociétés qui se font souvent concurrence. (Par exemple, les entreprises fabriquant des interrupteurs d'éclairage Z-Wave comprennent GE, Aeotec, Linear, DragonTech, etc.) De nombreux autres protocoles liés à l'IoT sont des silos à entreprise unique (par exemple Lutron Caséta); bien qu'ils puissent avoir des passerelles qui permettent à d'autres systèmes de les contrôler, seuls les appareils de cette entreprise peuvent rejoindre le réseau.


4

En tant que gars du logiciel - et de la pile de protocoles à ce sujet - j'ai tendance à voir les choses différemment de vous.

Pour moi, ces protocoles sont des trucs de "bas niveau" ( couches 1 et 2 du modèle de couche OSI 7 ).

Je ne me soucie pas particulièrement de la consommation d'énergie, sauf si l'appareil est alimenté par batterie ou solaire. Dans ma vie professionnelle, je peux laisser les décisions concernant le matériel, qui, s'il est standard, a tendance à dicter le choix du protocole de couche 2, aux gars du matériel. Dans ma vie privée, je choisis par prix, support (taille de la communauté et disponibilité des forums est très important) et une meilleure compréhension des spécifications

J'ai tendance à rechercher la fonctionnalité du système global. Par exemple, pour les réseaux maillés , il existe d'excellentes solutions ZigBee.

Par exemple, certains signaux fonctionnent-ils mieux à longue portée et d'autres dans des environnements "bruyants"?

Pour les longues distances, je ne peux pas recommander suffisamment Flutter avec une portée de 1 km / demi-mile, par opposition à 100 m.

Cela ne coûte que 20 $ US, et voici une photo pour vous donner une idée de la gamme entrez la description de l'image ici

Les environnements bruyants ne sont pas ma spécialité - je laisse cela aux gars du matériel, désolé - mais vous voudrez peut-être examiner des choses comme la limite de Shannon , qui est un logiciel, par opposition au matériel, une approche au bruit (aussi, Forward Error Correction , etc)

Comme je l'ai dit, ces protocoles sont des trucs de "bas niveau" pour moi, en tant que développeur d'application (gars de couche 3, en fait, ce qui est un peu plus bas).

Oui, il est important que vous envisagiez ce genre de chose, mais beaucoup diront simplement "Je sais, j'irai avec Raspberry PI (ou autre)" et accepterai tout ce qu'il offre.

Après cela, lors du développement de votre application, vous devez décider quel protocole de niveau supérieur utiliser. Généralement, à moins que votre serveur ne dicte un protocole particulier, vous avez trois choix principaux:

  • Utilisez TCP et développez un protocole propriétaire.
  • Utilisez HTTP (S) et développez une interface RESTful (allez AJAX si vous voulez asynchrone, non bloquant, par exemple si vous multi-thread). À moins que vous ayez de nombreuses transactions, que vous ayez un temps critique ou que les opérations de votre serveur prennent du temps, vous pouvez vous en sortir avec une interface de blocage.
  • Choisissez l'une des nombreuses normes de l'IoT. Je ne le conseillerais que si votre appareil fournit un support solide pour un protocole particulier ou si votre serveur l'exige.

J'espère avoir bien compris votre question. Peut-être pouvez-vous nous dire si vous êtes plus orienté matériel ou logiciel, et si vous développerez uniquement pour le dispositif IoT, ou aussi pour le serveur, ou peut-être que c'est juste une question générale (ce qui n'est pas encouragé)?


Les grandes lignes de votre approche de la sélection de protocoles sont excellentes, mais sans comparaison des protocoles sans fil IoT courants, ce n'est qu'une demi-réponse.
goobering

Cela explique le downvote, ce qui est bien. Nous essayons juste de faire décoller ce site, donc l'aide à l'amélioration est la bienvenue. Cependant, ne pas essayer de trouver des excuses, mais il existe différentes interprétations du «protocole». En plus du Layer 2 (qui, certes, l'OP a posé des questions), la plupart des développeurs sont plus intéressés par le protocole Layer 3, voire 4. Cette question me ressemble presque à une question "quel matériel". Une fois que la plate-forme est choisie, c'est à ce moment-là que les développeurs d'applications choisissent "notre protocole" :-) Tout cela fait partie de la vue d'ensemble :-) Hmm, j'aurais peut-être dû parler de la limite de Shannon
Mawg dit rétablir Monica

Sans suggérer une seconde qu'il semble être une question facile à répondre, même en utilisant une interprétation holistique du `` protocole '', il n'y a aucune mention des différences spécifiques entre un matériel, un logiciel ou d'autres choses IoT courants . Si vous allez l'interpréter comme une question `` quel matériel '', pouvez-vous entrer dans un petit détail avec quelques comparaisons dans la réponse?
goobering

1
Pour être honnête, je regrette même d'avoir essayé de répondre. Ce type de question a tendance à se fermer très rapidement sur tous les autres sites SE car trop large (et éventuellement basé sur une opinion). Il est minuit passé maintenant. Je vais dormir dessus. Peut-être supprimer la réponse, peut-être l'améliorer, peut-être voter pour fermer. Comment puis-je aider le PO et d'autres à l'avenir, et comment le faire mieux que Google? Yaaawnz. G'night
Mawg dit réintégrer Monica
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.