ZigBee和Z-Wave之间的区别？

#1 楼

我认为您应该主要关心的一件事：ZigBee解决方案是2.4 GHz还是868/908 MHz？ 2.4 GHz穿透墙壁的频率不到900 MHz，而2.4 GHz与Wifi，蓝牙和微波炉共享频谱，仅举几例。 Z-Wave仅使用900 MHz频段。

这两种解决方案都具有完整的网络堆栈，但不能互操作，至少不适用于照明控制等应用。这两种技术都不在手机中很常见，因此，如果要控制应用程序，则需要通过网关来选择技术。

#2 楼

Z-Wave和ZigBee确实有一些区别。

频率

第一个（如Eirik M所述）是它们的工作频率。 Z-Wave在915 MHz ISM频段内运行。这样可以合理渗透建筑材料（优于Wi-Fi）并具有良好的总体距离。很少有其他家用设备使用该频段（现在900 MHz无绳电话的普及程度较低）意味着存在更少的干扰。

ZigBee可以在2.4 GHz或915 MHz上运行。12.4 GHz是繁忙的乐队；这是Wi-Fi和微波炉（以及其他设备）的运行地。这意味着2.4 GHz ZigBee设备比915 MHz Z-Wave和ZigBee设备受到更大的干扰。他们也不容易穿过墙壁。 （2.4 GHz频段确实提供了更高的比特率，这就是为什么WiFi在那里（也使用5 GHz频段）存在的原因，但是大多数IoT设备不需要快速传输大量数据，因此915 MHz的带宽较低频段不是一个缺点。）

1 915 MHz仅在北美使用。尽管全球范围内都可以使用2.4 GHz，但ZigBee的较低频段在一个法规区域之间有所不同。各个频段大多在700 MHz至900 MHz范围内，因此有关915 MHz北美频段的声明通常也适用于其他地区。

开放性

ZigBee是一种开放标准，但是如果您想销售ZigBee设备，则需要加入ZigBee联盟（收费）。尽管高级协议已公开记录，但Z-Wave是许可的专有标准。如果要制造Z-Wave硬件，则必须从Z-Wave联盟获得许可的规格，然后对设备进行测试以符合标准。如果购买具有适当编程接口的Z-Wave设备，则可以使用已许可的硬件以及公共协议规范来编写自己的软件。

价格

由于进入门槛较低，ZigBee设备通常比具有相同功能的Z-Wave设备便宜。当然，由于许多其他原因，消费类IoT硬件的价格也可能相差很大。 Z-Wave标准的新版本发布后，它们保持了向后兼容性。任何Z-Wave设备都应该能够与任何其他Z-Wave设备进行明智的通信，而不管每个设备的年龄或制造商如何。 （显然，不会出现较新的协议功能，但会保留较旧的功能。）互操作性测试是Z-Wave遵从性过程的一部分。 ZigBee没有严格的测试方案，因此有时由于一个或两个设备的实现缺陷而导致两个应该能够互相通信的ZigBee设备无法相互通信。

其中，ZigBee支持许多不同的配置文件，它们共享相同的基础协议，但使用不同的通信详细信息。 （这有点类似于两个不同的HTTP API；它们都使用HTTP作为传输方式，但是如果您要与GitHub的服务器通信，则Google Maps API不会很有用。）大多数IoT ZigBee设备都使用家庭自动化配置文件，但通常不会记录在设备上，因此您可能会遇到意想不到的问题。例如，飞利浦Hue灯使用ZigBee，但是故意以无法使用的方式使用ZigBee，因此您必须使用飞利浦Hue桥来控制它们。 （与Z-Wave对比：Z-Wave认证过程要求所有Z-Wave灯泡都使用标准控制类，因此，可以由任何兼容的Z-Wave控制器进行管理。） >ZigBee联盟目前正在开发名为ZigBee 3.0的ZigBee协议的新迭代。看起来新规范目标的一部分将是提高ZigBee设备之间的互操作性。不过，我们必须看看情况如何。不过，似乎还没有制定新标准的时间表。

相似之处

只要我写了上面的内容，我就以为提到ZigBee和Z-Wave的一些共同点，使它们与用于IoT设备的其他协议区分开。

ZigBee和Z-Wave都是网状网络。与WiFi和蓝牙不同，每个设备都需要看到控制器，而Z *设备则可以，只要它们，同一网络中的其他Z *设备和控制器之间存在某种通信路径就可以。 （当然，Z-Wave设备将仅与Z-Wave设备啮合，具有特定配置文件的ZigBee设备将仅与具有该配置文件的其他ZigBee设备啮合。）
两种多供应商协议。尽管上面“开放性”部分有内容，但ZigBee和Z-Wave都具有可从经常相互竞争的各种公司获得的设备。 （例如制造Z-Wave灯开关的公司包括GE，Aeotec，Linear，DragonTech等）。许多其他与IoT相关的协议是单公司孤岛（例如LutronCaséta）;尽管它们可能具有让其他系统控制它们的网关，但只有该公司的设备才能加入网络。

#3 楼

作为一个软件专家和一个协议栈专家，我在这方面的看法与您可能会有所不同。 OSI 7层模型）。

除非设备由电池或太阳能供电，否则我并不特别在意功耗。在我的职业生涯中，我可以保留有关硬件的决定，如果这些决定是现成的，则倾向于由硬件人员决定选择第2层协议。在我的私人生活中，我会选择价格，支持（社区规模和论坛的可用性非常重要）以及对规范的最佳猜测

我倾向于寻找整个系统的功能。例如，对于网状网络，有一些出色的ZigBee解决方案。


例如，是否某些信号在远程范围内工作得更好，而某些信号在“嘈杂”环境下又好呢？


对于远距离飞行，我不推荐高度范围为1km /半英里的Flutter，而不是100m。这是一张可以让您对该范围有所了解的图片


嘈杂的环境不是我的专长-不好意思，我将其留给硬件人员，但是您可能想研究一下像Shannon极限之类的东西，它是一种软件，而不是硬件，噪声方法（也包括前向纠错等）
，作为一名应用程序开发人员（实际上是第3层人员，要低一些）。将与Raspberry PI（或其他任何版本）一起使用”并接受其提供的任何内容。

之后，在开发应用程序时，您需要确定要使用哪个更高级别的协议。通常，除非您的服务器规定了特定的协议，否则您有三个主要选择：


使用TCP并开发专有协议。
使用HTTP（S）并开发RESTful接口（如果要异步，非阻塞（例如，如果您是多线程），请使用AJAX）。除非您有很多事务，时间紧迫或者服务器操作将花费很长时间，否则您可以使用阻塞接口。
选择众多的物联网“标准”之一。仅当您的设备为某个特定协议提供了强大的支持，或者您的服务器要求它时，我才建议这样做。

我希望我能正确理解您的问题。也许您可以告诉我们您是面向硬件还是面向软件，是否仅针对IoT设备或服务器进行开发，或者这仅仅是一个普遍的问题（不鼓励）？ >