基于STM32的POE温湿度记录仪：SNMP历史数据与审计报表实现

机房运维这行干久了，最难堪的时刻不是设备故障本身，而是故障后给不出过程数据。我有一次处理机房空调停机，等赶到现场时设备已经高温自动关机，但原有监控系统只能告诉我"几点几分超过阈值"，之前三四个小时温度是怎么一步步涨上去的，曲线完全没有。家底薄的监控日志根本经不起审计。后来我决定自己动手做一套带本地存储的POE温湿度记录仪，走SNMP协议读历史曲线，最后导出机房审计报表，前前后后折腾了三个多月，硬件、协议、报表链路全部打通。现在把这套方案拆开来说清楚，给正在做机房环境监测、边缘数据采集或者物联网记录设备的朋友做个参考。

这个项目说白了就干三件事：让记录仪通过网线供电（POE）、数据存本地不死机丢数据（SD卡/Flash）、对外提供SNMP服务让上层直接读历史数据并生成报表。市面上的商用温湿度记录仪往往只给一个封闭的HTTP接口或者私有协议，历史数据被锁在厂商服务器里，审计时要么导不出来，要么格式不规范。自己做一套的好处是所有OID、存储结构、报表模板都自己说了算，后期想接Grafana、Prometheus还是私有运维平台都容易。

1. 机房温度审计需求背后的三个隐形痛点

1.1 只看实时告警解决不了"事后追溯"

绝大多数机房的温度监控停留在"超过阈值就发告警"这个层面。实时告警虽然及时，但审计问询时往往需要回答三个问题：温度是从什么时候开始异常爬升的？异常持续了多久？期间还有没有其他关联指标变化？如果记录仪自身不带本地存储、上层平台也只保留短期的轮询结果，这些问题基本答不上来。

我最早调研过几款商用POE温湿度传感器，它们的本地缓存通常只有几千条记录，五分钟采一条只能存三四天，想跨月拉曲线要不停翻平台。还有的所谓"历史曲线"其实依赖服务器端数据库留痕，一旦平台迁移、数据库清理或者网络抽风，那一小时的数据缺口就永远补不上。而本项目的设备端就是第一手数据源，断电断网都不影响数据落盘，这是审计安全感的来源。

1.2 SNMP协议不是"老古董"，是审计场景的刚需

很多做物联网的人觉得SNMP太老，都用MQTT了。但机房里的NVR、路由器、UPS、空调监控卡，几乎全部支持SNMP。机房审计系统、动环监控平台、网络管理软件（如Zabbix、华为esight、SolarWinds）对SNMP的兼容性远好于自定义协议。用SNMP对接记录仪的历史数据，等于让这台设备天然融入已有运维技术栈，不需要额外装Agent，不用开放SSH，只需要暴露几个OID就够了。

在热词里看到"华为 snmp实验"、"stm32 snmp trap v2c 代码"这类搜索，说明不少同学是在嵌入式设备上实现SNMP或者做网管联调时遇到了需求。实际上SNMP v2c的GET、WALK操作足够读取历史数据，TRAP可以作为越限触发的主动通知。用好了，一个传感器节点和一个交换机一样，管理端无感接入。

1.3 本地存储必须跟"供电方式"一起设计

POE供电的优势是省去一根电源线，但POE供电本身也有讲究。IEEE 802.3af标准最大提供约13W功率，到了802.3at（POE+）约25.5W，一个温湿度记录仪加上SD卡和以太网模块，功耗也就两三瓦，af足够了。真正要命的是POE交换机的PSE供电策略——有的交换机默认不做PoE定时供电，夜晚会断电来节能，这对实时性要求不高的传感器也许没事，但如果记录仪依赖不断电做数据写入，就会在断电瞬间产生文件系统损坏。

所以本地存储不能简单插个SD卡就完事，必须考虑掉电保护。这个小细节后面硬件章节细说。

