企业官网建设流程全解析

简介：面向光伏逆变器研发、嵌入式通信调试与电站运维人员的 Modbus TCP 协议参考文档，聚焦 Solax SK-SU 系列混合储能逆变器的寄存器定义与通信实现，可用于上位机开发、数据采集对接和现场故障排查。文档以寄存器表为核心，逐条列出地址、读写属性、单位、数据格式与量程说明，涵盖序列号与厂商信息、并网保护阈值、安规类型选择，以及 EPS 功能、远程控制、电池 SOH、充电器输入能量等扩展寄存器，并明确协议端口 502、帧格式与指令最小间隔、响应超时等时序参数。随附的版本变更记录从 V1.0 延续至 V2.50，逐版标注人员、日期与改动内容，如 uint16 改为 int16、寄存器单位修正、新增单写寄存器与硬件开关状态读取，便于对照固件版本定位差异。压缩包共 1 个 PDF 文件，约 1.58MB，已有 88 人学习。

1. 一台连不上云的储能机，把我拉回这份停在 V2.50 的寄存器表

上个月帮朋友处理一台二手混合储能逆变器，机器在发电，手机端却一直离线。现场没有网关，也没有厂家调试口，机箱侧面只剩一个 RJ45。想把电池 SOC、PV 两路电压电流、今日发电量取出来，唯一的路是走 Modbus TCP 直接问设备。于是翻出这份 SK-SU 系列混合储能逆变器的 Modbus 协议文档，主体内容 2016 年定稿，最后一版停在 V2.50。它更像一张寄存器地图：哪个地址放什么、单位是 0.1 还是 0.01、哪些只读哪些能写、写之前要先打开哪个开关。适合三类人：手上有一台机器却拿不到数据的运维，要做本地采集网关的嵌入式开发，以及需要把储能数据接进自有平台的集成方。

2. 先把通信底座搭对：502 端口、100ms 帧窗口与 1s 指令间隔

很多人拿到这类文档第一反应是翻寄存器表，直接抄地址开读，然后卡在超时上。文档开头那几行“协议通用参数”才是真正决定能不能通的部分，它们不是性能指标，是设备主控的处理窗口。

2.1 三个时序参数：限速，并非追求速度

第一条最容易被忽略：两条指令之间至少隔 1 秒。这不是“最好这样”，是设备的处理节奏——主控要在两次请求之间完成采样刷新和寄存器映射，间隔不够就直接丢包或回异常。这意味着你的轮询周期有一个算得出来的下限：假设一轮要读 120 个寄存器，按每段 40 个拆成 3 条报文，光指令间隔就是 2 秒，加上处理和网络往返，3 秒一轮是现实值。想做到 1 秒刷一次全量数据，物理上不成立，只能靠分组。

第二条“字符间隔 > 100ms”更隐蔽。Modbus TCP 本身没有字符间隔的概念，这是串行链路的 t3.5 遗留，但不少逆变器固件内部还是 RTU 状态机，靠包间静默判断帧边界。如果客户端把一帧拆成两个 TCP 段发出去，中间因为 Nagle 或者调度延迟隔了 100ms 以上，设备会把前半截当成一个完整帧解析，长度对不上，回异常码或者干脆不理。常见做法是一次sendall把整帧拼好发出去，别在业务层做分段。

提示：客户端 timeout 别设 0.5 s。文档写的是响应超时 1 s，设备在高负载（比如并网切换、电池唤醒）时响应会逼近这个值，设太短会把正常响应误判成掉线，然后触发重连风暴，越重连越不通。

2.2 0x03 和 0x04 的分工：配置区和实时区是两张地图

文档把寄存器分成两大块，功能码不同，地址空间是平行的，别混着读。

