4. 数据采集与接入：IoT设备接入与通信协议
好，咱们直接进入正题。这一章聊的是虚拟电厂平台最底层、也最磨人的环节——数据采集与接入。
说白了，你平台功能再牛，算法再炫，数据进不来，全是白搭。我见过太多聚合商，上来就搞高级应用，结果发现光伏逆变器读不到数据，充电桩协议对不上，空调压根儿没联网……嗯，那场面，挺尴尬的。
所以，咱们把这块地基打牢。今天重点讲三样东西：设备怎么接、用什么协议、数据进来后怎么洗。
4.1 设备接入：光伏、储能、充电桩、空调
先说说最常见的四类设备。每个设备的接入方式，其实差别挺大。
4.1.1 光伏逆变器
光伏逆变器是虚拟电厂里最成熟的设备了。大部分厂家都支持Modbus RTU或Modbus TCP。我个人习惯，优先走TCP，布线简单，调试也方便。
但有个坑——寄存器地址不统一。同样是阳光电源的逆变器，不同型号的功率寄存器地址可能不一样。我曾在项目里遇到过，同一批设备，固件版本差了一个小版本，地址就变了。你说气不气人？
4.1.2 储能系统（BMS + PCS）
储能系统比光伏复杂。它分两部分：电池管理系统（BMS）和储能变流器（PCS）。
BMS一般走CAN总线，但CAN转以太网需要网关。PCS则多走Modbus或104规约。我建议，BMS和PCS分开采集，别指望一个网关搞定所有。
为什么？因为BMS数据量大（每节电芯电压、温度），PCS数据实时性要求高（功率、电流）。混在一起，容易丢包。
4.1.3 充电桩
充电桩这块，协议最乱。国标GB/T 27930是物理层标准，但上层通信各家有各家的玩法。
目前主流充电桩都支持OCPP协议（开放充电点协议）。如果你接的是公共桩，OCPP 1.6 JSON版是首选。如果是私桩，很多只提供MQTT接口。
我记得有一次，客户要求接入某品牌交流桩。厂家说支持Modbus，结果我拿到文档一看，只支持读取状态，不支持控制。嗯，这玩意儿只能当“监视器”，没法参与调度。
1. 是否支持远程启停？
2. 是否支持功率调节？
3. 数据上报频率是多少？
4.1.4 空调（中央空调/分体机）
空调接入，是很多聚合商容易忽略的。其实空调是很好的柔性负荷资源。
中央空调一般走BACnet或Modbus。分体机就麻烦了，很多没有标准通信接口。我建议用红外遥控+智能插座的方案，成本低，部署快。
但要注意，红外遥控只能控制开关和温度设定，没法读取实时功率。想测功率，还得加个智能电表。
4.2 通信协议：Modbus、MQTT、104规约
协议这块，我挑三个最常用的讲。你想想看，一个虚拟电厂平台，大概率这三种都会遇到。
4.2.1 Modbus（RTU / TCP）
Modbus是工业界的“普通话”。几乎所有光伏逆变器、储能PCS、电表都支持。
RTU走串口（RS485），适合短距离、低速场景。TCP走以太网，适合长距离、高速场景。
我个人的经验是：能走TCP就别走RTU。RTU的轮询机制太慢，一个485总线上挂10个设备，轮询一圈可能要好几秒。对于虚拟电厂这种需要秒级响应的场景，不太够用。
// Modbus TCP 读取光伏逆变器功率示例
// 使用 libmodbus 库
modbus_t *ctx;
uint16_t tab_reg[2];
ctx = modbus_new_tcp("192.168.1.100", 502);
modbus_set_slave(ctx, 1);
// 读取寄存器地址 0x3100，长度2个寄存器
modbus_read_registers(ctx, 0x3100, 2, tab_reg);
// 功率值 = 第一个寄存器 * 0.1 (单位kW)
float power = tab_reg[0] * 0.1;
printf("当前功率: %.1f kW\n", power);
modbus_free(ctx);
4.2.2 MQTT
MQTT是物联网的“网红协议”。轻量、支持发布/订阅、支持QoS。特别适合充电桩、空调这类设备。
为什么用MQTT？因为设备数量多、网络不稳定。MQTT的断线重连机制很成熟，数据不会丢。
但要注意，MQTT本身不保证数据顺序。如果你需要严格的时间序列数据，建议在payload里带上时间戳。
/vpp/{聚合商ID}/{设备类型}/{设备ID}/{数据点}比如：
/vpp/1001/pv/inverter_001/power
4.2.3 104规约（IEC 60870-5-104）
104规约是电力系统的“老大哥”。电网调度端几乎都用它。如果你要跟电网互动，这个协议必须支持。
104规约的特点是：遥测、遥信、遥控、遥调。说白了，就是能读数据、能看状态、能下发指令、能调参数。
但104规约的学习曲线比较陡。报文结构复杂，状态机也多。我建议直接用现成的开源库，比如lib60870，别自己从头写。
4.3 数据清洗与预处理
数据进来了，但别急着用。你想想看，设备上报的数据，什么情况都有：
- 丢包了，数据断点
- 传感器坏了，数据跳变
- 时间戳不对，数据乱序
- 单位不一致，有的kW，有的W
所以，数据清洗是必须的。我一般分三步走：
4.3.1 去重与排序
先按时间戳排序，去掉重复数据。MQTT订阅模式下，偶尔会收到重复消息。用Redis的Set做去重，效率很高。
4.3.2 异常值处理
设定合理的阈值。比如光伏功率不可能超过额定容量的1.2倍。超过的，直接丢弃或标记。
我曾经遇到过，一个充电桩上报的电流值突然变成9999A。嗯，这明显是传感器故障。如果不处理，平台会以为发生了短路，触发告警，吓死人。
4.3.3 插值与补全
对于短时间的数据缺失（比如5秒内），用线性插值补全。长时间缺失（比如超过1分钟），标记为“无效”，别硬补。
// 线性插值示例（伪代码）
function linear_interpolate(t1, v1, t2, v2, t):
if t2 == t1:
return v1
return v1 + (v2 - v1) * (t - t1) / (t2 - t1)
4.4 知识体系总览
下面这张图，是我梳理的本章核心逻辑。你可以把它当作接入工作的“路线图”。
这张图从左到右，从上到下，就是数据从设备到平台的完整路径。你搭建平台时，就按这个结构来设计接入模块。
好了，这一章就到这里。数据接入这块，说白了就是“慢工出细活”。别急，一个一个设备调通，数据质量上去了，后面的调度算法才能跑得准。