2. 硬件选型：POE供电、本地存储与传感器三者的匹配逻辑

2.1 主控与以太网方案：STM32F407 + W5500 的黄金组合

芯片选型时我对比了好几个方案：

我最终选了STM32F407+W5500，原因是这台设备不仅要跑SNMP Agent，还要驱动SD卡记录数据、处理传感器读取、运行简易文件系统，而且现场可能出现多个管理端并发轮询。W5500自带完整的TCP/IP协议栈，主控不用在协议上投入太多心力，开发效率高。F407有足够RAM和Flash，后期想加TRAP、加Modbus转发、加Web配置页都能扛得住。

2.2 POE供电模块：隔离与非隔离的选择

POE供电一开始就要确定是用标准802.3af PD方案还是非标准的被动POE。标准PD（比如SI3402模块）会与PSE做特征电阻识别和分类握手，安全可靠，45W以内的大功率设备也适用。被动POE虽然便宜，但如果插到标准PSE上可能因为电压/极性不匹配直接烧设备，机房环境里风险太大，不建议用。

选型时注意PD模块的输出功率余量。一个模块额定输出13W，实际记录仪在SD卡写入瞬间的电流尖峰可能到400mA，加上W5500和传感器，峰值功耗在1.5W～2W之间，余量很充足。如果同时还要带一路外接排气扇，那就要往POE+方向选PD模块，否则时序上启动扇子的一刻电压跌破设备工作范围，系统可能反复重启。

2.3 传感器选型：SHT30在精度与成本之间最稳

温湿度传感器可选空间很大。DHT11太粗糙，SHT31高精度但是贵，SHT30在0~60°C范围内典型精度±0.3°C，湿度±2%RH，机房审计场景已经绰绰有余。关键要选带I2C地址可配置的型号，一条I2C总线上可以挂多路传感器。我在项目里预留了两路传感器接口，一路测机柜前门温度，一路测回风温度，后期扩展部署非常方便。

传感器读取不能一条I2C命令搞定就完事，SHT30在测量后需要等待约4.5ms的数据就绪时间，如果固件里不加延时或者不加数据就绪标志判断，会出现偶发的读回0xFFFF或数据跳变。另外传感器应远离W5500和变压器的散热区，不然测到的温度是板温。

2.4 本地存储：SD卡还是SPI Flash？

存储方案我纠结了最久。SPI Flash（W25Q64等）可靠性高、没有文件系统碎片问题，但容量通常只有64Mbit（8MB），以5分钟一条记录、每条记录约40字节计算，存储深度只有约3.7万条记录，也就是4个多月的量，对审计要求来说偏紧。

SD卡容量可以做到32GB直接覆盖十年级别的数据，但它有两个致命弱点：一是文件系统容易在突然断电时出现FAT表损坏，二是廉价SD卡的写寿命和稳定性参差不齐。

我的解决办法是双路存储：SD卡作为主线存储，定期把数据导出到CSV文件；板载W25Q64作为循环应急缓冲区，当SD卡尚未就绪或者文件系统异常时，先写到Flash，随后再补录。这个设计在实际运行中帮我挽回过一次因劣质SD卡导致的数据空白，功耗也只增加了不到0.3W。

2.5 硬件组装的几个关键细节

• 电源去耦在POE模块输出处必须加足够容量的钽电容/电解电容，通常330uF起步。POE握手成功后PSE会突然送电，瞬间的inrush current会导致输出电压跌落，没有储能电容会直接重启。
• 传感器探头用RJ45延长座的方案，可以做成外置探头，方便卡在机柜前后门。做线的时候注意I2C的SDA/SCL不能超过400kbps，线长超过0.5m建议走100kbps。
• SD卡座要用自弹式带卡检测引脚的类型，固件里可以通过卡检测引脚感知SD卡是否插牢，减少"明明插了卡但上报存储异常"的误报。
• W5500的INT引脚必须接主控的外部中断，不然在SNMP并发请求多的时候可能丢包。

