KNX 场景 1 为什么报文值是 0：怎样拆 DPT17 与 DPT18 学习位

人读的场景1到64，对应DPT17线上原始值0到63。DPT18还把最高位用于学习/调用控制，低六位仍是零基场景号；同一个字节必须先看DPT，不能把学习位加到场景编号里。

适用版本与输入范围

依据 XKNX 维护者仓库固定标签 3.6.0 的下列源码，只实现本文明示的数据点或组值解析子集。它不是 KNX 规范全文，也不是设备互通认证；组地址与DPT应由项目点表明确提供。 本文所有输入均为原创合成数据，未接真实设备。

人类编号和线上码各存一列

附件DPT17 raw=0解为场景1，raw=63则是场景64。这是维护者接口采用的人读编号转换，点表与界面应统一采用哪一种显示，不能一边用0起另一边用1起。程序输出scene为人读编号，输入raw保留线上码，避免为修复偏一问题直接修改组地址或场景绑定。DPT17 raw=64显式越界，不能取低六位回到场景1，因为那会把错误码变成完全不同场景。

DPT18的学习位单独解码

场景32的线上号31，加最高位80得到9F，也就是十进制159。程序返回scene=32、learn=true，而不是场景160。调用场景64时原始值3F，learn=false。学习与调用可能产生完全不同副作用，工程日志必须区分，不能只显示“场景32已发送”。本题仅解释位域，没有发送学习电报，不会改变任何设备已保存的场景状态。

保留位不要冒充场景高位

DPT18的bit6不属于低六位场景号，附件raw=64解为场景1并标记reserved_bit6=true，展示提取值与检测保留位可以同时完成。这个诊断字段是本程序额外提供，维护者解析器按掩码取场景号，不保证抛出相同错误。项目若要求严格发送检查，可在发送前拒绝保留位；处理既有日志时则应保存原字节和诊断，而不是静默抹掉后说输入完全规范。

场景码正确仍需设备场景表

数字32并不自带“开馆”“讲解”或“夜间”等业务名称，不同执行器可能保存不同动作，只有工程配置才能保证一致联动。交付时应将组地址、DPT17或18、编号显示方式、学习权限及实际设备场景清单对应起来。本附件未加载ETS项目，也不验证执行器是否已学习。它解决线上码与人读编号的转换及控制位解释，不将一个正确字节当作全馆场景已经设置或互通认证通过。

下载与复跑

将输入 fixture.json与独立程序 verify.py放在同一目录，用 Python 3.12 执行 python verify.py，无需安装第三方包。程序从自身目录读取输入并写入 report.json，不要求当前终端恰好位于下载目录。也可查看本次实跑报告和复跑说明。

本次实际运行通过 5 条输入断言，包括标有“显式负例”的记录；负例以JSON字段承载，不会把下载文件本身做成损坏编码。scene采用人读1到64；learn=None表示DPT17无该控制位，reserved_bit6是额外诊断。 修改输入后应同时审查期望结果，不能只改断言数字让测试变绿。

对象或字段的基础关系可回到KNX 组地址与DPT入门核对，更多接口入口在设备协议库。若需要把已确认的数据点接入展项编排，可了解SoftControl 展厅中控；具体接入能力以项目确认和实际测试为准。

一级依据

• DPTSceneControl；并参照dpt_17.py
• DPTSceneNumber零基场景号转换

来源核对日期：2026-10-24。离线结果只证明给定输入的解析或计算行为；现场兼容性、响应时间、硬件准确度和具体产品支持均未测量。