KNX GroupValueRead、Response、Write 的两个控制字节怎样区分

本题组值APCI子集中，00 00是GroupValueRead，00 40加短数据是Response，00 80加数据是Write。服务类型与数据负载应分别提取；读取请求没有值，响应与写入也不能因带同样数值就归为同一事件。

适用版本与输入范围

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

先识别服务再解释负载形态

附件00 41表示组值响应，低六位短值为1；00 80 80表示组值写，最后追加字节80为原始值128。两个80在后一条输入中角色不同：前者参与服务控制，后者才是数据。程序用掩码取服务高两位，剩下低六位与追加字节分别处理，避免对整个第二字节统一求值。本子集首字节固定00，不假装支持任意TPCI或全部APCI扩展服务。

读请求不能伪造一个零值

00 00的payload_kind应为none、payload为null，而不是数值零。否则采集日志每发一次GroupValueRead就可能记录一个假零，把真实反馈曲线打断。显式负例00 01虽然仍落在读服务位模式，但低位带了数据，本程序作为严格组读输入拒绝。Response与Write短数据可以是零，那与没有负载是不同状态；接口需要明确表达这个区别，不能只凭payload真假值判断是否有数据。

长数据和内嵌数据不混用

追加负载时，本程序要求低六位为空，再把第三字节起的数据保存成数组；两字节情况下则保存inline6短值。具体DPT决定该形态和长度是否合法，这一层不自动把128解释成50.196%或把1解释为开灯。完整解析应先拆APCI，再把payload交给点表指定的DPT解析器。这样服务解析与类型解析各自可测，遇到不支持类型时仍能保留服务和原始内容。

未知服务保留到正确处理路径

00 C0不属于这里三个组值服务，不能因为低位零就当成组写关闭。程序明确报超出子集，提醒调用方使用有依据的其他APCI实现。本题不处理KNXnet/IP连接、隧道序列、cEMI链路确认或安全包装，更不把GroupValueResponse等同于某次Write已成功的自动确认。附件只验证给定控制字节的分流，不发送读写，不声称真实设备会对所有读请求响应；实际组对象是否可读仍需工程配置。

下载与复跑

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

本次实际运行通过 5 条输入断言，包括标有“显式负例”的记录；负例以JSON字段承载，不会把下载文件本身做成损坏编码。payload_kind区分无值、短值和追加字节；payload不含DPT解释，不能直接视为工程量。 修改输入后应同时审查期望结果，不能只改断言数字让测试变绿。

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

一级依据

• APCIService / GroupValueRead / GroupValueWrite

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