0x03 区里有一段值得单独记住：0x002C 到 0x007B 是 80 个寄存器的 PowerManagerConfigData，紧跟着 0x007C 是 PowerManagerEnable。这 80 个寄存器文档没给逐位定义，属于厂内配置区，日常采集别去碰，读了也是黑匣子。0x007D 到 0x0083 是五路固件版本（逆变器主/从、充电器 1～4、管理器），做设备指纹很有用——同一个地址在不同固件版本上单位可能不一样，先读版本再决定换算系数，能省掉一堆“为什么我的数据和 APP 对不上”的争论。

0x04 区里则有大片 REV 空洞，比如 0x0024 到 0x003F 这一段大部分是保留位。从头读到尾看着省事，实际上既拉长了轮询周期，又可能在保留区拿到不定值，还可能触发非法地址异常。

2.3 用 pymodbus 打通第一条链路

先只读 0x04 区开头 9 个寄存器，验证链路、验证字节序、验证单位换算，三件事一次做完。

from pymodbus.client import ModbusTcpClient HOST, PORT, UNIT = "192.168.1.50", 502, 1 # UNIT 对应保持寄存器 0x0084 MyAddress client = ModbusTcpClient(HOST, port=PORT, timeout=1.2) # 略大于文档的 1s 响应超时 client.connect() # 0x04 区 0x0000~0x0008 共 9 个：电网电压/电流/功率、PV1/PV2 电压、PV1/PV2 电流、频率、温度 rr = client.read_input_registers(address=0x0000, count=9, slave=UNIT) raw = rr.registers def s16(v): """int16 还原：文档里电流、功率、温度类字段标的是 Int16，读到的是无符号位模式""" return v - 0x10000 if v & 0x8000 else v print("电网电压 V :", raw[0] * 0.1) # Uint16, 0.1V print("电网电流 A :", s16(raw[1]) * 0.1) # Int16, 0.1A print("电网功率 W :", s16(raw[2])) # Int16, 1W print("PV1 电压 V :", raw[3] * 0.1) # Uint16, 0.1V print("PV2 电压 V :", raw[4] * 0.1) print("PV1 电流 A :", raw[5] * 0.1) print("PV2 电流 A :", raw[6] * 0.1) print("电网频率 Hz :", raw[7] * 0.01) # Uint16, 0.01Hz print("机内温度 ℃ :", s16(raw[8])) # Int16, 1℃ client.close()

逻辑说明：一次请求覆盖一段连续地址，count=9对应 0x0000 到 0x0008，中间没有 REV 空洞，是这段地址能整读的原因。换算全部在本地做，别指望设备返回浮点——这份文档里没有一个浮点寄存器，全是定点整数加单位系数。

参数说明：slave在 pymodbus 3.x 是关键字参数，2.x 叫unit，直接抄旧代码会报unexpected keyword argument，这是我第一次接这类设备时卡了半小时的地方。count上限文档没写死，实践上一次别超过 40～60 个寄存器，一是部分固件对单帧长度有限制，二是单帧越长，中途被判定帧结束的概率越高。

3. 写寄存器的三道锁：安规枚举、运行模式与符号位编码

读通了不代表能写。这份文档里带 W 属性的寄存器不少，但每一个前面都有一道前置条件，跳过前置条件直接写，设备不报错，就是不执行——这种“静默失败”比报异常难查得多。

3.1 0x001D Safety：19 个枚举值决定了整套保护阈值

0x001D 是安规类型，只读，取值 0 到 18，对应不同的并网标准代号：

这个值的意义在于：它决定了 0x0019 到 0x0023 那一段保护阈值的合法区间。同一台机器切到不同的安规档，VacMinProtect、VacMaxProtect、FacMinProtect、FacMaxProtect 的可用范围跟着变。所以调试顺序永远是先读 0x001D 确认当前档位，再去解读后面的电压频率阈值，反过来做会把正常保护值当成故障。

文档里 0x0015 到 0x0018 是 PV 侧的启动门槛：VpvStart（0.1V）、TimeStart（1s）、VpvHighStop、VpvLowStop。这四个直接决定机器什么时候开始发电、什么时候停机，做发电量分析时要一起取，只看 PV 电压不看启动阈值，会出现“明明有电压为什么不发电”的误判。

