企业官网建设流程全解析

1. 这个系统解决的不只是“测个温湿度”

馆藏文物保存环境监测系统，在不少毕业设计和博物馆改造项目里都听过，但真正到现场跑过一轮的人会明白：它的难点不是“读个温度”那么简单，而是长期稳定地采集温湿度、光照、挥发性有机物等多项参数，还要把数据连续记录下来，方便后续追溯和分析。我用STM32做核心控制器，前前后后做了一年多，从第一版裸机采集，到后来加上远程报警、低功耗唤醒，中间踩过的坑完全可以单独写一篇流水账。这篇就结合我自己的实际项目，把完整的设计思路、硬件选型、软件实现和调试经验整理出来，给想做类似环境监测系统的朋友一个可以直接抄作业的参考。

这套系统能做什么，用一句话说清楚：STM32通过I2C总线读取高精度温湿度传感器、光照传感器和空气质量传感器的数据，在OLED屏幕上实时显示，同时通过ESP8266上报到MQTT云端；一旦温度、湿度、光照强度或者VOC浓度超过设定范围，本地蜂鸣器会报警，远程端也会收到通知。整套系统上电后自动运行，不需要人工干预，断电后重新上电也能自己恢复工作。

适合谁来参考？如果你有STM32和HAL库的基础，准备做环境监测相关的项目，或者正在为博物馆、档案室、实验室、库房这类场景设计温湿度监控方案，这篇的内容基本能覆盖从立项到调试的全过程。就算你只是刚学完单片机，想找一个能综合练习GPIO、I2C、串口、定时器、低功耗的项目，把下面这套东西拆开吃透，也比零散写几个跑马灯实验有价值得多。

1.1 文物保存到底需要监测哪些指标

先说为什么要监测，而不是先谈技术。纸张、丝织品、漆器、青铜器这些东西对环境的敏感程度远超普通人的想象。温度和湿度如果长期偏高，霉菌和害虫就会活跃，纸张变脆、漆器开裂；湿度要是太低，木器又会干缩变形。光照更不能忽视，阳光和灯光里的紫外线、可见光长时间照在书画和丝织品上，会造成不可逆的褪色和老化。另外，库房里的板材、胶粘剂、漆料会缓慢释放挥发性有机物，有些成分对金属和颜料有明显的腐蚀作用，所以VOC或者等效CO2也是需要关注的指标。

实际做监测系统时，我不建议一开始就把所有物理量都堆上去。先抓住四组最关键的参数就够了：温度和湿度、可见光照强度、空气中的VOC浓度。如果项目有条件，还可以在预留接口上加入震动检测，因为运输和展陈过程中轻微的持续震动对脆弱文物也有影响。但要记住，传感器多一条，系统的不稳定因素就多一层，第一版先做到少而精，后面再慢慢扩展。

这些指标并不是测出来显示一下就行，更重要的是“趋势”。博物馆库房对环境的要求通常会给出一个范围，但很多时候瞬时超标带来的损伤未必最大，真正怕的是长时间偏离或者反复波动。比如温度在一天内忽高忽低，即使每次都在安全区间内，频繁的热胀冷缩也会让文物的材料结构慢慢劣化。所以设计系统时不能只做阈值的“越限报警”，还要记录历史数据、观察变化趋势，这比一个冷冰冰的数值更有价值。

1.2 为什么用STM32而不是其他方案

做环境监测核心控制器，可选的方案很多：Arduino、ESP32、树莓派、PLC，甚至直接买一个工业温湿度记录仪都能干。但我最终选择STM32，有一个比较现实的原因：这套系统首先要保证“现场能长期稳定干活”，其次才是开发和调试方便。

STM32的外设资源足够丰富，I2C、SPI、USART、ADC、定时器都有，挂多个传感器和一个OLED屏都不用额外扩芯片。F103系列成本很低，市面上几块钱一片，开发板更是遍地都是，如果只是做毕业设计或者小批量试点，物料成本非常可控。另外，CubeMX和HAL库的生态已经很成熟，用图形化界面配置完引脚，再往生成的框架里填业务逻辑，开发效率比用标准库手写底层高很多。

