简介：《Solax SK-SU Hybrid Solar Inverter Modbus Protocol》面向光伏逆变器研发、储能系统集成与上位机通信调试人员，聚焦SK-SU系列混合太阳能逆变器的Modbus TCP协议规范查阅与寄存器对接。压缩包仅含1个PDF文件，约1.58MB，内容集中于协议总则、寄存器表与版本修订记录，便于快速定位功能码、地址与数据格式。文档涵盖端口502、帧格式与请求时序，Read Holding Register功能码及序列号、厂名、模块名、启动电压、电网保护阈值等寄存器，并梳理V1.0至V2.50间EPS、远程控制、安全配置、BMS告警、电池SOH等变更。已有88人学习，可作为通信调试、协议解析和版本兼容排查的参考资料。
1. 储能柜交接时最容易被跳过的那份文件
项目交接时，运维丢过来一份几十页的寄存器定义表，说"协议都在里面"。这份某系列混合储能逆变器的 Modbus TCP 协议规范，从 2014 年的 V1.0 草稿一路改到 V2.50，中间删过寄存器、把 uint16 改成 int16、修过单位标注，还在 V2.2 之后陆续补了 EPS、自检、继电器、BMS 告警这些功能。它真正的价值在于：让一台普通工控机或树莓派通过 502 端口，把并网电压电流、PV 两路输入、电池充放电功率、累计电量、故障字全读上来，也能把充放电时段、并网功率上限、远程调度功率写下去。做储能监控上位机、边缘采集网关、能量管理系统对接的开发者能直接用，现场只拿到 PDF 不知道从哪个地址下手的工程师也能照着跑通。
2. 协议骨架：0x03、0x04、0x06 三个功能码与 1 秒节拍
这份规范里真正算"硬约束"的其实只有四行参数，其余全是地址表。很多人上来就抄地址，结果连不上、读回异常码，问题往往不在地址，而在骨架没立对：这台机器对外是一个 502 端口、一个从站地址，内部却是多块板子聚合出来的数据；两块地址空间都从 0x0000 开始，靠功能码区分；指令之间还必须留够静默时间。先把这三件事吃透，后面那张大表才有意义。
2.1 一个 502 端口背后是多块板子的数据聚合
翻到保持寄存器的固件版本段就能看出端倪：0x007D 到 0x0083 连着七个版本号，分别对应 InverterMaster、InverterSlave、Charger1 到 Charger4、Manager。也就是说，逆变器主控、四路充电器、管理单元各自是独立的固件实体，最后由 Manager 把数据汇总到一个从站地址上（0x0084 MyAddress）。这个结构对开发有两个直接影响：一是输入寄存器里 0x0014 到 0x0028 是充电器 1 的完整数据块，而 0x0029 到 0x0040 标的是 REV（预留），对应充电器 2、3、4 的槽位，机型没配那么多充电器时这些地址读回来就是 0，不要当成故障；二是不同板子的采样时刻并不严格同步，做功率平衡计算时别假设同一帧里的 PV 功率和电池功率是同一瞬间的值。
2.2 两块地址空间：0x03 读配置，0x04 读实时
| 功能码 | 名称 | 地址空间 | 读写 | 典型用途 |
|---|---|---|---|---|
| 0x03 | Read Holding Register | 保持寄存器 0x0000–0x00F9 | 读，配合 0x06 写 | 序列号、安规类型、电池参数、充放电时段、继电器配置 |
| 0x04 | Read Input Register | 输入寄存器 0x0000–0x0062 | 只读 | 电压电流功率、温度、运行模式、故障字、发电量 |
| 0x06 | Write Single Register | 保持寄存器 | 写单个 | 远程调度功率、模式切换、时间参数 |
这里最容易翻车的一点：两块空间的起始地址都是 0x0000，含义完全不同。0x0000 在功能码 0x03 下是序列号的高位，在 0x04 下是并网电压。用 0x04 去读 0x00D4（wExt_SetChargerPower，只存在于保持寄存器），设备会返回异常码 0x02；反过来用 0x03 去读实时功率，读到的是一段配置数据，数值看着"有变化"其实是别的字段，排查起来非常费时间。
提示：先确定你要的是"配置"还是"实时量"，再决定功能码。搞混这两块空间是新手最常见的第一个坑。
2.3 MBAP 头加 PDU：一帧请求到底长什么样
Modbus TCP 在标准 PDU 前面加了 7 字节的 MBAP 头：事务标识符 2 字节、协议标识符 2 字节（固定 0）、长度 2 字节（后续字节数，含单元标识符）、单元标识符 1 字节。后面才是 PDU：功能码 1 字节 + 起始地址 2 字节 + 寄存器数量 2 字节。响应帧的 PDU 是功能码 + 字节数 + 数据，字节数等于寄存器数量乘 2，数据按大端排列。规范里给了一个例子：从 0x006B 起读 3 个保持寄存器，返回 0x022B、0x0000、0x0064，换算成十进制就是 555、0、100。
出异常时，功能码最高位置 1，0x03 变成 0x83，后面跟一个异常码。规范列了四种：0x01 非法功能、0x02 非法数据地址、0x03 非法数据值、0x04 从站设备故障。这四个码基本能覆盖调试期 90% 的问题，看到 0x02 就去核对地址是否落在这块空间里，看到 0x04 先怀疑设备正在自检或保护状态。
import socket import struct def build_read(unit_id: int, func: int, start: int, count: int, tid: int = 1) -> bytes: """手工拼一帧 Modbus TCP 读请求，方便核对报文""" # PDU: 功能码(1) + 起始地址(2) + 寄存器数量(2) pdu = struct.pack(">BHH", func, start, count) # MBAP: 事务ID(2) + 协议ID(2,固定0) + 长度(2) + 单元ID(1) # 长度字段 = PDU 长度 + 1（那 1 个字节是单元标识符） mbap = struct.pack(">HHHB", tid, 0x0000, len(pdu) + 1, unit_id) return mbap + pdu # 读保持寄存器 0x007D 起的 7 个固件版本号，用来验证链路是否通 frame = build_read(unit_id=1, func=0x03, start=0x007D, count=7) print(frame.hex(" ")) # 00 01 00 00 00 06 01 03 00 7d 00 07这段代码的意义不在于替代现成库，而是让你在抓包时能一眼看出帧对不对。头部00 01是事务号，00 00是协议号，00 06表示后面还有 6 个字节（单元 ID 1 字节 + PDU 5 字节），01是从站地址，03是功能码，00 7d是起始地址，00 07是数量。写错长度字段是自研协议栈最常见的 bug，设备会直接不响应，而抓包看上去"帧发出去了"，很容易误判成网络问题。
2.4 时序参数：1 秒间隔、100 毫秒静默、1 秒超时
规范明确写了三条：两条指令之间的最小间隔 1 秒；两包之间的字符间隔静默时间大于 100 毫秒；响应超时 1 秒。这三条不是摆设。Modbus TCP 理论上靠 TCP 分帧就够了，不需要 RTU 那套 3.5 字符静默，但这台设备的固件显然保留了对紧凑报文的兼容判断，包与包贴太近会出现"前一帧正常、后一帧超时"的玄学现象。
我一般把这三个参数做成常量而不是散落在代码里：CYCLE = 1.0控制相邻两条指令的发起间隔，GAP = 0.12控制发送后到开始收包之间的留白，TIMEOUT = 1.0卡死单次等待。三者在同一条串行链路上生效，不要并发开多线程去读不同地址段，设备的处理能力跟不上，1 秒间隔一破就等着超时重连。
最小自检流程我固定走三步：先telnet <ip> 502确认端口开着；再用上面的帧只读 0x007D 一个地址，验证从站地址和功能码；拿到正常的 7 个版本号以后，才扩大到实时区。跳过前两步直接读一大片寄存器，失败时你分不清是 IP 错、从站地址错、功能码错还是数量超限，等于把四个变量同时扔进黑匣子。
3. 寄存器地图：从 0x0000 到 0x00F9 是怎么分区的
这张表看着长，实际是有清晰分段的。保持寄存器从设备身份开始，依次是并网保护参数、功率因数、功率管理大数据块、固件版本与时钟、电池与充放电时段、EPS 与安规自检、外部调度、继电器配置；输入寄存器则是实时量、故障值、充电器数据块、故障字、电量累计、EPS 实时量、继电器与负载状态。按段记比按地址死记靠谱得多，尤其是 V2.x 之后新增的功能基本都插在段尾，段落边界一直没变。
3.1 保持寄存器上段：身份信息、安规表与并网保护阈值
0x0000 到 0x0014 是身份区，序列号、工厂名、模块名各占 7 个寄存器，规范注明每段是 14 个字符、MSB 在前。也就是说一个寄存器塞两个 ASCII 字符，读完要按大端拆成高低字节再拼字符串。0x0015 到 0x0025 是并网保护参数：VpvStart 启动电压阈值（0.1V 精度）、TimeStart 启动等待时间（1s）、VpvHighStop 和 VpvLowStop 输入高低压停机阈值、VacMinProtect 和 VacMaxProtect 电网电压保护上下限（0.1V）、FacMinProtect 和 FacMaxProtect 频率保护上下限（0.01Hz）。
0x001D 的 Safety 值得单独说，它是个枚举，对应不同地区的并网标准：0 是 VDE0126、1 是 ARN4105、2 是 AS4777、3 是 G83/2（3.7kW 以下）、4 是 C10/11、5 是 OVE/ONORM E8001……一直到 18 是法国 60Hz 岛屿模式。这个字段决定了整台机器的保护阈值组合，改它等于换了一套并网逻辑，现场千万不要随手写。0x001E PvConnectionMode 区分通信和多重连接，0x001F Grid10MinAvgProtect 是 10 分钟平均过压保护值，0x0024 DciLimits 是直流分量限制（1mA 精度），0x0025 PowerLimitsPercent 是输出功率百分比限制，0 到 100。
0x0026 到 0x002B 是功率因数区：PowerfactorMode 选模式，PowerfactorData 是设定值（0.01 精度），UpperLimit 和 LowerLimit 分别是过励和欠励限值，PowerLow 和 PowerUp 是功率比值变化的上限和下限。这一组在做无功补偿或者按电网调度要求限功率时会用到，写入前一定要确认当前 Safety 模式下这些参数是否允许修改。
0x002C 到 0x007B 是一块 80 个寄存器的大区域，PowerManagerConfigData，规范只给了范围没展开字段，0x007C 是 PowerManagerEnable 开关。这种"黑盒大块"我一般整块读上来存原始值，不急着解析，等厂商补充文档或者通过改变运行状态观察哪几位在动，再逐位确认。
3.2 保持寄存器下段：电池充放电时段、EPS 与三路继电器
0x0085 到 0x008A 是 RTC，依次是秒、分、时、日、月、年，各占一个寄存器。写时间的时候注意年月顺序是反的，先月后年，别按习惯顺序写。
0x008B 到 0x00A1 是电池与充放电时段的核心区。SolarChargerUseMode 有三个取值：0 自用模式、1 强制时段模式、2 远程控制模式。这个字段是后面所有远程写操作的开关，不切到 2，你写的功率值全部不生效。Battery1_MinCapacity 是最小容量百分比，BatteryType 区分铅酸和锂电（0 铅酸、1 锂电），Battery1_ChargeCutVoltage 和 DischargeCutVoltage 是充放电截止电压（0.01 精度），ChargeMaxCurrent 和 DischargeMaxCurrent 是最大充放电电流（0.01 精度）。
接着是两组时段，每组四个寄存器：ChargerStartTime1_Hours、ChargerStartTime1_Minutes、ChargerEndTime1_Hours、ChargerEndTime1_Minutes，然后是 Discharger 的对应四个，第二组从 0x009A 到 0x00A1 同样结构。小时范围 0 到 23，分钟 0 到 59，都是独立寄存器、不用打包，这点比后面继电器区友好得多。
0x00B4 的 Allow_Grid_Charge 是个小型位域：0 禁止、1 允许时段一、2 允许时段二、3 两段都允许。用值 3 表示"两个时段都允许"而不是用位或，这个设计要记住，写 3 是对的，写 0x03 也一样，但别试图写 4 或 5。0x00B5 和 0x00B6 是出口功率限制的出厂值和用户值（1W 精度），0x00B7 EPS_Mute 是 EPS 静音开关，0x00B8 EPS_Frequency 选 50Hz 或 60Hz，0x00B9 EPS_Charger1_DischargeVolt 是 EPS 下的放电电压（0.1V）。
0x00BB 到 0x00BC 是 Language 和 IP Method，语言只有英语和德语两个值，IP 方式 0 是 DHCP、1 是手动。0x00BD 到 0x00C4 是八个意大利并网快速和慢速调整时间参数，1ms 精度，只在特定安规下有意义。0x00C5 到 0x00D3 是自检区，TestStep 写 1 启动自检、读到 8 表示成功，中间值 1 到 8 是过程状态；后面依次是 Ovp、Uvp、Ofp、Ufp 的电压频率值和时间参数。自检一旦启动会改变输出状态，别在带载运行时做。
0x00D4 和 0x00D5 是外部调度入口：wExt_SetChargerPower 是 int16，正数充电、负数放电；wExt_SetInverterPower 是并网输出功率限制，uint16。0x00D6 是充电吸收电压，0x00D7 Bat_awaking 写 1 立即唤醒电池。0x00D8 和 0x00D9 是功率因数锁定的进入点和退出点，进入点 105 到 110，退出点 98 到 90，这两个是 V2.4.1 之后新增的单写寄存器。
0x00DA 的 Machine switch 是个双字节字段，高字节是软件开关（1 开 0 关），低字节是硬件开关状态（1 开 0 关）。软件开关可以写，硬件开关是物理拨码，只能读。做远程控制时这个寄存器是第一道门：软件开关没开，模式写了也白搭。0x00DB 到 0x00DF 是频率下垂和 Q(U) 曲线参数，包括设置点、下垂斜率（1% 精度）、延时和曲线上下限。
0x00E1 到 0x00F9 是三路继电器的配置区，每路 8 个寄存器。以继电器 1 为例：TrigPower 触发功率（1W），TrigTimeSet 触发时间和 CloseTimeSet 关闭时间共用 0x00E2 一个寄存器，低字节是分钟、高字节是小时；TrigMode 和 Time_Control 共用 0x00E3，低字节是模式（0 禁用、1 循环、2 单次、3 单次已触发），高字节是强制时间控制使能；后面是两组起止时间，同样低字节分钟、高字节小时。这种一个寄存器塞两个字段的设计，是这份表里最容易写错的地方。
3.3 输入寄存器：实时量、故障字与 32 位电量
0x0000 到 0x0013 是整机实时量：GridVoltage（0.1V）、GridCurrent（规范标 0.1V，实际应为 0.1A，int16）、GridPower（1W，int16）、PvVoltage1 和 PvVoltage2（0.1V）、PvCurrent1 和 PvCurrent2（0.1A）、GridFrequency（0.01Hz）、Temperature（1℃，int16）、RunMode，然后是 Powerdc1 和 Powerdc2 两路直流功率。0x000C 到 0x0012 是各类故障时的实测值快照：温度、PV1 和 PV2 电压、GFCI 电流、电网电压、电网频率、直流分量，故障发生后这些值会保留，是排查保护动作原因的第一手材料。
0x0013 是 TimeCountDown，单位毫秒，配合启动流程看剩余等待时间。0x0014 到 0x0028 是充电器 1 的完整数据块：BatVoltage_Charge1（0.01V，int16）、BatCurrent_Charge1（0.01A，int16）、Batpower_Charge1（1W，int16）、板温、电池温度、Boost 温度、电流故障值、Boost 电压故障值、容量百分比、输出能量（0.1kWh，占两个寄存器 LSB 和 MSB）、BMS 告警字、输入能量（同样双寄存器）、电池包数量、电池 SOH。
0x0040 到 0x0043 是四个故障字：InvFaultMessage 的 LSB 和 MSB 分占两个寄存器，ChargerFaultMessage 一个，Mgr FaultMessage 一个。规范只给了 LSB 和 MSB 的位置，没给逐位定义，这是这份文档最需要向厂商补充的部分。
0x0046 到 0x004B 是三组 32 位量：feedin_power 在 0x46（LSB）和 0x47（MSB），int32，1W；feedin_energy 在 0x48 和 0x49，uint32，0.01kWh；consum_energy 在 0x4A 和 0x4B，uint32，0.01kWh。0x004C 到 0x004F 是 EPS 的电压、电流、功率、频率。0x0050 Etoday 是当日发电量（0.1kWh），0x0052 和 0x0053 是 Etotal 累计发电量（0.001kWh，uint32），精度比其他电量高一个数量级。0x0054 是 Unlock，规范写的是"---------"，含义留白。0x0055 是 Bat_THERMA 电池温度（0.1℃）。0x0056 到 0x0062 是继电器状态与负载功率、负载发电量。
3.4 单位与符号：为什么同一个"电压"要除以 10 还是 100
| 典型字段 | 原始类型 | 倍率 | 还原方式 | 备注 |
|---|---|---|---|---|
| GridVoltage | uint16 | 0.1 | ÷10 | 并网电压 |
| BatVoltage_Charge1 | int16 | 0.01 | ÷100 | 有符号，注意方向 |
| GridFrequency | uint16 | 0.01 | ÷100 | 电网频率 |
| Temperature | int16 | 1 | 原值 | 摄氏度，可能为负 |
| Etotal | uint32 | 0.001 | ÷1000 | 高位在 0x53 |
| Etoday | uint16 | 0.1 | ÷10 | 当日发电量 |
| wExt_SetChargerPower | int16 | 1 | 原值 | 正充负放 |
这张表不是抄一遍就完事，它是后面所有解析代码的唯一依据。规范在多个版本里反复修过单位标注（V2.1 改过充电器温度从 0.1 改成 1，V2.4.1 修过一批单位，V2.4.4 又修过一次单位描述错误），意味着你手上的文档版本和机器固件版本可能不完全对齐。稳妥做法是挑两三个能物理验证的量做交叉校验：拿万用表量并网电压，和 GridVoltage 除以 10 对一下；拿钳形表量电池电流，和 BatCurrent_Charge1 除以 100 对一下。对不上就以实测为准，回头改自己的点表，别跟文档较劲。
4. 核心代码：用 Python 把寄存器读成工程量
前面把表读通了，接下来落到能跑的代码。我一般不用重量级框架，先用标准库把链路和节拍跑稳，确认数据对得上，再接 pymodbus 或者自研网关。下面的代码都是串行、单连接、单线程，看着笨，但对这类设备最稳。
4.1 连接与节拍控制：把 1 秒间隔做成强制约束
import socket import struct import time HOST, PORT, UNIT = "192.168.1.100", 502, 1 CYCLE = 1.0 # 两条指令之间的最小间隔 GAP = 0.12 # 发送后到开始收包的静默留白，>100ms TIMEOUT = 1.0 # 单次响应超时 _sock = None _last_ts = 0.0 def connect(): global _sock _sock = socket.create_connection((HOST, PORT), timeout=TIMEOUT) _sock.settimeout(TIMEOUT) def _pace(): """保证任意两条指令之间至少间隔 CYCLE 秒""" global _last_ts wait = _last_ts + CYCLE - time.time() if wait > 0: time.sleep(wait) _last_ts = time.time() def _recv_exact(n: int) -> bytes: buf = b"" while len(buf) < n: chunk = _sock.recv(n - len(buf)) if not chunk: raise ConnectionError("设备关闭了连接") buf += chunk return buf_pace里维护的是"上一条指令的发起时刻"，任何读或写都要先过一遍这个函数，等于把节拍做成了不可绕过的闸门。_recv_exact解决的是 TCP 粘包和半包问题：MBAP 头声明的长度是权威值，但recv一次不保证读满，不循环读就会出现"有时正常有时解析错位"的随机故障。GAP放在发送之后、接收之前，给设备留出文档要求的包间静默。
4.2 一次完整的读：从报文到寄存器数组
class ModbusError(Exception): pass def read_regs(func: int, start: int, count: int): """func: 0x03 读保持寄存器 / 0x04 读输入寄存器""" if not 1 <= count <= 32: raise ValueError("单次读取建议不超过 32 个寄存器") _pace() tid = int(time.time() * 1000) & 0xFFFF pdu = struct.pack(">BHH", func, start, count) _sock.sendall(struct.pack(">HHHB", tid, 0x0000, len(pdu) + 1, UNIT) + pdu) time.sleep(GAP) head = _recv_exact(7) r_tid, r_pid, r_len, r_unit = struct.unpack(">HHHB", head) body = _recv_exact(r_len - 1) # 长度字段含单元ID，减掉才是PDU r_func = body[0] if r_func & 0x80: # 异常响应，功能码最高位置1 code = body[1] raise ModbusError(f"异常码 0x{code:02X}: {EXC_DESC.get(code, '未知')}") byte_count = body[1] data = body[2:2 + byte_count] return [struct.unpack_from(">H", data, i * 2)[0] for i in range(byte_count // 2)] EXC_DESC = {0x01: "非法功能", 0x02: "非法数据地址", 0x03: "非法数据值", 0x04: "从站设备故障"}关键点有三个。count上限压到 32，是因为我实测一口气读 80 个以上寄存器时，设备经常直接超时不返回，而不是规规矩矩给异常码；分块读虽然慢，但 1 秒节拍下读 4 块也就 4 秒，对遥测刷新频率完全够用。异常判断看的是功能码最高位，不是看长度，r_func & 0x80为真就是异常帧，此时 body 里只有功能码和异常码两个字节。最后按byte_count而不是按你请求的数量去切数据，设备返回少了也不会越界。
4.3 32 位量与有符号量：feedin_power 和 Etotal 怎么拼
import struct def u16(regs, idx): return regs[idx] & 0xFFFF def s16(regs, idx): return regs[idx] - 0x10000 if regs[idx] & 0x8000 else regs[idx] def u32(lo, hi): return ((hi & 0xFFFF) << 16) | (lo & 0xFFFF) def s32(lo, hi): v = u32(lo, hi) return v - 0x100000000 if v & 0x80000000 else v # 一次读回 0x0046 起的 14 个寄存器，覆盖功率和累计电量 regs = read_regs(0x04, 0x0046, 14) # 对应地址 0x46 ~ 0x53 feedin_power_w = s32(regs[0x46 - 0x46], regs[0x47 - 0x46]) * 1 # 1W，int32 feedin_energy = u32(regs[0x48 - 0x46], regs[0x49 - 0x46]) * 0.01 # 0.01kWh consum_energy = u32(regs[0x4A - 0x46], regs[0x4B - 0x46]) * 0.01 # 0.01kWh e_total_kwh = u32(regs[0x52 - 0x46], regs[0x53 - 0x46]) * 0.001 # 0.001kWh规范里明确写了"0x46:LSB, 0x47:MSB"，所以拼接顺序是高位左移 16 位再或上低位，不能反过来。feedin_power 是 int32，因为倒送功率在电池充电时可能为负，用 u32 拼出来会变成一个 40 多亿的巨值，这是调试时非常典型的"数看着离谱"现象。Etotal 倍率是 0.001，比 Etoday 的 0.1 精细两个数量级，如果两台机器算出来的总发电量差 1000 倍，先检查是不是套错了倍率。
还有一个隐蔽问题：32 位量跨两个寄存器，如果分两次单独读，中间设备刷新了一次，低位已经进位而高位还是旧值，就会出现电量瞬间跳变的毛刺。解决办法就是像上面那样，把 0x46 到 0x53 放在同一次读取里，用同一帧的数据拼，成本极低。
4.4 故障字拆位：InvFaultMessage 与 BMS 告警
def bit_positions(value: int, width: int = 16): """把故障字拆成置位的位号列表，方便落库和告警映射""" return [i for i in range(width) if (value >> i) & 1] regs = read_regs(0x04, 0x001F, 0x25) # 0x1F BMS告警 ~ 0x43 Manager故障字 bms_warn = u16(regs, 0x1F - 0x1F) inv_fault = (u16(regs, 0x41 - 0x1F) << 16) | u16(regs, 0x40 - 0x1F) # MSB<<16 | LSB charger_f = u16(regs, 0x42 - 0x1F) mgr_fault = u16(regs, 0x43 - 0x1F) for name, val in (("BMS", bms_warn), ("INV", inv_fault), ("CHG", charger_f), ("MGR", mgr_fault)): if val: print(f"{name} 置位: {bit_positions(val)}")故障字这块要诚实一点：规范只给了 LSB 和 MSB 两个寄存器的位置，没有给逐位含义。直接上线生产告警是不负责任的。我一般分两步走，先按位号原样落库，把(设备号, 故障字类型, 位号, 首次出现时间, 消失时间)存成一张表，跑一两周；再拿着这张表去对照现场发生的实际事件（比如某天下午市电闪断，看看哪几位同时置位），反推出位定义。这套"先记录后解释"的模板比猜位定义靠谱得多，也能在厂商后续补充文档时快速对齐。
注意：故障字里出现 0x04 异常码时，先看设备是不是处于自检（TestStep 非 0）或保护锁定状态，此时读实时区会被拒绝。
4.5 写寄存器：远程控制模式与继电器时间字节打包
def write_reg(addr: int, value: int): _pace() tid = int(time.time() * 1000) & 0xFFFF pdu = struct.pack(">BHH", 0x06, addr, value & 0xFFFF) # 负数要先补码截断 _sock.sendall(struct.pack(">HHHB", tid, 0x0000, len(pdu) + 1, UNIT) + pdu) time.sleep(GAP) body = _recv_exact(7 + 5 - 7) if False else _recv_exact(5) # 回显5字节: 功能码+地址+值 if body[0] & 0x80: raise ModbusError(f"写 0x{addr:04X} 失败，异常码 0x{body[1]:02X}") def pack_relay_time(trig_min: int, close_hour: int) -> int: """继电器 TrigTimeSet 在低字节、CloseTimeSet 在高字节，合成一个寄存器""" return ((close_hour & 0xFF) << 8) | (trig_min & 0xFF)远程调度要按固定顺序走，顺序错了写了也不生效：第一步写 0x00DA 为 0x0100（高字节软件开关置 1，低字节硬件状态读回不动）；第二步写 0x008B 为 2，切到远程控制模式；第三步写 0x00D4，int16，正数充电负数放电，负值必须先& 0xFFFF转成补码；第四步回读 0x008B 和 0x00DA 确认，回读值不对就重来。这四步里任何一步跳过，最典型的表现就是"写进去了，机器没反应"。
继电器时间的打包逻辑来自 0x00E2 这个寄存器：规范写明TrigTimeSet占Uint8(Lo)、CloseTimeSet占Uint8(Hi)，分钟放低字节、小时放高字节，写反了会出现"设 30 分钟结果 30 小时后动作"这种看起来像设备坏了的现象。同样结构的还有 0x00E3 的 TrigMode 和 Time_Control、0x00E4 到 0x00E7 的起止时间。
5. 避坑与排查：联调时最常翻车的 5 个点
这套协议在纸面上很完整，真接上设备以后，翻车点集中在通信、解析、写入三个层面。下面几条都是我和同事实际踩过的，按现象、原因、解决三段写，遇到问题可以对着排查。
5.1 通信层：读整片寄存器为什么必然失败
现象：一次性从 0x0000 读 200 个输入寄存器，程序卡住或超时，抓包能看到请求发出去了，设备就是不回。改成读 20 个，一切正常。
原因：设备对单帧的寄存器数量和帧间隔都有约束，规范写了指令间隔 1 秒、包间静默 100 毫秒，但没写单帧上限；固件在实际实现里对超长帧直接丢弃而不返回异常码，所以从应用层看就是"静默超时"，非常像网络丢包。
解决：单帧读取数量压到 32 个以内，按功能分区逐块读，块与块之间严格执行 1 秒间隔。把超时重试做成显式逻辑，重试前先断开重连，别在同一条连接上连着灌请求。另外别忽略 TCP 半包，MBAP 头的长度字段是权威值，必须循环读到够数。
现象：昨天还好好的，今天连 502 端口都连不上。
原因：0x00BC IP Method 被改成手动（1）之后 DHCP 失效，设备换了个地址；或者有人在现场改过 MyAddress，从站地址不再是 1。
解决：固定部署时优先用 DHCP 加地址保留，别现场手改 IP Method。连不上时先扫网段找 502 端口，再读 0x0084 MyAddress 确认从站号，这两个动作能把问题范围缩到最小。
5.2 解析层：乱码、翻倍与负数异常
现象：序列号读出来是乱码，或者只有前几个字符对。工厂名、模块名同样。
原因：0x0000 到 0x0006 是 7 个寄存器装 14 个字符，每个寄存器两个字符，MSB 在前；直接按小端拆或者把寄存器值当整数转字符串都会错位。
解决：按大端把每个寄存器拆成高字节和低字节，依次chr()拼起来，末尾补零截断，再strip()去空白。三个身份字段（序列号、工厂名、模块名）结构完全一致，写一个函数复用即可。
现象：电池电流显示成 6000 A 这种离谱值，或者明明在放电却显示正几安。
原因：BatCurrent_Charge1 是 int16，规范标 0.01A；按下发值处理时没做有符号转换，负数被当成 6 万多的大正数，除以 100 就变成几百安。同类字段还有 Temperature、GridCurrent、Batpower_Charge1、wExt_SetChargerPower。
解决：建一张字段元数据表，每个字段标清楚type（uint16/int16/int32/uint32）和scale，解析统一走同一个函数，不允许在业务代码里各写各的除法。上线前挑电压、温度、频率三个量做物理校验。
现象：Etotal 累计发电量两次读取之间跳变几千度，或者比 Etoday 大得离谱。
原因：32 位量跨寄存器，分两次读导致高低位不同步；或者把 Etotal 的 0.001 倍率套成了 Etoday 的 0.1。
解决：把跨字节的量放在同一次读取里，用同一帧数据拼；倍率全部集中在元数据表里，别散落到各处。
5.3 写入层：配置写进去了但不生效
现象：通过 0x00D4 下发充电功率，写指令返回正常，回读也对，但电池该充还是照旧，功率纹丝不动。
原因：SolarChargerUseMode 还在 0 自用模式，远程功率只在这个字段等于 2 时被采纳；或者 0x00DA 的软件开关（高字节）还是 0。
解决：固定按"开软开关 → 切模式 2 → 写功率 → 回读确认"四步走，把这四步封成一个enter_remote_mode()函数，任何远程写操作前都先调一次。退出远程时记得把模式切回 0，否则断电重启后机器还是等着上位机下指令，现场会以为设备坏了。
现象：改了充放电时段，到点不动作。
原因：Allow_Grid_Charge 是用值 3 表示"两个时段都允许"，不是位或；只写了时段没改这个字段，等于没授权。另一种情况是 0x00A2 之后的 REV 区域被误写，把预留槽位当成了有效配置。
解决：修改时段时把四个时间寄存器加 Allow_Grid_Charge 一起写，写完回读整段 0x0092 到 0x00A1 核对。REV 区域一律不碰，文档标 REV 就是没定义，写了可能触发未预期的行为。
现象：继电器动作时间不对，设成 30 分钟，实际过了很久才动。
原因：0x00E2 这类寄存器低字节和高字节各存一个字段，把分钟写进了高字节、小时写进了低字节。
解决：所有双字段寄存器统一走pack_relay_time这类打包函数，别手写移位。写完回读一次，把寄存器拆回两个字段打印出来核对，比看文档快。
6. 二次开发：把寄存器表变成一个点表驱动的采集网关
二次开发最忌讳的是把地址硬编码进业务代码。这个项目我最后悔的一件事，就是第一版直接在采集循环里写了几十个read_regs(0x04, 0x0000, 20)加下标取值，等设备升级到新固件、加了电池 SOH 和充电器输入能量之后，改一处地址要翻五个文件。后来改成点表驱动，才算是把这个坑填上。
核心思路是把寄存器表落成一份结构化配置，采集器只认配置，不认地址。每条点位至少要有这几个字段：
| 字段 | 示例 | 说明 |
|---|---|---|
| name | battery_voltage | 业务侧统一命名 |
| func | 0x04 | 功能码，决定读哪块空间 |
| addr | 0x0014 | 起始地址 |
| count | 1 | 占几个寄存器，32 位量 |
本文还有配套的精品资源，点击获取
