直接回答
App 通过本地网络连接 Miniserver，也可经云服务或站点 VPN 远程访问。本地日程与逻辑在断网时继续运行。远程访问应是经过设计、基于角色并可审计的路径，而不是开放端口；云服务应是选项，而不是依赖。
设计上就是本地优先
正常路径很简单：App 在本地网络找到 Miniserver，验证用户，然后读写点位。日程、顺序与联动都在控制器上运行，不在 App 里。因此外网中断不会让建筑停摆，只会失去远程查看与控制。这种本地优先模式还降低了房间控制的延迟，并减少离开现场的数据。设计问题不是云有没有用，而是云不可用时哪些功能必须继续可用。写下哪些功能属于关键功能，因为这份清单决定哪里需要本地控制、独立告警与后备电源，也决定哪些功能可以安全等待。
- 房间控制在本地网络内可用
- 日程与联动在控制器上运行
- 远程访问是附加路径，不是基础
远程访问，但不暴露建筑
远程访问可以经厂商云服务、站点到站点 VPN 或受管理的远程接入设备实现，每种方式的信任边界不同。云中继方便，但依赖服务商与广域网；VPN 给业主更多控制，但需要网络能力；受管理设备可以合并访问控制、日志与支持。无论选哪种，都不要把控制器直接端口映射到公网。使用最小权限、独立账号、网络边缘的多因素认证，并记录谁改了什么。把所选路径画进网络图，包括谁持有凭据，以及承包商或员工离开时如何撤销访问。
- 有意识地选择云、VPN 或受管理接入
- 不要把控制器直接暴露在公网
- 记录修改设定值的远程会话
角色、视图与通知
不是每个用户都需要同一块屏幕。运维需要告警、趋势与清晰的建筑总览；技术人员需要点位、参数与诊断；住户或租户只需要房间场景与少量控制。基于角色的视图能减少误操作，也让培训更简单。通知遵循同样的逻辑：关键告警发给对应角色，抑制重复骚扰，确认状态可见。好的 App 不是工程工具的缩小版，而是运营模型的角色化视图。移交前让真实用户试用视图；在办公室看着整齐的页面，到了机房的手机上可能根本看不清，而那里才是它被使用的地方。
- 区分运维、技术人员与租户视图
- 按职责而不是设备清单分发告警
- 让确认与升级状态可见
安全与韧性清单
把自控网络与办公网络分成不同区域。记录开放了哪些端口与服务，保持固件更新，关闭不用的服务，修改默认凭据。远程作业前先备份项目，并记录每一次修改设定值的远程会话。要计划广域网故障、云服务商中断与人员离职时怎么办。远程访问是一种运营能力，需要负责人、复核周期与离场流程，而不只是手机里装一个 App。把远程账号与消防、门禁名单一起复核，避免建筑的“数字钥匙”比持有者留得更久。
- 对自控网络进行分区
- 保持固件与凭据更新
- 为远程账号定义离场流程
项目图景
3 张图片
常见问题
01没有外网时 App 能用吗？
在本地网络内可以。远程访问需要网络路径；无论远程是否可用，建筑本地控制都会继续，因为逻辑运行在 Miniserver 上。
02必须连接云端吗？
不是。云端访问是便利功能与监控选项。本地控制与项目文件留在现场，这才是本地优先模式的基础。
03租户可以有独立访问权限吗？
可以，用基于角色的账号限制在其房间或楼层。租户账号应与楼宇运维账号分开，并在租约变化时复核权限。
04广域网中断时会发生什么？
本地自动化继续运行。远程命令、云端报表与异地告警在连接恢复前不可用，因此关键告警需要本地或独立通道。
05远程访问应如何加固？
使用 VPN 或受管理中继、最小权限账号、边缘多因素认证、固件更新与会话日志。避免把控制器直接暴露在公网。
下一步
把建筑交给我们。
告诉我们建筑类型、纳入范围的系统，以及你需要的结果。我们会给出通往可用系统的最短路径。