有人可能会问，直接用ESP32不行吗？ESP32本身带WiFi和蓝牙，确实能省掉ESP8266这个从机，开发还更方便。但我在实际项目里不太喜欢把传感器采集和网络通信混在一个芯片上。博物馆库房里的WiFi环境不一定好，一旦网络模块跑飞，如果采集和控制逻辑也在同一颗芯片上，整个监测就会跟着瘫痪。STM32负责采集、显示、判断和报警，ESP8266只做数据透传，两者通过串口通信，网络出问题时不至于影响现场的基础监控。没有网络，本地报警和屏幕显示还能继续工作，这种解耦对长期运行来说非常重要。

1.3 整体架构和工作流程

系统架构其实不复杂，核心模块就这么几块：传感器采集端、STM32主控、本地显示与报警、无线通信端、云端或上位机。传感器都挂在同一条I2C总线上，通过不同的芯片地址区分。主控通过定时器触发周期性采集，数据经过滤波处理后同时做三件事：刷新OLED显示、判断报警条件、通过串口把封装好的JSON报文发给ESP8266，再由ESP8266走MQTT协议上云。

工作流程可以概括为一个简单的状态机。上电后先初始化时钟、I2C、串口和各个外设，然后尝试连接WiFi。如果连不上，系统不会卡死，而是继续本地显示和报警，并在屏幕上提示网络异常。网络就绪后，主循环按固定周期执行采集和上报。为了保证数据可比对，上报的数据结构里必须带时间戳，时间戳可以由STM32的RTC生成，也可以通过远程校时获得。这个设计细节非常关键，因为历史曲线的横轴如果没有准确时间，后面的分析基本没有意义。

我用STM32F103C8T6做第一版，够用且便宜；如果目标是长期电池供电、低功耗运行，可以换成STM32L431或者L496。下面从硬件选型开始讲，这部分决定了整个系统能不能稳定工作。

2. 硬件选型与电路设计，稳定是第一优先级

硬件部分看起来就是买几个模块接上线，但实际翻车最容易出现在供电和信号连接上。尤其是ESP8266的瞬时电流很大，传感器又对电源纹波敏感，如果供电设计不合理，经常会出现“单独测没问题、合在一起就随机重启”的怪现象。这一节我把每个模块的选择理由和接线要点说清楚。

2.1 传感器选型：从精度、成本和驱动难度上取舍

温湿度传感器我第一版用的是DHT22，这是很多新手入门喜欢用的型号，单总线协议，代码网上大把。但DHT22有两个问题让我后来果断换掉：一是时序要求严格，单片机任务稍微多了就容易读不到数据；二是没有数据校验，偶尔会跳出一个明显错误的数值。SHT30是I2C接口，带CRC校验，温度和湿度的精度都更好，实测放在库房里长期跑，数据很平滑，偶尔出现的坏帧也能通过校验直接丢弃，不会污染统计结果。价格虽然比DHT22贵一些，但对文物环境监测这种应用，这点成本完全值得。

光照传感器用的是BH1750，这也是很常见的I2C数字光照传感器，量程能到65535勒克斯，分辨率大概1勒克斯。它的窗口应该朝向文物受光面，安装时不能贴着灯具，否则测出来的是灯光直射强度，而不是文物表面的环境光。要注意BH1750探头上有一层滤光片，灰尘盖住之后读数会整体偏低，后期要定期清洁。

空气质量传感器是目前整个系统里最容易让人“误判”的部分。我选过SGP30，它输出TVOC和等效CO2两个数值，通过I2C读取。SGP30内部有一套算法，需要长期通电“预热”一段时间才能收敛，刚开机的前几十个小时数据漂移很大，所以千万不要拿它当精确的CO2检测仪。它更适合用来监测VOC浓度的相对变化，比如库房刚做过清洁、有油漆味，数值会明显上升，这就够了。如果条件允许，可以考虑BME680或者SFA30这类带更多补偿算法的传感器，但成本和代码复杂度也会上升。

