各种物联网协议学习笔记

admin 管理员组

文章数量: 1184232

HTTP协议

      HTTP（HyperText Transfer Protocol，超文本传输协议）是一种用于在网络中传输数据的应用层协议，是互联网的核心协议之一。它定义了客户端（如浏览器、App）与服务器之间如何通信，以及数据如何被格式化、传输和处理。

特性

(1)客户端 - 服务器模式

     客户端（如浏览器、手机 App）主动发起请求（Request)。 服务器被动接收请求，处理后返回响应（Response）。

(2)无状态协议

        服务器不会记忆客户端的历史请求（“忘记过去”），每次请求都是独立的。如需维持状态（如登录状态），需通过 Cookie 或 Session 等机制额外实现。

(3)基于 TCP 传输

     HTTP 依赖 TCP 协议建立可靠连接（三次握手），确保数据传输的完整性。（注：HTTP/3 基于 QUIC 协议，不再依赖 TCP，而是基于 UDP 实现更快的传输）。

(4)明文传输（HTTP）

      原始 HTTP 协议传输的数据是明文的，可能被中途窃听或篡改（不安全）。因此衍生出 HTTPS（HTTP + SSL/TLS 加密），通过加密保护数据安全。

工作流程

(1)建立连接：客户端通过 TCP 与服务器的 80 端口（HTTP 默认）建立连接（HTTP/1.1 及以上默认使用 “持久连接”，避免频繁建立 / 关闭连接）。

(2)发送请求：客户端向服务器发送一个 HTTP 请求（包含请求方法、目标资源、请求头、数据等）。

(3)处理请求：服务器解析请求，执行对应操作（如读取文件、查询数据库）。

(4)返回响应：服务器向客户端返回一个 HTTP 响应（包含状态码、响应头、响应数据等）。

(5)关闭连接：根据连接模式（持久 / 非持久），决定是否关闭 TCP 连接。

HTTP请求

    http请求由请(求行+请求头+请求体)组成.

