直接回答
Loxone 门禁集成把现有门控制器和读卡器接入楼宇模型，让一次合法通行触发照明、暖通、视频与告警。本站只做门禁系统集成，不销售锁具、电锁、读卡器或闸机；凭证校验仍由门禁系统负责。
只做集成，不供硬件
边界要说清楚。门禁是专业领域，有自己的凭证、电源、失效安全与规范义务。我们不销售锁具、电锁、读卡器、闸机或道闸。我们做的是把门禁系统接入楼宇：读取门状态和事件，在门控制器允许时下发受控开门指令，并让这些事件参与照明、暖通、视频和告警逻辑。谁可以通过一扇门由门禁系统决定；门打开之后建筑怎么响应，由楼宇平台负责。每份方案都会重申这条边界，因为范围模糊的集成项目，最后往往会装上没人设计过的硬件。清晰的边界也保护业主：凭证由一份合同覆盖，楼宇逻辑由另一份合同覆盖，各自可以独立验收。
- 凭证校验留在门禁系统
- 门事件驱动照明、暖通与视频逻辑
- 不供锁具、电锁、读卡器或闸机
门、分区与路线策略
门禁规划从人怎么走开始，而不是从硬件开始。我们列出每扇受控门、使用者、正常通行方向、非工作时段路线，以及它与电梯、楼梯和租户区域的关系。再把门分成与照明、暖通一致的分区，使一次进入事件有明确的楼宇响应。主入口、服务门、车库人行门和机房门的响应不应仅仅因为接在同一控制器上就完全相同。疏散门、防火门和无障碍入口的要求由门禁专业方与消防工程师确定；楼宇平台记录这些要求的存在，但不替代它们。门表还记录哪些门只监视不控制，因为这些事件对照明和暖通同样有意义。
- 按使用者、方向与非工作时段路线编制门表
- 门组与照明、暖通分区对齐
- 疏散与防火门要求仍归专业方
一个门事件能驱动什么
门事件是一小段建筑上下文。大堂闸机的合法进入可以把楼层照明切到使用场景，启动会议室新风，并把该区域标记为有人。非工作时段的一次出门可以启动闭楼顺序。门长时间未关可以触发告警并调出摄像机画面。强行开门可以升级到安防，并联动相邻分区封闭；封闭动作本身由门禁系统执行，而不是楼宇平台。这些都不替代门禁判断，而是把判断当作触发条件，让空间变得可用且安全。默认是单向映射：平台消费事件，只有门禁厂商明确允许的指令才写回。事件映射以表格保存，而不只是画一张图，这样可以逐行测试。
- 进出事件作为使用状态信号
- 门未关与强行开门告警联动视频
- 最后一次出门触发非工作时段顺序
接口与它能做到的事
集成深度取决于门控制器。OSDP 或 Wiegand 描述的是读卡器到控制器之间的链路，不是开放的楼宇接口，本身并不会给平台一个可用的事件流。带 API、事件导出或明确网络接口的控制器更适合作为起点。控制器开放时，干接点可以传递门状态或开门指令。审计阶段要确认哪些事件可得、哪些指令允许、门禁厂商愿意书面支持什么。如果控制器只开放一个继电器，集成就只做到这个继电器，我们会直接说明，而不是承诺硬件根本无法提供的完整事件模型。如果控制器只提供事件而没有指令，集成就停留在监视与上下文层面，这对照明和暖通往往已经够用。控制器选型、读卡器类型和门体五金仍由门禁专业方负责；我们的选型标准是控制器开放的事件与指令接口。楼宇侧则是一条有记录的网络连接：固定地址、受监视的链路，以及不依赖门体五金的供电路径。
- 视控制器而定：API、事件流或干接点
- 先读状态，再谈控制
- 接口与权限在审计中确认
访客、承包商与非工作时段
访客和承包商的流程主要是管理流程，技术只提供少量信号。前台可以在门禁系统里发一张临时凭证；楼宇平台用产生的事件打开会议区照明和空调，访问结束后再释放。非工作时段可以把通行限制在指定门和区域，照明跟随路线而不是整层点亮。承包商在机房作业，需要照明、通风和空间占用记录，但不需要整栋楼的场景。审计记录应能说明谁在何时从哪扇门进入，以及建筑随后做了什么。例外情况走同一条事件路径，避免人工开门变成没有记录的惯例。临时通行应自动到期，楼宇响应也随之结束，即使访客忘记签退。
- 临时通行由楼宇顺序配合
- 非工作时段路线限定在指定分区
- 事件日志串联门禁、照明与暖通响应
告警、升级与事件复盘
门禁告警只有在送到能处理的人手上时才有用。我们为门长时间未关、强行进入、控制器离线、读卡器被拆和开门失败定义告警级别，每一级都有送达对象、响应时限和升级路径。送货时门开着，与夜间被强行打开，不是同一类事件，即使控制器都把它们报成一个触点。平台为事件打时间戳、调出最近摄像机，并把运维的确认写入审计记录。事件复盘因此可以重建全过程：谁进入、哪扇门、建筑做了什么、谁响应、用了多久。这份记录比一个只显示实时门状态的看板更有价值。已知维护窗口内允许抑制告警，但抑制有时限，并让下一班次看得见。
- 告警分级，明确送达对象与响应时限
- 摄像机与确认记录关联到事件
- 基于合并日志重建事件过程
调试、移交与运维培训
门禁集成分期调试，因为每个阶段风险不同。先验证只读监视：门状态、事件和时间戳。再做事件驱动的照明与暖通，每个分区都从应当触发它的那扇门开始测试。开门指令最后启用，且只在门禁厂商书面确认权限与失效行为之后。每个阶段都有自己的测试记录和验收。移交内容包括门表、事件映射、升级矩阵、权限登记和经过测试的楼宇逻辑备份。运维培训覆盖告警确认、访客与承包商流程，以及“楼宇响应”和“门禁判断”的区别。移交后不久用真实事件做一次复盘，往往会修正纸面上看起来合理的响应。
- 只读、事件驱动、控制三个阶段
- 开门指令须有书面许可
- 移交门表、事件映射与培训
门禁集成职责与边界
15 行| 功能 | 门禁系统职责 | 楼宇平台职责 | 边界说明 |
|---|---|---|---|
| 凭证校验 | 读卡器、控制器、权限 | 无 | 留在门禁系统 |
| 开门动作 | 电锁、磁力锁、控制器输出 | 在允许范围内下发受控指令 | 硬件与失效模式由门禁专业方负责 |
| 门状态 | 门磁或控制器事件 | 监视、告警与趋势 | 传感器接线由安装方负责 |
| 门未关告警 | 控制器事件与计时 | 告警路由与升级 | 按门约定时间阈值 |
| 强行进入 | 控制器事件 | 告警路由、视频联动 | 响应流程与安防约定 |
| 出门请求 | 按钮、传感器与控制器逻辑 | 不下指令；事件仅作分区上下文 | 疏散行为由规范与专业方确定 |
| 访客流程 | 临时凭证与记录 | 照明与暖通顺序 | 前台流程仍由人工执行 |
| 承包商与非工作时段通行 | 门组与时区 | 路线照明、通风与记录 | 通行权限由安防确定 |
| 闸机集成 | 闸机控制器与硬件 | 仅消费事件 | 本范围不供闸机 |
| 道闸集成 | 道闸控制器与安全线圈 | 事件消费与分区响应 | 本范围不供道闸 |
| 电梯厅门禁 | 电梯控制器与目的层逻辑 | 电梯厅周边照明与暖通 | 电梯控制仍归电梯供应商 |
| 视频联动 | 摄像机与视频管理 | 事件到摄像机的映射 | 录像保存由安防团队负责 |
| 告警路由 | 事件生成 | 优先级、送达与升级 | 响应责任在移交时确认 |
| 合并审计记录 | 门禁事件导出 | 与楼宇动作合并的日志 | 数据所有权归业主 |
| 消防疏散 | 火警接口与门释放 | 仅监视 | 生命安全功能仍由消防与门禁系统负责 |
项目图景
3 张图片
常见问题
01你们提供锁具或闸机吗？
不提供。我们集成由门禁专业方提供的门控制器、读卡器和门体五金；我们的范围是它们外围的楼宇逻辑。
02能接入现有门禁系统吗？
如果它开放 API、事件流或干接点，通常可以。审计会确认可用事件和控制器允许的指令。
03门事件能开灯和空调吗？
可以。合法进入可以把分区切到使用场景；出门或超时后回到待用状态。响应按门和分区配置。
04平台会保存凭证吗？
不会。凭证数据留在门禁系统，平台只接收门事件和状态，不接收持卡人记录。
05可以先只读，后续再加控制吗？
可以。监视、事件驱动顺序和开门指令可以分阶段调试，各自独立测试与验收。
06强行开门怎么处理？
门控制器产生事件，平台按约定流程路由告警、调出最近摄像机，并触发分区响应。
07消防疏散怎么处理？
消防疏散和火警时的门释放仍由消防与门禁系统按当地规范设计。平台可以监视状态，但不替代该功能。
下一步
把建筑交给我们。
告诉我们建筑类型、纳入范围的系统，以及你需要的结果。我们会给出通往可用系统的最短路径。