物联网技术和智能空间有望掀起一场新的技术革命，但尽管存在数十亿物联网设备，但这些设备之间缺乏统一性，因而继续阻碍着该行业的发展。物联网设备面临哪些挑战，哪些解决方案可以提供帮助，以及工程师可以做些什么？
物联网的劲敌：碎片化
目前，全世界有多少物联网设备？这一数字不免令人惊讶，目前估计总数超过 140 亿，预计到 2024 年将达到 200 亿。不仅全球设备的数量难以摸清，产生的数据量也极为庞大，无法了解清楚。由于物联网技术的发展和产生的数据量，人工智能和机器学习等行业已经能够加速发展，实现大规模扩张，因此人工智能现在在日常生活中已变得司空见惯。
然而，尽管市场上的物联网设备和智能家居选项琳琅满目，但家庭中使用的大多数物联网设备远称不上智能。事实上，家庭中使用的大多数物联网设备之所以被归类为物联网，只是因为它们可以形成互联网连接，但它们并不能与其他系统共享数据，也不能对事件做出实时的智能响应。此外，绝大多数家庭在默认情况下没有整合任何智能技术，这让大多数家庭变得非智能。
虽然导致物联网-家居集成难以实现的因素有很多，但迄今为止最大的罪魁祸首是碎片化。
什么是物联网碎片化？
物联网行业有一个笑话，完美地描述了碎片化所面临的问题。简单来说，一名工程师认为物联网标准太多了，有 14 种，因此决定创建一种供所有人使用的标准，现在好了，有 15 种标准了。
不幸的是，这个笑话很大程度上反映了现实情况，数百家（即使没有数千家）设计和制造物联网设备的物联网公司和工程师就是这样做的。这些公司不仅创建了他们自己的标准（自认为是最好的），而且通常会创建整个解决方案生态系统，在他们的定制框架内工作。虽然这对只使用一家制造商的物联网解决方案的人来说可能是好事，但也带来了许多挑战，阻碍了智能空间的集成。
带来的第一个挑战是难以创建复杂的物联网解决方案，将不同制造商的设备组合在一起。例如，智能家居需要安装许多智能设备，包括智能门铃、智能电源插座、智能灯以及智能恒温器控制。尽管所有这些设备在市场上都有提供，但要在同一家制造商买齐所有这些设备或让不同制造商支持一个共同协议几乎是不可能的。
物联网碎片化带来的第二个挑战是智能家居缺乏软件支持。就像创建自己的标准一样，各大制造商也经常创建自己的软件平台来控制设备和读取数据，但这些软件平台很少公开一个 API 供其他制造商使用。因此，即使是物联网设备的软件端也是支离破碎，与其他开发者隔绝开来。
最后，被迫使用单一制造商的物联网解决方案的客户可能会被品牌所困，或者更糟的是，被该品牌做出的任何决定所束缚。例如，Hive 最近宣布，将终止包括安全摄像头和泄漏探测器在内的 HomeShield 产品系列。一旦这些设备的更新和服务停止，客户将别无选择，只能拆除并丢弃完全可用的物联网设备。
Matter 是什么？
认识到物联网设备面临的众多挑战，一群大型科技公司团结起来，声称已经“受够了”，并开发了一种新的物联网协议：Matter。尽管 Matter 的发布仍然逃不过之前创建新标准的笑话，让许多大型技术公司支持该平台（Google、Meta 等），但由于参与的技术公司规模庞大，因此基本上是迫使制造商加入该标准。
Matter 的核心是家庭自动化的专有标准，向制造商提供免版税许可，唯一的成本是认证。尽管认证费用很高，但 Matter 完全向公众开放源代码，这使得用户能够看到代码的运行情况，并提出编辑和修复错误的建议。虽然在没有获得认证的情况下使用 Matter 会受到什么处罚尚不明确，但很可能产品只是不能标有 Matter 的名称和标志（即，产品可以与 Matter 兼容，但不能以此为由进行广告宣传）。
随着 Matter 项目于 2019 年开始，众多制造商和公司宣布公开支持，其中包括 IKEA、Amazon、Google、Apple 和 Zigbee Alliance。然而，由于该协议在 2022 年 10 月才正式发布，因此尚未成为主流或被更广泛的社区采用。此外，Matter 的当前版本支持常见的家用设备，包括照明产品、电源开关、恒温器、门锁、制热系统、通风、安全传感器、电视和百叶窗。下一个版本将于 2024 年 3 月发布，支持的设备列表将扩大，包括机器人吸尘器、CO 传感器、烟雾报警器、能源管理、Wi-Fi、摄像头和其他主要电器。
Matter 有替代品吗？
到目前为止，还没有物联网标准与 Matter 一样得到同等程度的支持，但这并不是意味着，没有其他标准可以帮助工程师创建连接良好的设备。
到目前为止，物联网通信的一些更流行的方法是 REST 和 HTTP，这是因为大多数 web 服务器的自然支持选择。这意味着物联网设备可以将数据包发送到用 PHP 或 Node.js 编码的标准网络服务器，这些协议的额外好处包括查看数据非常简单，因为用于支持网站的数据库也可以用于存储物联网数据。因此，从理论上讲，整个物联网解决方案可以集成到单个网络服务器中。
HTTP 和 REST 的替代方案是使用 web 套接字。PHP、HTML、JavaScript 都支持 web 套接字，这使得它们成为物联网设备的绝佳选择；但 HTTP 和 REST 是单包消息，完成后会关闭连接，而 web 套接字可以保持开放状态，这使得它们非常适合大量的数据流。
最后，MQTT 是另一个被全球数百万设备使用的热门协议。MQTT 最初是为石油和天然气行业开发的，允许整个设备网络发布和订阅特定变量，而且 MQTT 的轻量级特性使其成为低能耗和低端微控制器的理想选择。此外，由于协议的简单性，MQTT 的定制也很容易实现，网上有许多例子可以采用。
工程师应该怎么做？
在 HTTP 和 MQTT 中，设计者都可以公开他们的 API，至少为其他制造商提供与设备接口的选项。此外，还可以制定桥接软件，即可以连接两种不同标准的软件，但这只会帮助产品与其他制造商产品一起使用。
但除此之外，很难说工程师到底应该怎么做，因为 Matter 本身还非常年轻，其文档非常深奥而复杂，Matter 可能不是所有物联网产品的最佳解决方案。当然，创造新的标准显然已被证明毫无帮助，所以工程师应该尽可能避免创建新标准。
一个可能的解决方案是，让工程师关注可以在现场轻松更改的开源设计。例如，从支持无线更新的 Linux 系统创建物联网设备，理论上可以在 Matter 作为一种协议变得更加成熟时，可以在未来更新以支持 Matter。
另一个解决方案是，工程师坚持使用主流解决方案，如 HTTP 和 REST，并希望通过向公众提供他们的 API，使 Matter 能够在一定程度上支持他们的产品。事实上，有可能在物联网设备和 Matter 服务器之间创建一个 web 接口，在两者之间翻译消息。
但 Matter 的存在并不意味着就应该使用该协议。除非是对设计来说必不可少，否则为了支持 Matter 而一股脑进行集成可能弊大于利 — 尤其是在未知 Bug 困扰 Matter 的情况下。
