两种架构，一句话说清
KNX 把智能分散到设备。存在传感器、调光执行器、遮阳执行器与按键各自拥有总线连接和应用程序，通过双绞线总线交换组地址，任何调试过的设备都能在没有中央控制器的情况下响应报文。Loxone 把逻辑集中在控制器：Miniserver 读取输入、运行程序、驱动输出，设备可以通过 Tree、Air、KNX、Modbus 或 IP 接入。后面的多数实际取舍，都源于这个差别。它也解释了两者失效方式的不同：监控层丢失时，KNX 仍能逐设备运行；Loxone 则依赖控制器及其备份。两种模型都不是信仰，各自对设计、测试与文档提出不同纪律。真正的问题是：在建筑的整个生命周期里，逻辑应该放在哪里。
- KNX：设备分布式，靠组地址报文通信
- Loxone：逻辑集中，本地控制器，多协议设备
- 两者可以在同一项目中并存
布线、拓扑与设备上限
KNX 安装是一条总线：设备以手拉手或星形接在同一对线上，线路与区域之间用电源和耦合器分隔。协议参考：一条线路最多 64 个总线设备，一个区域最多 15 条线路，因此拓扑与余量需要规划，不能临场发挥。它可预测，适合设备表清晰的新建项目。Loxone Tree 用一根线同时供电与通信，减少回拉线缆，但设备选择被限定在 Tree 生态内；Air 适合改造和难以布线的位置。实际项目中常见混合设计：KNX 做照明与遮阳，Tree 或 Air 做房间控制，控制器负责跨系统逻辑。拓扑应在拉第一根线之前画好。总线长度、电源余量、耦合器位置与备用设备，比线缆上的标签更重要。
- KNX 总线：线路、区域与耦合器规划
- Tree：一根线同时供电与通信
- Air：改造项目与难布线位置
- 混合：按设备选协议，不按立场选
编程、变更控制与版本管理
KNX 工程在 ETS 中完成。每个设备都有应用程序、参数与组地址；修改意味着重新下载设备。模型明确、可迁移，但依赖 ETS 项目与组地址规范。Loxone 工程在 Loxone Config 中完成，逻辑以功能块和连接构建在控制器上，跨系统顺序更易读、易改，但逻辑绑定在该控制器配置里。两种模型没有绝对优劣，失效方式不同。没有 ETS 文件的 KNX 项目很难安全变更；没有版本化 Config 备份的 Loxone 项目同样脆弱。两者都需要竣工记录、变更日志，以及一位有权批准下载的负责人。实用的检验很简单：一位有能力的第三方能否看懂变更、完成变更并回滚？
- KNX：ETS 项目、设备参数、组地址
- Loxone：Config 项目、功能块、连接
- 两者都要版本化备份
- 下载需指定批准人
网关与接口选择
网关决定了对方能看到多少。KNX IP 接口把组地址暴露给控制器；KNX IP 路由器连接线路与区域，可以同时支持路由与隧道。选择影响容量、延迟、诊断与并发连接数。要问清楚接口能导出多少组地址、支持路由还是隧道、网络中断后如何动作、是否需要 KNX Secure。移交时就已饱和的网关，没有余量应对下一次改造。其他协议桥接同理：按点位而不是设备计数，并为总会到来的变更留余量。网关应被当作基础设施：有失效模式、有备件、有书面更换流程。IP 地址、子网、端口与凭据要记录并纳入变更控制。
- KNX IP 接口与 IP 路由器
- 隧道与路由及并发客户端
- 容量、延迟与 KNX Secure
- 备件、固定地址与更换流程
调试、测试与失效模式
先测总线，再测网关，最后测平台。总线上确认设备供电、线路耦合器、组地址通信与场景调用；网关上确认发现、地址导出、读写行为，以及网络中断后的重连；平台上确认每个映射点显示正确的值、单位与状态，命令能到达现场设备。还要测试失效路径：断开网关，检查本地 KNX 功能是否继续。测试结果记录在点位表上，而不是另一个本子里。点位出现在浏览树里不算调试完成，直到它在现场设备上被读取、写入并观察过。顺序测试应覆盖只在夜间发生的情况：灯具故障、窗帘卡住、场景执行中控制器重启。
- 总线健康、耦合器与组地址通信
- 网关发现、读写与重连
- 平台每个点位的值、单位与状态
- 网关离线时的本地运行
- 对照点位表的签字测试记录
生态、生命周期成本与锁定
KNX 的设备市场很宽：厂商多、形态多、存量项目多，尤其在欧洲。竞争让设备价格更透明，但工程与调试时间也是真实成本。Loxone 的设备目录更窄，软件体验更整合；控制器及其编程成为项目中心。两种情况下，首轮报价更低不等于全生命周期更便宜。要把工程小时、备件、培训与后续变更算进去，而不只是硬件。还要计算边界的成本：两个系统意味着两套技能、两套文档，以及一份必须持续维护的映射。混合设计常常是正确答案，但它不是免费的。锁定不只是许可问题，也是技能问题；诚实的比较要把五年后仍能改一个组地址或一个 Config 功能块的人算进去。
- KNX：多厂商设备，需要 ETS 技能
- Loxone：整合栈，以控制器为中心
- 生命周期成本包含工程与变更
- 两个系统意味着两套技能和一份映射
你的建筑更适合哪一种
当规格要求厂商中立的总线、顾问或业主已有 KNX 能力，或必须跨多厂商选设备时，选 KNX。当建筑需要在暖通、照明、遮阳、能耗与门禁之上有一层统一逻辑，且本地控制与清晰的操作界面比设备独立性更重要时，选 Loxone。很多项目两者都用：KNX 在现场层，Loxone 在集成层。这是设计决策，不是妥协。决策应连同理由一起记录，因为下一个人会问边界为什么在这里。一条简单规则有帮助：控制放在设备所在处，协调放在建筑所在处。如果项目没有维护团队，优先选择活动部件更少、文档更清楚的架构。
- KNX 优先：多厂商现场设备，自有 ETS 能力
- Loxone 优先：统一逻辑与单一操作视图
- 混合：KNX 现场总线，Loxone 监控层
- 记录边界及其理由
Loxone 与 KNX 对比
15 行| 对比项 | Loxone | KNX |
|---|---|---|
| 架构 | 以控制器为中心，逻辑在 Miniserver | 分布式，逻辑在总线设备 |
| 现场布线 | Tree、Air、KNX、Modbus 与 IP | 双绞线总线，线路与区域耦合器 |
| 拓扑上限 | 控制器容量与 Tree/Air 网段限制 | 每条线路最多 64 个设备，每个区域 15 条线路 |
| 编程 | Loxone Config 功能块 | ETS 设备参数与组地址 |
| 设备选择 | Loxone 生态加开放协议 | 多厂商 KNX 产品目录 |
| 照明与遮阳 | 原生设备，或经 KNX、DALI 集成 | 原生 KNX 执行器与传感器 |
| 暖通 | 经 I/O、Modbus、BACnet 或 KNX | 经 KNX 执行器与网关 |
| 跨系统逻辑 | 较强，集中在控制器程序 | 可以实现，但分散在设备与网关 |
| 改造 | Air 与 Tree 减少新增布线 | 每个设备仍需总线布线 |
| 网关与接口 | 原生 KNX 接口或 IP 网关 | IP 接口或路由器，隧道或路由 |
| 诊断 | 平台日志与控制器诊断 | 总线监视、网关日志与 ETS 诊断 |
| 失效行为 | 控制器故障停止中央逻辑，本地设备行为不一 | 总线设备可保留本地功能 |
| 变更管理 | Config 版本与控制器备份 | ETS 项目与组地址规范 |
| 技能 | Loxone Config 培训 | ETS 经验与组地址规范 |
| 适用场景 | 统一建筑逻辑与单一操作视图 | 多厂商设备规格 |
项目图景
3 张图片
常见问题
01Loxone 能控制 KNX 设备吗？
可以，通过 KNX 接口或网关。KNX 设备保留自己的应用程序，Loxone 读写组地址。项目应确认暴露了哪些数据点类型与组地址。
02KNX 比 Loxone 更开放吗？
KNX 是开放标准，设备来自多家厂商；Loxone 是专有平台，但提供 KNX、Modbus、BACnet 与基于 IP 的 API 等开放接口。开放性取决于你以后需要改什么，而不只是协议名称。
03哪一种更便宜？
没有统一答案。KNX 的设备价格可能更有竞争，但需要 ETS 工程；Loxone 可能减少布线与集成工作量，但项目会围绕其控制器展开。应比较全生命周期：设计、硬件、编程、调试、备件与后续变更。
04同一栋建筑可以混用 Loxone 和 KNX 吗？
可以。常见做法是 KNX 负责现场层照明与遮阳，Loxone 运行跨系统逻辑、暖通与能耗。边界要写清楚：每个组地址、场景与日程归谁负责。
05Loxone 会取代 KNX 系统吗？
不会从物理上取代。现有 KNX 设备通常可以保留并接入。只有当设备过时、停产或无法提供所需功能时，替换才有意义。
06酒店项目选哪一种？
两者都能做。KNX 在欧洲酒店规格中很常见，设备选择面宽；Loxone 在客房控制、PMS 事件、能耗与楼宇监管需要统一逻辑时更有优势。应由房型与运营模式决定。
07修改 KNX 系统需要 ETS 吗？
设备级修改需要。参数与组地址都在 ETS 项目里。监控层可以修改场景与日程，但不能改设备应用程序。
08控制器故障时会发生什么？
不依赖控制器的 KNX 功能可以继续在总线上运行。Loxone 控制器应预留容量、配置备份，并写入有文档的恢复流程。失效模式属于设计内容。
下一步
把建筑交给我们。
告诉我们建筑类型、纳入范围的系统，以及你需要的结果。我们会给出通往可用系统的最短路径。