传感器选型还有一个容易忽略的点，就是工作电压和电平。上面这几款传感器虽然都能在3.3V下工作，但有些模块板上自带了电平转换，有些没有。接STM32时要注意统一参考地，I2C的上拉电阻要接到3.3V，不能接到5V，否则会烧掉传感器。

2.2 STM32芯片选型与最小系统

如果项目只做样机，STM32F103C8T6是最划算的选择，48脚封装，焊接和飞线都方便，Flash有64KB，跑裸机程序绰绰有余。如果你的系统规划里要加RTOS、LVGL图形界面或者大量历史日志存储，64KB会变得紧张，这时候可以考虑换成STM32F103RCT6或者GD32的兼容芯片。

F103C8T6最小系统主要包括8MHz外部晶振、复位电路、BOOT0下拉电阻、3.3V供电和去耦电容。很多人在最小系统上偷懒，直接用内部的HSI振荡器跑，结果串口波特率偏差很大，I2C时序也不稳定。做这种需要连续通信的项目，我建议还是上外部晶振，省掉很多奇怪的No Response问题。调试口默认是SWD，用ST-Link连接时只需接SWDIO、SWCLK、GND、3.3V四根线。

如果你考虑低功耗，那么F103并不是好选择，STOP模式下的功耗仍然偏高，而且唤醒后的时钟恢复要格外小心。第二版我换了STM32L431RCT6，支持多种低功耗模式，Stop2模式静态电流能到微安级，片上还带RTC，适合做15分钟一次定时唤醒采集的方案。芯片选型要结合现场供电条件，如果能接市电，用F103完全没问题；如果靠18650电池撑一年，那就老老实实选L4系列。

2.3 显示、通信和报警电路

OLED我用了0.96寸SSD1306，I2C接口，和传感器挂在同一条总线上，不同地址不会冲突。OLED在上电初始化时会有一段较大的冲击电流，所以它的供电最好单独从主电源经过一个小滤波电容接过去，不要和传感器挤在同一个引脚上。显示内容不需要花哨，一行温度、一行湿度、一行光照、一行网络状态就行，字体大一点反而方便现场巡检员看。

ESP8266-01S是最小型的WiFi模块，双排8针，串口通信。接线时一定要交叉连接：STM32的TX接ESP8266的RX，STM32的RX接ESP8266的TX，然后共地。ESP8266-01S的GPIO0和GPIO2引脚在上电时会决定工作模式，正常运行时这两个引脚不能悬空，否则模块可能进入下载模式或者启动异常。我习惯把GPIO0和GPIO2通过10k电阻上拉到3.3V。

这里有个特别关键的坑：ESP8266在发射瞬间电流可以达到300mA甚至更高，如果从开发板上的AMS1117取电，压降一掉，模块就会反复重启。正确做法是给它单独用一个降压芯片供电，我试过MP1584降压模块，稳定性和噪音都还可以。如果坚持用3.3V LDO，至少要用能输出1A以上的型号并在输入输出端都加大电容。电平方面，STM32和ESP8266都是3.3V逻辑，可以直接连，但有些卖家做的ESP8266模块上有板载低压差转换或者其他电路，最好用万用表确认一下TX引脚空闲电平是不是3.3V，以免反向供电。

蜂鸣器报警电路不要用GPIO直接驱动，需要加一颗NPN三极管（比如S8050）或者用ULN2003，GPIO经过1k电阻接到基极，蜂鸣器接在集电极和电源之间，再并一个续流二极管吸收反向电动势。报警还可以加一颗红色LED做视觉提示，GPIO串联一个220欧姆电阻。

2.4 供电与保护

第一版样机我直接用USB取电，5V进来，板上AMS1117转3.3V给STM32、OLED和传感器，ESP8266单独用MP1584降压模块供电，实测很稳。如果要做成正式安装在库房里的设备，建议用认证过的5V/2A适配器，并且加TVS管和自恢复保险丝。博物馆这类场所会有严格的用电规范，设备电源不能是那种裸漏的劣质电源适配器，安全第一。

