极物科技 | KNX协议 - APCI指令与数据点类型解析
前言
KNX 之所以能成为全球楼宇自动化的"通用语言"，靠的是严谨到字节级的协议设计------它既是国际标准 ISO/IEC 14543-3，也意味着任何厂商按规范实现的设备都能在同一总线上精确协作。
极物科技的产品同样构建在开放标准之上：自研 KNX 主机的极物 OS 原生支持 KNXnet/IP 路由与隧道双通道，与 knxd、ETS 等主流工具链无缝互通；配套鸿蒙、苹果、安卓三端原生 APP，深度接入 Apple HomeKit 与小度生态，支持主机远程调试------工程调试不受任何私有协议锁定。
一句话概述：本文回答"KNX报文里的指令和数据分别怎么编码"------APCI决定"做什么"，DPT决定"数据长什么样"，两者组合是每条KNX报文的语义内核。
1. APCI：应用层指令集
APCI（Application Program Connection Interface）共10位（TPCI 2bit + APCI 8bit），日常工程只用三个指令：
| APCI | 指令 | 语义 | 典型触发方 |
|---|---|---|---|
| 0x000 | GroupValueRead | "这个组地址现在的值是多少？" | 主机/面板 |
| 0x040 | GroupValueResponse | "这个组地址的值是X" | 执行器 |
| 0x080 | GroupValueWrite | "把这个组地址写成X" | 主机/面板/传感器 |
1.1 指令协作的闭环
text
主机 ──Read(0x000)──→ 执行器
主机 ←─Response(0x040)── 执行器 ← 状态查询闭环
主机 ──Write(0x080)──→ 执行器 ← 控制下发
执行器 ──Write(0x080)──→ 总线 ← 状态主动上报（可选）1.2 APCI字节的位拼装
APCI高2位在指令字节的高2位，低2位直接充当数据首2bit------这是1bit数据无独立数据字节的原因：
text
指令字节 0x81 = 1000 0001
└APCI写┘└值=1 → 开
指令字节 0x80 + 数据 0x32 → 写百分比502. DPT：数据点类型
DPT（Data Point Type）规范了组地址上数据的长度与量纲，格式主类型.子类型：
2.1 日常高频DPT速查表
| DPT | 名称 | 长度 | 值域 | 极物设备模型映射 |
|---|---|---|---|---|
| 1.001 | 开关 | 1bit | 0/1 | 继电器开关、面板按键 |
| 1.003 | 使能 | 1bit | 0/1 | 空调/新风开关 |
| 1.008 | 升/降 | 1bit | 0/1 | 窗帘升降 |
| 1.009 | 升/降步进 | 1bit | 0/1 | 百叶步进 |
| 5.001 | 百分比 | 1byte | 0~100 | 调光亮度、窗帘行程 |
| 5.003 | 角度 | 1byte | 0~360 | 百叶角度（映射0~100） |
| 5.010 | 计数器0-255 | 1byte | 0~255 | 场景号（17.001更常用） |
| 6.001 | 百分比(带符号) | 1byte | -100~100 | 相对调光 |
| 9.001 | 温度 | 2byte | -273~670760 | 环境温度 |
| 9.021 | 亮度lux | 2byte | --- | 光照传感 |
| 17.001 | 场景号 | 1byte | 164（总线063） | KNX原生场景 |
| 20.102 | HVAC模式 | 1byte | 枚举 | 空调模式 |
| 232.600 | RGB | 3byte | 0~255×3 | 彩色灯 |
2.2 2byte浮点（DPT 9）编码
9.xxx采用"1bit符号+4bit指数+11bit尾数"的半精度格式：
text
值 = ±尾数 × 0.01 × 2^指数
字节1：S EEE EMMM（S=符号，E=指数，M=尾数高位）
字节2：MMMM MMMM（尾数低8位）
示例：0x07 0x94
→ 符号0，指数0000，尾数 0x794 = 1940
→ 1940 × 0.01 × 2^0 = 19.40（℃）💡 温度报文建议直接用极物主机的UDP JSON协议（
temperature_now字段，单位℃）对接，免去浮点换算；DPT 9仅在直接分析总线报文时需要手撕。
2.3 场景号DPT 17.001的"减一陷阱"
ETS中场景号显示164，总线上实际传输**063**（写入值=场景号-1）。极物主机激活KNX场景时自动完成减一：
c
/* 场景激活：配置的场景值 → 总线场景号 */
knx_write_one_byte(scene->group_address, scene->value - 1);3. DPT与极物主机设备模型的映射实践
极物主机将常用DPT预映射进八类设备模型，工程侧"选模型+绑地址"即可，无需逐字段配置DPT：
| 设备功能项 | 约定DPT | 说明 |
|---|---|---|
| 继电器 开关/状态 | 1.001 | 控制与状态地址成对 |
| 调光灯 亮度 | 5.001 | 0~100直接对应 |
| 窗帘 行程 | 5.001 | 100=全开（以机构配置为准） |
| 窗帘 角度 | 5.001 | 主机内部映射0~100 |
| 空调 开关 | 1.003 | on/off |
| 空调 模式 | 20.102 | 制冷/制热/除湿/送风/自动 |
| 空调 设定温度 | 9.001 | 16~30℃ |
| KNX场景 | 17.001 | 主机侧值=总线值+1 |
⚠️ ETS工程中若把开关对象配成了5.001而主机按1.001解析，会出现"开灯变调光"的怪象------导入XML后逐设备核对DPT是验收必做项。
4. 用knxtool验证DPT
bash
# 读1bit组地址（观察返回 00/01）
knxtool grouplisten ip:localhost 1/1/1
# 写1byte百分比
knxtool groupswrite ip:localhost 1/2/50
# 写2byte温度
knxtool groupwrite ip:localhost 1/3/1 0x00 0xC25. 相关文档
- 《极物科技 | KNX协议 - CEMI报文帧格式详解》
- 《极物科技 | KNX协议 - 读/写/响应机制与状态同步》
- 《极物科技 | knxd - knxtool命令行调试工具全解》
- 《极物科技 | KNX空调 - 模式风速与控制码适配》
关于极物科技（ZEEWO）
极物科技（Zeewo）致力于为用户提供智能控制系统及硬件产品。我们以总线系统为技术底座，以**"稳定、可靠、快速响应"**为产品底线，是国内少有的拥有 KNX、DALI 全套软硬件自主研发能力的厂商之一。
我们的核心能力：
- 系统架构：自研极物 OS，支持多协议无界融合（KNX/DALI/CAN/RS485/IP）。
- 核心硬件：带双路 DALI 的 KNX 主机、超薄全金属定制面板、各类智选传感器及网关。
- 生态互联：深度融入 Apple HomeKit、Matter、小度、HomeAssistant 及纯血鸿蒙生态。
- 调试交付：独家支持 ETS 导出 XML 直接导入进行 APP 免编程调试，支持远程 WEB 运维。
我们的市场覆盖：
服务网点已覆盖全国核心城市（含长三角、珠三角、成渝等），并以高品质的方案深耕家居生活、酒店民宿、企业办公、疗愈康养、餐馆会所等多个细分领域。
(如果您在开发或落地中遇到技术问题，欢迎通过官网或后台私信与我交流探讨)