STM32与Zigbee智能家居环境监测系统实战：硬件选型、软件架构与低功耗优化

1. 项目缘起与整体设计思路

1.1 为什么选STM32加Zigbee这套组合

做智能家居环境监测这个方向，方案其实挺多的。市面上常见的搭配有ESP32加LoRa、ESP8266加WiFi、STM32加蓝牙等等。我当初选STM32加Zigbee，不是拍脑袋决定的，而是从几个实际维度权衡下来的。

先说主控。STM32F103C8T6这颗芯片，72MHz主频、64KB Flash、20KB SRAM，用来跑环境监测这种任务绰绰有余。它的外设资源很规整：多个USART、I2C、SPI、ADC通道，接温湿度传感器、空气质量传感器、OLED屏幕都不需要额外扩展芯片。更关键的是，STM32的生态成熟度极高，HAL库、标准库、LL库三套体系任选，网上能查到的参考资料和踩坑记录远超其他平台。对于需要快速出原型、又要保证稳定性的项目来说，这个选择很务实。

再说通信。Zigbee的核心优势在于自组网和低功耗。WiFi方案虽然带宽大、接入方便，但节点多了之后路由器压力大，而且每个节点都要维持TCP连接，功耗下不来。蓝牙的覆盖范围又太短，穿一堵墙就衰减得厉害。Zigbee用的是IEEE 802.15.4底层协议，2.4GHz频段，支持Mesh拓扑，节点之间可以互相中继，一个协调器带几十个终端节点很轻松。在家庭环境里，穿墙能力比蓝牙强不少，功耗又比WiFi低一个数量级。

注意：Zigbee和WiFi都工作在2.4GHz频段，实际部署时要注意信道错开。WiFi常用1、6、11信道，Zigbee建议选15、20、25这几个信道，减少同频干扰。

1.2 系统架构怎么分层

整个系统我按四层来设计，从下往上依次是感知层、网络层、处理层和应用层。这个分层不是为了好看，而是为了让每一层的职责清晰，调试的时候能快速定位问题出在哪一层。

感知层就是各种传感器和执行器。温湿度用DHT11或者SHT30，空气质量用MQ-135，光照用BH1750，这些都是常见且便宜的选型。执行器方面留了继电器接口，可以接风扇、加湿器之类的设备。

网络层由Zigbee终端节点和协调器组成。每个监测点放一个Zigbee终端节点，负责采集传感器数据并通过无线发给协调器。协调器通过串口和STM32主控连接，把数据汇总上来。

处理层就是STM32主控板。它负责解析协调器发来的数据帧、做阈值判断、驱动本地显示、控制执行器，同时通过另一个串口和上位机通信。

应用层是PC端的监测软件或者手机App。我这边用的是Qt写的上位机，能实时显示数据曲线、设置报警阈值、查看历史记录。

1.3 关键器件的选型对比

选型这块我踩过一些坑，这里把几个核心器件的对比列出来，方便你参考。

这里重点说一下Zigbee模块的选择。CC2530是TI的老牌芯片，Z-Stack协议栈虽然学习曲线陡，但功能完整、稳定性经过大量项目验证。CC2531和CC2530基本一样，只是USB接口的差异。ESP32-C6虽然也支持Zigbee，但生态还在完善中，资料相对少。对于第一次做Zigbee项目的朋友，我还是推荐CC2530。

2. 硬件电路设计与核心细节

2.1 STM32最小系统的搭建要点

STM32最小系统看着简单，但有几个地方不注意就会出问题。我第一版板子打回来之后，发现MCU时不时复位，查了半天才发现是复位电路的问题。

复位电路用经典的RC加按键方案：10K上拉电阻接VCC，100nF电容接地，并联一个复位按键。这个组合能保证上电时复位引脚有足够长的低电平时间，让MCU完成初始化。电容别用太小，我试过用10nF，结果上电复位不稳定，偶尔会跑飞。