电池供电方案我建议用18650锂电池加TP4056充电模块，输出到HT7833或者ME6211这类低静态功耗的LDO，再接L431主控。整套系统休眠电流控制在微安级别，采集一次并上报，然后继续休眠，两个18650并联能撑很久。注意断电检测，如果检测到主电源掉电，要在掉电瞬间把当前数据存进Flash，防止环境数据丢失。

3. 软件实现：CubeMX初始化 + HAL库业务逻辑

软件部分是我花时间最多的地方，也是很多新手容易卡住的地方。别一上来就想着写驱动，先把项目框架用STM32CubeMX搭好，把时钟、引脚和外设配清楚，再往里面填业务逻辑。下面按我的实际操作顺序讲。

3.1 用CubeMX生成工程时的关键配置

打开STM32CubeMX，选择STM32F103C8T6，如果是L431就选对应型号。时钟树里启用外部HSE晶振，配置PLL让HCLK跑到最高频（F103一般是72MHz）。调试接口选择Serial Wire，否则ST-Link可能连不上。I2C1选择Fast Mode，速度为400kHz。USART1设置为异步通信，波特率115200，8位数据、无校验、1位停止位。再用一个GPIO输出接LED，一个GPIO输出接蜂鸣器，其他引脚按实际分配。

使用HAL库时，每次重新生成代码都会覆盖main.c，所以自定义的业务逻辑最好写在单独的模块文件里，比如sensor.c、display.c、network.c，在main中调用，不要把大段功能代码直接堆在while(1)里。CubeMX生成的代码帮你初始化了HAL库，但底层驱动的细节需要自己补。我见过很多人卡在Keil5打开工程后发现Device选不上，其实就是没有安装对应的芯片包，需要在Pack Installer里装好F1或L4的DFP，STM32CubeIDE则一般不用单独装。

如果你用的是标准库，也没问题，但要注意固件库的SystemInit和时钟树配置，别默认按内部时钟跑。F103的HAL库代码和标准库在引脚配置上的语法差异很大，建议选定一个方向后就别来回切。

3.2 SHT30和BH1750驱动代码的关键细节

SHT30的I2C地址是0x44（7位地址），如果是ADDR引脚接高，会变成0x45。读取温湿度时先发一条测量命令，比如0x2C 0x06，表示高重复性、单次测量。等待大约15ms，然后读取6个字节：温度高字节、温度低字节、温度CRC、湿度高字节、湿度低字节、湿度CRC。HAL库读I2C时可以用HAL_I2C_Master_Transmit发送命令，再用HAL_I2C_Master_Receive读取数据，但要注意每次读之前最好发送一次测量命令。

这一步最容易踩坑的是CRC校验。SHT30返回的CRC是对两个数据字节做的多项式0x31校验，如果你的程序不去校验，偶尔出现的坏帧可能会让温度变成-40度或者湿度变成120%，导致误报警。我封装了一个单字节CRC函数，读到的数据先校验再换算，不通过就丢弃这次采集结果。

BH1750相对简单，写命令0x01进入连续高分辨率测量模式，等待约180ms，然后读取两个字节，光照值就是(MSB << 8 | LSB) / 1.2。如果想要更低噪声，可以读取三次取平均，但要注意高分辨率模式测量时间比较长，连续读取时延时不够会读到上一次的旧值。

I2C多设备总线还有一个细节：如果某次通信超时，总线可能被一个从机锁死，SCL或SDA被拉低。标准做法是软件复位I2C外设，或者对SCL做几次脉冲，让从机释放总线。HAL库的HAL_I2C_IsDeviceReady可以用来检测地址是否在线，调试时非常有用。

下面给一段SHT30读取的简化示例：

