1.6 连接 IoT 世界的技术地图

返回第 1 章：IoT 世界地图

前面已经看到，同一种设备可以组成单设备、套装、场景、行业方案或开放生态。产品形态变了，设备之间、设备与平台之间、平台与应用之间需要建立的连接也会变多。

这时最容易出现一个误解：把 Wi-Fi、蓝牙、MQTT、Matter 和 5G 放在同一张清单里比较。它们确实都和“连接”有关，却处在不同层次，解决的也不是同一个问题。无线电技术决定信息怎样离开设备，网络技术决定消息怎样到达目的地，应用通信协议决定双方怎样交换信息，互操作标准则决定不同厂商能否理解彼此的设备。

本节先把这些层次分开，再把它们重新组合到几个真实场景中。具体协议报文、设备接入流程和平台实现留到后续章节展开。

1.6.1 先分清连接、通信与互操作

一台温度传感器向平台报告读数，至少要经过几类不同的约定。

第一类约定解决“信号怎么传”。设备可能通过 Wi-Fi、蓝牙、Thread、蜂窝网络或 LoRa 无线电发送数据，也可能直接使用以太网。它们决定覆盖范围、功耗、带宽、网络拓扑和部署条件，但通常不会定义“温度”这个业务字段究竟叫什么。

第二类约定解决“消息怎么交换”。设备可以通过 MQTT 向消息代理发布数据，也可以用 HTTP 请求接口，或者使用更适合受限设备的 CoAP。它们定义的是消息传递方式、请求与响应关系或发布与订阅关系，不等于底层一定使用某一种无线技术。

第三类约定解决“不同产品怎样理解同一件事”。即使两台设备都能传输消息，如果一台把亮度写成 level，另一台写成 brightness，或者两者对“开关”取值的含义不同，连接仍然不会自动变成互操作。Matter 这类标准试图在更高层规定设备类型、能力和交互方式，但它仍然需要运行在底层网络之上。

所以，选型时不能只问“它的距离多远”或“它是不是物联网协议”，还要问：这一项技术处在哪一层，它替系统承担了哪部分工作，剩下的工作由谁完成。

1.6.2 短距离与局部网络：设备怎样在附近互相到达

家庭、楼宇和工厂内部的设备，通常先面对一个局部范围的问题：设备怎样在房间、楼层或现场内互相发现并交换信息。短距离技术之间的差别，主要体现在功耗、距离、带宽、拓扑和是否直接使用 IP 网络。

Wi-Fi：接入已有的 IP 网络

Wi-Fi 的优势是基础设施普及、带宽较高，许多家庭和企业已经部署了无线局域网。摄像头、家电和需要频繁传输数据的设备，可以直接通过 Wi-Fi 接入局域网，再访问互联网或本地服务。

代价也很清楚：设备需要承担无线通信和网络协议栈的功耗，配网要处理网络名称、密码、认证和漫游，家庭路由器或企业网络的变化也可能影响设备。对于一颗只需偶尔报告温度、依靠电池运行数年的传感器，Wi-Fi 的能力未必值得它承担的能耗和配置复杂度。

Bluetooth：靠近设备，或者作为配网入口

Bluetooth Classic 长期用于音频和点对点连接；Bluetooth Low Energy 则更适合低功耗设备、近距离数据交换、广播和部分网状场景。Bluetooth SIG 的技术说明同时列出了点对点、广播和 Mesh 等通信拓扑，说明“蓝牙”并不只对应一种使用方式。Bluetooth 技术概览

在 IoT 产品中，蓝牙常见的作用有两种：手机靠近设备时完成首次配置，或者设备与附近的传感器、控制器直接通信。它并不自动提供一条从设备到云端的长期互联网连接；如果设备需要远程控制，通常还要借助手机、网关或其他网络设备转发信息。

Zigbee：用低功耗节点组成局部网络

Zigbee 常用于灯具、开关和传感器等低功耗设备。多个节点可以在局部范围内协同转发消息，减少每个电池设备都直接连接路由器的要求。实际部署通常还需要协调器或网关，把局部网络与更上层的系统连接起来。

这类网络适合设备数量较多、消息量不大、需要较长电池寿命的场景。它的局部网络能力并不等于跨品牌互操作：设备能否被同一个系统识别，还取决于设备模型、认证和上层产品规则。

Thread：低功耗的 IP 局部网络

