DALI 分组、场景矩阵与断电回归复核

围绕 DALI 编址完成后的分组逻辑、场景矩阵、断电重启回归和资料同步复核，避免地址写进去了但系统仍不稳定。

很多 DALI 系统的问题，并不出在“地址没写进去”，而是地址写进去以后没有把分组、场景矩阵和断电回归真正做扎实。调试当天灯具都能点亮，大家就默认系统已经好了；可一到第二天重启、断电恢复、切换高频场景或换人接手，就会暴露出串组、错场景、部分灯具不跟随或回归失败的问题。

这篇内容处理的是“编址之后的回归复核”这一步，不重复讲 DALI address 编程批次调试 的批量写入动作，也不重复讲 智能照明网关场景版本冻结与回退复核 的版本管理。前者负责把地址写进去，这篇负责证明系统在真实使用和重启后仍然稳定。

编址完成后，先别急着交付

更稳妥的 DALI 调试节奏通常是：

1. 先完成基础寻址和逐点识别。
2. 再完成分组策略和场景矩阵录入。
3. 然后做场景调用、跨组联动和异常边界测试。
4. 最后做断电重启、重新扫描和资料同步回归。

少了最后两步，系统通常只是“调通过”，还称不上“可交付”。

先复核分组，不要只看地址

分组边界是否真的符合使用逻辑

• 同一区域是否被完整放进同一组，还是只因安装顺序相邻就被硬编到一起。
• 不同功能场景是否需要跨回路同组控制，若需要，组逻辑是否已清楚标到资料里。
• 应急、保洁、展示、会议、夜景等不同工况是否被混在同一控制组中。

地址对，不代表组就一定对。很多串组问题只有在调用真实场景时才会暴露。

组号、组名和图纸分区是否统一

• 平台组名、面板组名和图纸分区名要能互相对应，不要一边叫“东走廊”，另一边叫“L2-C3”。
• 组号可以是技术编号，但现场至少要能映射回人能看懂的区域名称。
• 后续维保如果需要靠猜哪个组对应哪个区域，这套分组基本就不算稳定。

场景矩阵怎么复核才有意义

不要只测全开全关

• 真正容易暴露问题的，通常是半亮、夜间、清扫、会客、演示或跨区联动场景。
• 这些场景能更快看出是不是有一部分灯具没进对组、亮度值没写对，或者同一组里混入了不该跟随的回路。
• 如果只测全开和全关，很多分组偏差会被彻底掩盖。

场景矩阵要能倒推出每组的目标状态

• 复核时要能说清某一场景下每个组该处于什么亮度、是否开启、是否允许过渡。
• 如果现场只是看“差不多亮了”，但说不清哪个组应该亮到多少，后面几乎没法复盘。
• 涉及渐变和延时的场景，至少要确认过渡方向和结果是否稳定，不要只看起点。

断电重启回归，为什么必须做

很多系统在调试期间一直带电，地址、分组和场景看起来都正常。但真正交付后，问题往往出在：

• 断电恢复后部分设备未正确回到原分组。
• 场景参数生效在运行内存里，重启后并没有真正保留。
• 重新扫描后设备顺序变化，导致资料和现场不再一致。

所以更稳妥的做法是：

1. 在一轮完整调试通过后，执行断电重启或受控重启。
2. 重启后重新抽查关键地址、关键组和高频场景。
3. 对比重启前后的资料导出和现场结果，确认没有隐性漂移。

如果这一轮不做，后面很多所谓“偶发问题”其实只是调试时没验证到重启行为。

什么时候该怀疑不是分组，而是别的链路

• 如果同一回路反复掉线、寻址失败或最远端常不稳定，优先怀疑总线电压余量而不是场景参数。
• 如果同一组里只有某个模块下游不响应，优先怀疑模块映射或端口标签问题。
• 如果平台和本地面板显示不同步，但现场灯具动作正确，优先怀疑网关状态回写或版本基线。

把问题先归到正确链路，比一上来改场景参数更重要。

最容易出现的假闭环

• 地址分配完成就结束，不再做场景矩阵和断电回归。
• 只做全开全关，不测高频业务场景。
• 分组逻辑能在调试人脑子里解释，但没写进资料。
• 重启后只抽查一盏灯，不抽查关键组和关键场景。
• 场景改了，但平台、面板和资料版本没有同步。

资料怎么留，后面才不用重调一遍

• 编址、分组、场景调用和回归过程，主记录继续用 DALI 地址编程器批量调试记录。
• 如果同时涉及网关场景包、版本冻结和回退路径，再补到 智能照明网关场景下发记录。
• 分区名称、图纸归属和现场对象还没统一时，先用 图纸核对清单 把分组边界锁清。

关联页面

• 批量寻址和逐点识别，继续看 DALI address 编程批次调试。
• 编址前的回路规划和地址策略，继续看 DALI 回路规划与地址策略复核。
• 模块端口和回路对象对应关系，继续看 照明控制模块地址标签与回路映射复核。
• 网关版本冻结与异常回退，继续看 智能照明网关场景版本冻结与回退复核。