3. SNMP历史数据读取：从设备OID到曲线图的完整链条

3.1 私有OID规划：不能随手乱写

SNMP读取历史数据，关键在设计一套合理的OID结构。标准MIB-2（如system、interfaces）是留给网络设备的，温湿度记录仪要做成企业私有MIB，一般挂在enterprises节点下面。假设企业号为45214，那设备基础信息就可以规划成：

1.3.6.1.4.1.45214.x.1.0 设备信息（厂商、型号、固件版本） 1.3.6.1.4.1.45214.x.2.0 当前温度 1.3.6.1.4.1.45214.x.3.0 当前湿度 1.3.6.1.4.1.45214.x.4.1.<index> 历史记录温度表 1.3.6.1.4.1.45214.x.4.2.<index> 历史记录湿度表 1.3.6.1.4.1.45214.x.4.3.<index> 历史记录时间戳表 1.3.6.1.4.1.45214.x.5.0 告警状态

时间戳建议用Unix时间戳（The 'unsigned integer' type），这样管理端不需要处理字符串解析，绘图时直接转成本地时区即可。历史记录表可以按记录ID连续递增，SNMP WALK顺着表走一遍就能取出所有历史数据。

3.2 Agent端实现：基于Net-SNMP移植还是手抄协议栈

STM32上实现SNMP Agent有两条路子。第一条是用现成的Net-SNMP交叉编译到ARM平台，但Net-SNMP体量庞大，在STM32上跑吃力；第二条是手写一个轻量SNMP Agent，只实现需要的MIB子树和GET/WALK操作。

本项目我用了自研轻量Agent的思路，核心代码只有几百行。理由很直接：历史记录表的WALK在SNMP标准协议里逻辑相对简单，请求OID、找到对应记录、响应OID和值，不需要复杂的SET操作。SNMP v2c消息格式也就BER编码，用STM32的C代码完全可以控制住。

提供一段核心的GET处理思路示意：

// 伪代码/核心逻辑示例：根据OID定位到历史记录 static int mib_history_lookup(oid *oid_array, size_t oid_len, record_t *rec) { // 判断属于history的哪一列（温度/湿度/时间戳） int column = oid_array[ARRAY_POS_COLUMN]; int index = oid_array[ARRAY_POS_INDEX]; if (index <= 0 || index > get_max_record_index()) return OID_NOT_FOUND; rec->column = column; rec->index = index; return OK; }

真正的实现里还需要处理BER TLV的编解码、OID压缩编码（子标识符1234会被编码成0x80, 0x2A等），细节很多，但想拓展的同学可以先拿现成库比如“lwSNMP”来改。

3.3 TRAP主动推送：越限不能只靠轮询

历史曲线适合用GET/WALK去拉取，但实时告警必须有主动推送机制，否则轮询周期太长，温度突变可能到下一轮才被发现。我在Agent里实现了SNMP TRAP v2c，当温度超过设定阈值，主动向管理端发送一条包含设备编号、当前温度、湿度、时间戳的TRAP报文。

TRAP的实现在STM32上有个坑：TRAP报文和普通GET响应的构造过程几乎一样，但TRAP目标地址由配置文件指定，而且标准UDP端口是162，防火墙经常拦。实测发现机房网络里必须提前确认UDP 162端口未被ACL阻断，否则告警消息静默丢失。我的做法是在TRAP头里加一个本地性能标志“engine id”的方式避免被部分网管平台因SNMP版本校验直接丢弃。

3.4 管理端读取历史数据并绘图

管理端我用Python写了一个调度脚本，基于pysnmp同步获取，每5分钟拉一次数据并写入SQLite，配合Grafana或matplotlib绘图。用pysnmp进行历史表WALK的示例：

