KNX 是什么、用在哪里
KNX 是开放的楼宇控制标准，以双绞线总线为基础，并有 IP、无线与电力线扩展。它在欧洲很常见，广泛用于照明、遮阳、房间控制、暖通执行器与存在感应。设备逐个调试：每个设备都有应用程序、参数与组地址。总线是分布式的，按键不需要中央控制器就能触发调光。这种本地韧性，是 KNX 在原始安装商离场多年后仍能运行的原因之一。它首先是现场总线，不是 IP 系统。集成项目应尊重这一点：总线保留本地行为，平台增加监管，而不是制造依赖。协议参考：一条线路最多 64 个总线设备，一个区域最多 15 条线路，总线电源与设备自身供电分开。这些上限决定耦合器、中继器与备用容量应放在哪里。现场层健康的总线也可能文档混乱，而文档正是下一个项目继承的东西。
- 照明、调光与场景控制
- 遮阳与立面自动化
- 房间控制、暖通执行器与存在感应
- 欧洲市场与多厂商规格项目
- 集成前规划总线上限
集成路径与网关选择
常见路径有三条。KNX 接口或网关通过 IP 把总线接入平台，把组地址暴露为可读写点位；KNX IP 路由器在网络层完成同样的事，并可跨线路；控制器支持时也可以使用原生 KNX 端口。路径决定容量、延迟与诊断能力。要问清楚网关能暴露多少组地址、支持隧道还是路由、允许多少并发连接，以及总线或 IP 网络中断时如何动作。大型安装应把总线分段，有意识地布置路由器，而不是把一条线路无限延长。网关是基础设施：给它备件、固定地址与书面更换流程。单台监控用隧道方便；多个客户端同时访问总线时，路由更合适。记录哪条线路位于哪个耦合器之后；一条线路故障不应要求打开整个柜体。
- KNX 网关或 IP 接口
- 较大或分段安装用 KNX IP 路由器
- 控制器支持时使用原生 KNX 端口
- 设计前确认容量、延迟与故障切换
从组地址到平台点位
KNX 点位不只是一个地址。映射记录应包含组地址、数据点类型、单位、缩放、读写方向、所属设备与对应功能。一个单比特对象可能是状态、命令或场景触发，记录必须说明是哪一种。数据点类型决定缩放：单字节值可能是百分比，双字节值可能是以十分之一度为单位的温度。读写标志不能互换，状态地址应与命令地址分开。命名应遵循建筑标准，而不是安装商的缩写。点位表就是 KNX 程序员与平台工程师之间的合同。每种数据点类型都要抽样测试，不能假设一个可用例子就覆盖了其余。若一个组地址会被两个系统写入，项目需要仲裁规则与唯一归属。命令与状态共用同一个组地址，是振荡的常见原因。
- 组地址与数据点类型
- 读写方向与归属
- 单位、缩放与工程量程
- 命名规范与仲裁规则
点位命名与映射登记表
点位命名应在凌晨三点也能读懂。采用固定结构：建筑、楼层、房间或系统、设备、功能与信号类型。组地址保留在记录里，不一定放进可见名称；运维需要功能，工程师需要地址。映射登记表应可导出，因为它要与 ETS 项目、网关导出和平台数据库对照。每个点位都应显示数据点类型、单位、缩放、方向、告警限值与归属。计算点或组合点要记录输入。命名规范只有在被强制执行时才有用；在冻结点位表之前增加复核环节。避免把临时状态写进名称，例如将来会改名的楼层或会搬走的租户。避免只有一个安装商看得懂的缩写。登记表还应记录 ETS 设备地址，以便把总线跟踪对应到具体设备。
- 不看图纸也能读懂固定结构
- 组地址进记录，功能进名称
- 映射登记表可导出
- 冻结点位表前复核
测试与调试
先测总线，再测网关，最后测平台。总线上确认设备供电、线路耦合器、组地址通信与场景调用；网关上确认发现、地址导出、读写行为，以及网络中断后的重连；平台上确认每个映射点显示正确的值、单位与状态，命令能到达现场设备。还要测试失效路径：断开网关，检查本地 KNX 功能是否继续。测试结果记录在点位表上，而不是另一个本子里。点位出现在浏览树里不算调试完成，直到它被读取、写入并观察过。还要检查总线负载：过度轮询会让健康的安装看起来不可靠。要做网关重启与平台重启测试；恢复行为也是功能的一部分。先在平台断开时测总线，再在平台连接时测一次；两种状态都重要。
- 总线健康、耦合器与组地址通信
- 网关发现、读写与重连
- 平台每个点位的值、单位与状态
- 网关离线时的本地运行
- 重启与恢复测试
限制、移交与责任
KNX 在现场层很稳健，但有边界。总线带宽共享，大量轮询不是好设计。老项目里组地址混乱很常见，集成前必须整理。有些设备只暴露有限对象，有些厂商使用自己的扩展。KNX Secure 需要密钥管理，平台必须支持。实用原则很简单：现场控制留在现场，跨系统逻辑放在平台，边界写进文档。集成应让总线更清晰，而不是把它藏起来。移交包应包含 ETS 项目或地址导出、映射登记表、网关配置与测试记录。总线的责任留在 KNX 安装商，映射的责任在集成商。把这条分工写进合同，尤其是移交后的变更。未来的改造会增加设备；为它预留地址范围与网关容量。少量备用耦合器、电源与总线端子，可以省下一次返场。
- 能用事件通信时不要依赖轮询
- 整理并记录遗留组地址
- 设计前确认 KNX Secure 支持
- 本地控制独立于平台
- 预留地址与网关余量
KNX 集成规划
14 行| 项目 | 需要确认 | 为什么重要 |
|---|---|---|
| 总线介质 | 双绞线、IP、无线或混合 | 决定网关与拓扑 |
| 线路与区域结构 | 耦合器、电源、余量 | 避免过载，便于诊断 |
| 设备上限 | 协议参考：每线 64 个设备，每区域 15 条线路 | 决定耦合器与中继器的位置 |
| 组地址方案 | 命名、范围、归属 | 让映射与后续变更可行 |
| 数据点类型 | 类型、单位、缩放 | 避免错误的值与命令 |
| 读写标志 | 命令与状态分开 | 避免反馈回路与写入冲突 |
| 网关容量 | 地址数量、隧道或路由、客户端数 | 决定集成上限 |
| 读写权限 | 谁可以写每个地址 | 避免命令冲突 |
| 场景与日程 | 放在哪里、归谁所有 | 避免重复逻辑 |
| KNX Secure | 密钥管理与设备支持 | 影响调试与平台选择 |
| 诊断 | 总线监视、网关日志、平台事件 | 缩短故障定位时间 |
| 总线负载 | 轮询速率与事件流量 | 保持响应可预测 |
| 测试记录 | 地址、数据点类型与观察结果 | 证明每个映射点 |
| 移交 | ETS 项目、地址导出、点位表 | 让系统可维护 |
项目图景
3 张图片
常见问题
01可以接入现有 KNX 系统吗？
通常可以，前提是总线健康、组地址可读。审计应确认设备供电、耦合器、ETS 项目是否可用，以及地址是否有文档。
02需要原始 ETS 项目吗？
有会好很多。没有它，设备参数与组地址也许仍可读取，但变更风险很高。缺失 ETS 项目是集成前要解决的发现项，不应留到调试时才暴露。
03Loxone 与 KNX 可以共同控制吗？
可以。项目要定义每个组地址归哪个系统、冲突如何解决。常见分工是 KNX 负责现场设备，Loxone 负责跨系统逻辑与操作视图。
04KNX 集成一定需要网关吗？
需要的是 KNX 总线与平台之间的接口。它可以是网关、IP 路由器或原生 KNX 端口，取决于控制器与现场安装。
05可以集成多少组地址？
取决于网关与控制器，而不是平台的固定上限。设计应在冻结点位表前确认地址数量、更新速率与诊断能力。
06可以保留 KNX 场景吗？
可以。场景可以留在 KNX 设备，也可以移到平台，但不能两边都做而没有明确归属。重复的场景逻辑常导致行为不一致。
07平台离线时会发生什么？
KNX 设备应继续本地功能：按键、调光、遮阳执行器与房间控制。跨系统逻辑暂停，直到平台恢复。这个失效模式应被测试，并向运维人员说明。
08KNX 适合酒店吗？
KNX 常用于酒店客房规格，尤其在欧洲。它适合照明、遮阳与房间控制；PMS 与能耗逻辑通常在上层。
下一步
把建筑交给我们。
告诉我们建筑类型、纳入范围的系统，以及你需要的结果。我们会给出通往可用系统的最短路径。