🌐 This page is not yet available in English. Showing the Chinese version. Back to Chinese page.
本文目录
- 1. 1. KNXProtocol分层（OSI模型简化）
- 2. 2. Communication模式
- 3. 3. message type
- 4. 4. address结构
- 5. 5. data表示（APDU）
- 6. 6. Communication服务
- 7. 7. 安全机制
- 8. 8. 实际debug建议
- 9. 1. 标准帧（L_Data Standard）
- 10. 2. 扩展帧（L_Data Extended）
- 11. 3. Confirm帧（ACK/NACK）
- 12. 4. 轮询Request（Polling Request）
- 13. 5. Response帧（Response）
- 14. 6. 广播帧（Broadcast）
- 15. 7. 安全message（KNX Secure）
- 16. 关键对比表
- 17. Precautions
- 18. 以下示例说明：
- 19. 示例1：switch控制（标准帧）
- 20. 示例2：Temperature Sensordata（扩展帧）
- 21. 示例3：Scenarios控制（多byte count据）
- 22. 关键点
- 23. 实际应用建议
1. KNXProtocol分层（OSI模型简化）
KNXProtocol主要基于 OSI模型的简化版本，分为四层：
| OSI层 | KNX实现 | Function说明 |
|---|---|---|
| 物理层 | TP（双绞线）、RF、IP | 定义物理介质（如KNX TP1总线、无线射频、KNXnet/IP隧道）。 |
| data链路层 | KNX Data Link Layer | 管理总线仲裁、冲突检测、帧校验（如checksum）。 |
| 网络层 | KNX Network Layer | 处理路由（组播/广播）、address过滤（物理address与组address）。 |
| 应用层 | KNX Application Layer | 定义data语义（如DPTType）、设备间交互逻辑（读/写/Response）。 |
2. Communication模式
(1) 组播（Group Communication）
- 用途：设备向组addresssenddata，所有订阅该组addressequipmentreceive并处理。
- 特点：高效的一对多Communication，适用于灯光控制、Scenarios触发等。
- 示例：
组address 1/2/3receive开灯指令，所有绑定此address的灯执行Operation。
(2) 点对点（Point-to-Point）
- 用途：设备直接通过物理addressCommunication（如配置、诊断）。
- 特点：需明确指定目标物理address，用于设备初始化或维护。
- 示例：中控设备
0.0.1向Sensors1.1.10Requesttemperaturedata。
3. message type
KNXmessage分为 标准帧（L_Data） 和 扩展帧（L_Data Extended）：
| Type | 控制field值 | dataLength限制 | 适用Scenarios |
|---|---|---|---|
| 标准帧 | 0xBC | ≤ 15byte | 常规控制指令（switch、百分比） |
| 扩展帧 | 0xBF | ≤ 255byte | 大data传输（如日志、配置） |
4. address结构
(1) 物理address（Individual Address）
- format：
区域(4bit).线(4bit).设备(8bit)→ 2byte。 - 示例：
1.2.3→0x12 0x03（binary0001 0010 0000 0011）。 - 用途：唯一标识设备，用于点对点Communication或设备配置。
(2) 组address（Group Address）
- format：
主组(5bit)/中间组(3bit)/子组(8bit)或主组(5bit)/子组(11bit)→ 2byte。 - 示例：
3/2/1→0xE3 0x21（binary1110 0011 0010 0001）。5/2047→0xA5 0xFF（binary1010 0101 1111 1111）。- 用途：逻辑分组，设备订阅组address实现一对多Communication。
5. data表示（APDU）
(1) DPT（Data Point Type）
KNX通过 DPT标准 定义data语义，format为 主Type.子Type（如 DPT 1.001 表示布尔switch）：
| DPT示例 | dataLength | 说明 |
|---|---|---|
| DPT 1.001 | 1 bit | 布尔值（0=关，1=开）。 |
| DPT 5.001 | 1byte | 百分比（0x00=0%，0xFF=100%）。 |
| DPT 9.001 | 2byte | temperature（浮点数，如 0x0C00=24°C）。 |
| DPT 16.001 | 14byte | 字符串（ASCIICoding，如 "KNX"）。 |
(2) APDU结构
- TPCI（Transport Control）：1byte，标记message type（如dataRequest、Confirm）。
- APCI（Application Control）：1byte，定义OperationType（读、写、Response）。
- data负载：根据DPTCoding的实际data。
示例：
- switch写入指令：
TPCI=0x00（写）,APCI=0x80（DPT 1.001）, data=0x01（开）。 - temperature读取Request：
TPCI=0x40（读）,APCI=0x00（无data）。
6. Communication服务
(1) 轮询（Polling）
- 主设备主动向从设备Requestdata（如查询Sensors状态）。
- message示例：
控制field=0xBC,目标address=Sensors物理address,APCI=读Request。
(2) Confirm（Acknowledge）
- receive方需回复Confirm帧（ACK）以确保可靠性。
- 示例：设备收到控制指令后返回
ACKmessage（0xB0）。
(3) 重试机制
- 若未收到ACK，send方在指定超时后重传message（通常最多3次）。
7. 安全机制
- 传统模式：无加密，依赖物理层安全（如总线访问控制）。
- KNX Secure：新增data加密（AES-128）和身份验证，防止篡改与窃听。
- 安全message示例：在标准帧基础上增加加密负载和MAC（消息认证码）。
8. 实际debug建议
- 抓包Tools：使用Wireshark + KNX插件 分析总线流量，过滤特定组address。
- Error排查：
- checksumError：检查message异或结果。
- address冲突：确保物理address和组address唯一。
- ETS配置：在ETS工程中绑定DPTType，避免dataParseError。
KNXProtocol中，message type主要通过控制field和TPCI（Transport Control Information）区分，不同message type适用于不同Scenarios（如控制指令、dataRequest、Response等）。以下是常见KNXmessage type的详细说明及示例：
1. 标准帧（L_Data Standard）
- 控制field：
0xBC - dataLength：≤ 15byte
- 适用Scenarios：常规控制指令（switch、百分比、状态读取等）。
示例：switch控制
BC 11 0A E1 03 01 01 80- 控制field
0xBC：标准帧，正常优先级。 - 源address
0x110A（1.1.10）。 - 目标address
0xE103（组address1/2/3）。 - data
0x01：switch状态（开）。 - checksum
0x80：异或Computation result。
2. 扩展帧（L_Data Extended）
- 控制field：
0xBF - dataLength：≤ 255byte
- 适用Scenarios：大data传输（如字符串、日志、复杂配置）。
示例：send字符串信息
BF 23 05 E2 51 0E 10 4B 4E 58 20 54 65 73 74 00 00 00 5C- 控制field
0xBF：扩展帧，低优先级。 - 源address
0x2305（2.3.5）。 - 目标address
0xE251（组address2/5/1）。 - dataLength
0x0E：14byte count据。 - data
0x10 4B 4E 58 20 54 65 73 74 00 00 00： - DPT 16.001（字符串），内容为
"KNX Test"（ASCIICoding）。 - checksum
0x5C：计算略。
3. Confirm帧（ACK/NACK）
- 控制field：
0xB0（ACK）或0xB1（NACK） - 结构：无data部分，仅控制field和checksum。
- 适用Scenarios：receive方回复Confirm或拒绝。
示例：ACKConfirm
B0 00 00 00 00 00 00 B0- 控制field
0xB0：Confirm帧（ACK）。 - checksum
0xB0：仅自身异或结果为0xB0。
4. 轮询Request（Polling Request）
- 控制field：
0xBC（标准帧） - TPCI：
0x40（读Request） - 适用Scenarios：主设备主动Request从设备data。
示例：读取Temperature Sensordata
BC 00 01 12 34 01 40 00 2D- 源address
0x0001（中控设备0.0.1）。 - 目标address
0x1234（Sensors物理address1.2.52）。 - dataLength
0x01：1byte count据。 - TPCI+APCI
0x40：读Request（无data负载）。 - checksum
0x2D：计算略。
5. Response帧（Response）
- TPCI：
0x80（写Response）或0xC0（读Response） - 适用Scenarios：设备回复Request的data或状态。
示例：Temperature Sensor返回data
BC 12 34 00 01 02 06 00 5C- 源address
0x1234（Sensorsaddress1.2.52）。 - 目标address
0x0001（中控设备0.0.1）。 - dataLength
0x02：2byte count据。 - data
0x0600：temperature值（DPT 9.001，24.0°C）。 - checksum
0x5C：计算略。
6. 广播帧（Broadcast）
- 目标address：
0x0000（全零address） - 适用Scenarios：设备向总线所有节点send全局指令（如system复位）。
示例：全局复位指令
BC 00 01 00 00 01 FF 01- 源address
0x0001（中控设备）。 - 目标address
0x0000：广播address。 - data
0xFF：复位指令（CustomizationCoding）。
7. 安全message（KNX Secure）
- 控制field：
0xBC或0xBF（结合加密标志） - 结构：在标准帧基础上增加加密负载和MAC（消息认证码）。
- 适用Scenarios：防止data篡改或窃听。
示例（简化的加密message）
BC 11 0A E1 03 10 01 80 [加密负载] [MAC] 2A- data部分：明文data
0x01被加密为更长byte。 - MAC：用于验证data完整性（如AES-128计算）。
关键对比表
| message type | 控制field | dataLength | TPCI | 典型Scenarios |
|---|---|---|---|---|
| 标准帧 | 0xBC | ≤15byte | 0x00 | switch控制、百分比调节 |
| 扩展帧 | 0xBF | ≤255byte | 0x00 | 长Text、复杂配置 |
| ACKConfirm | 0xB0 | 无 | – | receive成功Response |
| NACK拒绝 | 0xB1 | 无 | – | receive失败Response |
| 读Request | 0xBC | 1byte | 0x40 | 主动RequestSensorsdata |
| 写Response | 0xBC | 可变 | 0x80 | 设备状态更新Confirm |
| 广播帧 | 0xBC | 可变 | 0x00 | system级指令（如复位） |
Precautions
- TPCI与APCI：
- TPCI（传输控制）标记message type（读、写、Response）。
- APCI（应用控制）定义具体Operation（如DPTType）。
- address过滤：设备仅处理目标address匹配的message（物理address或订阅的组address）。
- checksum：始终为前面所有byte的异或（XOR）值。
希望这些示例能帮助你理解KNX不同message type的写法！实际开发中建议结合官方ProtocolDocument和ETSTools验证。
以下示例说明：
示例1：switch控制（标准帧）
Scenarios：物理address 1.1.10 equipment向组address 1/2/3 send开灯指令。
message：
BC 11 0A E1 03 01 01 80- 控制field
0xBC：标准帧，正常优先级。 - 源address
0x110A：Device address1.1.10。 - 目标address
0xE103：组address1/2/3（E1表示组addressType）。 - dataLength
0x01：1byte count据。 - data
0x01：switch状态（0x01=开，0x00=关）。 - checksum
0x80：BC XOR 11 XOR 0A XOR E1 XOR 03 XOR 01 XOR 01 = 80。
示例2：Temperature Sensordata（扩展帧）
Scenarios：Sensors 2.3.5 上报temperature 22.5°C 到组address 2/5/1。
message：
BF 23 05 E2 51 02 06 00 5C- 控制field
0xBF：扩展帧，低优先级。 - 源address
0x2305：Device address2.3.5。 - 目标address
0xE251：组address2/5/1。 - dataLength
0x02：2byte count据。 - data
0x0600： - DPT 9.001（temperature），Coding为
0x0600→22.5°C（浮点format）。 - checksum
0x5C：计算略。
示例3：Scenarios控制（多byte count据）
Scenarios：中控设备 0.0.1 触发Scenarios 3（组address 5/0/3）。
message：
BC 00 01 E5 03 03 03 00 00 6F- 控制field
0xBC：标准帧。 - 源address
0x0001：中控address0.0.1。 - 目标address
0xE503：组address5/0/3。 - dataLength
0x03：3byte count据。 - data
0x030000：Scenarios编号3，附加参数。 - checksum
0x6F：计算略。
关键点
- addressCoding：
- 物理address：
区域(4bit).线(4bit).设备(8bit)→ 2byte（如1.1.10→0x11 0x0A）。 - 组address：
主组(5bit)/中间组(3bit)/子组(8bit)→ 2byte（如1/2/3→0xE1 0x03，高位1110表示组address）。
- dataCoding：
- switch：1byte（
0x00=关，0x01=开）。 - temperature：2byte浮点（如 DPT 9.001）。
- 百分比：1byte（
0x00=0%，0xFF=100%）。
- checksum：对所有前面byte进行异或运算（如
BC XOR 11 XOR 0A XOR E1 XOR 03 XOR 01 XOR 01 = 80）。
实际应用建议
- 使用ETS（KNX工程Tools软件）配置设备，无需手动组包。
- message示例主要用于理解底层Protocol，debug时可借助抓包Tools（如Wireshark + KNX插件）。
- 深入学习可参考KNX官方Document《KNX Standard》或书籍《KNX for IoT》。
Leave a Reply