from pysnmp.hlapi import * def walk_history(ip, community='public'): hits = [] for (errorIndication, errorStatus, errorIndex, varBinds) in nextCmd( SnmpEngine(), CommunityData(community, mpModel=1), UdpTransportTarget((ip, 161)), ContextData(), ObjectType(ObjectIdentity('1.3.6.1.4.1.45214.x.4')) ): if errorIndication or errorStatus: break for varBind in varBinds: hits.append(varBind) return hits

曲线绘制我直接用了Grafana+SQLite数据源。

如果你不想引入Grafana，用matplotlib把SQLite里的数据按天导出成PNG图片，然后嵌入网页或邮件发送，也能达到审计展示的效果。曲线图的美化不重要，关键在时间轴的连续性，处理好时区偏移。

3.5 历史曲线的"完整性校验"

由于SNMP GET请求的数据包大小有限，一次WALK大量历史记录可能因为UDP分片或者Agent处理超时被截断。设计Agent时不能让管理端一次性WALK全部记录，而是按时间分页，或者按记录ID分段。我在管理端脚本中实现了按日的范围WALK：当天记录ID在A到B之间，只WALK这个区间，第二天再WALK下一个区间。

用SQLite存储到本地后，我还会做完整性校验：如果发现相邻两条记录的时间间隔远大于采集周期（例如5分钟采一条，却发现间隔30分钟），就标记为“疑似异常断档”，同时在审计报表最后一行列出断档时间段。机器可以偶尔断网，但不能"瞒报自己断网了"，这是审计逻辑里很重要的一环。

4. 审计报表导出的设计与自动化实现

4.1 报表结构：给审计人员看什么

报表不是简单把温度表原样导出，而是要有"摘要+明细+取证"。我设计的报表包含以下几个部分：

• 基本信息：设备编号、位置、部署时间、固件版本
• 时间范围：本次报表覆盖的起止时间
• 温度统计：最高/最低/平均温度、发生时间点
• 湿度统计：最高/最低/平均湿度、发生时间点
• 越限事件：每一次超过温度/湿度阈值的时间段，逐个列出
• 断档记录：设备离线、存储异常等数据缺口的时间段
• 附录：完整的数据明细表

4.2 导出格式选型：CSV与Excel的取舍

审计交付时经常被要求提供Excel文档，所以我做了两种格式：

• CSV格式：机器可读性最好，适合后续二次分析、数据库导入，体积小。
• Excel格式（xlsx）：有固定模版，自动带有条件格式，比如温度高于设定阈值自动标红，适合直接发给人工审计。

用Python的pandas和openpyxl可以很轻松地把SQLite数据转成Excel并按条件着色。

import pandas as pd from openpyxl import load_workbook from openpyxl.styles import PatternFill df = pd.read_sql_query("SELECT * FROM history WHERE ts BETWEEN ? AND ?", conn, params=(start_ts, end_ts)) df['time_str'] = pd.to_datetime(df['ts'], unit='s').dt.tz_localize('UTC').dt.tz_convert('Asia/Shanghai') with pd.ExcelWriter('audit_report.xlsx', engine='openpyxl') as writer: df.to_excel(writer, sheet_name='明细', index=False)

如果你想让报表直接通过邮件定时发送，用Python的smtplib和email模块打包，配合系统的crontab或Windows任务计划，就能做到每周一早上9点自动把上周的审计报表发到负责人邮箱。我在项目中就是月度打包成ZIP再发。

4.3 越限事件与断档记录怎么自动标记

SQLite里我除了历史明细表，还维护一张event_log表，每次Agent处理过程中发现温度越限、TRAP发送成功/重试失败、SD卡写失败、断电重启都往里写一条事件记录。

生成审计报表时，直接查询这张表并按时间段归类。需要注意：越限事件的时长计算不能简单用“越限时刻减解除时刻”，因为可能中间管理端离线，Agent端TRAP重发多次但都没收到响应。我的做法是每次轮询都记录一个"当前是否越限"的布尔字段，报表统计时重新从明细数据计算越限时刻和解除时刻，保证计算逻辑不受网络抖动影响。