3.2 0x008B 运行模式：时间表能不能生效的总开关

0x008B SolarChargerUseMode 三个取值：0 自用模式、1 强制时段模式、2 远控模式。0x0092 到 0x00A1 这两段时间表（充电/放电各两组，每组含起止时分），只有在模式等于 1 的时候才被执行。

现场最典型的翻车是这样：集成方把时间表写进去，读回来数据也对，等了一天发现电池根本没按时段充。原因是模式还停在 0。这一段没有任何“写入成功即生效”的反馈，写了就是写了，执行不执行是另一回事。

模式 2 是远控，此时充电功率由 0x00D4 wExt_SetChargerPower 决定，正数充电、负数放电；逆变输出功率由 0x00D5 wExt_SetInverterPower 决定。这两个是整份文档里少数几个明确标了有符号（W，Int16）的保持寄存器，也是远程调度场景的核心。0x00B4 Allow_Grid_Charge 则是另一个维度的开关：0 禁止从电网充电，1 允许时段 1，2 允许时段 2，3 两段都允许。它和 0x008B 是叠加关系，不是替代关系。

3.3 uint16 改 int16 那一段历史：符号位不处理，读到 65486

这份文档从 V1.0 到 V2.50 改了二十多次，其中影响最大的两次修改是单位调整和符号类型调整。V2.1 把三个寄存器的格式从 uint16 改成 int16，V2.2 又把输入寄存器 0x46 改了。改的原因很实际：充电器在放电时功率是负的，用无符号表示不了。

如果按无符号去读 0x00D4，放电 50W 会读成 65486。这个数字看着像坏数据，其实是 -50 的补码。换算和写入都得处理符号位：

UNIT = 1 def to_s16(u16): """原始 16 位值 -> 有符号整数。 适用：0x00D4 wExt_SetChargerPower、0x00D5 wExt_SetInverterPower、 0x0014~0x0019 电池电压电流温度、0x0046 feedin_power 等 """ return u16 - 0x10000 if u16 & 0x8000 else u16 def from_s16(v): """有符号整数 -> 写入用的 16 位位模式。别直接传负数给某些客户端库""" return v & 0xFFFF # 例子：远控模式下让充电器以 800W 充电 client.write_register(address=0x008B, value=2, slave=UNIT) # 先切远控模式 client.write_register(address=0x00D4, value=from_s16(800), slave=UNIT) # 例子：读回来验证，放电时应该是负数 rr = client.read_holding_registers(address=0x00D4, count=1, slave=UNIT) print("外部设定充电功率 W:", to_s16(rr.registers[0]))

逻辑说明：先切模式再写功率，顺序不能反。写入前把负数转成无符号位模式，是因为部分客户端库在write_register里对负值会做范围校验直接抛异常，或者按有符号打包出错。

参数说明：0x00D4 单位是 1W，Int16 范围 ±32767W，实际可用范围还受电池最大充放电电流（0x0090、0x0091，单位 0.01A）约束。写入一个超出电池能力的值，设备不会报错，只会按内部限幅执行，读回来和你写进去的不一样——这不算故障，是限幅逻辑在起作用。

4. 四类数据的拆包：倒序字符串、32 位能量、电池簇与故障位图

寄存器读回来只是一串 0～65535 的整数，真正的活在拆包。这份文档里的数据格式至少有四种：倒序字符串、16 位定点、32 位高低字组合、按字节打包的双参数。

4.1 序列号和厂名：14 个字符是倒着存的

0x0000 到 0x0006 是序列号，7 个寄存器正好 14 个字符；0x0007 到 0x000D 是厂名，0x000E 到 0x0014 是模块名，结构一样。文档在描述里写了一句容易看漏的话：MSB = SN[14]，意思是第一个寄存器的高字节存放的是序列号的最后一个字符。