#define SHT30_ADDR (0x44 << 1) #define SHT30_CMD_MEASURE 0x2C06 uint8_t sht30_read_temp_humi(float *temp, float *humi) { uint8_t cmd[2] = {(SHT30_CMD_MEASURE >> 8) & 0xFF, SHT30_CMD_MEASURE & 0xFF}; uint8_t buf[6]; if (HAL_I2C_Master_Transmit(&hi2c1, SHT30_ADDR, cmd, 2, 100) != HAL_OK) return 0; HAL_Delay(15); if (HAL_I2C_Master_Receive(&hi2c1, SHT30_ADDR, buf, 6, 100) != HAL_OK) return 0; uint16_t raw_t = (buf[0] << 8) | buf[1]; uint16_t raw_h = (buf[3] << 8) | buf[4]; if (crc8(buf, 2, buf[2]) != 0 || crc8(buf + 3, 2, buf[5]) != 0) return 0; *temp = -45.0f + 175.0f * (float)raw_t / 65535.0f; *humi = 100.0f * (float)raw_h / 65535.0f; return 1; }

注意HAL库的地址参数是8位地址，需要把7位地址左移一位，也就是0x44 << 1。不同版本HAL库可能在地址参数上的处理略有区别，你编译期遇到I2C通信异常时优先检查这个。

3.3 数据滤波、报警判断与状态管理

传感器数据即使再平稳，也还是会有轻微抖动。博物馆库房的环境变化本身是慢变量，没必要对每一条原始值都响应。我用了滑动平均滤波，简单维护一个长度为10的环形缓冲区，每次采集新值后计算平均值。对于温湿度这种变化很慢的物理量，还可以把窗口缩小到5次，保证实时性；光照数据噪声稍大，可以取10次平均。

报警逻辑要分两条路径：瞬时超限和持续超限。瞬时超限，比如温度一下子到了28度，先不触发远程告警，只做本地提示；如果连续5分钟都在阈值之外，说明不是传感器抖动，这时候才推送告警。这样做的好处是大幅减少误报，现场管理员不会因为半夜一条假报警而被折腾起来。报警状态还需要设置“恢复”条件，比如温度回到阈值内并稳定3分钟后，自动解除报警，否则容易在阈值边缘反复触发。

变化率报警是这个系统里容易被忽略的地方。我后来加了温度变化率监测：如果10分钟内温度变化超过2度，即使绝对值还在允许范围内，也发一条提示消息。因为对文物来说，剧烈的温湿度波动比暂时的偏离更可怕。实现起来也很简单，记录十分钟前的温度值，每次采集后算差值，不需要复杂的PID或者预测算法。

状态管理方面，建议把系统状态定义成枚举，比如INIT、NETWORK_WAIT、RUNNING、ALERT。不同状态下主循环做的动作不同。网络异常时不阻塞，显示模块提示“WiFi断网”，本地采集报警继续运行；网络恢复后自动重新连接MQTT，不需要重启设备。这个逻辑看起来简单，却是系统能应对现场复杂网络环境的关键。

3.4 ESP8266连接云端与MQTT上报

ESP8266的固件决定了它的工作方式。如果用乐鑫官方AT固件，支持AT+MQTTUSERCFG和AT+MQTTCONN这类指令，可以直接发AT指令让模块作为MQTT客户端连接 broker。ST官方开发板其实也有类似例程。但如果你的ESP8266模块是老的AT固件，可能不支持MQTT相关指令，就需要先用AT指令升级固件，或者刷成NodeMCU/Arduino固件再跑MQTT。

我这里用AT指令的方式做一个最小示例，适合快速验证。先让模块连接WiFi：

AT+RST AT+CWMODE=1 AT+CWJAP="your_ssid","your_password"

然后配置MQTT：

AT+MQTTUSERCFG=0,1,"client_id","user","password",0,0,"" AT+MQTTCONN=0,"192.168.1.100",1883,1 AT+MQTTSUB=0,"env/notify",1 AT+MQTTPUB=0,"env/data","{\"temp\":22.5,\"humi\":52.3,\"light\":35.0}",1,0

串口发出的JSON字符串要注意转义。在C代码里，可以用sprintf拼装字符串，但要注意缓冲区长度，不要越界。我更推荐用cJSON库，虽然会占用一些Flash，但生成和解析JSON都规范很多，后续扩展字段也方便。

如果不用AT固件，也可以让ESP8266刷入自定义程序，通过串口接收STM32的简单协议数据，再自己构建MQTT报文。这种方式自由度更高，但你需要维护两套固件，调试门槛也高一些。对于我这种习惯把STM32当主控的人来说，AT指令透传已经足够。

