KNX 相对调光值不是亮度百分比：怎样解析 DPT3 方向和步长码

DPT3.007的四位数据由一位方向和三位步长码组成，不能当成0到100%的绝对亮度。步长码0表示break，1到7表示分割级别；方向位为一表示增加，为零表示减少，本程序保留方向与步长两个独立字段。

适用版本与输入范围

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

四位值不是十六档亮度

附件nibble=9就是二进制1001：高位1表示增加，低三位001是步长码1。它不是亮度9%，也不是目标值9。若把这个值直接写入绝对调光百分比字段，用户按“变亮”会被误解释成跳到一个很暗的固定值。本题只解析DPT3.007的相对调光子型，遮阳等其他DPT3子型要另按其方向枚举解释，不沿用increase/decrease命名。

步长码通过分割级别表达

公开实现以2的step_code-1次方表示范围分割数量，代码1对应1份、代码7对应64份。报告输出subdivisions而不输出实际每秒变化亮度，因为灯具执行速度、设备设置及持续动作策略不在这些位里。步长码越大分割越细，但不能由此推导某型号灯具的实测响应时长；如果界面要显示增减幅度，应清楚这是协议码解释，而非亮度测量。

break与方向分别保存

输入0和8的步长码都为零，都是break，只是方向位不同。程序不会把8解释成“继续增加8级”，也不会把零误当作缺失值。显式负例16超出四位，必须拒绝而非与15相与截断，后者会把错误输入变成另一个合法命令。工程日志应同时保存原短值和拆分字段，便于追踪按键按下、保持、松开等动作序列，但本题没有模拟完整按钮状态机。

相对控制与绝对反馈分开

实际执行器收到相对命令后形成的最终亮度，还取决于当前状态、配置和执行时间，不能只看一个DPT3电报就推算。交付应注明命令组地址采用DPT3.007，若需要百分比显示，另确认反馈数据点及其DPT。附件没有访问总线，也没有测灯具调光曲线。它的价值在于接设备前验证网关是否把方向与步长拆对，避免在协议转换中把命令码误当成工程量。

下载与复跑

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

本次实际运行通过 5 条输入断言，包括标有“显式负例”的记录；负例以JSON字段承载，不会把下载文件本身做成损坏编码。subdivisions是协议步长级别，不是灯具速度；command=break时不计算分割数量。 修改输入后应同时审查期望结果，不能只改断言数字让测试变绿。

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

一级依据

• DPTControlDimming / DPTControlBlinds

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