直接回答
Loxone Config 是配置建筑设备、输入输出与控制逻辑的工程环境。它产出运行在本地控制器上的日程、联动、告警与运维视图，并由有记录的备份、版本管理和楼宇团队可维护的移交包支撑。
工程环境
Config 是建筑在软件里被搭建起来的地方。设备寻址、输入输出映射，每个功能都取一个对运维有意义、而不是对安装工有意义的名称。环境连接本地控制器，因此修改针对真实安装进行，并能在现场测试。结构良好的项目读起来像一栋建筑：机房、楼层、管井、租户区域、室外分区。这个结构不是装饰，它决定凌晨两点出故障时，问题能被多快找到。同一环境既产出本地运行的逻辑，也产出运维使用的视图，因此组态纪律是运营问题，不是 IT 细节。项目应当让没写过它的人也能读懂。检验方法很简单：把结构树交给一位新工程师，让他找一处故障。
- 设备寻址与输入输出映射
- 按建筑命名，而不是按控制箱命名
- 连接本地控制器，针对真实设备测试
项目结构与命名
靠复制粘贴长起来的项目最终无法维护。编程前先定义层级：建筑、楼层、分区、系统、设备。机组、房间传感器和租户区域都挂在这棵树上，每个对象都带一个与图纸和点表一致的位号。这棵树同时对应控制箱、管井与房间的物理拓扑，软件里的地址能在建筑里找到。重复的房间类型用模板，客房或标准办公配置一次后实例化，只改地址和房间名。命名遵循一套规则：位置、服务、设备，必要时加后缀。避免“备用”或“测试2”这类名字留到移交。结构要与楼宇团队一起复核，因为在压力下检索它的人正是他们。调试后再改名代价很高，因为每张图纸、标签和报表都指向旧名字。
- 从建筑到设备的层级结构
- 重复房间类型使用模板
- 图纸、点位与软件共用一套命名规则
逻辑、顺序与告警
大部分工程工作其实是逻辑。日程决定一个区域何时应当有人；联动决定泵启动或风阀动作前必须先发生什么；顺序让冷热源与末端按正确次序投入；告警逻辑决定什么紧急、什么提示、什么在已知事件期间应当抑制。逻辑按模块组织，一个楼层或一个系统可以复制、测试和维护，而不必拆开整个项目。重复顺序用共享功能块，通过参数区分，而不是复制逻辑。每个不直观的决定都写进控制说明，包括延时、死区或联锁的理由。逻辑索引把每个功能块对应到顺序和说明书的页码。一段讲不清楚的逻辑，通常是意外长出来的逻辑。
- 按楼层、系统与设备做模块化逻辑
- 共享功能块用参数区分，避免复制逻辑
- 告警分级与有记录的抑制
应用与运维视图
应用不是消费级遥控器，而是运维界面：面向后勤、工程师和管理层的角色视图，各自看到需要的告警、趋势和指令。技术员能看到设备、趋势与联动关系；管理者能看到能源与舒适度汇总，但没有阀门指令权限。图形围绕运维的判断设计，而不是照设备表排布。告警页是默认视图，因为注意力首先要到这里。同一套模型可以服务大堂的墙面面板、后勤办公室的工作站和楼层的移动设备。只存在于工程师笔记本电脑上的视图，不算移交成果。默认视图应先回答“现在需要关注什么”，再回答“有什么设备”。
- 角色视图与指令权限
- 告警优先的默认视图
- 工作站、墙面面板与移动端共用模型
远程访问与安全
远程访问是便利，也是一条安全边界。连接应当显式、经过认证并留痕，建筑网络之外的用户需要双因素认证。控制网络与租户、访客网络分开；入站路径通过代理，而不是直接暴露。本地优先意味着建筑运行不依赖这条远程通道。承包商离场时可以撤销访问，审计记录应说明谁在何时连接、改了什么。账户按人分配，不共用；服务账户要记录责任人。这些既是网络决定，也是组态决定，应在系统上线前与 IT 一起复核，而不是等第一次事件之后。一直开着的远程连接，就像一扇没锁的门；应当为具体任务打开，用完关闭。
- 远程用户启用双因素认证
- 控制网络分段，访问经代理
- 账户按人分配，可撤销并留审计
备份、版本与变更控制
已组态的建筑既是知识产权，也是运行基础设施。项目文件、控制器备份、点表、网络图和控制说明都属于移交包。备份按既定周期运行，并通过恢复到备用控制器来验证，而不是只看文件是否存在。版本记录写明变更内容、日期和责任人，出现回退时能追到某个版本。移交后的变更走一条简单的变更路径：申请、影响评估、批准、实施、记录。正是这套纪律，让一栋正常运行的建筑在原始工程师离开后仍然正常，也是“受维护的系统”和“一堆没有记录的修改”之间的区别。从未恢复过的备份只是希望，不是备份。版本名称要对楼宇团队有意义，而不只是对开发者有意义。
- 项目文件、控制器备份与点表
- 在备用控制器上做恢复测试
- 版本记录与变更申请留痕
调试支持、文档与运维培训
组态是在调试中被证明的，而不是编译通过就算数。我们支持逐点测试、顺序测试和故障模拟，并记录实际设置的参数值：设定值上下限、延时、死区和告警阈值。竣工文档包括项目文件、逻辑索引、点表、告警清单、图形索引和网络图。培训按角色安排：运维学习告警、日程和允许的超驰；技术员学习趋势、备份和一线诊断；管理者学习报表与能源视图。能力要记录，而不是假定。目标是让楼宇团队能安全地做日常变更，并知道什么时候该求助。培训以实操收尾：改一条日程、确认一条告警、在备用控制器上恢复一次备份。当楼宇团队能在工程师不在场时重复这些操作，移交才算完成。
- 记录调试后的实际参数值
- 竣工文件集与逻辑索引
- 按角色培训并记录能力
组态工作范围与交付物
15 行| 工作范围 | 配置内容 | 交付物 | 移交后归属 |
|---|---|---|---|
| 项目层级 | 建筑、楼层、分区、系统与设备树 | 项目结构图 | 楼宇团队 |
| 命名与位号 | 位置、服务、设备与点位后缀 | 命名规则与位号登记 | 楼宇团队 |
| 模板 | 标准房间、楼层与设备组 | 模板库与实例化说明 | 楼宇团队 |
| 设备寻址 | 控制器、扩展模块、Tree 与 Air 设备 | 地址与设备清单 | 楼宇团队 |
| 输入输出映射 | 输入、输出、传感器与执行器 | 带名称与量程的点表 | 楼宇团队 |
| 日程 | 使用、降载、清洁与季节时段 | 按分区的日程矩阵 | 楼宇团队 |
| 控制逻辑 | 联动、顺序、PID 回路与切换 | 控制说明与逻辑索引 | 楼宇团队 |
| 告警 | 优先级、路由、抑制与升级 | 告警清单与升级矩阵 | 楼宇团队 |
| 趋势与日志 | 点位、间隔、保存与导出 | 趋势计划与导出流程 | 楼宇团队 |
| 运维视图 | 仪表盘、平面图、趋势与指令 | 图形包与角色矩阵 | 楼宇团队 |
| 用户角色 | 账户、权限与指令范围 | 角色登记与权限矩阵 | 楼宇团队 |
| 远程访问 | 账户、双因素、连接策略 | 访问登记与策略 | 楼宇团队与 IT |
| 备份与恢复 | 周期、保留与恢复测试 | 备份记录与恢复流程 | 楼宇团队 |
| 版本控制 | 版本名称、日期与变更历史 | 版本登记与变更日志 | 楼宇团队 |
| 文档与培训 | 竣工图、说明文件与培训材料 | 移交包与培训记录 | 楼宇团队 |
项目图景
3 张图片
常见问题
01Loxone Config 是一种编程语言吗？
它是一个由功能块和配置对象构成的图形化工程环境。复杂逻辑可以被结构化、命名和记录，不需要编写通用代码。
02我们可以自己修改系统吗？
楼宇团队可以接受培训，在既定权限内修改日程、设定值和用户账户。结构性逻辑变更应走变更控制，必要时由集成方支持。
03应用需要云端账户吗？
本地运行不依赖云端账户。远程访问可以通过带双因素认证的代理连接提供。
04备份如何处理？
项目文件和控制器配置按既定周期备份，并在移交前用备用控制器做恢复测试。
05不同用户能看到不同内容吗？
可以。按运维、工程师、管理层，以及必要时的租户或住户配置角色视图和指令权限。
06移交哪些文档？
点表、控制说明、告警清单、网络图、图形索引、备份记录和培训记录。
07移交后变更如何跟踪？
通过变更控制路径：申请、影响评估、批准、实施，并在审计记录中留档。
下一步
把建筑交给我们。
告诉我们建筑类型、纳入范围的系统，以及你需要的结果。我们会给出通往可用系统的最短路径。