去年冬天实验室那台精密分析仪突然离线，我赶过去才发现是给它的那路电源模块输出掉了，却没有任何人收到过通知。更狼狈的是，那次异常直到一周后翻记录时才被察觉，白白损失了好几组实验数据。那次之后我下定决心，不再依赖单一的成品电源，而是自己动手搭了一套完整的 Power Supply Monitoring and Control System。
现在这套系统已经在工位上稳定跑了半年多，市电输入、各路输出电压电流、功率、温度、开关状态全部实时可见，异常时能自动断电保护，也能发告警到手机。这篇文章就把这大半年里从0到1的完整过程写出来，包括硬件选型、采样电路设计、固件逻辑、校准方法以及实际部署中踩过的坑。如果你是电子工程师、嵌入式开发爱好者，或者只是搞了几个外设想知道它们到底吃多少电，这篇文章都值得花十分钟看完。
1. 为什么放着现成的PDU/电源监控模块不用，非要自己造一套
市面上并非没有电源监控方案。网络机柜里常见的智能PDU可以测电流，高端电源自带I2C/PMBus接口能回读电压电流，还有一些带屏幕的数控电源模块也能做基本的监控。但真的用起来，你会发现它们各自有各自的别扭。
1.1 成品方案的三类痛点
第一类是信息封闭。很多智能PDU回传的数据只有电流和总功率，根本没有单路的电压数据和开关状态。你只知道这一路“还在跑”，但不知道它是在12.1V还是10.8V这种危险边界上跑。对敏感负载来说，电压偏离往往比过流更致命。
第二类是可控性差。PDU能做的控制通常只是“远程开/关这一路”，但做不到按阈值自动保护，更别说把保护逻辑做成一套可配置的策略。第三类是协议绑定。设备本身的网管协议和云平台绑定得死死的，想接入自己的监控面板、数据库，需要逆向或者等官方API，麻烦又被动。
自己做一套的成本其实很低：一块ESP32或STM32，一个INA226电流/电压采集芯片，一个固态继电器或MOSFET开关，加上24V转5V的电源模块，几十块钱就能把硬件打样出来。真正的工作量在固件逻辑和后期校准上，但这部分恰恰是最能沉淀成经验的地方，也是我最有收获的部分。
1.2 确认自己的真实需求清单
动工之前，我花了一个晚上把需求写到纸上，避免做成一个“什么都有但哪都不好用”的东西。我的需求清单大概是这样的：
- 监测范围：6路独立负载输入，每路支持0-30V/0-10A，精度要求电压±0.05V、电流±0.05A；
- 采集刷新率：1秒1次，告警判定需要100ms内响应；
- 控制能力：支持远程开/关每一路，支持过压、欠压、过流、过温自动保护；
- 通信方式：现场有局域网，直接用WiFi+MQTT，方便和自建的Web面板集成；
- 可靠性：一旦MCU死机或通信失效，所有输出必须保持原状态，不能直接断开造成负载丢失。
如果你不需要多路，只是想盯着某一台设备，那可以砍到只有1路，成本和复杂度都会低很多。这篇文章下面还是以6路为例讲，因为单路系统的所有问题在这个方案里都会被放大，能讲得更清楚。
2. 系统架构选型：传感器、主控、执行器怎么各司其职
整个系统拆开看就是一条链路：采样感知、主控决策、执行动作、通信上报、面板展示。链路不复杂，但每一环的选型都会直接影响最终的效果。
2.1 采样方案：为什么我选了INA226而不是霍尔传感器
电压电流采集有几种常见路线，我在选型时认真对比过。
用电阻分压加ADC（比如STM32内置ADC）最便宜，但问题是采样精度受ADC参考电压漂移和PCB噪声影响很大，要获得0.05V级别精度，你得上低温漂基准源加差分放大，复杂度反而上去了。霍尔电流传感器（ACS712等）适合大电流和隔离场景，但小电流下线性度差，10A量程测0.1A时误差能到百分之十几，不适合需要精细读数的场景。
最终我选的是TI的INA226，一块既能测电压又能测电流的双向监控芯片。它的核心原理是让负载电流流过外部采样电阻，通过内部差分放大器测量电阻两端压差来计算电流，同时另一路ADC直接测量总线电压。芯片内置16位ADC，精度很高，而且通过I2C接口最多可以挂16个地址，很适合做6路甚至更多路的扩展。
INA226的另一个好处是自带电流/功率告警比较器和可配置的转换时间，告警响应不用主控轮询。实际做下来，这个芯片没有让我失望，配合低温漂采样电阻，全量程精度轻松达到需求。如果预算再紧张点，也可以用INA219，但注意INA219只有12位ADC，电流分辨率略低，长期稳定性也不如INA226。
2.2 主控选型与通信协议：ESP32的取舍
主控我直接用了ESP32-WROOM-32E。选择它有几个非常现实的原因：第一，自带WiFi和蓝牙，通信不需要再加模块；第二，I2C硬件接口够稳，能够承载6路INA226的轮询；第三，社区资料多，写代码遇到问题几乎都能搜到答案。
不过ESP32也有一个明显的短板：长期工业级可靠性不如STM32，特别是WiFi协议栈出问题时容易死机。我在系统里加了一个硬件看门狗，一旦主控失联，输出状态保持原值，并且通过LED和蜂鸣器本地告警。关于看门狗的具体做法，后面有专门的章节讲。
通信协议我在Modbus RTU和MQTT之间选了MQTT。原因很简单：我的上位机是Web面板，而MQTT走局域网非常方便，配合Eclipse Mosquitto做Broker，几十毫秒就能完成一次状态推送。Modbus RTU如果走RS485，需要额外芯片，且和Web面板对接要自己写TCP网关，明显更折腾。如果未来要接入PLC等工业系统，再挂一个Modbus RTU从机也不难，但现阶段MQTT足够好用了。
系统整体架构可以概括成一句话：INA226负责感知，ESP32负责决策，MOSFET负责执行，MQTT负责传递，Web面板负责呈现。
2.3 控制执行器：MOSFET和继电器各用对场合
每一路的通断控制，我对比了继电器和MOSFET两种方案。继电器有明显的机械触点声，抗过载能力好，导通电阻几乎为零；但问题是寿命有限（开关次数最多几十万次），而且线圈需要驱动电路，响应速度是毫秒级。MOSFET没有机械结构，响应微秒级，寿命几乎无限，但需要注意散热和导通关断时的浪涌。
我最终选择的是P沟道MOSFET做高边开关，型号是AO3401A，负载电流最大4A，对这个场景足够了。如果是更大电流（10A以上），可能要考虑N沟道MOSFET配电荷泵驱动，或者直接上固态继电器。
这里有个很关键的细节：MOSFET关断时，如果负载是感性或容性负载，会产生反电动势或浪涌电流。后者在上电瞬间特别明显，因为电容充电瞬间相当于短路。我处理的办法是在每一路输出并联一个预充电电阻回路，上电时先通过电阻给电容充电，200ms之后再旁路掉，这样能避免大部分MOSFET被浪涌击穿的情况。
3. 硬件核心设计：采样电阻、电源树和PCB布局的细节
很多初做电源监控的人容易忽略硬件细节，认为“芯片选好了，接线就完事”。实际上，采样精度和长期稳定性很大程度都取决于这里的硬件功夫。
3.1 采样电阻的选用：散热和温度系数需要同时关心
INA226再准，如果采样电阻不准，一切白搭。我用的是2mΩ的合金电阻，封装2512，额定功率1W，温漂系数50ppm/°C以内。这组参数怎么定的？举个例子，当电流为10A时，采样电阻上的压降为20mV，功率为0.2W，虽然距离额定1W还有余量，但考虑到PCB上紧挨着其他发热元件，温度可能上升20°C，2mΩ带来的阻值偏差约为2mΩ × 50ppm × 20 = 2μΩ，反映到电流读数上大约是1mA，完全可接受。但如果用了廉价碳膜电阻，温漂可能到几百ppm，那就成了误差的主要来源。
采样电阻的layout也非常重要，它必须使用四线开尔文连接：两线给电流通路，两线给INA226的差分采样。如果直接拿一根长走线串联采样，铜线本身的电阻变化会混进读数，误差会非常随机。我第一版PCB就没做开尔文连接，结果同一路电流在冷机热机时能偏出0.3A，后来改版后才稳定下来。
3.2 电源树设计：独立模拟供电是精度保障
6路INA226的数字部分由ESP32的3.3V供电，模拟参考电压部分我单独用了一个低噪声LDO（AMS1117-3.3）供电，和主控的数字电源做了磁珠隔离。原因很简单：ESP32的WiFi发射瞬间电流可达几百毫安，会拉低数字电源电压，即使在I2C通信里不产生协议错误，但INA226的参考电压如果和数字电源共享，采样值会出现几十毫伏的跳动。隔离之后，实测WiFi广播时电压读数纹波从±0.12V降到了±0.01V以内，效果非常显著。
主电源树的结构是：外部24V输入 -> DC-DC降压到5V（给MOSFET驱动和蜂鸣器）-> LDO降到3.3V（给ESP32和INA226模拟部分）。每一级的电容选型也很关键，DC-DC输出端要低ESR的固态电容，而LDO输入输出端分别加上10μF和22μF陶瓷电容，避免高频振荡。
3.3 PCB布局的几条硬性经验
因为这是一个小规模系统，我没有用四层板，两层板就能搞定。但两点经验必须提醒：第一，INA226的采样电阻要靠近输入端，远端负载线缆尽量短，减少长线电阻的干扰；第二，MOSFET的漏源极走线要走宽（至少2mm），不然大电流下铜箔会发热甚至烧断。
另外，所有地平面最后用单点汇聚到电源输入端，避免模拟地和数字地在多个点混合连接形成地环路。这一点在开始布线时就要规划好，如果第一版图没考虑，后面调试时容易遇见莫名其妙的数据跳动；而改成单点接地后，我的系统所有通道的底噪都降到了1mV以下。
4. 固件逻辑：状态机、滤波算法和EEPROM存储
固件是这套系统里工作量最大、也最能折腾人的部分。它的核心不只是“读芯片、发数据”，更重要的是如何让数据稳定、保护逻辑可靠、故障时行为可预测。
4.1 I2C轮询与数据滤波：不能直接拿原始值用
ESP32作为I2C主机，需要以1秒周期轮询6个INA226地址。每轮读取需要约10ms，所以CPU占用很低。但INA226的原始读数是有噪声的，特别是电流在小电流段时，噪声比例会比较高。我第一版直接显示原始值，结果待机电流0.3A时读数在0.1A到0.5A之间跳，非常难看。
后来加了滑动窗口滤波：每路维护一个长度为10的环形缓冲区，每秒钟更新一个值，计算平均值作为显示值。同时保留原始的瞬时值用于告警判定。这个设计是有意的：显示值要平稳，告警值要灵敏。如果告警也用滤波后的平均值，那响应时间会被拉到最长10秒；当发生短路或过流时，这10秒可能就够设备烧坏了。
INA226还有个配置项是ADC转换时间和采样平均数。我把电压和电流的ADC转换时间都设为588μs，采样平均数为8次。这样每次测量大约4.7ms，对1秒轮询完全够用，同时能显著压低噪声。如果对实时性要求更高，可以减少平均次数，但噪声相应会变大。
4.2 保护逻辑状态机：从正常到故障再到恢复
保护逻辑我用状态机实现，状态包括NORMAL、WARNING和FAULT。NORMAL状态下，每路实时检查电压、电流、功率和温度四个维度；一旦某个指标超过阈值，就进入WARNING，此时不会立即断电，而是先触发告警并等待一个可配置的延时（默认2秒）；如果2秒后还在异常区间，才进入FAULT状态并关断对应通道。
这个“先告警再动作”的设计很重要。有些负载启动瞬间电流会短时超过额定值，例如电机或者有大电解电容的DC-DC模块，如果刚观察到过流就立刻切断，会导致系统频繁误动作。我在实际测试中发现，某种工业触摸屏上电瞬间电流会跳到额定值的3倍持续约150ms，如果设了瞬时保护，它永远开不了机。所以阈值和延时需要针对每路负载个性化配置。
FAULT状态一旦进入，这一路必须通过手动远程复位或者本地按键才能重新上电，不允许软件自动恢复。这个选择是吸取了群里一位朋友的经验：他的系统在晚上因为某路负载瞬间过流被保护，但第二天负载恢复正常，如果自动恢复会导致冲击更大，结果过热烧坏了电源。自动恢复看似方便，在保护场景里却可能放大故障。
以下是保护逻辑的简化伪代码：
enum State { NORMAL, WARNING, FAULT }; void loop() { for (int i = 0; i < CHANNEL_COUNT; i++) { sample = readINA226(i); switch (state[i]) { case NORMAL: if (isOverThreshold(sample)) { state[i] = WARNING; warningTimer[i] = millis(); sendAlarm(i, "warning"); } break; case WARNING: if (!isOverThreshold(sample)) { state[i] = NORMAL; break; } if (millis() - warningTimer[i] > WARNING_DELAY_MS) { channelOff(i); state[i] = FAULT; sendAlarm(i, "fault"); } break; case FAULT: // 等待远程或本地复位 break; } } }4.3 看门狗与断线策略：死机时不能丢输出
前面提到ESP32可能在WiFi协议栈异常时死机，因此我在固件里加了两种看门狗：内部任务看门狗和外部硬件看门狗。内部看门狗依靠FreeRTOS的任务通知来实现，如果主任务超过3秒没喂狗，就强制重启；外部硬件看门狗用一个独立的555定时器电路实现，主控正常时定期输出一个高电平脉冲，如果超过5秒没有脉冲，输出控制锁存器就会保持最后的电平状态。
这里必须强调：当主控死机时，所有通道必须保持通电前的状态，不能直接关闭。我一开始用的是在死机时把输出全断掉的逻辑，想着“安全第一”。但后来发现这对无人值守的负载来说反而是灾难：如果某路正在跑一个需要连续运行24小时的电机设备，监控系统死机一次就把它停了，这个损失比监控系统本身的价值还大。正确的做法是让输出状态完全由锁存器保存，主控只是负责“改变”它，而不是通过持续控制来“维持”它。
同时，通信断开也要有策略。我配置了MQTT的Last Will和遗嘱消息：当ESP32和Broker断开连接时，Broker会自动发布一条离线消息，上位机收到后立即在面板上显示告警。这样即使设备本身没有感知到任何电气异常，运维人员至少知道“监控系统失联了”，而不是傻等。
4.4 关键参数存储：EEPROM里存什么
校准后的电压/电流偏置、各路负载的路由名称（比如“LED灯带”“工控主机”）、过压欠压过流阈值、告警延时，统统存在NVS（非易失存储）里。NVS的好处是掉电不丢、支持键值对读写，不用自己设计存储格式。
一个重要的细节是：修改阈值时不能直接写入，要写入后重启并回读验证。我之前遇到过在运行中频繁写NVS导致存储区损坏的情况，后来在每次写操作前增加写入校验和，并在重启后打印参数对比，确保没有问题再继续运行。如果你只是玩玩，不搞这些也能跑，但如果是长期运行的系统，这点成本绝不能省。
5. 上位机和远程监控：数据要变成能看懂的告警才有价值
硬件和固件都通了之后，真正让这套系统“好用”的是上位机和告警链路。我不建议一上来就搞复杂的App，一个Web面板加一个告警机器人就能覆盖90%的需求。
5.1 MQTT主题设计和JSON消息格式
MQTT主题我按“层级清晰、便于通配订阅”的规则设计：
powermonitor/{device_id}/status # 周期上报，1秒一次 powermonitor/{device_id}/alarm # 告警消息 powermonitor/{device_id}/command # 下发控制指令周期上报的消息体用JSON，内容格式如下：
{ "ts": 1710000000, "channels": { "0": {"voltage": 12.03, "current": 0.45, "power": 5.41, "state": "on"}, "1": {"voltage": 5.02, "current": 1.10, "power": 5.52, "state": "on"} } }注意，这里我把功率值也直接算好发出来，而不是让上位机拿电压乘电流。原因是电压和电流本身有采样时间差，直接相乘会引入一定的瞬时误差；在INA226固件侧直接用芯片内部的功率寄存器读取，精度更高也减少上位机计算负担。
命令消息设计成如下格式，并带上一个递增的序列号以处理重发：
{ "cmd": "set_channel", "channel": 0, "state": "off", "token": 1001 }上位机收到后解析执行，并返回一条ACK；如果主控没有收到ACK，会重试3次。这套机制虽然简单，但避免了“命令丢了导致负载没关掉”的隐患。
5.2 Web面板：不非得用重型框架
Web面板我直接用Node-RED+InfluxDB+Grafana的组合。Node-RED订阅MQTT，把数据写入InfluxDB时序数据库，Grafana负责展示和告警配置。很多人一提物联网监控就想到用复杂的云端平台，但局域网里这套组合完全够用，而且都是开源免费的。
Grafana里我建了两类dashboard：总览页展示所有6路的状态卡片，每一路显示实时电压、电流、功率和运行时长，颜色编码标记正常/预警/故障；详情页展示某一路的历史曲线，这样能看出一台设备的用电规律，比如夜间待机电流是否异常升高，某个时间段是不是峰值功率突刺。
另外一个很有用的功能是历史回放。我在InfluxDB里保存了30天数据，出现故障后可以直接拖动时间轴回溯故障发生前后几秒的电压电流曲线，比只看瞬时值更容易定位根因。这个能力让我在排查一次“某路电压跌落”问题时直接锁定了是外部DC-DC模块老化导致的纹波超标，而不是监控系统本身的问题。
5.3 告警通知：接telegram/钉钉/邮件都行
告警我不推荐只依赖面板上的红黄绿颜色，因为人不可能一直盯着屏幕。我自己接入了钉钉机器人Webhook：当MQTT收到alarm主题消息时，Node-RED通过HTTP POST把告警内容推送到钉钉群，标题带上设备名和通道号。如果你用其他的IM，逻辑一样，都是HTTP回调，照葫芦画瓢就行。
告警内容要比“某路电压异常”这种空话强得多。我的告警模板包括：通道编号、负载名称、触发的指标、实测值、阈值、时间戳。比如：
【电源监控告警】 设备：bench-psu-01 通道：2（工控主机） 指标：电压过低 实测：10.82 V 阈值：11.00 V 时间：2025-06-01 14:22:33这样运维人员不用登录面板就能判断问题的严重程度，是立刻去机柜处理还是先观察几分钟。
6. 校准与精度验证：不校准的电源监控系统都是“仅供参考”
我以为焊好板子、烧好固件就能用了，结果一测就傻眼：INA226读到的电压比万用表低了0.25V，电流在小负载档差了0.08A。这个教训让我明白，任何ADC系统都必须校准，尤其是电流采样还要考虑线性度而不是一个零漂偏置。
6.1 校准步骤：硬件基准和线性点
电压校准不需要高级设备，一个3位半的万用表就够用。分别在空载和带载时，用万用表测输出端实际电压，同时记录INA226的读数，计算偏差值，把这个偏差作为每路电压的固定偏置保存。
电流校准稍微麻烦点，需要可调电子负载来设定不同电流点。至少选0A、1A、2A、5A、10A五个点，记录实测值和芯片读数的对应关系，用最小二乘法拟合出一个一次函数 y = a*x + b，然后把这个线性校正系数存入NVS。不要只做单点校准，因为不同电流段的误差不是固定平移，很多时候是斜率偏差。
我记得第一路通道在校准前10A档偏差是-0.23A，校准后全量程误差控制在±0.02A以内，对监控来说已经绰绰有余。
6.2 校准后的精度验证：跑一组对比数据
我整理了一组校准后10A量程的数据对比，以电流为例：
| 电子负载设定 | 万用表实测 | INA226读数 | 误差 |
|---|---|---|---|
| 0.00A | 0.000A | 0.001A | +1mA |
| 1.00A | 1.008A | 1.004A | -4mA |
| 2.50A | 2.512A | 2.509A | -3mA |
| 5.00A | 5.021A | 5.018A | -3mA |
| 8.00A | 8.034A | 8.031A | -3mA |
| 10.00A | 10.050A | 10.046A | -4mA |
这个结果验证了一个重要规律：误差在大电流段基本恒定，说明前期温漂和layout措施是有效的，剩下的误差主要来自采样电阻本身的绝对精度和万用表引入的系统偏差。
6.3 长期稳定性与温漂实测
我还特意做过一次烤机测试：系统带2A假负载连续运行12小时，每隔30分钟记录一次读数。结果电压读数漂移只有±0.02V，电流读数漂移±0.03A，大部分变化其实来自负载本身发热导致的电流变化，而不是采样链路引入的。这算是比较理想的结果，主要归功于采样电阻和LDO独立供电的设计。如果你发现读数随时间明显缓慢漂移，优先怀疑采样电阻温漂和电源基准不稳定，不要急着怀疑芯片。
7. 部署半年后复盘：最值得记住的几个坑与经验
最后这部分不是教程里能学到的，是我这套系统从第一版到现在迭代了4版后踩出来的经验。如果你准备自己也做一套，这些坑能帮你少走很多弯路。
7.1 坑一：MOSFET关断瞬间的电压尖峰把主控吓了一跳
第一次测试关断带感性的小风扇负载时，示波器捕捉到输出端出现了负向30V的尖峰，持续时间约200ns。这个尖峰虽然不会直接损坏MOSFET，但通过寄生电容耦合到I2C线上，导致ESP32的I2C总线上出现了连续的总线错误。解决办法是在每一路输出端并联一个TVS管（SMBJ24A），同时把MOSFET的栅极驱动电阻从10Ω提高到47Ω，减缓开关速度。这不是玄学，开关速度慢一点，尖峰能量就被冲散了很多。
7.2 坑二：远程复位逻辑变成了误操作源头
我给上位机加了“一键复位所有故障通道”的按钮，看起来很方便，但有一次本来只有通道3保护跳闸，我误点成了全部复位，结果所有通道重新上电，正在测试的设备全部重启。后来我把复位逻辑改成“必须逐通道点击复位”，并在面板上增加二次确认弹窗，才算终结这个隐患。监控系统里的权限和确认机制看着是小事，关键时刻能决定一次运维事故是否发生。
7.3 坑三：WiFi信号不稳定导致状态上报间隔忽长忽短
ESP32放在金属机柜里，WiFi信号差的时候，MQTT消息可能积压几秒才发出去。这在面板上看起来就是曲线断断续续。我的处理方式是把上报逻辑改成“在WiFi连通时才发布，不重连不阻塞主逻辑”，同时把MQTT的KeepAlive调成30秒，避免频繁掉线重连。更重要的是，在机柜外接了一个带3米延长线的WiFi天线，信号强度从-70dBm提升到-45dBm，问题基本消失。
7.4 坑四：过度设计让人疲惫
刚做完时我一度想加入LCD显示屏、按键菜单、多级权限管理，还想过对每路做独立PID稳压输出。后来冷静下来，砍掉了这些需求，因为这套系统的定位是“监控和开关控制”，而不是“高精度可调电源”。如果你需要可调输出，去用成品数控电源模块就好，硬把两者揉在一起，只会让电路和固件的复杂度指数上升，维护成本远大于收益。
产品化和自动化之间有一个度，我的体会是：先跑起来，再根据实际使用场景去迭代。像现在这样，每个月看看Grafana面板上的趋势，偶尔看一眼告警推送，它已经成为了实验室里一个沉默但可靠的助手。整套系统成本不到200元，但我学到的东西和获得的踏实感，远超这个数字。