def read_reversed_string(client, start, count=7, unit=1): """读 14 字符的倒序字符串：7 个寄存器 -> 14 字节 -> 反转 -> 解码""" rr = client.read_holding_registers(address=start, count=count, slave=unit) buf = bytearray() for reg in rr.registers: buf.append((reg >> 8) & 0xFF) # 高字节在前 buf.append(reg & 0xFF) return bytes(reversed(buf)).decode("ascii", errors="ignore").strip("\x00 ") sn = read_reversed_string(client, 0x0000) # 序列号 vendor = read_reversed_string(client, 0x0007) # 厂名 model = read_reversed_string(client, 0x000E) # 模块名

逻辑说明：先按大端把 7 个寄存器摊成 14 字节，再整体反转，最后按 ASCII 解码。不反转的话读出来是一串看着像乱码但又有规律可循的字符——我第一次读的时候以为是编码问题，换了三种解码方式都不对，最后才回头看见那句 MSB 说明。

参数说明：errors="ignore"用来吃掉尾部填充的空字符，不同固件对未使用位的填充不一致，有的是 0x00，有的是 0x20 空格。

4.2 32 位能量寄存器：低字在前，单位差十倍

文档明确标了低字在前：0x0048 是 LSB，0x0049 是 MSB。拼接方式是low + (high << 16)，不是反过来。Etotal 的单位是 0.001kWh，而 feedin_energy 和 Load1 Yield 是 0.01kWh，两者差十倍，混用会让发电量报表直接错一个数量级。

def u32(low, high): return (high << 16) + low def s32(low, high): v = u32(low, high) return v - 0x100000000 if v & 0x80000000 else v rr = client.read_input_registers(address=0x0046, count=14, slave=UNIT) r = rr.registers print("馈入电网功率 W :", s32(r[0], r[1])) print("馈入电量 kWh :", u32(r[2], r[3]) * 0.01) print("用电量 kWh :", u32(r[4], r[5]) * 0.01) print("总发电量 kWh :", u32(r[12], r[13]) * 0.001) # 0x0052/0x0053

逻辑说明：0x0046 到 0x0053 中间夹着 0x0044、0x0045 两个 REV，但从 0x0046 起连续 14 个寄存器是一整段有效数据，所以能一次读完。32 位字段必须一次请求读回两个寄存器，分两次读会在中间插入一次采样，高字和低字来自不同时刻，累计电量会出现跳变甚至倒退。

参数说明：0x0051 是夹在 Etoday 和 Etotal 之间的 REV，取值无意义，别拿它做校验。

4.3 电池簇：0x0014 到 0x0023 这一段，单位最杂

温度这一组有三个寄存器挨着，单位都是 1℃，但文档 V2.1 改过一次充电器温度的单位，从 0.1 统一成 1。如果手上有旧版采集脚本，这里就会出现“温度差了十倍”。另外 0x0055 的 Bat_THERMA 单位是 0.1℃，和 0x0018 的电池温度不是同一个口径，两个都放在报表里却不做标注，读数会对不上。

0x0023 BatterySOH 是 V2.50 才加进来的，老固件这个地址是保留位，读回来是 0。判断方式是先读 0x0083 管理器固件版本，老版本直接跳过这个字段，别把 0 当成“电池健康度归零”报警出去。

4.4 故障字：文档给了地址，没给位定义

0x0040 / 0x0041 是 InvFaultMessage 的 LSB 和 MSB，拼起来是一个 32 位故障码；0x0042 是充电器故障，0x0043 是管理器故障，0x001F 是 BMS 警告，另外还有 CAN CommLost 这类离散标志。