晶振电路是另一个容易翻车的地方。STM32F103外部高速晶振用8MHz，两个负载电容一般选20pF。但实际值要根据晶振的负载电容参数来算，公式是：CL = (C1 * C2) / (C1 + C2) + Cstray，其中Cstray是PCB走线的寄生电容，一般取3到5pF。如果晶振规格书上写负载电容是12pF，那C1和C2大概取18到22pF。我实测下来，20pF配大多数8MHz晶振都能稳定起振。

提示：PCB布局时晶振要尽量靠近MCU的OSC引脚，走线要短且包地处理。晶振下面不要走其他信号线，否则容易引入干扰导致起振困难。

BOOT引脚的处理也别忘了。BOOT0接10K下拉电阻到地，BOOT1接10K下拉到地，这样默认从Flash启动。如果要串口下载程序，把BOOT0跳线到VCC，下载完再跳回来。

2.2 Zigbee终端节点的电路设计

Zigbee终端节点以CC2530为核心，外围电路比STM32简单不少。CC2530内部集成了8051内核和2.4GHz射频收发器，只需要加晶振、天线匹配网络和少量去耦电容就能工作。

晶振方面，CC2530需要两个晶振：32MHz的高速晶振用于射频和CPU，32.768kHz的低速晶振用于睡眠定时器。32MHz晶振的负载电容一般选10pF到15pF，具体看晶振规格。低速晶振不是必须的，但如果要做低功耗休眠唤醒，这个晶振就得焊上。

天线部分有两种方案：PCB板载天线和SMA外接天线。板载天线成本低，但增益和方向性不如外接天线。我第一版用的板载天线，实测室内传输距离大概20米左右，穿一堵墙后信号明显衰减。后来换成SMA接口加2dBi小天线，同样的环境能到35米以上。如果你对传输距离有要求，建议直接上外接天线。

电源部分，CC2530工作电压范围是2.0V到3.6V，典型值3.3V。可以用AMS1117-3.3从5V降压得到。注意CC2530在发射时的瞬时电流可能达到30mA左右，去耦电容要放足，我在VCC引脚旁边放了10uF钽电容加100nF陶瓷电容的组合，实测电源纹波控制得不错。

2.3 传感器接口的分配与注意事项

STM32F103C8T6的IO口数量有限，合理分配很重要。我把接口分配整理成表格，你可以直接参考。

I2C总线挂多个设备时，要注意上拉电阻。STM32内部有弱上拉，但驱动能力不够，建议在SCL和SDA上各加4.7K的外部上拉电阻到3.3V。我试过不加外部上拉，OLED能显示但偶尔会花屏，加了之后就没再出现过。

MQ-135的输出是模拟电压，接STM32的ADC引脚。MQ-135需要预热，刚上电时读数会偏高，大概预热24小时后才稳定。代码里我加了一个预热标志，上电后前5分钟的数据不参与报警判断。

3. 软件架构与核心代码实现

3.1 开发环境搭建与工程配置

开发环境我用的是Keil MDK5，配合STM32CubeMX做初始化配置。CubeMX的好处是图形化配置时钟树、外设参数，自动生成初始化代码，省去大量查手册的时间。

安装Keil5的时候有个坑要注意：Keil5默认不包含STM32的器件支持包，需要单独下载安装。你可以从Keil官网下载STM32F1系列的Device Family Pack，双击安装即可。如果同时要开发C51单片机，Keil5和Keil4可以共存，但安装路径要分开，否则会冲突。

注意：安装STM32芯片包时，如果提示“Cannot find the file”，大概率是下载的包不完整，重新下载一次就行。另外Keil5的注册机杀毒软件会报毒，添加信任即可。

CubeMX配置时钟树的步骤：先选外部高速晶振HSE，然后在Clock Configuration里把PLL倍频到72MHz，AHB分频设为1，APB1分频设为2（36MHz），APB2分频设为1（72MHz）。这个配置是STM32F103的标准跑法，稳定且性能足够。