4.4 报表自动生成的时间窗口设计

审计报表通常按天、按周、按月三个维度生成。我在设计时可没想着每生成一次就全量导出，那会让系统在月末那个小时性能很差。更好的方式是把历史数据分成"当前月分区"和"历史月分区"，日报只读当天数据，月报读整月数据后汇总，同时增量更新摘要表。

一套记录仪可能在现场连续运行一两年，报表导出的SQL查询如果没有索引，后期会越来越慢。我给历史表建了(ts, device_id)联合索引，SQLite查询性能大大改善。数据量在两百万条记录时，月报生成时间从最初的十几秒降到两秒内。

5. 实测运行效果与现场排查经验

5.1 一个真实机柜的24小时曲线

部署在通信机房一个标准42U机柜温度采集点后，记录了24小时的温湿度数据。温度白天稳定在23.5°C～26.8°C之间，凌晨空调低负荷运行，温度降到22.1°C。湿度基本维持在45%～55%RH。整个曲线在Grafana里正常显示，SNMP WALK拉取六个月历史记录也没有出现大缺口。

对比同机柜原商用传感器的数据，温差在0.3°C以内，湿度在2%RH以内，符合预期。

5.2 踩坑记录一：POE供电不稳导致SD卡文件系统损坏

第一版样机连续跑了十天，某天查看历史发现某一段记录全部丢失。检查代码没发现逻辑问题，后来查SD卡文件系统，发现FAT表异常。原因是这台交换机是支持PoE的8口千兆交换机，但有PSE省电策略，当负载电流低于阈值时会自动断电再重启。记录仪断电瞬间，SD卡正在进行写入，于是文件系统崩溃。

解决方案是三步走：第一，SD卡在每次写入前先调用flush，确保数据进入物理扇区；第二，SD卡格式化时预留一段FAT备份区，启动时自动做一致性检查；第三，应急Flash缓冲区优先级更高，遇到SD卡写入失败立刻切到Flash，不阻塞主流程。

经过这轮修改，后续三个月没有出现过数据断档。

5.3 踩坑记录二：SNMP响应速率过快导致UDP丢包

W5500硬件协议栈性能很强，我刚开始没有限速，管理端WALK几百条历史记录时，Agent以毫秒级速度连续发送UDP响应，结果管理端pysnmp经常报超时。原因是管理端处理SNMP响应需要时间，UDP缓冲区溢出。

解决方法是Agent响应之间加微延时，比如每条记录间隔1ms～3ms，W5500的发送缓冲区分割成多个小段，每条记录独立发送。同时管理端WALK时增加下行重试次数，观察吞吐量从每秒几十条提升到稳定每秒两百多条，再也不丢包。

5.4 踩坑记录三：传感器受通风道影响读数偏低

在调试初期，我把传感器板卡直接贴在交换机散热口附近，测得的温度始终比机柜前门温度低三四度。实际上传感器探头必须尽量处于空气自由流通的位置，不能被机柜钣金遮挡，也不要在服务器正面出风直吹的位置附近。后来我把探头用延长线引出到机柜前门进风口的位置，读数与机房动环平台的实际温度趋于一致。

5.5 关于后续扩展的几个方向

方案稳定后，我额外做了两件事：一是把SNMP Agent的能力延伸到了"多设备管理"模式，一台采集器后面挂多个传感终端，走私有协议汇总后统一对外提供SNMP接口；二是把历史数据在管理端自动同步一份到对象存储，机房现场即使损毁，审计数据仍有备份。

如果你也准备做一个类似的设备，我的核心建议是最开始就分好"设备存储模型"与"管理端读取模型"，不要把历史数据的组织方式跟报表需求耦合太深。设备端只负责可靠地记录和按OID暴露数据，报表是上层的事。切好这一刀，后面所有功能都能顺畅加上。