Differenza tra ZigBee e Z-Wave?


10

Ho installato interruttori e prese Z-Wave in alcuni punti della mia casa. Tuttavia, quando ho acquistato i dispositivi ho notato che c'erano un paio di diverse opzioni wireless disponibili nel marchio che stavo guardando.

Sarei curioso di conoscere alcuni dei pro / contro tra i dispositivi Z-Wave e ZigBee. Un confronto come questo post su quando usare il WiFi tramite Bluetooth sarebbe sorprendente.

Ad esempio, sono curioso di sapere se uno stile è potenzialmente più favorevole nelle case con molti muri o se si fa meglio nelle case senza fili "rumorose" (es. Molti dispositivi / tipi di segnale senza fili).



Risposte:


9

Penso che ci sia principalmente una cosa di cui dovresti preoccuparti: la soluzione ZigBee è 2,4 GHz o 868/908 MHz? Il 2,4 GHz penetra meno di ~ 900 MHz attraverso i muri e il 2,4 GHz condivide lo spettro con Wifi, Bluetooth, il forno a microonde, per citarne alcuni. Z-Wave utilizza solo la banda 900 MHz.

Entrambe le soluzioni hanno stack di rete completi, ma non sono interoperabili, almeno non per applicazioni come il controllo della luce. Nessuna delle tecnologie è comune nei telefoni cellulari e simili, quindi se si desidera il controllo delle app è necessario passare attraverso un gateway per la tecnologia scelta.


13

Ci sono alcune cose che distinguono davvero Z-Wave e ZigBee l'una dall'altra.

Frequenza

Il primo (come notato da Eirik M) è la frequenza su cui operano. Z-Wave opera all'interno della banda ISM a 915 MHz. Ciò fornisce una ragionevole penetrazione dei materiali da costruzione (meglio del Wi-Fi) e una buona distanza complessiva. Il fatto che pochi altri dispositivi domestici utilizzino quella banda (ora che i telefoni cordless a 900 MHz sono meno diffusi) significa che ci sono anche meno interferenze.

ZigBee può funzionare a 2,4 GHz o 915 MHz. 1 2,4 GHz è una banda occupata; è qui che operano i forni Wi-Fi e microonde (tra le altre cose). Ciò significa che i dispositivi ZigBee a 2,4 GHz sono soggetti a più interferenze rispetto ai dispositivi Z-Wave e ZigBee a 915 MHz. Inoltre non attraversano i muri così facilmente. (La banda a 2,4 GHz offre bit rate più elevati, motivo per cui il WiFi vive lì (e utilizza anche la banda a 5 GHz), ma la maggior parte dei dispositivi IoT non ha bisogno di trasferire molti dati rapidamente, quindi la larghezza di banda inferiore dei 915 MHz la band non è un inconveniente.)

1 915 MHz viene utilizzato solo in Nord America. Sebbene 2.4 GHz sia disponibile in tutto il mondo, la banda di frequenza inferiore di ZigBee varia da una regione di regolamentazione all'altra. Le varie bande sono per lo più nell'intervallo da 700 MHz a 900 MHz, quindi le dichiarazioni sulla banda nordamericana da 915 MHz sono generalmente applicabili anche ad altre regioni.

Apertura

ZigBee è uno standard aperto, anche se è necessario aderire all'alleanza ZigBee (a pagamento), se si desidera vendere dispositivi ZigBee. Z-Wave è uno standard proprietario concesso in licenza, sebbene il protocollo di alto livello sia documentato pubblicamente. Se si desidera realizzare l'hardware Z-Wave, è necessario concedere in licenza le specifiche di Z-Wave Alliance e quindi testare il dispositivo per la conformità allo standard. Se si acquista un dispositivo Z-Wave con un'interfaccia opportunamente programmabile, è possibile utilizzare l'hardware già concesso in licenza con le specifiche del protocollo pubblico per scrivere il proprio software.

Prezzo

A causa della barriera inferiore all'ingresso, i dispositivi ZigBee possono spesso essere meno costosi dei dispositivi Z-Wave con la stessa funzionalità. L'hardware IoT di consumo può variare notevolmente nel prezzo per molte altre ragioni, ovviamente.