串口配置方面，USART1和USART2都设为115200波特率、8位数据位、1位停止位、无校验。中断优先级方面，USART1接收中断设为抢占优先级1，USART2设为2，确保Zigbee数据的实时性。

3.2 Zigbee协调器与终端节点的固件开发

Zigbee部分的固件基于TI的Z-Stack协议栈开发。Z-Stack的代码结构比较庞大，但核心逻辑集中在几个文件里：协调器的任务处理在Coordinator.c，终端节点的在EndDevice.c，应用层数据处理在App.c。

协调器的主要工作是组建网络、允许节点加入、接收终端节点发来的数据并通过串口转发给STM32。关键配置在f8wConfig.cfg文件里，需要设置PAN ID和信道。PAN ID我设为0x1234，信道设为15。这两个参数要和终端节点保持一致，否则入不了网。

终端节点的固件要配置成低功耗模式。在f8wConfig.cfg里把RFD_RCVC_ALWAYS_ON设为FALSE，这样节点在空闲时会进入休眠，有数据时才唤醒。实测下来，两节5号电池供电的终端节点，采样间隔30秒的情况下，能撑大概3个月。

数据发送的格式我定义了一个简单的帧结构：

typedef struct { uint8_t header; // 帧头 0xAA uint8_t nodeId; // 节点编号 uint16_t temp; // 温度，放大10倍 uint16_t humidity; // 湿度，放大10倍 uint16_t airQuality; // 空气质量ADC值 uint16_t light; // 光照值 uint8_t checksum; // 校验和 } SensorFrame_t;

温度放大10倍是为了用整数传输，避免浮点运算在CC2530上耗时。比如25.6度传256，STM32收到后除以10.0还原。

3.3 STM32主控的数据解析与处理逻辑

STM32这边我用的是HAL库加FreeRTOS。虽然这个项目用裸机跑也完全没问题，但上RTOS之后任务调度更清晰，后续扩展也方便。

我创建了四个任务：串口接收任务、数据处理任务、显示刷新任务、报警检测任务。串口接收任务优先级最高，用中断加消息队列的方式，收到完整帧后把数据丢进队列。数据处理任务从队列取数据，解析帧结构，更新全局变量。显示刷新任务每500ms刷新一次OLED。报警检测任务每1秒检查一次各参数是否超阈值。

串口接收的中断回调函数里，我用了一个状态机来解析帧：

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart->Instance == USART1) { static uint8_t state = 0; static uint8_t frameIdx = 0; static uint8_t rxByte; rxByte = g_rxBuffer[0]; switch (state) { case 0: // 等待帧头 if (rxByte == 0xAA) { g_frameBuffer[0] = rxByte; frameIdx = 1; state = 1; } break; case 1: // 接收数据 g_frameBuffer[frameIdx++] = rxByte; if (frameIdx >= FRAME_LENGTH) { // 校验 if (checkSum(g_frameBuffer, FRAME_LENGTH)) { osMessageQueuePut(uartQueue, g_frameBuffer, 0, 0); } state = 0; } break; } HAL_UART_Receive_IT(&huart1, g_rxBuffer, 1); } }

这个状态机的好处是，即使数据流中间有干扰字节，也能自动重新同步。我试过在Zigbee信号不好的时候，偶尔会有丢包，但状态机保证了下一次正确帧能被正常解析。

3.4 上位机监测界面的实现

上位机我用Qt5写的，主要功能是串口通信、数据解析、实时曲线显示、历史数据存储。

串口部分用QSerialPort类，配置好波特率和数据位后，监听readyRead信号。收到数据后调用解析函数，把字节流还原成传感器数值。

实时曲线用QCustomPlot库，这个库轻量且功能强。我设置了三条曲线：温度、湿度、空气质量。X轴是时间，Y轴是数值。每次收到新数据就追加一个点，同时移除最旧的点，保持窗口内显示最近100个数据点。

历史数据存储用SQLite数据库，每次收到数据就插入一条记录。表结构很简单：

CREATE TABLE sensor_data ( id INTEGER PRIMARY KEY AUTOINCREMENT, node_id INTEGER, timestamp DATETIME DEFAULT CURRENT_TIMESTAMP, temperature REAL, humidity REAL, air_quality INTEGER, light INTEGER );

这样后续要做数据分析或者导出Excel都很方便。

4. 系统联调与常见问题排查

4.1 Zigbee组网失败的排查思路

Zigbee组网失败是最常见的问题，表现是终端节点一直入不了网，协调器的串口也没有入网提示。排查的时候按以下顺序来。

先确认协调器是否成功组建了网络。协调器上电后，如果网络建立成功，Z-Stack会打印“Network formed”之类的日志。如果没有，检查PAN ID和信道配置是否正确，以及协调器的固件是否烧录成功。

然后确认终端节点的配置。终端节点的PAN ID和信道必须和协调器完全一致。另外终端节点的DEVICE_TYPE要设为END_DEVICE，不能设成ROUTER或COORDINATOR。

如果配置都没问题但还是入不了网，检查天线和电源。天线没接或者虚焊会导致信号极弱，终端节点根本收不到协调器的信标帧。电源方面，CC2530在入网过程中电流波动较大，如果电源供电不足，入网过程会中断。

提示：可以用Zigbee抓包工具（比如TI的Packet Sniffer）抓空口数据，看协调器有没有发信标帧、终端节点有没有发入网请求。这个方法最直接，但需要额外的抓包硬件。

4.2 串口通信乱码与丢包的处理

串口乱码一般两个原因：波特率不匹配或者地线没接好。STM32和Zigbee协调器之间的串口，两边波特率必须一致，我统一用115200。地线一定要接，只接TX和RX不接地线，通信会时好时坏。

丢包问题在Zigbee通信中比较常见，尤其是节点多的时候。我遇到过协调器同时收到多个节点数据时，串口输出出现丢帧的情况。后来发现是串口发送缓冲区太小，改成DMA发送后问题解决。

STM32这边接收Zigbee数据时，如果处理不及时，也会丢包。我的做法是用中断接收加消息队列，中断里只负责把数据存进队列，解析和处理放到任务里做。这样即使处理任务被其他高优先级任务抢占，数据也不会丢。

4.3 传感器读数异常的校准方法

MQ-135的读数受环境影响很大，温度湿度变化都会导致读数漂移。我的做法是每隔一段时间做一次基线校准。具体操作是：把传感器放在洁净空气中预热24小时，记录此时的ADC值作为基线，后续读数减去基线得到相对值。

SHT30的精度不错，但要注意I2C总线的上拉电阻。如果上拉电阻太大，信号上升沿变缓，可能导致通信失败。我试过用10K上拉，在400kHz速率下偶尔会NACK，换成4.7K后稳定运行。

光照传感器BH1750的读数受安装位置影响很大。如果装在盒子里面，读数会偏低。我建议把传感器露出来，或者用导光柱把光线引到传感器上。

4.4 常见问题速查表

4.5 低功耗优化的实操经验

如果终端节点要用电池供电，低功耗优化是绕不开的。我总结了几条实用经验。

第一，降低采样频率。环境参数变化慢，没必要每秒采一次。我把采样间隔设为30秒，功耗直接降了一个数量级。

第二，用好CC2530的休眠模式。在两次采样之间，让CC2530进入PM2模式，电流从20多mA降到1uA左右。唤醒源用32.768kHz晶振的定时器，定时到了自动唤醒。

第三，传感器供电要可控。DHT11、MQ-135这些传感器静态电流不小，我用MOS管控制它们的电源，采样时才上电，采完就断电。

第四，STM32这边如果也用电池，可以开启Stop模式。不过这个项目STM32是主控，一般放在固定位置用适配器供电，低功耗需求没那么迫切。

实测下来，两节南孚5号电池给CC2530终端节点供电，30秒采样间隔，能连续工作3个月左右。如果换成1000mAh的锂电池，能撑半年以上。

5. 系统扩展与个人实操体会

5.1 从单节点到多节点的扩展

单节点跑通之后，扩展到多节点其实很简单。Zigbee协议栈本身支持多节点，协调器只需要在应用层维护一个节点列表就行。

我在协调器的代码里加了一个节点管理数组，每个入网的终端节点分配一个短地址，数据帧里带上节点编号。STM32收到数据后根据节点编号区分不同房间的传感器。

多节点部署时要注意信道容量。Zigbee一个信道最多支持大概100个节点，但实际用下来，超过20个节点后网络响应会变慢。家庭环境一般每个房间一个节点，总共不超过10个，完全够用。

5.2 接入云平台和手机App的思路

本地监测跑通后，下一步自然是接入云平台和手机App。我的做法是在STM32上加一个ESP8266模块，通过WiFi把数据上传到云平台。

ESP8266和STM32之间用AT指令通信，STM32通过USART3发送AT指令控制ESP8266连接WiFi和MQTT服务器。数据格式用JSON，云平台收到后存储并推送到手机App。

手机App我用的是微信小程序，开发成本低，用户不用安装。小程序通过WebSocket连接云平台，实时接收数据并显示。报警推送用微信模板消息，超阈值时自动推送到用户微信。

注意：ESP8266和Zigbee都用2.4GHz频段，同时工作时要注意天线隔离，两个模块的天线尽量远离，减少相互干扰。

5.3 我在这个项目里踩过的坑

第一个坑是电源。我一开始用AMS1117-3.3给整个系统供电，结果Zigbee模块发射时电流突增，导致STM32复位。后来在AMS1117输出端加了470uF电解电容加100nF陶瓷电容，问题解决。AMS1117的瞬态响应一般，输出电容要放足。

第二个坑是I2C总线。OLED和SHT30挂在同一条I2C总线上，单独测试都正常，一起用就偶尔通信失败。查了之后发现是总线电容太大，上升沿变缓。把上拉电阻从10K换成4.7K后稳定了。

第三个坑是Zigbee固件烧录。CC2530用CC Debugger烧录，第一次烧录时提示“Device not found”。检查后发现是CC Debugger的驱动没装好，重新安装驱动后正常。另外烧录时目标板要独立供电，不能只靠CC Debugger供电，否则电流不够。

第四个坑是FreeRTOS任务栈溢出。我一开始给显示任务分配了128字的栈，结果OLED刷新时偶尔死机。后来用FreeRTOS的栈检测功能查出来是栈溢出，改成256字后正常。任务栈大小要根据实际使用情况调整，不能拍脑袋。

5.4 后续可以继续折腾的方向

这个系统目前实现了基本的环境监测和报警功能，后续还有不少可以扩展的方向。

一是增加执行器控制。现在只留了继电器接口，可以接风扇、加湿器、空气净化器，根据传感器数据自动控制。比如温度超过30度自动开风扇，湿度低于40%自动开加湿器。

二是加入本地存储。在STM32上挂一个SD卡模块，把数据存到SD卡里，断网时数据不丢失，联网后补传。

三是做数据分析和预测。把历史数据导入Python做分析，用简单的线性回归预测未来趋势，提前预警。

四是优化Zigbee网络。加入路由节点扩展覆盖范围，或者用Zigbee 3.0协议栈支持更多设备类型。

这个项目从画板子到调通花了大概三周时间，其中Zigbee组网和低功耗调试占了一半以上。如果你也在做类似的项目，我的建议是先把STM32和Zigbee各自单独调通，再联调。联调时先保证有线串口通信正常，再加无线。一步一步来，比一上来就全系统联调效率高得多。