refs
用户 yeg <1347747024@qq.com>
星期日, 十月 11, 2026 02:15 +0800
提交者 yeg <1347747024@qq.com>
星期日, 十月 11, 2026 02:15 +0800
提交09e7ea0d2270acdedc37ab4338834a0c35da0611
目录 b8ff443aa6d953207d65e27071f66a9af4f58357 目录 | zip | gz
parent 6b99cc391064cb38c706979fafcecb9f50ea1587 查看 | 对比
搁置步的容量能量不再当该步自身值交出(与厂商库逐项核对后修)

核对方式是拿同一个测试把接口工步层对到厂商自己的库表上(C 那台两条路都能读):
21 段工步序列(含两处"回到上一步"的中断分段)、逐项结束时间、结束电流、
容量能量、循环号全部一致,逐点行数在三处(接口 inquiredf / test.rec_num / cap_step 末行 seq_id)
都是 3494。界面显示的就是库里的数,所以这比截图核更硬。

核对抓到一个真缺陷:接口的 cap/eng 在搁置步上不是该步自身累计,而是跨步过渡值
(实测 +0.290039804444444,恰等于上一步充电容量;另一处 −0.178807573333333 取负)。
原实现按"方向已确认就给"的口径,搁置方向也把它当该步容量,会写出"搁置步容量 0.29 Ah"
这种不成立的事实。现在只有充放电方向交出单项容量能量,搁置步留空;原文仍留在明细里供核对。
该步自身累计为 0 这件事设备没给,所以留空而不是补零。

battery-device-bts 71 项通过;后端全量通过、BUILD SUCCESS。
2个文件已修改
52 ■■■■■ 已修改文件
battery-device-bts/src/main/java/com/battery/device/bts/BtsXmlCodec.java 30 ●●●●● 对比 | 查看 | 原始文档 | blame | 历史
battery-device-bts/src/test/java/com/battery/device/bts/NewareBtsXmlCodecTest.java 22 ●●●●● 对比 | 查看 | 原始文档 | blame | 历史