请求行

     格式为 (方法+URL+协议版本）,例如：GET /index.html HTTP/1.1。请求方法由以下几种：定义客户端对服务器的操作，常见有：

• GET:从服务器获取资源（如网页、图片），参数附在 URL 后（明文，长度有限）。
• POST:向服务器提交数据（如表单提交、API 请求），参数在请求体中（更安全，适合大量数据）。
• PUT:更新服务器上的资源（全量替换）。
• DELETE:删除服务器上的资源。
• HEAD:仅获取响应头（不返回体，用于检查资源是否存在）。

请求头

     键值对格式，传递额外信息（如客户端类型、数据类型等），例如：

请求体

    仅在需要向服务器发送数据时使用（如 POST 请求的表单数据、JSON 数据），例如：

HTTP响应

     http请求由请(状态行+响应头+响应体)组成。

状态行

     格式为 协议版本 状态码 原因短语例如：HTTP/1.1 200 OK。状态码：3 位数字，表示请求处理结果，分为 5 类。

• 2xx（成功）：如 200 OK（请求成功）、201 Created（资源创建成功）。
• 3xx（重定向）：如 301 Moved Permanently（资源永久迁移）、302 Found（临时重定向）。
• 4xx（客户端错误）：如 404 Not Found（资源不存在）、403 Forbidden（权限不足）。
• 5xx（服务器错误）：如 500 Internal Server Error（服务器内部错误）、503 Service Unavailable（服务不可用）。

响应头

     传递服务器的附加信息，例如：

响应体

      服务器返回的实际数据（如网页 HTML、JSON、图片二进制等）。

Cookies

       在计算机网络和 Web 开发中，Cookies（通常称为 “Cookie”） 是服务器发送到用户浏览器并保存在本地的一小块数据（文本信息）。它的核心作用是帮助服务器在多个 HTTP 请求之间 “记住” 用户的状态，因为 HTTP 协议本身是无状态的（即服务器无法默认记住前后两次请求是否来自同一个用户）。

工作流程

①首次访问：用户第一次访问服务器时，服务器处理请求后，会生成一个 Cookie（包含用户标识、状态等信息），并通过 HTTP 响应头（Set-Cookie）发送给浏览器。

②本地保存：浏览器收到 Cookie 后，会按照规则（如域名、路径、过期时间）将其保存在用户设备的本地（通常是文件或内存中）。

③后续访问：当用户再次访问该服务器时，浏览器会自动检查本地是否有该服务器的 Cookie，若有则通过 HTTP 请求头（Cookie）将其发送给服务器。

④识别用户：服务器通过读取请求中的 Cookie，即可识别用户身份或获取之前的状态信息（如 “用户是否已登录”“购物车内容” 等）。

主要用途

①登录状态保持：用户登录后，服务器通过 Cookie 记录登录状态，后续访问无需重复输入账号密码（如 “记住我” 功能）。

②用户偏好设置：记住用户的语言选择、主题偏好、页面布局等（如网站默认显示中文还是英文）。

③行为跟踪：统计用户浏览习惯、广告投放效果等（需注意隐私合规）。

MQTT协议

     MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是一种轻量级、基于发布 / 订阅（Publish/Subscribe）模式的消息传输协议，专为低带宽、低功耗、网络不稳定的场景设计，尤其适用于物联网（IoT）设备间的通信。

核心特点

(1)轻量级：协议头部极小（最小仅 2 字节），降低网络传输开销，适合带宽有限的设备（如传感器、嵌入式设备）。

(2)发布 / 订阅模式：消息的发送者（发布者）与接收者（订阅者）完全解耦，无需直接交互，通过 “主题” 关联，灵活性高。

(3)支持不同服务质量（QoS）：根据场景需求选择消息可靠性等级，平衡性能与可靠性。

(4)低功耗：协议设计简洁，减少设备计算与通信消耗，适合电池供电的物联网设备。

(5)基于 TCP：依赖 TCP/IP 提供可靠传输（确保消息不丢失、按序到达），也可通过 SSL/TLS 加密保障安全。

客户端（Client）

     MQTT 中的 “客户端” 是指通过网络连接到 MQTT 服务器（Broker）的终端设备或应用程序，是 MQTT 通信的发起者和参与者。

• 核心作用：客户端可以同时扮演两种角色 ——

  • 发布者（Publisher）：向服务器发送消息（“发布” 动作）；
  • 订阅者（Subscriber）：从服务器接收消息（需先执行 “订阅” 动作）。
    （一个客户端可同时发布和订阅，例如传感器既发布数据，也订阅控制指令。）

• 类型：包括物联网设备（如传感器、摄像头）、移动应用、后端服务等，只要能通过 TCP/IP（或 WebSocket）连接服务器并遵循 MQTT 协议格式，都可称为客户端。

• 特点：客户端主动发起连接（服务器被动监听连接），连接后通过 “发布” 和 “订阅” 与服务器交互。

服务器（Server / Broker）

      MQTT 服务器（通常称为 “Broker”）是整个通信的核心中间件，负责协调客户端之间的消息传递。

• 核心作用：

  • 接收客户端的连接请求，管理连接状态；
  • 接收客户端发布的消息，根据 “订阅关系” 将消息路由到对应的订阅者；
  • 存储临时消息（如未确认的消息、保留消息），并处理消息的 QoS（服务质量）保证；
  • 管理客户端的会话状态（如未完成的消息确认、订阅关系等）。

• 特点：服务器不生产消息，也不消费消息，仅负责 “转发和管理”，实现发布者与订阅者的 “解耦”（发布者无需知道订阅者的存在，反之亦然）

消息（Information）

     “消息” 是 MQTT 中传递的数据载体，由发布者产生，通过服务器路由到订阅者。

• 结构：消息本身不包含 “发送者” 或 “接收者” 信息，核心组成包括：

  • 主题（Topic）：字符串（如device/123/data），用于标识消息的类别，是服务器路由的核心依据（类似 “地址”）；
  • 负载 (Payload)：实际的数据内容（如 JSON 字符串、二进制数据等），协议对 Payload 格式无限制；
  • 附加标志：QoS、保留消息标志（Retain）、重复发送标志（Dup）等，用于控制消息传递行为;

• 分类：

  • 普通消息：仅在发布时被转发给当前订阅者；
  • 保留消息（Retained Message）：服务器会存储该消息，当新客户端订阅匹配主题时，服务器会立即将该保留消息推送给它;

会话（session）

     会话” 是客户端与服务器之间在连接期间（及断开后）维护的 “状态信息集合”，用于保证消息传递的可靠性（尤其在重连场景）。

• 存储的信息：

  • 客户端未确认的消息（如 QoS 1/2 中未收到 ACK 的消息）；
  • 订阅关系（仅 “持久会话” 保留，“临时会话” 不保留）；
  • 未发送给客户端的消息（如客户端离线时，服务器为持久会话暂存的消息）。

• 生命周期：

  • 由客户端连接时的 “Clean Session” 标志（MQTT 3.1.1）或 “Clean Start” 标志（MQTT 5.0）决定：
  • 若为Clean Session = true（临时会话）连接断开后，服务器会删除该会话的所有状态；
  • 若为Clean Session = false（持久会话）连接断开后，服务器会保留会话状态，直到客户端重连（使用相同 Client ID）后恢复会话。

• 作用：通过会话状态的维护，确保客户端在重连后能继续处理未完成的消息（如重新接收未确认的消息），或恢复之前的订阅关系。

报文（Message）

      MQTT 协议的所有通信都通过标准化的报文（Message） 完成，这些报文采用二进制格式编码，结构紧凑、开销小，适合低带宽、高延迟的网络场景（如物联网设备通信）。MQTT 报文的核心特点是：按功能分类（如连接、发布、订阅等），每种报文有固定的格式和用途。以下从 “通用结构” 和 “具体报文类型” 两方面详细介绍。

固定头（Fixed Header）

      固定头是所有报文的 “基础标识”，结构如下：

报文类型(4 位):用 0-15 的数值表示 14 种报文类型。

标志位(4 位):仅部分报文使用（如 PUBLISH 的 QoS、Retain、Dup 标志），其他报文的标志位需设为 0（否则服务器可能拒绝）。

 剩余长度(Remaining Length):表示 “可变头 + 有效载荷” 的总字节数，采用 “可变长度编码”（1-4 字节）。

可变头（Variable Header） 

     可变头的内容因报文类型而异，核心作用是补充该报文的关键参数。常见的可变头信息包括：

Packet ID(报文标识符):16位无符号整数，用于标识需要确认的报文（如 QoS 1/2 的 PUBLISH、SUBSCRIBE、PUBACK 等）,确保消息交互的顺序和可靠性（同一会话内 Packet ID 唯一）。

主题名(Topic Name):PUBLISH 报文的可变头包含消息对应的主题（字符串，如sensor/temp）。

协议名 / 版本：CONNECT 报文的可变头包含 MQTT 协议名（如 “MQTT”）和版本号（3.1.1 对应 4）。

有效载荷（Payload）

       有效载荷是报文的 “实际数据”，仅部分报文需要。例如：PUBLISH 的有效载荷是消息内容（Payload，如 “25℃”）；CONNECT 的有效载荷包含客户端 ID、用户名、密码、Will 消息等；SUBSCRIBE 的有效载荷包含订阅的 “主题过滤器 + QoS” 列表。

各类报文详解

(1) CONNECT报文

 固定头

    固定头是所有 MQTT 控制报文的基础结构，CONNECT 报文的固定头包含 2 个关键字段：

可变头

    可变头包含连接建立的核心配置信息，是 CONNECT 报文的 “控制中枢”，主要字段如下：

有效载荷

    有效载荷包含连接所需的具体数据（如身份标识、认证信息、遗嘱内容等），其字段是否存在由连接标志控制（即 “标志位为 1 时，对应字段必须存在”）。主要字段如下：

(2) CONNACK 报文

固定头

   同上，标识报文类型和剩余长度。

可变头

(1)连接确认标志

(2)返回码

有效载荷

(3) PUBLISH报文

固定头

可变头

有效载荷

(4) PUBACK /PUBREC/ PUBCOMP 报文

     在 MQTT 协议中，客户端发送PUBLISH报文后，服务器是否返回响应以及返回何种报文，完全取决于该PUBLISH报文的 QoS（服务质量）等级。QoS 等级决定了消息传递的可靠性和确认机制：

QoS 0（最多一次）

客户端行为：
客户端发送PUBLISH报文后，不等待服务器确认，立即认为消息发送成功。

服务器行为：
不返回任何响应。服务器收到消息后直接转发给订阅者，不向发布者确认。

特点：
消息可能丢失（如网络故障），但传输效率最高（无往返确认）。

QoS 1（至少一次）

客户端行为：
客户端发送PUBLISH报文后，等待服务器返回PUBACK报文。若超时未收到确认，客户端会重发PUBLISH（使用相同的 Packet Identifier）。

服务器行为：
返回PUBACK报文（固定头类型为0x04），其中包含与收到的PUBLISH相同的 Packet Identifier，表明已接收消息。

特点：
消息不会丢失，但可能重复（如网络延迟导致客户端重发）。

PUBACK报文

固定头

控制报文类型：
PUBACK 的类型值为0x04（二进制0100），高 4 位表示报文类型，低 4 位固定为0000（保留位）。

剩余长度：
固定为2字节（因为可变头长度固定为 2 字节）。

可变头

仅包含一个字段：Packet Identifier（报文标识符）。占用2 字节，无符号整数。该标识符与客户端发送的 QoS 1 级 PUBLISH 报文中的 Packet Identifier 完全一致，用于客户端将 PUBACK 与对应的 PUBLISH 请求关联。（例如，客户端发送 PUBLISH（Packet ID=1234），则服务器返回的 PUBACK 中 Packet ID 也为 1234）。

原因码

1 字节，指示 PUBLISH 处理结果。

0x00（Success）：消息已接收。

0x80（Malformed Packet）：报文格式错误。

0x83（Topic Name Invalid）：主题名非法。

0x87（Packet Identifier In Use）：Packet ID 已被使用。

其他错误码（如权限不足、服务器忙等）。

属性

变长字段，包含额外元数据（如响应主题、用户属性等）。

QoS 2（恰好一次）

客户端行为：

发送PUBLISH报文（QoS=2），并等待服务器返回PUBREC报文。

收到PUBREC后，发送PUBREL报文（释放消息），并等待服务器返回PUBCOMP。

收到PUBCOMP后，确认消息已成功传递。

服务器行为：

收到PUBLISH后，返回PUBREC（固定头类型0x05），表示已接收并处理。

收到客户端的PUBREL后，返回PUBCOMP（固定头类型0x07），表示消息已完全处理。

特点：
通过四次握手（PUBLISH → PUBREC → PUBREL → PUBCOMP）确保消息仅传递一次，无丢失或重复。

                                                 PUBREL报文

固定头

控制报文类型与标志位：1 字节

高 4 位：控制报文类型（0110，对应类型值 6，代表 PUBREL）；

低 4 位：标志位（0010），其中：

bit3（最高位）：0

该位为保留位，必须始终设置为 0，不可用于其他用途。

bit2：0

同样是保留位，强制为 0，无实际功能。

bit1：1

该位是 PUBREL 报文的唯一有效标志，表明这是 QoS 2 流程中的释放阶段。

bit0（最低位）：0

保留位，必须置 0。

可变头

    仅包含数据包标识符（Packet Identifier），为 2 字节（16 位）整数，用于匹配对应的 QoS 2 PUBLISH报文（需与PUBLISH、PUBREC、PUBCOMP的标识符一致）。规则：同一客户端连接中，标识符需唯一，直到该 QoS 2 流程完成释放Packet ID。

                                                           PUBCOMP报文

固定头

控制报文类型：

PUBCOMP 的类型值为0x07（二进制0111），高 4 位表示报文类型，低 4 位固定为0000（保留位）。

剩余长度：

可变头

      Packet Identifier（报文标识符）：占用2 字节，无符号整数。该标识符与客户端发送的 PUBREL 报文中的 Packet Identifier 完全一致，用于客户端将 PUBCOMP 与对应的 PUBREL 请求关联。

      Reason Code（原因码，MQTT 5.0 新增）：占用1 字节，指示 PUBREL 处理结果。常见值：

0x00（Success）：消息已成功处理。

0x92（Packet Identifier Not Found）：Packet ID 未找到（可能因服务器重启导致状态丢失）。

(5) SUBSCRIB报文

     SUBSCRIBE 报文由客户端发送至服务器，用于订阅一个或多个主题，并指定每个主题的 QoS 等级。其结构如下：

固定头

可变头

有效载荷

     SUBSCRIBE 报文的有效载荷（Payload） 是核心数据部分，用于指定客户端希望订阅的主题过滤器（Topic Filter） 列表及对应的服务质量等级（QoS）。其结构设计支持一次订阅多个主题，格式紧凑且灵活。

(6) SUBACK报文

   SUBACK报文是服务器对客户端SUBSCRIBE请求的确认，用于告知客户端每个订阅请求的处理结果（成功、失败或受限）。

固定头

可变头

有效字段

Zigbee协议

      Zigbee 是一种基于 IEEE 802.15.4 标准的低速率、低功耗、短距离无线通信协议，主要用于设备间的低成本、低复杂度组网，尤其适合需要大规模设备协同的场景（如智能家居、工业传感器网络等）。其名称源自 “蜜蜂跳 Zigzag 舞传递信息”，象征着协议的 “低功耗、小数据量、多节点协同” 特性。

物理层是协议栈的最底层，直接与硬件（射频芯片）交互，核心功能是 “实现无线信号的发送与接收”，定义了无线通信的物理参数。

物理层

     频段与信道选择：支持全球主流免授权频段（不同地区略有差异）：2.4GHz 频段（全球通用）：共 16 个信道（信道 11-26），传输速率最高250kbps（Zigbee 的主流频段）；868MHz 频段（欧洲）：1 个信道，速率 20kbps；915MHz 频段（美洲）：10 个信道，速率 40kbps。

     信号调制与解调：将 MAC 层传来的数字信号（帧）转换为射频模拟信号（发送），或反之（接收），采用O-QPSK 调制技术（2.4GHz 频段），确保低功耗和抗干扰性。

      射频参数控制：调节发射功率（1-7dBm，对应通信距离 10-100 米）、接收灵敏度（-90dBm 以下，确保弱信号可识别），平衡通信距离与功耗。

     低功耗控制：支持 “休眠 - 唤醒” 模式，闲置时关闭射频模块，仅在需要传输时激活，是 Zigbee 终端设备 “长续航” 的核心保障。

介质访问控制层（MAC Layer）

    介质访问控制：采用CSMA/CA（载波侦听多路访问 / 冲突避免） 机制 —— 设备发送数据前先 “侦听” 信道：若信道空闲则发信，若繁忙则等待随机时间后重试，从根源减少冲突（区别于 Wi-Fi 的 CSMA/CD，Zigbee 因低功耗不支持冲突检测）。

      帧处理：封装：将网络层传来的 “数据载荷” 加上 MAC 帧头（包含源 / 目的地址、帧类型）和帧尾（校验码 FCS），形成完整 MAC 帧；

     解析：接收物理层传来的信号，校验帧完整性（FCS 校验），剥离 MAC 头后将有效数据传给网络层。

    地址管理：支持两种地址格式，适配不同组网规模：64 位扩展地址（全球唯一，类似设备的 “身份证”，由芯片厂商分配）；16 位短地址（网络内临时分配，如协调器给终端分配的 “局域网地址”，减少帧长度以降低功耗）。

     安全初始化：提供底层安全支持，如 AES-128 加密的帧加密、身份认证，为上层安全（如网络层加密）奠定基础。

    关键交互：通过 “PHY-SAP” 与物理层通信，通过 “MAC-SAP” 与网络层通信。

MAC 层：负责每一跳的物理链路级确认（如节点 A→B、B→C 的逐跳 ACK）；

网络层：处理端到端的逻辑链路确认（如源节点 A 到目的节点 D 的整体传输确认）。

这种分层设计既保证了单跳传输的可靠性，又避免了网络层因频繁确认而增加的功耗和延迟。

网络层（NWK Layer）

     网络层是 Zigbee区别于其他短距离协议的关键，负责 “网络的建立、维护和路由管理”，实现多设备的灵活组网（星型、树形、Mesh）。

     网络初始化与管理：仅PAN 协调器可执行：创建网络（分配唯一的 “PAN ID”，即个人区域网标识）、设定网络参数（如信道、加密方式）；

   管理设备接入：验证新设备的接入请求，分配 16 位短地址，记录设备角色（路由器 / 终端）。

    拓扑结构维护：星型：协调器直接连接所有终端，网络层仅需维护 “协调器 - 终端” 的链路；树形 / Mesh：路由器可转发数据，网络层需维护 “邻居表”（记录周边设备信息）和 “路由表”（规划数据传输路径），支持 “自组网” 和 “自愈”（某设备故障时，自动重新规划路由）。

    路由算法：默认采用AODVjr（Ad-hoc 按需距离矢量路由简化版） —— 仅在需要传输数据时，临时计算从源设备到目的设备的最优路径（减少路由维护的功耗），适配 Mesh 拓扑的灵活性需求。

    跨层优化：与 MAC 层、物理层协作，比如根据信道质量动态调整传输参数（如重传次数、发射功率），平衡通信稳定性与功耗。

协调器（Coordinator）

      网络的 “创始者” 和 “管理者”，是整个 ZigBee 网络的核心。每个网络只能有一个协调器，通常由全功能设备（FFD）担任。负责，网络初始化：选择通信信道（如 2.4GHz 频段的 11-26 信道）和唯一的 PAN ID，启动网络；地址分配：为新加入的路由器和终端设备分配 16 位短地址，确保网络内地址唯一性；网络维护：管理设备关联 / 解关联请求，维护路由表，并作为信任中心管理网络安全（如加密密钥分发）；数据中转：为休眠的终端设备缓存数据，待其唤醒后转发。需持续供电（如市电），具备较强的计算和存储能力，支持与外部网络（如 Wi-Fi、以太网）通过网关连接。

路由器（Router）

    网络的 “中继站” 和 “扩展器”，负责数据转发和网络覆盖扩展，同样由 FFD 担任。数据路由：通过 AODVjr 或 Cluster-Tree 路由协议，为多跳通信提供路径选择，确保数据从源节点到目的节点的可靠传输；设备接入：允许其他路由器或终端设备通过自身加入网络，扩展网络规模；数据缓存：为关联的休眠终端设备暂存数据，等待其唤醒后提取。硬件特性：需持续供电（如市电或大容量电池），具备稳定的无线信号收发能力，通常部署在网络边缘以扩大覆盖范围。

 终端设备（End Device）

     网络的 “感知者” 和 “执行者”，通常由精简功能设备（RFD）担任，专注于数据采集或控制执行。核心功能：数据交互：通过父设备（协调器或路由器）发送传感器数据（如温湿度、光照强度）或接收控制指令（如开关灯、调节阀门）；低功耗休眠：在非活跃期进入深度休眠状态，仅在预设周期（如 10 秒）唤醒与父设备通信，显著降低能耗。硬件特性：资源有限（如低性能 MCU、小容量内存），支持电池供电（如 CR2032 纽扣电池），典型应用包括传感器、智能开关等。

应用层（APL Layer）

 端点

      Endpoint（端点） 是实现设备 “多功能协同” 与 “精准通信” 的核心逻辑标识。简单来说，它是设备上不同应用功能的 “数字标签”，用于区分同一物理设备内的多个独立功能模块（如智能灯的 “开关控制” 和 “亮度调节”），确保数据能准确传递到目标功能。Endpoint 用 8 位二进制数表示（范围 0~255），但不同编号段有严格的协议规定，不可混用：

cluster通讯模型

      Cluster 模型通过标准化命令、属性和交互逻辑，解决了不同厂商设备的 “通信语言障碍”，是 ZigBee 协议支持 “跨品牌、多功能协同” 的核心机制，也是智能家居、工业物联网等场景中设备联动的基础。

     luster 通信的典型流程（以 “开关控制灯” 为例）:

通信前准备：

    智能灯的 Endpoint 1 声明支持 “On/Off Input Cluster（0x0006）”，并注册了On/Off命令的处理函数；智能开关的 Endpoint 1 声明支持 “On/Off Output Cluster（0x0006）”，具备发送On/Off命令的能力；开关通过 ZDO（Endpoint 0）的绑定功能，与灯建立关联（记录灯的地址、Endpoint 和 Cluster 信息。

发送命令

    用户按下开关的 “开” 按钮，开关的 Endpoint 1 通过 “On/Off Output Cluster” 构建On命令帧（包含 Cluster ID 0x0006）；命令帧附加目标信息：设备地址（0x0005）、目标 Endpoint（1），通过网络层发送。

接收与执行

    智能灯接收命令帧，通过地址确认 “发给自己”，通过 Endpoint 1 找到对应的功能模块；功能模块解析 Cluster ID（0x0006），确认是 “On/Off Input Cluster”，调用On命令的处理函数（如接通电路）；灯执行后，通过 “On/Off Input Cluster” 的属性（如OnOff状态）更新为 “1（开）”，并可主动上报状态给开关。

属性读写

     开关可通过 “On/Off Cluster” 的Read Attribute命令，查询灯的OnOff属性（确认是否已打开）；灯通过Attribute Report命 令，主动上报状态变化（如被手动关闭时，通知开关）。

联网过程

阶段 1：协调器建网（Coordinator Forms Network）

     ZigBee 网络由协调器（Coordinator） 唯一创建，建网时需确定网络的核心参数（图中左侧 “Four parameters of a network”）：协调器通过 “Form network” 动作完成建网，随后持续发送Beacon（信标帧），向周围广播 “本网络可接入” 的信号。

阶段 2：设备发现网络（Device Discovers Network）

      新设备（如传感器、智能灯）需主动扫描周围可接入的 ZigBee 网络，流程如下：发送 Beacon Request：设备在所有可能的 ZigBee 信道（如 11-26）上广播 “Beacon 请求”，询问 “哪些网络可加入？”；接收 Beacon：协调器（或已存在的路由器）回复 Beacon，包含网络的 PAN ID、Extended PAN ID、信道等信息；选择最优网络：设备可能收到多个网络的 Beacon（如附近有多个 ZigBee 网络），需通过RSSI（信号强度） 选择信号最好的网络（图中 “Choose the one with best RSSI”）。

阶段 3：关联请求与接入（Association Request & Response）

      设备选定目标网络后，需向协调器发送 “关联请求”，申请正式加入：Association Request：设备向协调器发送请求，包含自身能力（如是否支持路由、功耗类型）；Association Response：协调器审核请求（如验证设备合法性、检查地址资源），若通过则回复响应，包含设备的16 位短地址（Node ID）（图中 “Got node ID”），相当于给设备分配 “网络内身份 ID”。

阶段 4：密钥传输与加密（Transport NWK Key）

      为保障网络安全，协调器需向设备下发NWK 密钥（网络层加密密钥），用于后续数据加密：协调器使用 “已知链路密钥（well-known link key）” 加密 NWK 密钥后发送给设备（图中 “Encrypted with well-known link key”）；设备解密后获得 NWK 密钥（图中 “Got NWK key”），此后设备与网络的通信均通过该密钥加密，防止数据被窃听。

本文标签： 学习笔记 协议