可寻址照明网关场景下发别只看平台成功
把平台、网关、本地面板和现场灯具的场景执行结果一起核清，避免下载成功了，分区动作、回写状态和实际效果却各走各的。
现场判断
施工知识
先确认工序边界、施工条件和交接面，再按本文步骤落到现场。
优先把本文对应的工序检查点、照片编号和交接条件写进当天记录。
- 施工部位与工序条件
- 班组交接与样板状态
- 照片编号与复查结论
检查清单
优先使用文章内配套清单；没有清单时可复制正文检查项。
读完直接接到现场动作
按本文内容匹配规范口径、资料模板、计算工具和材料条目，减少来回搜索。
可用模板
把检查结论落到表格、台账或记录。
对应计算器
涉及数量、坡度、损耗或工期时先统一口径。
可寻址照明系统最容易留下的假闭环，就是平台上点了“下发成功”，现场也能看到几盏灯亮起来，于是所有人都默认场景已经调通。可一到真正交付、夜间运行或跨区联动时，就会暴露出一连串问题：网关实际生效的不是这一版，面板名称和平台分区对不上，部分回路延时、漏动作，回写状态还显示正常。
这篇内容只处理 场景下发后的执行结果一致性。它不重复讲 智能照明网关场景版本冻结与回退复核 的版本冻结与回退边界，也不替代 照明控制模块地址标签与回路映射复核 的模块映射问题。前者更偏 这次发的是哪一版、出错怎么退，后者更偏 这个地址到底控谁，这篇解决的是一句话：这次场景发下去以后，平台、网关、面板和现场动作到底是不是同一个结果。
哪些时候必须做场景执行一致性审核
- 准备把智能照明系统从调试阶段转入交付或试运行阶段。
- 刚做过场景调整、分区重组、模块换位或回路归属修正。
- 现场存在本地面板、远程平台和网关日志三套观察面，结果却经常对不上。
- 高峰时段、夜景模式、保洁模式或跨区联动场景准备正式投入使用。
如果当前连地址、端口和受控回路对象都没锁清，先回到模块映射页；如果当前主要风险是下载前版本没冻结、旧包回不去，先回到版本冻结页。顺序不要反。
这篇回答什么，不回答什么
这篇回答的是：
- 场景包下发后，目标网关是否真正生效到预期版本和预期分区。
- 平台、本地面板、网关状态和现场灯具动作是否一致。
- 高频场景、跨区联动场景和回写状态是否在真实工况下稳定。
它不直接回答：
- 新旧场景包如何冻结、编号和回退。
- DALI 编址前的地址策略和分组预留是否合理。
- 控制箱移交时当前手自动状态和恢复路径是否已交清。
下发前先锁住四个基线
1. 网关和场景版本
- 先确认本轮要验证的是哪只网关、哪一版场景包、哪一轮变更。
- 平台显示的目标版本、网关当前版本和测试记录里的版本号要一致。
- 没有明确版本号的“最新版”不算基线。
2. 分区和场景命名
- 平台分区名、本地面板分区名和图纸区域名要能互相回指。
大厅东侧洗墙灯、L1-SC-03、A 区夜景组这类叫法若不能建立映射，后面很难判断是不是动作正确。
3. 观察窗口
- 平台操作界面、网关状态页、本地面板和现场观察点要提前确定。
- 只看其中一端，通常只能证明“某一端看起来成功”，不能证明整个链路一致。
4. 高频场景清单
- 不要只准备全开全关。
- 至少把夜景、保洁、值守、半亮、会客、跨区联动这类高频或高投诉风险场景列出来。
现场审核怎么做才有意义
先看网关是否真的吃到了目标场景
- 平台显示下载成功，不代表目标网关已经按预期版本运行。
- 先确认目标网关在线状态、场景包编号和下发时间，与本轮记录一致。
- 如果不同网关表现不一致，先怀疑生效范围和下发结果，不要急着把所有问题都归到灯具故障。
再看平台、本地面板和现场动作是否同步
- 在平台侧触发目标场景。
- 同步观察本地面板显示、网关状态变化和现场灯具动作。
- 核对分区内每一类灯具的开关、亮度、渐变方向和响应时序。
- 对跨区联动场景，确认不该动作的区域确实没有被带动。
只要有一端结果不同，就不能简单算“基本没问题”。场景一致性审核看的不是有没有亮，而是 该亮的都按预期亮，不该亮的没有误动作，显示状态还能回得来。
最后看回写和二次调用是否稳定
- 首次调用正确，不代表第二次、第三次调用也正确。
- 对关键场景至少做重复触发，确认回写状态不会漂移，面板状态不会卡住，现场效果不会越调越偏。
- 若同一场景第一次正确、第二次异常，优先怀疑网关状态同步、设备掉线或局部分区映射，而不是继续盲目改场景值。
哪些现象说明场景还不能交
- 平台显示下发成功，但网关里看不到对应版本或对应场景编号。
- 本地面板显示已切换，现场灯具却没有按预期动作。
- 现场效果基本对，但回写状态长期错误，后续值守人员无法判断当前真实模式。
- 只要跨区联动或半亮场景就出现串区、漏动作或亮度不一致。
- 同一场景重复调用后，响应时间、分区结果或状态回写发生漂移。
这些问题只靠截图平台成功页是盖不住的。
它和版本冻结、模块映射、控制箱交接怎么分工
- 智能照明网关场景版本冻结与回退复核 负责
这次发的是哪一版，旧版能不能退。 - 照明控制模块地址标签与回路映射复核 负责
地址、端口和回路对象是不是同一个东西。 - 照明控制箱交接不要只交钥匙和回路表 负责
接手人知不知道当前模式、控制范围和恢复路径。
这篇处在中间，专门证明 场景执行结果本身 是一致的。版本基线没锁清、对象映射没锁清或控制状态没交清，都会让这一步反复返工，但它们不能替代这一步。
更稳的审核顺序
- 先确认模块地址、端口和回路对象已经收口。
- 再冻结本轮场景版本、分区命名和观察窗口。
- 先做单网关、单批次试点，不要一上来整片区域同时推送。
- 重点验证高频场景、跨区联动和重复调用结果。
- 最后再把当前正式版本、异常清单和恢复结论带入交接。
资料和规范怎么落
- 主记录直接使用 智能照明网关场景下发记录。
- 分区命名、图纸区域和现场对象还没统一时，先用 图纸核对清单 收口。
- 如果异常已经明确涉及版本冻结、回退包和试点窗口，再联查 智能照明网关场景版本冻结与回退复核。
- 控制口径优先查 智能照明网关场景下发一致性控制，系统总体验收再联查 建筑电气验收。
一句话记住：场景下发审核不是看“平台有没有报成功”，而是看 平台、网关、面板和现场效果是不是同一个结果。只要四端还没有真正对齐，这套场景就还不能算交付完成。