这里有个必须说清楚的边界：这份文档只给了寄存器地址和“故障信息”这个描述，没有逐位定义表。实践中常见的做法是把它当作整体故障码记录，配合时间戳做“故障发生前最后一次正常快照”和“故障时快照”的对比，先定位到是 PV 侧、电网侧还是电池侧；要做精确到位的告警解读，只能另外要一份位定义表。自己按猜测去映射位，最后一定会在某台机器上把“过温”报成“漏电流”。

rr = client.read_input_registers(address=0x0040, count=4, slave=UNIT) inv_fault = u32(rr.registers[0], rr.registers[1]) print(f"逆变器故障码 0x{inv_fault:08X}") print(f"充电器故障码 0x{rr.registers[2]:04X}") print(f"管理器故障码 0x{rr.registers[3]:04X}")

逻辑说明：故障码用十六进制打印而不是十进制，方便和现场记录、售后工单上的写法对齐。0 表示无故障，非 0 就把整轮快照（电压、电流、温度、能量）一起落库，这是后面复盘时唯一能用的材料。

5. 避坑与排查：五条从现场带回来的记录

这一章的五条都是我或者身边人真实撞过的，按“现象→原因→解决”写，每条都能对上文档里的具体某一行。

5.1 全部读请求超时，但 ping 得通

现象：客户端连上就超时，网线换过、IP 换过，ping 一直是通的。

原因有三个层次。最常见的是从站地址不对：这份文档的 MyAddress 在保持寄存器 0x0084，如果现场装过多台机器做过地址偏移，按默认 1 去请求会全部无响应。第二是端口被上位机网关占着，同一台设备不接受第二个 TCP 连接。第三就是 2.1 节说的帧被拆包，设备把半帧当完整帧丢掉，表现同样是超时，但会偶发一次成功，容易误判成网络抖动。

解决：先用 0x03 读 0x0084 拿到真实地址，再用这个地址去读 0x04 区；确认没有其它客户端连着；发送侧保证整帧一次性发出，关闭业务层的分段逻辑。三条按顺序排，能省掉大量无效排查。

5.2 返回异常码 0x83 + 0x02

现象：读某一段地址时设备回 0x83，异常码 0x02，意思是非法数据地址。

原因：请求跨越了 REV 保留区，或者越过了一段地址的末尾。典型翻车是从 0x0014 一口气读到 0x0024，中间 0x0024 是 REV，部分固件对保留地址直接拒绝整帧，而不是返回 0。另一处高发区是 0x002C 到 0x007B 的 PowerManagerConfigData，看着是一整块，实际不是所有固件版本都完整实现。

解决：按功能段拆请求，每段的起止地址在文档表里逐条核对过再发。别用“从最小地址读到最大地址再切片”的偷懒写法。

注意：异常码 0x02 出现一次之后，部分固件会有一小段静默期，紧接着的合法请求也可能被丢掉。重试之前先等够 1 秒间隔，别立刻狂发。

5.3 充放电时间表写进去了，机器不执行

现象：0x0092 到 0x00A1 的时段寄存器读回来和写进去的一致，到点电池不动。

原因：0x008B SolarChargerUseMode 不等于 1。时间表只在强制时段模式下生效，自用模式和远控模式下这两段时间表就是死数据。还有一种情况是 0x00B4 Allow_Grid_Charge 为 0，市电充电被整体禁止，时段到了也不会从电网取电。

解决：写入序列固定为“先读 0x008B 确认当前模式 → 写 0x008B = 1 → 写时段 → 读回校验 → 再读 0x00B4 确认允许电网充电”。顺序错了不会报错，只是不生效。

5.4 继电器参数写完互相覆盖

现象：按 0x00E1 到 0x00E7 配好继电器 1，写完 TrigTimeSet 之后 CloseTimeSet 变了，或者干脆两个都不对。

原因：这一组寄存器是双参数打包的。0x00E2 的低字节是 TrigTimeSet（单位 min），高字节是 CloseTimeSet（单位 Hour）；0x00E3 低字节 TrigMode、高字节 Time_Control；0x00E4 到 0x00E7 同样是低字节分钟、高字节小时。按 uint16 整体写，等于把另一个参数一起改了。

