1. 从零搭建一套环境监测节点，先想清楚这三件事
智能家居环境监测这个词听起来挺大，但落到硬件层面，本质上就是一套“传感器采集 + 无线传输 + 本地显示/告警”的组合。我前后做过三版类似的系统，第一版用ESP8266凑合，第二版换成STM32F103加Zigbee模块，第三版才把电源、外壳、组网逻辑全部理顺。回头看，真正决定项目能不能稳定跑起来的，不是代码写得多花哨，而是动手之前有没有把下面三件事想明白。
第一件事是监测什么。温湿度、空气质量、光照强度、烟雾浓度，这四个是最常见的组合。温湿度用DHT22或SHT30，空气质量用MQ-135，光照用BH1750，烟雾用MQ-2。选型的时候不要只看精度参数，要看响应时间和预热时间。MQ系列传感器都需要预热，冷启动后前几分钟的数据基本不可信，这一点在写采集逻辑时必须处理。
第二件事是数据往哪传。Zigbee的优势在于自组网和低功耗，适合多个节点分散布置的场景。但它不像WiFi那样直接接入互联网，需要一个协调器（Coordinator）做汇聚，再通过串口把数据交给主控。很多人第一次做Zigbee项目，卡在“模块买回来不知道怎么配对”这一步，其实核心就是搞清楚Coordinator、Router、End Device三种角色。
第三件事是谁来显示和告警。本地用OLED或TFT屏做实时显示，超阈值时蜂鸣器响、LED闪，同时把数据通过串口上报给上位机。如果要做远程查看，可以在协调器端加一个WiFi模块做数据转发，但这是后话，第一版先把本地闭环跑通。
提示：新手最容易犯的错误是一上来就买一堆模块，结果发现引脚不够、供电不足、协议不兼容。建议先用最小系统板加一个传感器跑通采集，再逐步加无线和显示。
这套系统的核心关键词是STM32、Zigbee、智能家居、环境监测。STM32负责采集和处理，Zigbee负责传输，两者通过UART串口通信。下面我会按照实际搭建顺序，把每个环节的选型理由、接线细节、代码逻辑和踩过的坑全部展开。
2. 主控与传感器选型：为什么是STM32F103而不是别的
2.1 STM32F103C8T6最小系统板的性价比分析
市面上做环境监测的主控选择很多，ESP32、Arduino、树莓派Pico都能干。我最终选STM32F103C8T6，理由很实际：外设够用、资料够多、价格够低。它有两个USART、两个I2C、两个SPI、多个ADC通道，对于同时接DHT22、BH1750、MQ-135和OLED屏来说绰绰有余。48引脚封装，焊接和布线都不算难。
相比之下，ESP32虽然自带WiFi和蓝牙，但如果你已经决定用Zigbee做无线传输，ESP32的无线能力就浪费了，而且它的ADC线性度一直被诟病，测模拟传感器时误差偏大。Arduino Uno的RAM只有2KB，跑多传感器轮询加OLED刷新很容易爆内存。STM32F103C8T6有64KB Flash和20KB RAM，留足了余量。
选型时还有一个容易被忽略的点：晶振频率。F103C8T6默认用8MHz外部晶振，经过PLL倍频到72MHz。如果你买的是“蓝色药丸”板，上面通常已经焊好了8MHz晶振和32.768kHz RTC晶振。但有些廉价板子省掉了RTC晶振，如果你需要精确时间戳，就得自己补焊。
2.2 四类传感器的接线逻辑与注意事项
DHT22是单总线协议，数据引脚接STM32的任意GPIO，建议加一个4.7kΩ到10kΩ的上拉电阻。很多人直接接上去也能读，但长线传输时数据会偶发错误，加上拉电阻后稳定性明显提升。供电用3.3V还是5V？DHT22支持3.3V到5.5V，接3.3V可以和STM32电平匹配，省掉电平转换。
BH1750是I2C接口，SCL和SDA分别接STM32的PB6和PB7（I2C1），地址默认0x23。注意BH1750的ADDR引脚悬空时地址是0x23，接VCC时变成0x5C。如果你同时接多个I2C设备，要确认地址不冲突。
MQ-135和MQ-2都是模拟输出，接STM32的ADC引脚，比如PA0和PA1。这两个传感器需要5V供电加热，但模拟输出最高可能到5V，而STM32的ADC参考电压是3.3V。直接接会烧引脚，必须用电阻分压。我的做法是用两个10kΩ电阻串联分压，把0到5V映射到0到2.5V，虽然损失了精度，但安全第一。
OLED屏用SSD1306驱动，I2C接口，地址通常是0x3C。它和BH1750可以挂在同一条I2C总线上，只要地址不同就行。刷新率不用太高，每秒2到3次足够，太高反而会让I2C总线拥堵。
| 传感器 | 接口类型 | 供电 | 引脚分配 | 注意事项 |
|---|---|---|---|---|
| DHT22 | 单总线 | 3.3V | PA5 | 加上拉电阻 |
| BH1750 | I2C | 3.3V | PB6/PB7 | 地址0x23 |
| MQ-135 | 模拟 | 5V | PA0 | 分压后接ADC |
| MQ-2 | 模拟 | 5V | PA1 | 分压后接ADC |
| OLED | I2C | 3.3V | PB6/PB7 | 地址0x3C |
2.3 电源方案：AMS1117发热问题的实际处理
整个系统需要3.3V和5V两路供电。5V给MQ系列传感器加热，3.3V给STM32、DHT22、BH1750和OLED。最常见的做法是用AMS1117-3.3把5V降到3.3V。但AMS1117有个毛病：压差大时发热严重。如果输入5V、输出3.3V、负载电流200mA，功耗就是(5-3.3)×0.2=0.34W，封装小的话温度会明显上升。
我试过在AMS1117的输出端把钽电容换成陶瓷电容，结果发现纹波反而变大了。后来查资料才明白，AMS1117这类LDO对输出电容的ESR有要求，钽电容的ESR在0.1Ω到1Ω之间比较合适，陶瓷电容ESR太低，容易导致环路不稳定。所以如果你要换电容，最好保留一个钽电容或者加一个1Ω左右的电阻串联。
更稳妥的方案是用MP1584这类DC-DC降压模块，效率高、发热小，但输出纹波比LDO大。对于ADC采集来说，纹波会影响精度。我的折中方案是：DC-DC降到3.6V，再用AMS1117降到3.3V，这样压差小，发热也小。
3. Zigbee组网：从模块配对到数据透传的完整链路
3.1 Zigbee三种设备角色的实际含义
Zigbee网络里有三种角色：Coordinator、Router、End Device。很多人第一次接触时搞不清楚区别，我用一个生活化的类比来解释。Coordinator就像家里的路由器，负责创建网络、分配地址，一个网络只能有一个。Router就像信号中继器，可以转发其他设备的数据，通常接市电供电。End Device就像电池供电的传感器，大部分时间在睡觉，定期醒来发数据。
在环境监测场景里，我的布局是：一个Coordinator接在STM32主控板上，负责接收所有节点数据；每个监测节点用一个End Device，因为节点通常放在不同房间，用电池供电。如果房子面积大，中间加一个Router做中继。
注意：Coordinator必须一直供电，不能休眠。End Device可以休眠，但休眠期间无法接收数据，只能主动上报。
3.2 模块选型与固件版本匹配
我用的是CC2530核心板，配合Z-Stack协议栈。市面上常见的Zigbee模块有CC2530、CC2630、CC2652等。CC2530最经典，资料最多，但RAM只有8KB，跑复杂应用会吃力。CC2652性能强很多，但价格也高。对于环境监测这种数据量很小的场景，CC2530完全够用。
买模块时一定要注意固件版本。Coordinator和End Device的固件必须匹配，否则无法配对。我遇到过买了两批模块，一批是Z-Stack 2.5.1a，另一批是3.0.2，结果死活配不上。后来用Flash Programmer把两批都刷成同一个版本才解决。
固件烧录需要CC Debugger和SmartRF Flash Programmer。接线是VCC、GND、P2.1（DD）、P2.2（DC）、RESET。烧录时先点Erase，再点Program。如果提示“无法识别设备”，检查Debugger驱动是否装好，以及模块是否供电正常。
3.3 串口透传配置：Coordinator与STM32的通信协议
Coordinator和STM32之间通过UART通信，波特率通常设115200。Z-Stack默认的串口协议是MT（Monitor and Test）格式，数据帧有固定的帧头和校验。如果你不想解析复杂协议，可以把Coordinator固件改成“透明传输”模式，这样它收到什么就通过串口发什么。
透明传输的配置方法是在Z-Stack里修改ZTOOL_P1和MT_TASK相关宏定义，或者直接用别人写好的透传固件。我建议新手先用透传固件跑通链路，再研究MT协议。
数据格式我定义了一个简单的帧结构：帧头0xAA、节点地址2字节、温度2字节、湿度2字节、空气质量2字节、光照2字节、校验和1字节、帧尾0x55。STM32收到后先找帧头，再读固定长度，最后校验。这样即使偶尔丢包，也不会解析错位。
// STM32串口接收解析示例 #define FRAME_HEAD 0xAA #define FRAME_TAIL 0x55 #define FRAME_LEN 12 uint8_t rx_buf[FRAME_LEN]; uint8_t rx_index = 0; void USART1_IRQHandler(void) { if(USART_GetITStatus(USART1, USART_IT_RXNE) != RESET) { uint8_t data = USART_ReceiveData(USART1); if(rx_index == 0 && data != FRAME_HEAD) return; rx_buf[rx_index++] = data; if(rx_index >= FRAME_LEN) { if(rx_buf[FRAME_LEN-1] == FRAME_TAIL) { parse_frame(rx_buf); } rx_index = 0; } } }3.4 组网测试中常见的三个坑
第一个坑是信道冲突。Zigbee默认使用信道11到26，如果周围有多个WiFi路由器，2.4GHz频段会很拥挤。我建议在Coordinator固件里把信道固定为15或20，避开WiFi常用的1、6、11信道。
第二个坑是PAN ID重复。如果邻居家也用了Zigbee设备，PAN ID相同会导致网络混乱。Z-Stack默认PAN ID是0xFFFF，表示随机选择。最好手动指定一个不常见的PAN ID，比如0x1A2B。
第三个坑是End Device休眠后无法被找到。End Device休眠时，父节点会缓存发给它的数据。如果休眠时间太长，父节点缓存满了就会丢弃数据。解决办法是缩短休眠周期，或者让End Device定期发送“数据请求”命令。
4. 固件开发：Keil5环境搭建与多传感器轮询逻辑
4.1 Keil5安装STM32芯片包的完整步骤
Keil5本身不自带STM32的器件支持包，需要单独安装。打开Keil5，点Pack Installer，在Devices里找到STMicroelectronics，展开STM32F1系列，选择STM32F103C8，点Install。如果网络慢，可以去Keil官网下载对应的.pack文件离线安装。
安装完成后，新建工程时选择STM32F103C8，运行环境里勾选CMSIS的CORE和Device的Startup。如果你用标准外设库，还需要手动添加库文件；如果用HAL库，可以用STM32CubeMX生成初始化代码。
提示：Keil5兼容C51和STM32，但需要分别安装对应的芯片包。如果你同时开发51和STM32，建议装两个独立的Keil实例，避免冲突。
4.2 DHT22时序驱动的关键延时处理
DHT22的单总线协议对时序要求很严。主机先拉低至少1ms，然后释放，等待DHT22响应。DHT22会拉低80us，再拉高80us，然后开始传输40位数据。每位数据以50us低电平开始，高电平持续26到28us表示0，持续70us表示1。
用STM32的延时函数时，要注意delay_us的精度。如果系统时钟是72MHz，一个简单的for循环延时可能不准。我建议用SysTick定时器做微秒延时，或者用定时器捕获来测量高电平持续时间。
// DHT22读取函数核心逻辑 uint8_t DHT22_ReadByte(void) { uint8_t i, byte = 0; for(i = 0; i < 8; i++) { while(!DHT22_PIN); // 等待50us低电平结束 delay_us(40); // 延时40us后采样 byte <<= 1; if(DHT22_PIN) byte |= 1; while(DHT22_PIN); // 等待剩余高电平结束 } return byte; }实测中发现，如果delay_us(40)不够准，读出来的数据会偶尔出错。解决办法是用定时器输入捕获测量高电平时间，大于40us判为1，小于40us判为0。这样不依赖延时精度，稳定性更好。
4.3 多传感器轮询与OLED刷新节奏
四个传感器如果同时采集，I2C总线和ADC会互相干扰。我的做法是分时轮询：先读DHT22（耗时约5ms），再读BH1750（I2C，约1ms），再读MQ-135和MQ-2（ADC，各约0.1ms），最后刷新OLED（约20ms）。整个循环控制在50ms以内，人眼看起来是实时刷新。
OLED刷新不要每次采集都做，可以每500ms刷新一次。中间的数据变化用变量缓存，超阈值时立即触发蜂鸣器。这样既保证了响应速度，又不会让I2C总线太忙。
// 主循环逻辑 while(1) { if(tick - last_dht_tick > 2000) { DHT22_Read(&temp, &humi); last_dht_tick = tick; } if(tick - last_oled_tick > 500) { OLED_Refresh(temp, humi, air_quality, light); last_oled_tick = tick; } if(temp > TEMP_THRESHOLD || air_quality > AIR_THRESHOLD) { Buzzer_On(); LED_Alert(); } else { Buzzer_Off(); LED_Normal(); } }4.4 串口调试与PID调参的意外收获
调试MQ-135时，我发现模拟输出波动很大，直接读ADC值跳变严重。后来加了一个滑动平均滤波，取最近10次采样的平均值，数据就平稳多了。如果你要做更精确的标定，可以用串口把原始数据发到上位机，用Excel画曲线，观察趋势。
有意思的是，我在调MQ-135的加热电压时，用串口调试PID的思路来调PWM占空比，发现加热电压稳定后，传感器读数的一致性明显提升。虽然MQ-135不需要PID控制，但这种“用调试工具反推硬件特性”的思路很实用。
5. 系统联调：从单节点到多节点组网的排查实录
5.1 单节点跑通后的第一次联调
单节点跑通的标准是：STM32能读到四个传感器的数据，OLED能显示，串口能打印。这时候把Zigbee End Device接上，配置好PAN ID和信道，上电后Coordinator应该能收到数据。
我第一次联调时，Coordinator串口一直没输出。排查过程是这样的：先确认End Device是否入网（看模块上的LED闪烁频率），再确认Coordinator是否创建了网络（用Zigbee抓包工具看），最后检查串口波特率是否匹配。结果是波特率设成了9600，而Coordinator固件是115200。改过来后数据就通了。
5.2 多节点数据冲突与轮询机制
两个End Device同时上报时，Coordinator串口会出现数据交错。因为Zigbee模块的串口是半双工的，两个节点的数据如果同时到达，会混在一起。解决办法是在Coordinator固件里加一个队列，收到一个节点的完整帧后再处理下一个。
另一个办法是让End Device错开上报时间。比如节点1在0秒上报，节点2在1秒上报，节点3在2秒上报。这样即使有轻微的时间漂移，也不会撞在一起。我在固件里用osal_start_timerEx设置不同的延时，效果很好。
5.3 数据丢包与重传策略
Zigbee本身有重传机制，但应用层也要做兜底。我在帧结构里加了一个序列号，Coordinator收到重复序列号就丢弃，收到跳号就请求重传。请求重传的命令通过串口发给Coordinator，再由Coordinator广播给所有节点。
实测下来，在室内环境下，Zigbee的丢包率大约在1%到3%之间。加了应用层重传后，有效数据完整率能到99.9%以上。对于环境监测来说，这个可靠性足够了。
5.4 长时间运行的稳定性观察
系统连续跑了72小时，发现两个问题。一是DHT22在湿度高于90%时读数会漂移，这是传感器本身的特性，没办法完全消除，只能加软件补偿。二是OLED屏在连续刷新72小时后出现了轻微残影，后来把刷新率从500ms改成1秒，残影就消失了。
还有一个意外发现：MQ-135在连续工作24小时后，读数会比刚上电时偏高约5%。这是加热丝老化导致的，属于正常现象。如果要做长期监测，建议每24小时做一次基线校准。
6. 外壳设计与部署：让这套系统真正能放进房间
6.1 3D打印外壳的散热开孔设计
电子部分跑通后，下一步是装外壳。我用Fusion 360画了一个简单的盒子，尺寸120mm×80mm×40mm。关键点是散热开孔：MQ系列传感器需要空气流通，DHT22也需要接触环境空气。我在盒子侧面开了几排直径3mm的孔，顶部也开了孔，形成对流。
STM32和AMS1117的发热不大，但Zigbee模块在发射时会有瞬时功耗，外壳内部温度会比环境高2到3度。如果做温度监测，这个温差要补偿。我的做法是把DHT22用导线引出外壳，直接暴露在空气中，避免外壳内部温升影响读数。
6.2 传感器布局对读数的影响
MQ-135和MQ-2如果靠得太近，加热丝的热量会互相影响。我一开始把两个传感器并排放在一起，结果MQ-2的读数总是偏高。后来把它们分开至少30mm，中间加了一块隔热板，读数就正常了。
BH1750是光照传感器，要避免被外壳遮挡。我在外壳顶部开了一个透明窗口，用亚克力板封住，BH1750贴在窗口下方。这样既能防尘，又不影响光照采集。
6.3 部署位置选择与WiFi干扰规避
Zigbee和WiFi都在2.4GHz频段，如果部署位置离路由器太近，Zigbee信号会被压制。我建议Coordinator离WiFi路由器至少2米，End Device和Coordinator之间不要有承重墙。如果必须穿墙，加一个Router做中继。
实际部署时，我把Coordinator放在客厅电视柜上，End Device放在卧室和厨房。客厅到卧室隔了一堵墙，信号强度从-60dBm降到-75dBm，但数据还能稳定传输。厨房因为有微波炉，2.4GHz干扰严重，后来把厨房节点的上报周期从2秒改成5秒，丢包率就降下来了。
7. 这套系统还能怎么扩展
第一版跑通后，我陆续加了几个功能。一个是数据记录，在Coordinator端加了一个SD卡模块，把数据按CSV格式存下来，方便后期分析。另一个是手机查看，在Coordinator端加了一个ESP8266，把数据转发到本地服务器，手机连同一个WiFi就能看实时曲线。
如果你要做毕业设计或者课程项目，这套系统的基础框架足够用了。关键是把每个环节的“为什么”搞清楚，而不是照抄代码。比如为什么DHT22要加上拉电阻，为什么MQ-135要分压，为什么Zigbee要错开上报时间。这些细节才是真正体现功底的地方。
最后分享一个我在调试中养成的小习惯：每次改完代码，先用串口打印关键变量，确认逻辑正确后再接传感器。这样能把软件问题和硬件问题分开，排查效率高很多。
