直接回答
Miniserver 是 Loxone 系统的本地核心控制器，在现场运行日程、顺序与联动，保存组态并连接扩展模块、Tree/Air 设备及第三方系统。容量应按控制器与建筑分区规划，而不是只看一个笼统数字。
控制器到底负责什么
Miniserver 不是带继电器的路由器，而是保存整栋建筑控制逻辑的计算机：日程、设定值、顺序、联动、告警规则与趋势采集都在这里运行。逻辑在本地执行，因此外网、云服务或上位机不可用时，建筑仍能继续运行。项目文件是现场的唯一事实来源，版本管理、备份与变更流程和硬件选型同样重要。把 Miniserver 看作本地行为的拥有者，而不是一台仪表盘服务器。这种归属也划清了与 App 和网络的边界：控制器做决定，界面只负责呈现。依赖云服务的顺序不再是本地行为，应作为例外记录。
- 在现场运行时间程序、逻辑与联动
- 广域网或云端中断时仍可运行
- 保存项目文件与设备组态
扩展，而不是硬撑
Loxone 系统靠增加控制器与扩展模块来扩展，而不是让一台设备硬撑整栋楼。扩展模块增加物理输入、输出、继电器或调光通道，通过 Loxone Link 连接；Tree 扩展提供有线现场总线，Air 提供无线路径，1-Wire 负责简单传感器。大型项目按竖井、楼层、租户或机房分区部署多台 Miniserver，再作为一个系统统一监控。这样布线更短、故障影响更小，每台控制器的点位表也小到足以测试和维护。设计还应说明哪台控制器是室外温度、时间等共享数据的主站，避免两个设备向同一个点位发布冲突值。
- 扩展模块把 I/O 放在现场设备附近
- 一栋建筑可以使用多台控制器
- 按竖井、楼层或租户分区部署
能经受移交的容量规划
容量不只是输入输出点数。一份有用的容量表应记录物理 I/O、总线设备、逻辑与可视化负载、网络地址、供电预算、箱体空间与备用端子。设计要为人住后的变化留余量：新增一道门、一块表、一次租户改造。还要记录哪台控制器拥有哪段顺序，避免后来的工程师靠猜。点位表与控制器分配在设计阶段完成，调试才是核对，而不是发现。一个简单原则是按移交时的建筑规模选型，再加一份业主能在点位表里看到的明确余量，而不是藏在控制箱里的余量。
- 统计 I/O、总线设备、逻辑与网络负载
- 为移交后的变更预留余量
- 记录每段顺序由哪台控制器负责
选型与移交
选型要按角色而不是只按型号：它控制什么、装在哪里、如何供电、如何备份、谁能修改。要求提交网络图、地址表、移交前备份与恢复测试。远程访问应是书面决策，而不是意外开放的端口。固件与软件版本要写进移交包，并附项目文件与变更记录。检验标准很简单：另一位称职的工程师能否打开项目、看懂它，并在不联系原安装商的情况下做一个小改动？这项检验也能防止项目只在原工程师的电脑上能跑，却没有一条有记录的路径回到建筑本身。
- 记录角色、位置、供电与网络
- 移交前测试备份与恢复
- 交付项目文件、版本与变更记录
Miniserver 容量规划维度
6 行| 维度 | 记录内容 | 为什么重要 |
|---|---|---|
| 物理 I/O | 每台控制器的输入、输出、继电器与模拟通道 | 避免后期加扩展和箱内过载 |
| 现场总线 | 每段的 Tree、Air 与 1-Wire 设备 | 让每段可测试且不超过供电预算 |
| 逻辑负载 | 日程、顺序、联动与告警规则 | 让性能与变更影响可见 |
| 网络 | IP 地址、VLAN 与远程访问路径 | 支持分区与可靠的远程支持 |
| 供电与箱体 | 供电预算、端子空间与导轨容量 | 避免箱内拥挤与散热问题 |
| 备用容量 | 空闲端子、地址与控制器余量 | 无需重新设计即可应对移交后的变更 |
项目图景
3 张图片
常见问题
01每栋建筑都需要多台 Miniserver 吗？
不一定。一栋紧凑建筑或边界清晰的分区可以由一台控制器承担。当线缆长度、点位数、容错或租户分隔让单台控制器变得别扭时，分布式部署才有价值。
02外网中断时会发生什么？
本地日程、顺序与联动继续在 Miniserver 上运行。远程 App 访问与云端报表会中断，直到连接恢复；这与依赖云端的系统有本质区别。
03第三方集成需要扩展模块吗？
不需要。第三方系统通过网络接口、网关或原生协议支持接入。扩展模块主要用于物理 I/O 与现场设备，而不是每一种集成。
04一台 Miniserver 能管理多个楼层吗？
可以，前提是布线、点位数与故障影响仍可接受。很多项目按楼层或竖井分配控制器，使故障只影响一个区域，调试也能逐区推进。
05备用容量应该如何写进规格？
可以按已用点位的百分比，或按空闲端子与地址的固定数量来规定，并写进点位表。关键是在控制箱成套之前就把这个数字定下来。
下一步
把建筑交给我们。
告诉我们建筑类型、纳入范围的系统，以及你需要的结果。我们会给出通往可用系统的最短路径。