Thread 基于 IEEE 802.15.4，并以低功耗、IPv6 和网状网络为主要特征。Thread Group 将它定位为面向家庭和楼宇的 IP 网络，设备可以在局部网络中通信，也可以通过边界路由器连接到更大的 IP 网络。Thread 官方概览

Thread 解决的是“设备怎样进入一个低功耗的 IP 网络”，并不单独规定灯具、门锁或温控器应该提供哪些业务能力。它可以与 Matter 等更高层标准配合，也可以承载其他应用协议。Thread 不是 Matter 的同义词：前者主要提供网络，后者还要规定设备怎样被发现、描述和控制。

以太网：有线连接也属于 IoT 的连接选择

服务器、网关、工业控制器和固定安装的设备，常常可以使用以太网。它不受无线信号遮挡和频道拥塞的影响，供电和网络条件也更容易集中管理。代价是布线和现场改造，移动设备和电池设备通常不适合采用它。

因此，局部连接没有统一的优劣排序。摄像头可能需要 Wi-Fi 或以太网，门窗传感器可能使用 Zigbee 或 Thread，手机配网可能使用 Bluetooth。一个完整产品往往同时采用其中几种技术。

1.6.3 广域连接：设备怎样离开现场

设备一旦离开家庭路由器、楼宇局域网或工厂现场，就需要另一类连接方式。选择广域连接时，覆盖范围、运营费用、功耗、移动性、部署地点和数据量通常比峰值带宽更重要。

蜂窝网络：直接连接运营商网络

4G、5G 和面向特定物联网场景的蜂窝连接，可以让车辆、物流终端、户外设备和分散部署的传感器直接接入运营商网络。设备企业不必在每个现场建设自己的局域网，但需要处理通信卡、套餐、覆盖、资费和运营商服务变化。

蜂窝网络的能力范围很宽：需要持续传输视频或频繁交互的设备，关注带宽和时延；只需周期性上报少量数据的设备，可能更关注功耗、覆盖和连接成本。NB-IoT 等低功耗广域连接适合一部分小数据、低频率和长续航场景，但具体可用性仍取决于地区、运营商和设备部署条件。

LoRa 与 LoRaWAN：把低功耗和广覆盖结合起来

LoRa 通常指无线物理层相关的调制技术，LoRaWAN 则是建立在其上的低功耗广域网络协议。LoRa Alliance 将 LoRaWAN 描述为面向 LPWAN 的开放标准，重点关注电池寿命、覆盖、容量和成本。LoRa Alliance：LoRaWAN 技术介绍

LoRaWAN 设备一般通过网关接入网络，再由网络服务器和应用系统处理数据。企业可以在园区、农场或楼宇部署自己的网络，也可以使用公共网络。它适合分布广、数据量小、对实时性要求有限的监测场景；如果业务需要大数据量、连续连接或快速双向交互，就要重新评估它的适用性。

这里也要区分 LoRa 和 LoRaWAN：前者不能单独代表一套完整的设备到平台服务，后者也不等于任何使用 LoRa 无线电的私有协议。

卫星连接：为难以铺设网络的地点提供选择

海上、荒野、山区和跨地域运输中的设备，可能无法使用固定网络或常规蜂窝网络。卫星连接可以扩大覆盖范围，但通常伴随更高的终端、通信和能源成本，也需要考虑时延、天气、天线和服务区域。

因此，广域连接选择的本质不是追求“覆盖越大越好”，而是判断设备的部署地点、上报频率、供电方式、移动状态和业务价值，是否值得承担相应的连接成本。

1.6.4 设备与平台怎样交换消息

底层网络解决“消息能不能到达”，应用通信协议解决“双方怎样交换消息”。同一套 Wi-Fi、蜂窝或以太网连接上，可以运行不同的应用协议；同一种应用协议，也可能跨越不同的网络。

MQTT：让设备发布消息，让系统订阅消息

MQTT 采用发布与订阅模型。设备可以把温度数据发布到某个主题，平台或其他服务订阅这个主题；平台也可以向设备所在主题发布控制命令。设备不必知道每个接收方是谁，消息代理负责转发和连接管理。MQTT 官方将其定义为 IoT 连接的 OASIS 标准。MQTT FAQ

这种模型适合设备数量多、消息方向复杂、设备和消费者需要解耦的系统。但 MQTT 只规定消息交换方式，不会替企业决定主题怎样命名、载荷字段怎样定义、命令是否幂等，也不会自动保证业务操作最终成功。

