Diferença entre o ZigBee e o Z-Wave?

Instalei interruptores e tomadas Z-Wave em alguns locais da minha casa. No entanto, notei ao comprar os dispositivos que havia duas opções sem fio diferentes disponíveis na marca que eu estava olhando.

Gostaria de saber alguns dos prós / contras entre os dispositivos Z-Wave e ZigBee. Uma comparação como esta publicação sobre quando usar o WiFi por Bluetooth seria incrível.

Por exemplo, tenho curiosidade em informações como se um estilo é potencialmente mais favorável em casas com muitas paredes ou se alguém se sai melhor em residências sem fio "barulhentas" (por exemplo, muitos dispositivos sem fio / tipos de sinal).

Acho que há principalmente uma coisa com a qual você deve se preocupar: a solução ZigBee é de 2,4 GHz ou 868/908 MHz? Os 2,4 GHz penetram menos de ~ 900 MHz através das paredes, e os 2,4 GHz compartilham o espectro com Wifi, Bluetooth, o forno de microondas, para citar alguns. O Z-Wave está usando apenas a banda de 900 MHz.

Ambas as soluções têm pilhas de rede completas, mas não são interoperáveis, pelo menos não para aplicativos como controle de luz. Nenhuma das tecnologias é comum em telefones celulares e tal; portanto, se você deseja controlar o aplicativo, precisa passar por um gateway para a tecnologia escolhida.

Existem algumas coisas que realmente distinguem o Z-Wave e o ZigBee um do outro.

Frequência

O primeiro (como observou Eirik M) é a frequência com que eles operam. O Z-Wave opera dentro da faixa ISM de 915 MHz. Isso proporciona uma penetração razoável dos materiais de construção (melhor que o Wi-Fi) e uma boa distância geral. O fato de poucos outros dispositivos domésticos usarem essa banda (agora que os telefones sem fio de 900 MHz são menos comuns) significa que também há menos interferência.

O ZigBee pode operar em 2,4 GHz ou 915 MHz. ¹ 2,4 GHz é uma banda ocupada; é onde os Wi-Fi e os fornos de microondas (entre outras coisas) operam. Isso significa que os dispositivos ZigBee de 2,4 GHz estão sujeitos a mais interferências que os dispositivos Z-Wave e ZigBee de 915 MHz. Eles também não atravessam paredes tão rapidamente. (A banda de 2,4 GHz fornece taxas de bits mais altas, é por isso que o WiFi mora lá (e também usa a banda de 5 GHz), mas a maioria dos dispositivos IoT não precisa transferir muitos dados rapidamente, portanto, a largura de banda mais baixa dos 915 MHz banda não é uma desvantagem.)

¹ 915 MHz é usado apenas na América do Norte. Embora 2,4 GHz esteja disponível em todo o mundo, a faixa de frequência mais baixa do ZigBee varia de uma região reguladora para outra. As várias bandas estão principalmente na faixa de 700 MHz a 900 MHz, portanto, as declarações sobre a banda norte-americana de 915 MHz também são geralmente aplicáveis ​​a outras regiões.

Abertura

O ZigBee é um padrão aberto, embora você precise ingressar na aliança ZigBee (mediante taxa), se quiser vender dispositivos ZigBee. O Z-Wave é um padrão proprietário licenciado, embora o protocolo de alto nível seja documentado publicamente. Se você deseja fabricar o hardware do Z-Wave, é necessário licenciar a especificação da Z-Wave Alliance e testar seu dispositivo quanto à conformidade com o padrão. Se você comprar um dispositivo Z-Wave com uma interface adequadamente programável, poderá usar o hardware já licenciado com a especificação de protocolo público para escrever seu próprio software.

Preço

Devido à menor barreira à entrada, os dispositivos ZigBee geralmente podem ser mais baratos que os dispositivos Z-Wave com a mesma funcionalidade. O hardware da IoT do consumidor pode variar bastante de preço por vários outros motivos, é claro.

Interoperabilidade

Os dispositivos Z-Wave tendem a ter melhor interoperabilidade em geral. Quando novas versões do padrão Z-Wave são lançadas, elas mantêm a compatibilidade com versões anteriores; qualquer dispositivo Z-Wave deve poder se comunicar de maneira sensata com qualquer outro dispositivo Z-Wave, independentemente da idade ou fabricante de cada um. (Obviamente, os recursos mais recentes do protocolo não estarão presentes, mas a funcionalidade mais antiga será preservada.) O teste de interoperabilidade faz parte do processo de conformidade do Z-Wave. O ZigBee não possui um regime de teste tão rigoroso; portanto, às vezes acontece que dois dispositivos ZigBee que devem poder se comunicar não podem, devido a falhas de implementação em um ou ambos os dispositivos.

