迅饶 KNX 网关点位配置——读写点位轮询策略设置

迅饶 KNX 网关对接第三方系统时，读点位采用 wo（被动监听 KNX 变化），只写点采用 wo nopolling（禁止轮询），防止频繁轮询导致 ETS 故障和总线数据过多。

背景

迅饶 KNX 网关在对接第三方系统（如 BA 楼宇自控、能源管理平台等）时，需要通过点位配置将 KNX 总线上的数据映射到第三方协议。

错误的轮询策略会导致：

ETS 故障——频繁轮询占用总线，干扰 ETS 调试下载
总线数据过多——不必要的轮询报文挤占带宽，影响正常通信
网关负载过高——轮询周期过短导致网关 CPU 满载

点位配置策略

读点位（Read Point）

配置	值	说明
模式	`wo`（Write Only）	不主动轮询，被动等待 KNX 总线上的变化报文
更新机制	根据 KNX 变化更新读	当 KNX 设备主动发送组地址报文时，网关捕获并更新数值

原理：KNX 总线本身是事件驱动的——设备状态变化时会主动发送报文。因此读点位不需要网关轮询，只需监听总线即可获取最新值。这样既保证了数据实时性，又不增加总线负载。

只写点（Write Only Point）

配置	值	说明
模式	`wo nopolling`	仅写入，完全禁止轮询

适用场景：第三方系统需要下发指令到 KNX 总线（如开灯、关灯、调光），不需要回读状态时使用。

配置示例

点位类型     | 组地址  | 数据类型 | 读写模式
读点位       | 1/1/1   | 1-bit   | wo（被动监听）
读点位       | 1/1/10  | 1-byte  | wo（被动监听）
只写点       | 1/1/2   | 1-bit   | wo nopolling
只写点       | 1/1/11  | 1-byte  | wo nopolling

为什么不能用主动轮询？

问题	说明
ETS 下载故障	轮询报文与 ETS 下载报文争抢总线，导致下载超时失败
总线负载过高	KNX 总线速率仅 9600 bit/s，大量轮询报文会挤占有效通信带宽
设备响应延迟	轮询周期越短，对 KNX 设备的 CPU 占用越高，影响正常控制响应
网关死机	点位数量多 + 轮询周期短 → 网关处理不过来

总结

读点位 → wo（被动监听 KNX 变化），不主动轮询
只写点 → wo nopolling，完全禁止轮询
核心理念：KNX 是事件驱动总线，利用其主动上报特性，避免不必要的轮询

来源：湖北德龙自动化科技有限公司