简介：这份资源面向物联网初学者与嵌入式开发者，提供一套基于ZIGBEE协议栈的无线温湿度采集系统完整工程，用于解决短距离低功耗环境监测中数据采集与无线组网的实际问题，可服务于农业大棚、仓储管理、智能家居等场景的入门实践与二次开发。压缩包共637个文件、约26.18MB，以125个r51与125个s51编译中间文件、122个lst列表文件、107个头文件和81个C源文件为主体，另含dll、lib库文件及少量工程配置与说明文档，覆盖协议栈各层源码与构建产物，便于对照阅读网络层、应用层实现。目前已有1316人学习下载。读者可从中获得DHT10传感器驱动、ZIGBEE节点组网与协调器数据汇聚的完整代码框架，理解物理层到应用层的分层结构，并借助工程文件直接编译调试，为搭建分布式温湿度监控方案提供可复用的参考。
1. 温湿度采集为什么不能只靠“轮询”：ZigBee 协议栈到底在解决什么
一个温湿度节点，硬件上无非是传感器加射频芯片，看起来简单得不像值得写协议栈的东西。但真把几十个节点撒进一栋楼里，问题立刻变味：谁先发、发多久、撞了怎么办、路由断了怎么绕、电池怎么撑过一年。这些不是硬件能回答的，是协议栈要回答的。ZigBee 协议栈的核心价值，恰恰在于它把“多个低功耗节点如何有序共享一个无线信道”这件事，拆成了物理层、MAC 层、网络层、应用支持子层四层职责，让温湿度这种小数据包能在不牺牲功耗的前提下可靠送达。搞懂这套分层，你才知道为什么采集周期设成 30 秒而不是 3 秒，为什么协调器一挂全网就瘫，为什么有的节点明明在线却收不到数据。
2. 分层不是摆设：ZigBee 协议栈的四层职责怎么切
2.1 从射频到应用：每一层到底替谁挡了什么
ZigBee 协议栈建立在 IEEE 802.15.4 之上，这个底层标准只定义了物理层（PHY）和媒体访问控制层（MAC），负责 2.4GHz 频段的调制、信道选择、CSMA/CA 载波侦听和 16 位短地址分配。再往上，ZigBee 联盟补了网络层（NWK）和应用支持子层（APS），应用层（AF）才是用户代码待的地方。
这个切法的动机很直接：802.15.4 只管“一跳到下一跳怎么发出去”，不管“多跳怎么到”。温湿度节点往往不在协调器射频范围内，必须靠中间节点转发，这就是网络层存在的理由。网络层维护路由表、处理路由发现、管理邻居表，还负责地址分配——协调器给每个入网设备发一个 16 位网络地址，这个地址和 64 位 MAC 地址是两套体系，前者用于路由，后者用于身份。
APS 层则解决“一个节点上跑多个应用”的问题。一个温湿度节点可能同时上报温度和湿度两个端点（Endpoint），APS 用端点号区分它们，还提供绑定表——把某个端点直接绑到另一个设备的端点，之后发数据不用再写目标地址。常见的实现思路是：绑定表存在协调器或父节点上，源节点只管往绑定表里查，查到了就发，省去每次组包填地址的开销。
我一般会这么理解这四层：PHY/MAC 是“怎么把比特推出去”，NWK 是“怎么找到路”，APS 是“怎么区分谁的数据”，AF 是“数据长什么样”。温湿度采集的整个链路，就是传感器读数从 AF 往下逐层封装，每层加自己的头，到射频发出去；接收端逐层剥头，最后把载荷交给应用。
2.2 帧结构里的隐藏成本：为什么小数据包也有开销
一个温湿度读数可能只有 4 个字节（温度 2 字节、湿度 2 字节），但实际空口传输的帧远不止这些。以典型的 ZigBee 应用帧为例，从 MAC 头到 NWK 头再到 APS 头，每层都要加地址、序列号、控制字段。MAC 头在启用安全时可能到 20 多字节，NWK 头 8 字节左右，APS 头 8 字节左右，加上载荷和 MAC 尾的 FCS，一帧轻松超过 40 字节。
这意味着什么？意味着你设的采集周期不能只看传感器转换时间，还要看空口占用时间。2.4GHz 下 250kbps 的理论速率，传 40 字节大约 1.3 毫秒，看似不多，但几十个节点在同一信道竞争，CSMA/CA 的退避窗口会把这些毫秒放大成几十甚至上百毫秒的延迟。血泪经验是：采集周期设得太密，节点不是“发不出去”，而是“一直在退避”，功耗反而飙升。
/* 典型的应用层发送请求结构（简化示意，非特定厂商API） */ typedef struct { uint8_t dstEndpoint; /* 目标端点号，区分温度/湿度等应用 */ uint16_t dstShortAddr; /* 网络层短地址，路由用 */ uint16_t clusterId; /* 簇ID，标识数据类型，如温度测量簇 */ uint8_t srcEndpoint; /* 源端点号 */ uint8_t payloadLen; /* 载荷长度，温湿度通常4字节 */ uint8_t payload[16]; /* 实际数据 */ uint8_t radius; /* 最大跳数，防止路由环路 */ } app_send_req_t;这段结构里，clusterId是关键参数——ZigBee 用簇（Cluster）来约定数据语义，温度测量簇和湿度测量簇各有固定 ID，接收端靠它判断载荷该怎么解析。radius限制最大转发跳数，设太小远端节点到不了，设太大路由环路时帧会在网里打转。payloadLen直接决定空口占用，温湿度场景下没必要把整个传感器寄存器 dump 出去，只传换算后的值即可。
2.3 地址与路由：16 位短地址背后的分配逻辑
协调器上电后先选信道、建网，拿到一个 PAN ID，然后开始接受入网请求。设备入网时，协调器或路由器按分布式地址分配方案给它分一个 16 位短地址。常见的实现思路是：每个父节点维护一个地址池，按子节点类型（路由器/终端）划分子网段，路由器分到的地址段还能继续往下分，终端设备只拿单个地址不分段。
这个设计的动机是让路由可以“算”出来而不是“查”出来——在树形路由下，知道目标短地址就能推断它在哪棵子树，往哪个方向转发。但树形路由的短板很明显：一旦某个中间路由器掉电，它下面整棵子树的节点全部失联，因为路由路径被物理切断。所以实际部署里往往启用网状网（Mesh）路由，节点间维护邻居表和路由表，路由发现时广播路由请求（RREQ），目标回路由应答（RREP），中间节点缓存转发路径。
对温湿度采集来说，这个区别很实际：如果节点是电池供电的终端设备（End Device），它大部分时间休眠，只定期唤醒上报，那它不适合做路由器，因为休眠时无法转发别人的数据。网络里必须保证有足够多的常供电路由器（通常是市电供电的节点）撑起骨干，否则远端终端设备的路由会频繁失效。踩坑最多的地方就在这里——有人把所有节点都配成终端设备省电，结果网络深度一增加，路由发现成功率断崖式下跌。
3. 采集链路怎么跑通：从传感器读数到协调器入库的完整时序
3.1 入网与绑定：数据还没发，关系先建好
温湿度节点上电后的第一件事不是采集，是入网。它扫描信道、发信标请求、选一个父节点、发关联请求，父节点分配短地址，入网完成。这一步的耗时取决于信道拥挤程度和父节点响应速度，常见在几百毫秒到几秒之间。入网成功后，节点才拿到自己的网络地址，才能参与路由。
接下来是绑定。如果采用绑定方式上报，协调器上的应用要先创建一个绑定表项，把源节点的端点、簇 ID 和目标端点关联起来。之后源节点发数据时，APS 层查绑定表自动填目标地址，应用代码不用关心协调器地址是多少。这个机制的好处是解耦——协调器换地址或换设备，只要绑定表更新，源节点代码不动。
但绑定表存在哪里很关键。存在协调器上，源节点每次发数据前要发绑定查询，多一次往返；存在源节点自己上，协调器要提前把绑定信息下发过去。常见的实现思路是协调器集中管理绑定表，因为协调器常供电、存储大，源节点省内存。代价是绑定查询增加了延迟，对温湿度这种低频上报影响不大，但对实时性要求高的场景就得权衡。
3.2 上报时序：一次温湿度数据要经过几次握手
假设节点已入网、绑定已建立，一次完整上报的时序大致是：应用层组包（温度值、湿度值、时间戳可选）→ APS 加头（源/目标端点、簇 ID）→ NWK 加头（源/目标短地址、跳数、序列号）→ MAC 加头（PAN ID、序列号、帧控制）→ PHY 调制发送。接收端反向剥头，协调器应用层拿到载荷，解析出温湿度值，写入本地存储或转发给上位机。
如果启用了确认机制（APS Ack），接收端在 APS 层回一个确认帧，源节点收到确认才认为发送成功，否则重试。这个确认是端到端的，跨多跳也有效，比 MAC 层的单跳确认更可靠。代价是每次上报多一个确认帧的空口开销，对电池节点来说，这个开销在低占空比下可以接受，但如果采集频率高，确认帧的能耗会累积。
/* 上报流程的伪代码，体现层次调用关系 */ void report_temperature_humidity(void) { uint8_t payload[4]; int16_t temp = read_sensor_temp(); /* 单位0.01摄氏度 */ uint16_t humi = read_sensor_humi(); /* 单位0.01%RH */ payload[0] = temp & 0xFF; payload[1] = (temp >> 8) & 0xFF; payload[2] = humi & 0xFF; payload[3] = (humi >> 8) & 0xFF; app_send_req_t req = { .dstEndpoint = 1, /* 协调器上的数据接收端点 */ .dstShortAddr = 0x0000, /* 协调器短地址固定为0 */ .clusterId = 0x0402, /* 温度测量簇示例ID */ .srcEndpoint = 1, .payloadLen = 4, .radius = 5 /* 允许最多5跳 */ }; memcpy(req.payload, payload, 4); /* 阻塞等待确认，实际产品中应改为异步回调 */ if (af_send(&req, APS_ACK_ENABLE) == SUCCESS) { enter_sleep(SLEEP_MS); /* 发送成功，休眠到下一个周期 */ } else { retry_count++; if (retry_count > MAX_RETRY) { rejoin_network(); /* 多次失败，重新入网 */ } } }这段代码里几个参数值得展开。dstShortAddr = 0x0000是 ZigBee 的约定，协调器短地址固定为零，所有节点都知道往零地址发就是发给协调器。clusterId用温度测量簇的示例 ID，实际项目里要按 ZigBee 簇库规范选，选错了接收端解析会错位。radius = 5是经验值，网络深度一般不超过 5 到 7 跳，设太大对路由环路没有保护作用，设太小远端节点直接丢包。APS_ACK_ENABLE打开端到端确认，代价是功耗，收益是可靠性，温湿度场景通常值得开。
3.3 休眠与唤醒：电池节点的时间账怎么算
电池供电的温湿度节点，功耗大头不是传感器，是射频。传感器转换一次可能几毫秒、几毫安，射频发一帧虽然只有毫秒级，但电流能到几十毫安。所以省电的核心是让射频尽可能少开、开的时间尽可能短。
典型的低功耗时序是：休眠定时器到期 → 唤醒 MCU → 读传感器 → 组包发送 → 等确认 → 回休眠。整个唤醒窗口如果能压到几十毫秒，占空比就极低，电池寿命按年算。但这里有个玄学：等确认的时间不好估。如果父节点忙、信道挤，确认可能几百毫秒才回来，这段时间射频一直开着接收，功耗就上去了。
常见的实现思路是给确认设超时，超时就重试或直接休眠下次再说，不无限等。另一个技巧是让终端设备采用“间接发送”——数据先发给父节点，父节点缓存，终端设备休眠后由父节点代为转发给协调器。这样终端设备发完就能睡，不用等端到端确认。代价是父节点要占缓存，缓存满了会丢数据，所以父节点的缓存深度要按子节点数量和上报频率算。
4. 避坑与排查：温湿度采集链路上最容易翻车的几个点
4.1 现象：节点显示在线，协调器收不到数据
原因通常是绑定表或端点配置不一致。源节点往端点 1 发，协调器应用只监听了端点 2，数据到了 APS 层就被丢弃，网络层看起来一切正常。排查方法是抓空口包看 APS 头的目标端点号，和协调器注册的端点比对。解决方式是统一端点号约定，或者在协调器上注册通配端点。
4.2 现象：网络运行几小时后大面积丢包
原因多半是路由表老化或邻居表溢出。Mesh 网络里节点移动、信号波动会导致路由表项失效，但表项不会立刻删除，过期路由被继续使用就丢包。排查看路由表条目数和老化时间配置。解决方式是缩短路由老化时间、增加路由维护频率，或者对固定部署的场景改用树形路由加静态路由表，减少动态发现的开销。
4.3 现象：电池寿命远低于预期
原因往往是休眠没真正睡下去，或者射频接收窗口过长。有些协议栈实现里，终端设备入网后仍周期性开接收窗口听信标，这个窗口如果设得宽，功耗就下不来。排查用电流表看休眠电流，正常应在微安级，如果到毫安级说明没睡透。解决方式是确认休眠模式配置、关闭不必要的信标监听、把确认等待改成异步不阻塞。
4.4 现象：新节点入网失败，反复重试
原因可能是地址池耗尽或父节点满载。协调器的分布式地址分配有上限，子节点数量超了就不再分配。排查看协调器的地址分配表和子节点数。解决方式是增加路由器节点分担子节点、调整地址分配参数扩大子网段，或者清理长期离线的僵尸表项。
提示：抓空口包是排查 ZigBee 问题最有效的手段，比在应用层打日志快得多。看 MAC 序列号能判断重传，看 NWK 跳数能判断路由路径，看 APS 确认能判断端到端是否送达。
5. 设计取舍：为什么温湿度采集不该追求“全功能协议栈”
ZigBee 协议栈功能很全，路由、绑定、安全、组播都有，但温湿度采集这个场景其实用不到大半。全功能协议栈的代码体积、RAM 占用、入网时间都更高，对低成本节点是负担。我见过不少项目一开始上全套，后来发现节点 flash 不够、电池撑不住，又回头裁剪。
裁剪的边界在哪？我的经验是：如果网络规模小于 20 个节点、拓扑固定、协调器常供电，树形路由加简单绑定就够了，不需要 Mesh 的动态路由发现，省下的路由表和发现开销很可观。如果节点会移动或中间路由器可能掉电，那 Mesh 的路由自愈能力就值得保留，但可以把路由发现频率调低，用被动维护代替主动探测。
安全机制也是取舍点。ZigBee 支持网络层和应用层加密，温湿度数据敏感度不高，很多项目只开网络层加密防止外部设备随意入网，应用层加密关掉省 CPU 和功耗。但如果数据要出网关上传，网关侧再做一次加密更合适，节点侧不必承担。
| 取舍维度 | 全功能方案 | 裁剪方案 | 适用判断 |
|---|---|---|---|
| 路由方式 | Mesh 动态发现 | 树形加静态表 | 拓扑是否固定 |
| 确认机制 | 端到端 APS Ack | 仅 MAC 层 Ack | 数据可容忍丢失否 |
| 安全层级 | 网络层加应用层 | 仅网络层 | 数据敏感度 |
| 休眠策略 | 信标同步休眠 | 定时唤醒加间接发送 | 父节点缓存是否充足 |
验证裁剪是否安全，最直接的办法是做压力测试：把节点数加到设计上限的 1.5 倍，连续跑 72 小时，统计丢包率和平均功耗。丢包率超过阈值或者功耗超标，说明裁过头了，得把某项功能加回来。这个测试比看文档估算靠谱得多，因为空口环境的干扰、路由收敛的实际耗时，只有跑起来才知道。
从那以后我每次做低功耗无线采集，都强制先画一张时序图，把唤醒、发送、等确认、休眠的时间段标出来，再对着算功耗预算，算不平就不动手写代码。希望帮到你。
本文还有配套的精品资源，点击获取