CoAP：面向受限设备的请求与响应

CoAP 是为受限节点和受限网络设计的应用协议，采用与 Web 类似的资源和请求响应思路，但考虑了设备内存、网络质量和功耗限制。IETF RFC 7252 对它的目标和基本模型作了定义。RFC 7252：CoAP

CoAP 适合一部分局部网络或低功耗设备。它可以通过代理与 HTTP 体系对接，但这不意味着设备使用 CoAP 后就天然拥有云端业务能力。认证、重试、数据模型、设备身份和平台接入仍然需要另外设计。

HTTP：工具丰富，适合较完整的网络环境

HTTP 的工具链、调试方式和服务端支持非常成熟。设备可以通过 HTTP 请求上传数据或获取配置，平台也容易与现有 Web 系统整合。对于资源充足、连接稳定、交互频率不高的设备，HTTP 可能比引入另一套消息系统更直接。

它的代价是请求头和连接管理带来的开销，以及设备需要面对网络中断、重试、认证和数据重复。选择 HTTP 并不代表系统简单，业务语义仍要由产品和平台定义。

厂商私有协议：短期灵活，长期需要承担迁移成本

企业也可能使用私有协议，把设备、云端和 App 紧密绑定起来。这样做可以快速适配特定产品和硬件，控制实现细节，但会增加生态接入和供应商替换的成本。设备数量扩大以后，私有协议的文档、版本兼容、测试工具和迁移路径都需要有人长期维护。

所以，应用协议的比较不能停在“哪个更快”。还要看消息模型、设备资源、网络可靠性、调试工具、生态支持和未来替换成本。

1.6.5 互操作标准解决的不是同一个问题

如果两家企业都支持 Wi-Fi，它们的设备可以进入同一个局域网，但不代表它们能够互相理解。把条件再推进一步：即使两家生产的都是调光灯，而且都采用 MQTT，也可能完全无法接入对方的平台或直接替换使用。

问题出在“支持 MQTT”没有说明的那些约定里。MQTT 本身已经是应用层协议，但它提供的是通用的消息交换机制；建立在 MQTT 之上的设备业务协议，仍要规定主题的用途、消息内容以及设备应该怎样响应。OASIS 的 MQTT 规范明确指出，消息传递机制不依赖载荷的具体内容，应用消息的数据内容和格式由应用自行定义。OASIS：MQTT 5.0 规范

都用 MQTT，为什么仍然不能直接兼容

假设两款调光灯已经通过认证，连接到同一个 MQTT 消息代理，并且具备所需的发布和订阅权限。这样，网络和接入条件都已满足，剩下的差异可以单独看清楚。

下面是两家虚构厂商的业务协议约定。两款灯都支持开关和亮度调节，载荷也都使用 JSON，但同一个“开灯并设为约一半亮度”的操作可能写成：

约定	厂商 A 的灯	厂商 B 的灯
设备订阅的控制主题	a/lights/{id}/set	b/{id}/command
控制消息	{"power":true,"brightness":50}	{"op":"set","switch":1,"level":128}
亮度数值的含义	brightness 取值为 0—100	level 取值为 0—255
实际状态上报主题	a/lights/{id}/state	b/{id}/report

平台按照 A 的协议向控制主题发布消息时，B 的灯并没有订阅这个主题，自然不会收到命令。即使把主题改成 B 的主题，B 的灯也未必认识 power 和 brightness。再把字段名改过来，如果仍把 50 原样填入 level，按 B 的约定得到的也只是约 20% 的亮度设定值。

这些差异并不违反 MQTT 规范。消息代理可以按照订阅关系转发消息，却不会自动知道两个主题都代表“控制灯”，更不会替应用换算亮度。使用 JSON 也只统一了数据的表达格式，并没有统一字段含义。

因此，同类设备采用相同的 MQTT 协议，仍可能使用彼此不兼容的业务协议。能交换消息，只是实现互操作的一步。

兼容还包括动作和结果的含义

字段能对应起来以后，仍然需要理解交互过程。继续沿用这个例子：假设 A 的灯在实际状态更新后才报告操作成功，B 的灯则在接受命令后立即返回“已接受”，稍后再上报实际状态。如果平台把这两种回复都解释成“灯已亮起”，界面就可能先显示成功，而设备尚未执行，甚至最终执行失败。