上报时间戳我直接用RTC，如果系统没有外接RTC模块，F103内部的RTC在断电后会清零。建议连接网络后通过网络校准时间，否则历史数据的时间线是乱的。如果只是本地演示，用sysTick计时也可以凑合，但真正部署时要认真处理。

4. 实际调试中遇到的坑与排查方法

这部分是全文最有价值的干货。很多问题在教程里不会写，但只要你把设备放在现场连续运行，大概率都会碰到。我按照故障现象、原因、处理办法的格式整理成了速查表。

4.1 I2C总线常见故障

现象1：系统刚上电能读到数据，运行十分钟后突然读不到传感器。先用逻辑分析仪看SDA，发现一直为低。这种一般是I2C从机死锁，尤其是在多设备总线上，某个从机异常拉低SDA，导致主机无法发出START信号。解决办法：在每次I2C超时后调用HAL_I2C_DeInit和HAL_I2C_Init重新初始化，同时对SCL手动输出9个脉冲，强制从机释放总线。我甚至在低功耗唤醒后都会重新初始化I2C，避免未知状态。

现象2：SHT30读数偶发错误，CRC校验不通过。优先怀疑I2C速率太高，降到100kHz试试。博物馆这类环境电线回路长，如果传感器用杜邦线延长，信号质量下降尤其明显。另一种原因就是供电电压偏低，传感器3.3V电源引脚有毛刺，给传感器供电端加10uF和0.1uF电容基本能解决。

现象3：OLED、SHT30、BH1750三台设备挂同一条总线，某些设备一直No Ack。这种大概率是I2C地址判断错了，或者模块的ADDR引脚悬空/电平设置导致地址改变。可以用HAL_I2C_IsDeviceReady循环扫描地址，把0x00到0x7F都扫一遍，很快能确认每个模块的真实地址。

4.2 串口和ESP8266通信问题

STM32和ESP8266之间的串口通信，最经典的问题就是“丢第一个指令”。很多模块上电后需要几百毫秒启动，如果STM32刚上电就发AT，肯定会丢掉。建议在发送AT指令前先发一个空的“AT”，等待模块返回“OK”后再进入正式流程。另外AT指令的结尾必须是“\r\n”，很多人只发“\n”，导致模块不识别。

ESP8266反复重启，这个问题十有八九是供电不足。我遇到过STM32这边用同一个3.3V LDO带ESP8266，每次发射WiFi的时候屏幕跟着变暗，然后模块自动重启。解决办法是给ESP8266独立供电，或者用带载能力更强的降压模块。如果串口和ESP8266之间没有共地，也会出现接收乱码，注意GND必须可靠连接。

如果MQTT连接失败，先不要怀疑STM32代码，用电脑上的MQTTX或者Mosquitto订阅同一个topic，然后通过AT指令手动发一条消息测试。能收到，再回头查STM32的串口发送逻辑。我调试时习惯把ESP8266回显的内容全部打印到调试串口，否则看不到模块的报错信息。

4.3 低功耗模式不省电怎么办

第一次测试低功耗时，我把MCU切到STOP模式，结果量电流还有几十毫安，完全不符合预期。后来逐个排查发现，罪魁祸首是三个没关的外设：OLED一直上电、传感器一直上电、ESP8266处于待机模式仍然耗电。真正设计低功耗系统时，外设供电要能切割，比如用MOS管或负载开关控制传感器和OLED的电源，需要测量的时候再上电。

更隐蔽的是GPIO悬空漏电。进入STOP模式前，所有外部中断引脚、I2C引脚都要做处理，尤其I2C的上拉电阻是从3.3V接出来的，如果SDA/SCL引脚在休眠时没有配置成高阻或者保持确定电平，可能会形成贯通电流。用L431的低功耗模式，还要注意RTC唤醒后系统时钟从HSI重新起振需要时间，不要在唤醒中断里立刻做耗时的传感器采集，否则历史记录会出现时间戳跳动。

4.4 传感器数据漂移和标定

