Z-Wave 和 ZigBee 之间有一些真正的区别。

频率

第一个（正如 Eirik M 指出的）是它们运行的​​频率。Z-Wave 在 915 MHz ISM 频段内运行。这使其能够合理地穿透建筑材料（优于 Wi-Fi）和良好的整体距离。事实上，很少有其他家用设备使用该频段（现在 900 MHz 无绳电话不那么普遍）意味着干扰也更少。

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

¹ 915 MHz 仅在北美使用。尽管 2.4 GHz 在全球范围内可用，但 ZigBee 的较低频段因监​​管区域而异。各个频段大多在700MHz到900MHz范围内，所以关于915MHz北美频段的说法也普遍适用于其他地区。

开放性

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

价格

由于进入门槛较低，ZigBee 设备通常比具有相同功能的 Z-Wave 设备便宜。当然，由于许多其他原因，消费者物联网硬件的价格差异很大。

互操作性

Z-Wave 设备总体上往往具有更好的互操作性。当 Z-Wave 标准的新版本发布时，它们保持了向后兼容性；任何 Z-Wave 设备都应该能够与任何其他 Z-Wave 设备进行合理的通信，无论每个设备的年龄或制造商如何。（显然，不会出现较新的协议功能，但会保留较旧的功能。）互操作性测试是 Z-Wave 合规性流程的一部分。ZigBee 没有那么严格的测试方案，因此有时会发生两个本应能够相互通信的 ZigBee 设备，因为一个或两个设备的实施缺陷。

最重要的是，ZigBee 支持许多不同的配置文件，它们共享相同的底层协议，但使用不同的通信细节。（这有点类似于两个不同的HTTP API的，都使用HTTP作为交通工具，但谷歌地图API是不会，如果你在跟谁说话GitHub的服务器是非常有用的。） 大多数IoT ZigBee 设备使用家庭自动化配置文件，但这通常不会记录在设备上，因此您可能会遇到意外问题。例如，飞利浦 Hue 灯使用 ZigBee，但以一种故意无法操作的方式使用，因此您必须使用飞利浦 Hue Bridge 来控制它们。（与 Z-Wave 相比：Z-Wave 认证过程要求任何 Z-Wave 灯泡使用标准控制类，因此可以由任何兼容的 Z-Wave 控制器管理。）

ZigBee 联盟目前正在开发名为 ZigBee 3.0 的 ZigBee 协议的新迭代。看起来新规范的一部分目标是提高 ZigBee 设备之间的互操作性。不过，我们必须看看情况如何。不过，似乎还没有最终确定新标准的时间表。

相似之处

只要我写了上面的内容，我就想我会提到 ZigBee 和 Z-Wave 的一些共同点，它们将它们与用于物联网设备的其他协议区分开来。

ZigBee 和 Z-Wave 都是网状网络。与 WiFi 和蓝牙不同，每个设备都需要看到控制器，Z* 设备是可以的，只要它们、同一网络中的其他 Z* 设备和控制器之间有一些通信路径。（当然，Z-Wave 设备只会与 Z-Wave 设备啮合，而具有特定配置文件的 ZigBee 设备只会与具有该配置文件的其他 ZigBee 设备啮合。）

ZigBee 和 Z-Wave 都是多供应商协议。尽管上面的“开放性”部分有这些内容，但 ZigBee 和 Z-Wave 都有来自经常相互竞争的各种公司的设备。（例如，制造 Z-Wave 灯开关的公司包括 GE、Aeotec、Linear、DragonTech 等。）许多其他与物联网相关的协议是单一公司的孤岛（例如 Lutron Caséta）；虽然他们可能拥有让其他系统控制它们的网关，但只有该公司的设备才能加入网络。

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

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

作为一名软件人员——以及协议栈方面的人员——我倾向于与你不同的看法。

对我来说，这些协议是“低级”的东西（OSI 7 层模型的第 1 层和第 2 层）。

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

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

例如，某些信号在远距离工作是否更好，而在“嘈杂”环境中是否更好？

对于远程，我不能推荐足够高的Flutter，其范围为 1km/半英里，而不是 100m。

它的成本仅为 20 美元，这是一张图片，可以让您了解范围

嘈杂的环境不是我的专长——我把这留给硬件人员，对不起——但你可能想研究香农极限之类的东西，它是一种软件，而不是硬件，噪声方法（还有前向纠错，等等）

正如我所说，这些协议对我来说是“低级”的东西，作为应用程序开发人员（实际上是第 3 层的人，这有点低）。

是的，考虑这类事情很重要，但许多人只会说“我知道，我会选择 Raspberry PI（或其他）”并接受它提供的任何内容。

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

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

我希望我正确理解了你的问题。或许你可以告诉我们你是更面向硬件还是软件，你是只为物联网设备开发，还是为服务器开发，或者这只是一个普遍的问题（不鼓励）？