类似地，“设为开启”和“切换一次开关状态”看起来都能让一盏关闭的灯亮起来，但重复执行时结果不同。前者重复执行仍然是开启，后者执行两次就又关闭了。适配时如果只把两个命令都命名为“开关”，就会丢掉这种行为差异。

所以，设备业务协议还需要约定命令对应的动作、结果如何确认、错误怎样表达、重复请求怎样处理，以及设备支持哪些可选能力和协议版本。MQTT 的消息传递确认也不能直接当作设备动作已经完成的证明；动作是否完成，需要业务协议给出可判断的结果。

共同约定怎样减少适配工作

让这两款灯进入同一个系统，一种办法是在平台或网关中编写适配层。上层应用使用统一的“开关”和“亮度”能力，适配层负责转换各厂商的主题、字段和数值，并把设备回复还原成统一的状态与结果。这里的互操作能力来自适配工作，而不是来自“都支持 MQTT”这项声明。

适配也有边界。如果设备只提供“切换状态”，又不能查询或报告当前状态，就无法仅靠字段转换可靠地提供“设为开启”。设备没有提供的能力，适配层也不能凭空补齐。厂商协议新增功能或改变行为时，适配逻辑还需要继续维护。

另一种办法，是让不同厂商事先遵循共同的设备模型与交互约定：同一种设备提供哪些能力，属性使用什么单位和取值，命令产生什么效果，怎样报告状态和失败。这才是互操作标准要进一步解决的问题。共同约定可以建立在 MQTT 之上，也可以采用其他通信机制；仅统一 MQTT 或 JSON，都还没有完成这项工作。

Matter 是智能家居中的一个例子，它通过共同的设备能力和交互约定帮助不同品牌的产品协作。这里需要关注的是它补充了哪些共同语义，而不是把它当成 MQTT 或 Wi-Fi 的直接替代品。CSA：Matter

互操作标准的价值，是把原本需要逐家适配的一部分工作变成共同规则。但实际兼容范围仍取决于双方实现的设备类型、能力和版本，厂商扩展功能也可能需要额外适配。设备能够被共同控制以后，账号、售后、数据服务和长期运营仍然需要产品与平台负责。

1.6.6 把技术放回场景中选择

把几类技术放在一起，可以看到它们通常是组合使用的：

场景	可能的连接组合	主要关注点
手机给智能灯配网	Bluetooth Low Energy + Wi-Fi 或 Thread	配网成功率、权限和用户操作成本
家庭低功耗传感器	Thread 或 Zigbee + 网关/边界路由器	电池寿命、局部覆盖和设备扩展
家庭摄像头	Wi-Fi 或以太网 + HTTPS、厂商协议或消息服务	带宽、稳定性、隐私和远程访问
户外环境监测	蜂窝网络或 LoRaWAN + MQTT、HTTP 或平台接口	覆盖、供电、资费和数据频率
物流与车辆终端	蜂窝网络 + MQTT、HTTP 或私有协议	移动性、连续在线、漫游和远程维护
多品牌智能家居	Wi-Fi、Thread 或以太网 + Matter	设备认证、能力模型和跨平台控制
工业或园区项目	以太网、Wi-Fi、蜂窝或专用网络 + 行业协议	现场条件、实时性、安全和系统集成

这张表不是选型答案。它只提醒我们：一项技术通常只解决链路中的一部分问题。家庭传感器即使选择了 Thread，仍然需要边界路由器、设备身份、数据模型和应用；一台使用蜂窝网络的车辆终端，也仍然需要平台确认消息是否重复、指令是否执行以及设备是否已经更换。

真正的选型顺序可以从几个问题开始：设备在哪里，怎样供电，需要传输多少数据，多久交互一次，是否需要移动，现场有没有现成网络，谁负责支付连接费用，设备离线时业务怎样继续，以及将来能否更换网络或平台。

没有一种连接技术能够同时在所有场景中提供最低功耗、最大覆盖、最高带宽、最简单部署和最低成本。 工程判断的目标，是让技术组合与产品承诺相互匹配，而不是为设备贴上一个“物联网协议”的标签。

到这里，IoT 的技术地图已经从局部网络延伸到广域连接、消息交换和互操作标准。下一节将沿着设备的时间顺序继续追问：一台设备怎样从工厂被生产出来，经过配网和平台接入，进入用户的家庭或现场，并在多年运行中接受升级、维护和淘汰。