SHT30虽然是数字传感器，出厂前做过校准，但长期在潮湿、粉尘环境下使用，读数会逐渐偏移。我建议每半年就和标准温湿度计放在同一个密闭环境里对比一次，做单点偏移修正。修正后的系数可以存在STM32的Flash里，不要每次编译都写死，否则现场校准后重新烧录程序就会丢掉修正值。

BH1750的问题主要是镜头脏污。有一次光照数据持续偏低，排查好久才发现是传感器上盖了一层灰尘。加一个透明滤光罩并定期清洁，能避免很多麻烦。SGP30需要预热时间长，头几天的数据根本不可信，如果项目急着上线，可以先用厂家默认算法跑起来，等一周后把零点校准的数据重新写入模块，这样后续曲线会更稳。

下面用一个表格把常见问题汇总一下：

5. 从样机到可用系统，还能怎么扩展

第一版系统做完之后，你会发现它已经能实现“监测”这个核心目标，但如果真的拿去博物馆现场部署，可能还需要解决几个现实问题：采集点太少、数据没有联动、网络覆盖不足、设备状态无法远程看。下面这几个方向是我自己正在扩展或者调研过的，可以根据自身需求选做。

5.1 单点扩展到多点监测

一个博物馆库房面积很大，单靠一个监测终端很难覆盖。最简单的方式是设计成RS485总线：每个采集节点用STM32采集传感器数据，通过RS485总线连到主控，主控汇总后统一显示和上报。RS485支持多个节点挂在同一条双绞线上，通信距离能到上百米，适合现有库房改造。如果不想布线，也可以给每个节点加LoRa模块，用LoRa网关集中接收，虽然成本高一些，但能灵活布置。

多节点系统有个新问题：时间同步。每个采集节点如果各用STM32内部RTC，时间会慢慢漂移，历史数据对不齐就难分析。建议主控通过NTP或者基站校时后，周期性地给从节点广播时间戳，保证全系统时间基本一致。这个工作不复杂，但能显著提升数据质量。

5.2 数据可视化与联动控制

监测数据上云后，最好配合一套可视化界面。用现成的物联网平台或者开源监控系统，比如Grafana，把MQTT数据库里的数据做成趋势曲线和报警面板，现场管理员打开网页或者手机就能看到各点位的历史曲线，不用专门跑到设备前看OLED。我用过这种组合，效果比自己在嵌入式里画曲线好得多，开发成本也低。

更进一步的联动控制是空调、加湿器、除湿机和新风系统。STM32通过继电器或者RS485协议控制这些设备，根据监测数据自动调节环境。比如湿度低于45%时启动加湿器，高于65%时启动除湿机，亮度超标时联动窗帘电机。做联动时要注意启动延时和死区，避免设备频繁启停。联动控制不是环境监测的必需功能，但加上之后，系统就从“看着环境变坏”变成了“主动维持环境”，对文物保护的意义更大。

5.3 数据积累后的趋势分析

等系统稳定运行几个月，后台积累了大量的历史数据，就能做更有价值的事情。比如观察不同季节、不同展柜内温湿度的日波动规律，提前预判哪些时间点容易超标。再比如通过数据发现某台空调设备工作异常，往往在故障前几个小时耗电量或者送风温度已经出现轻微偏移，用简单的统计方法就能捕捉到。这些分析已经不局限于嵌入式开发，更像是数据驱动运维，但对文物保护来说非常重要。

从我的体会来看，做这类系统不要迷信传感器越贵越好。系统稳定、数据可追溯、报警及时，这三件事比什么都重要。你把一套SHT30加BH1750做到运行半年不重启、不丢数据，远比堆一堆高精度传感器但三天两头断线更有实用价值。如果后续想继续深挖，可以研究一下STM32的OTA固件升级，或者把本地离线存储的历史数据导出到U盘，这样即使断网也不会丢掉现场记录。总之，文物环境监测的目的是让环境变化“看得见、记得住、追得回”，每一次报警和每一份历史数据，都应该能反过来帮助你优化保存条件。这才是这个项目最有意义的延展。