interoperabilità

I dispositivi Z-Wave tendono ad avere una migliore interoperabilità nel complesso. Quando sono state rilasciate nuove versioni dello standard Z-Wave, hanno mantenuto la compatibilità con le versioni precedenti; qualsiasi dispositivo Z-Wave dovrebbe essere in grado di comunicare in modo sensato con qualsiasi altro dispositivo Z-Wave, indipendentemente dall'età o dal produttore di ciascuno. (Ovviamente, le nuove funzionalità del protocollo non saranno presenti, ma le funzionalità precedenti verranno preservate.) I test di interoperabilità fanno parte del processo di conformità Z-Wave. ZigBee non ha un regime di test così rigoroso, quindi a volte capita che due dispositivi ZigBee che dovrebbero essere in grado di comunicare tra loro non possano, a causa di difetti di implementazione in uno o entrambi i dispositivi.

Inoltre, ZigBee supporta diversi profili che condividono tutti lo stesso protocollo sottostante ma utilizzano dettagli di comunicazione diversi. (Questo è in qualche modo analogo a due diverse API HTTP;. Sia per uso HTTP come trasporto, ma l'API di Google Maps non sta per essere molto utile se si sta parlando ai server di GitHub) MostI dispositivi IoT ZigBee utilizzano il profilo di automazione domestica, ma in genere non è documentato sul dispositivo, pertanto è possibile riscontrare problemi imprevisti. Ad esempio, le luci Philips Hue utilizzano ZigBee, ma lo fanno in modo deliberatamente inutilizzabile, quindi è necessario utilizzare il bridge Philips Hue per controllarle. (Contrasto con Z-Wave: il processo di certificazione Z-Wave richiede che qualsiasi lampadina Z-Wave utilizzi le classi di controllo standard e, quindi, possa essere gestita da qualsiasi controller Z-Wave conforme.)

ZigBee Alliance sta attualmente sviluppando una nuova iterazione del protocollo ZigBee chiamato ZigBee 3.0. Sembra che parte dell'obiettivo della nuova specifica sarà aumentare l'interoperabilità tra i dispositivi ZigBee. Dovremo vedere come va, comunque. Tuttavia, non sembra esserci ancora un calendario per la finalizzazione del nuovo standard.

Somiglianze

Finché ho scritto quanto sopra, ho pensato di menzionare alcune cose che ZigBee e Z-Wave hanno in comune che le differenziano dagli altri protocolli utilizzati per i dispositivi IoT.

ZigBee e Z-Wave sono entrambe reti mesh. A differenza del WiFi e del Bluetooth, dove ogni dispositivo deve vedere il controller, i dispositivi Z * vanno bene purché ci sia un percorso di comunicazione tra loro, altri dispositivi Z * nella stessa rete e il controller. (I dispositivi Z-Wave si collegheranno solo con i dispositivi Z-Wave, e i dispositivi ZigBee con un particolare profilo si collegheranno solo con altri dispositivi ZigBee con quel profilo, ovviamente.)

ZigBee e Z-Wave sono entrambi protocolli multi-vendor. Nonostante le cose nella sezione "Apertura" sopra, sia ZigBee che Z-Wave hanno dispositivi disponibili da una varietà di aziende che spesso competono tra loro. (ad esempio le aziende che producono interruttori della luce Z-Wave includono GE, Aeotec, Linear, DragonTech e altri.) Molti altri protocolli relativi all'IoT sono silos per singola azienda (ad esempio Lutron Caséta); mentre potrebbero avere gateway che consentono ad altri sistemi di controllarli, solo i dispositivi dell'azienda possono unirsi alla rete.


4

Come un tipo di software - e un tipo di stack di protocollo - tendo a guardarlo diversamente da come potresti.

Per me, questi protocolli sono roba "di basso livello" ( layer 1 e 2 del modello OSI 7 layer ).

Non mi interessa particolarmente il consumo di energia, a meno che il dispositivo non sia alimentato a batteria o solare. Nella mia vita professionale, posso lasciare le decisioni sull'hardware, che, se è standard, tende a dettare la scelta del protocollo Layer 2, ai ragazzi dell'hardware. Nella mia vita privata, scelgo per prezzo, supporto (la dimensione della comunità e la disponibilità dei forum è molto importante) e una migliore comprensione delle specifiche

Tendo a cercare la funzionalità dell'intero sistema. Ad esempio, per le reti mesh , ci sono alcune eccellenti soluzioni ZigBee.

Ad esempio, alcuni segnali funzionano meglio a lungo raggio e altri meglio in ambienti "rumorosi"?

Per il lungo raggio, non posso raccomandare abbastanza Flutter con una portata di 1 km / mezzo miglio, invece di 100 m.

Costa solo $ 20, ed ecco una foto per darti un'idea della gamma inserisci qui la descrizione dell'immagine

Gli ambienti rumorosi non sono la mia specialità — lo lascio ai ragazzi hardware, scusate — ma potreste voler esaminare cose come il limite di Shannon , che è un software, al contrario dell'hardware, un approccio al rumore (anche, Forward Error Correction , eccetera)

Come ho detto, quei protocolli sono roba "di basso livello" per me, in quanto sviluppatore di applicazioni (ragazzo di livello 3, in realtà, che è un po 'più basso).

Sì, è importante considerare questo genere di cose, ma molti diranno semplicemente "Lo so, andrò con Raspberry PI (o qualsiasi altra cosa)" e accetterò qualunque cosa offra.

Successivamente, quando si sviluppa l'applicazione, è necessario decidere quale protocollo di livello superiore utilizzare. Generalmente, a meno che il tuo server non imponga un protocollo particolare, hai tre scelte principali:

  • Usa TCP e sviluppa un protocollo proprietario.
  • Usa HTTP (S) e sviluppa un'interfaccia RESTful (vai su AJAX se vuoi asincrono, non bloccante, per esempio se usi multi-thread). A meno che non si disponga di molte transazioni, che siano critici in termini di tempo o che le operazioni del server richiedano molto tempo, è possibile cavarsela con un'interfaccia di blocco.
  • Scegli una delle numerose "norme" IoT. Lo consiglierei solo se il tuo dispositivo fornisce un forte supporto per un protocollo particolare o se il tuo server lo richiede.

Spero di aver capito bene la tua domanda. Forse puoi dirci se sei più orientato all'hardware o al software e se svilupperai solo per il dispositivo IoT, o anche per il server, o forse questa è solo una domanda generale (che non è incoraggiata)?


Lo schema del tuo approccio alla selezione dei protocolli è eccezionale, ma senza un confronto tra i comuni protocolli wireless IoT è solo una mezza risposta.
goobering

Questo spiega il downvote, che va bene. Stiamo solo cercando di far decollare questo sito, quindi un aiuto per migliorare è il benvenuto. Tuttavia, non cercando di trovare scuse, ma ci sono diverse interpretazioni del "protocollo". Oltre al Layer 2 (che, a dire il vero, l'OP ha chiesto), la maggior parte degli sviluppatori è più interessata al protocollo Layer 3, o addirittura 4. Questa domanda mi sembra quasi una domanda "quale hardware". Una volta scelta la piattaforma, è allora che noi sviluppatori di app scegliamo "il nostro protocollo" :-) Tutto parte del quadro generale :-) Hmm, forse avrei dovuto parlare del limite di Shannon
Mawg dice di ripristinare Monica il

Senza suggerendo per un secondo che sembra una semplice domanda a cui rispondere, anche utilizzando un'interpretazione olistica del 'protocollo' non c'è alcuna menzione delle differenze specifiche tra qualsiasi hardware comune, software o altri IoT cose . Se hai intenzione di interpretarlo come una domanda "quale hardware", puoi entrare in un piccolo dettaglio con alcuni confronti nella risposta?
goobering

1
Ad essere sincero, mi rammarico persino di provare a rispondere. Questo tipo di domanda tende a chiudersi molto rapidamente su ogni altro sito SE come troppo ampio (e forse basato sull'opinione). Ormai è mezzanotte passata. Ci dormirò sopra. Forse cancella la risposta, forse la migliora, forse vota per chiudere. Come posso aiutare l'OP e altri in futuro e come posso farlo meglio di Google? Yaaawnz. G'night
Mawg dice di reintegrare Monica il
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.