Além disso, o ZigBee suporta vários perfis diferentes, todos compartilhando o mesmo protocolo subjacente, mas usando diferentes detalhes de comunicação. (Isso é um pouco semelhante a duas APIs HTTP diferentes;. Tanto para uso HTTP como um transporte, mas a API do Google Maps não vai ser muito útil se você está falando para os servidores do GitHub) MostOs dispositivos IoT ZigBee usam o perfil de automação residencial, mas isso normalmente não é documentado no dispositivo, para que você possa ter problemas inesperados. Como exemplo, as luzes Philips Hue usam o ZigBee, mas de maneira deliberadamente inoperante, para que você precise usar o Philips Hue Bridge para controlá-las. (Compare isso com o Z-Wave: o processo de certificação Z-Wave exige que qualquer lâmpada Z-Wave use as classes de controle padrão e, portanto, possa ser gerenciada por qualquer controlador Z-Wave compatível.)

A ZigBee Alliance está atualmente no processo de desenvolvimento de uma nova iteração do protocolo ZigBee chamado ZigBee 3.0. Parece que parte do objetivo da nova especificação será aumentar a interoperabilidade entre os dispositivos ZigBee. Nós vamos ter que ver como isso vai, no entanto. Ainda não parece haver um cronograma para a finalização do novo padrão.

Semelhanças

Desde que escrevi o texto acima, imaginei mencionar algumas coisas que o ZigBee e o Z-Wave têm em comum que os diferenciam de outros protocolos usados ​​para dispositivos de IoT.

ZigBee e Z-Wave são redes de malha. Ao contrário do WiFi e do Bluetooth, onde todos os dispositivos precisam ver o controlador, os dispositivos Z * estão bem desde que haja algum caminho de comunicação entre eles, outros dispositivos Z * na mesma rede e o controlador. (Os dispositivos Z-Wave serão combinados apenas com dispositivos Z-Wave, e os dispositivos ZigBee com um perfil específico serão combinados apenas com outros dispositivos ZigBee com esse perfil, é claro.)

O ZigBee e o Z-Wave são protocolos de vários fornecedores. Não obstante o conteúdo da seção "Abertura" acima, o ZigBee e o Z-Wave têm dispositivos disponíveis em várias empresas que frequentemente competem entre si. (por exemplo, empresas que fabricam interruptores de luz Z-Wave incluem GE, Aeotec, Linear, DragonTech e outros.) Muitos outros protocolos relacionados à IoT são silos de uma empresa (por exemplo, Lutron Caséta); embora possam ter gateways que permitem que outros sistemas os controlem, apenas os dispositivos dessa empresa podem ingressar na rede.

Como um cara de software - e um cara de pilha de protocolos -, costumo olhar de maneira diferente para isso.

Para mim, esses protocolos são coisas de "baixo nível" ( camadas 1 e 2 do modelo de camada OSI 7 ).

Não me importo particularmente com o consumo de energia, a menos que o dispositivo seja alimentado por bateria ou energia solar. Na minha vida profissional, posso deixar decisões sobre o hardware, que, se disponível, tende a ditar a escolha do protocolo da Camada 2, para o pessoal do hardware. Na minha vida privada, escolho por preço, suporte (tamanho da comunidade e disponibilidade de fóruns é muito importante) e um melhor entendimento das especificações

Costumo procurar a funcionalidade do sistema geral. Por exemplo, para redes mesh , existem algumas excelentes soluções ZigBee.

Por exemplo, alguns sinais funcionam melhor em longo alcance e outros em ambientes "barulhentos"?

Para o longo alcance, não posso recomendar o Flutter com uma faixa de 1 km / meia milha, em vez de 100 m.

Custa apenas US $ 20, e aqui está uma foto para você ter uma ideia do alcance

Ambientes barulhentos não são a minha especialidade - deixo isso para o pessoal do hardware, desculpe - mas você pode examinar coisas como o limite de Shannon , que é um software, em oposição ao hardware, uma abordagem ao ruído (também, Forward Error Correction , etc)

Como eu disse, esses protocolos são coisas de "baixo nível" para mim, como desenvolvedor de aplicativos (cara da camada 3, na verdade, que é um pouco menor).

Sim, é importante que você considere esse tipo de coisa, mas muitos dirão "eu sei, eu irei com o Raspberry PI (ou o que for)" e aceitamos o que ele oferece.

Depois disso, ao desenvolver seu aplicativo, você precisa decidir qual protocolo de nível superior usar. Geralmente, a menos que seu servidor dite um protocolo específico, você tem três opções principais:

• Use o TCP e desenvolva um protocolo proprietário.
• Use HTTP (S) e desenvolva uma interface RESTful (vá para AJAX se desejar assíncrono, sem bloqueio, por exemplo, se você for multithread). A menos que você tenha muitas transações, seja crítico em termos de tempo ou que as operações do servidor demorem muito tempo, você poderá usar uma interface de bloqueio.
• Escolha um dos muitos "padrões" da IoT. Eu recomendaria isso apenas se o seu dispositivo fornecer suporte forte para um protocolo específico ou se o servidor exigir.

Espero ter entendido sua pergunta corretamente. Talvez você possa nos dizer se é mais orientado por hardware ou software e se estará desenvolvendo apenas para o dispositivo IoT ou também para o servidor, ou talvez essa seja apenas uma pergunta geral (que não é incentivada)?