def pack_u8_pair(lo_val, hi_val): """把两个 8 位参数打进一个 16 位寄存器：低字节 lo，高字节 hi""" return ((hi_val & 0xFF) << 8) | (lo_val & 0xFF) # 继电器 1：触发时长 30 分钟、闭合时长 2 小时 client.write_register(address=0x00E2, value=pack_u8_pair(30, 2), slave=UNIT)

逻辑说明：读的时候反向拆，lo = v & 0xFF、hi = (v >> 8) & 0xFF。千万别图省事直接写十进制整数，比如写个 30，高字节就是 0，等于把 CloseTimeSet 清成 0。

5.5 累计电量跳变或倒退

现象：Etotal 隔几秒跳一次，甚至比上一次读到的还小。

原因：两个寄存器分两次请求读，高字和低字来自不同时刻，中间低字进位了，拼出来就是个错误值。另一个原因是单位看错，把 0.001kWh 当 0.1kWh 算，数值直接差一百倍，看起来像跳变其实是换算错。

解决：32 位字段一律单次请求读两个连续寄存器；换算系数在代码里写死并加注释标明来源行；对 Etotal 做单调性校验，新值小于旧值时丢弃本次采样而不是覆盖入库。

6. 长期采集：把一百多个寄存器砍成三档轮询

跑通单次读取之后，真正的难点是让它连续跑几个月不出事。1 秒指令间隔这条硬约束决定了不可能全量高频轮询，我的做法是按变化速度分三档。

快档一轮只有一条报文，加上间隔大约 4 秒一轮，完全够看趋势；中档和慢档穿插在快档的间隔里发，用一个简单的调度器控制节奏，不要开多线程同时打设备——多线程会让两条指令的间隔小于 1 秒，直接踩 2.1 节的坑。

import time def poll_once(client, plan, unit=1): """按计划表顺序轮询，强制满足 1 秒指令间隔""" out = {} for name, fc, addr, cnt in plan: try: if fc == 0x04: rr = client.read_input_registers(address=addr, count=cnt, slave=unit) else: rr = client.read_holding_registers(address=addr, count=cnt, slave=unit) if rr.isError(): out[name] = None else: out[name] = rr.registers except Exception as e: out[name] = None client.close() client.connect() # 掉线重连，别在这里递归重试 time.sleep(1.0) # 文档硬性要求：两条指令最小间隔 1s return out # 快档计划：一段地址读完实时区 FAST_PLAN = [("realtime", 0x04, 0x0000, 20)]

逻辑说明：time.sleep(1.0)放在每次请求之后而不是之前，保证无论成功失败间隔都成立。异常分支里只做一次关闭重连，不做循环重试——设备掉线往往是并网切换或者电池唤醒引起的短暂不可用，狂重连只会把恢复时间拉长。返回结构里失败段置 None 而不是抛异常，让上层决定是补采还是记一次空洞。

慢档里我最看重的是 0x007D 到 0x0083 的固件版本和 0x001D 的安规类型，这两个值平时不变，一旦变了就说明有人动过设备配置，这时候把前后快照拉出来对比，比事后猜要省事得多。至于 PowerManagerConfigData 那 80 个寄存器，采集端一直跳过，需要时单独抓一次留档就够。

早几年我接手一个采集项目，图省事把所有寄存器塞进一个大循环，5 秒一轮，跑了三天数据全是锯齿状。后来才发现指令间隔不够导致设备丢包，客户端重连后读到的是缓存值。从那以后我每次接新设备，第一件事不是写业务逻辑，而是拿秒表把时序参数跑一遍，确认 1 秒间隔和 100ms 帧窗口都守住了，再往上叠功能。这份协议文档的价值也在这里：它把设备的脾气一条条写在最前面，读懂了能少走很多弯路。希望帮到你。

本文还有配套的精品资源，点击获取