共享台球室门禁控制：怎么将单路触摸出门开关集成到自己的项目中_解决方案

CATALOG

一、背景与需求分析

共享台球室作为一种典型的无人值守业态，痛点在于：如何让用户既能无障碍进入包间，又能确保只有已下单的合法用户才能开门？

在实际运营场景中，用户通过小程序下单后获得开门权限，到达现场开门入场。但这里存在一个问题：用户离开现场时后，下一位用户可能还在路上，此时包间处于“空闲但未锁”的尴尬状态。更麻烦的是，包间内部的出门开关——这个看似简单的设备，在无人值守场景下却成了安全隐患：任何人按一下开关就能开门离开，但如果是尾随者呢？如果不法分子从内部开门后放人进入呢？

因此，一套完整的门禁控制系统，不仅要管“进门”，还要管“出门”。本文将重点解决：如何将传统的单路触摸出门开关，通过芯步开放平台，集成到共享台球室的自有系统中，实现出门权限的可控管理。

二、痛点：为什么不能直接串联机械开关？

在传统的办公室或家庭门禁中，出门开关通常是一个常开型（NO）自复位开关，直接与磁力锁串联。按下开关即切断锁电源（或触发门禁控制器的开门信号），门打开。

但在共享台球室场景下，这种做法存在三个致命缺陷：

痛点	描述
无法记录离开现场时时间	系统不知道用户何时离开，无法精准计费（超时部分无法判定）
无法防止“一码多人”	下单用户走后，开关仍可被后续进入者使用，等于“尾随入场”
安全责任无法追溯	如果有人从内部非法开门（如破坏门禁），系统没有任何留痕

因此，出门开关不能直接物理连接锁具，而必须经过系统控制器的“鉴权”。

三、解决方案架构

3.1 整体架构图（逻辑描述）

本方案的核心思路是：出门开关不再直接控制门锁，而是作为一个输入信号上报给芯步平台，由平台结合当前的订单状态，决定是否执行开锁动作。

信号流向：

用户触摸出门开关 → 开关信号被芯步智能控制器捕获 → 控制器通过HTTP/HTTPS上报事件到您的业务服务器 → 业务服务器校验当前订单状态（是否有人、是否超时等） → 下发“开锁”指令 → 门锁打开

3.2 所需硬件清单

设备	型号	作用
芯步WiFi控制器	支持IO输入输出的通用控制器	核心控制单元，采集触摸开关信号，控制磁力锁
单路触摸出门开关	常开型（NO），干接点输出	用户按下时闭合电路，给控制器一个低电平触发信号
磁力锁（电磁锁）	280kg拉力	锁住门体，断电开锁型
12V/24V电源适配器	根据磁力锁规格选择	供电
芯步开放平台账号	免费注册	设备管理、API Key生成
共享台球室业务系统	自研或第三方SaaS	订单管理、用户鉴权逻辑

四、集成步骤详解

4.1 硬件接线（专业级指导）

电路说明：

触摸出门开关的两个接线柱分别连接到控制器的DI（数字输入）端和GND（公共地）端。
控制器的DO（数字输出）端连接到一个中间继电器线圈，继电器的常开触点串联在磁力锁的电源回路中。
为什么要加中间继电器？因为控制器IO口的驱动电流通常只有几十毫安，无法直接驱动磁力锁（需要几百毫安到几安培）。

接线要点：

触摸开关应设置为“点动模式”（按下时导通，松开即断开），而不是“锁存模式”。
可在DI输入端并联一个10KΩ的上拉电阻，防止信号漂移（部分控制器内置此功能，请查阅数据手册）。

4.2 设备配网与注册

给控制器接通电源，设备进入AP配网模式。
使用手机连接控制器的WiFi热点，将门店的2.4G WiFi SSID和密码发送给设备。
设备获得IP地址后，自动注册到芯步平台，获得唯一的设备ID（例如：820720）。
记录下这个设备ID，后续调用接口时需要用到。

4.3 芯步平台配置

登录芯步开放平台控制台。
在“设备管理”中找到您刚才注册的控制器设备。
配置消息推送URL：将您的业务服务器的接收地址填入（例如：https://yourdomain.com/api/yoyo/callback）。这个URL用于接收设备上报的触摸事件。
获取AppId和AppSecret：这两个凭证用于生成API调用签名，请妥善保管。
设置签名方式：平台支持自定义签名算法，通常为MD5(AppId + ts + AppSecret)的拼接形式。

4.4 业务服务器对接（核心代码逻辑）

集成分为两个关键环节：接收设备上报事件 和 下发开门指令。

4.4.1 接收触摸开关上报

当用户触摸开关时，控制器会将DI口的状态变化推送到您配置的URL。您需要实现的接口逻辑如下（伪代码描述）：

# 接收设备上报的触摸事件
@app.route('/api/yoyo/callback', methods=['POST'])
def handle_touch_event():
    data = request.json
    device_id = data['device']          # 例如:820720
    di_status = data['di_status']       # 1表示被按下，0表示松开
    
    if di_status == 1:  # 有人按了出门开关
        # 1. 查询当前包间是否有进行中的订单
        room_id = get_room_by_device(device_id)
        active_order = db.query(
            "SELECT * FROM orders WHERE room_id=%s 
             AND status='active' AND end_time > NOW()", 
            room_id
        )
        
        # 2. 鉴权:只有有有效订单时才允许开门
        if active_order:
            # 记录离开现场时时间（用于计费）
            db.execute(
                "UPDATE orders SET actual_end=NOW() WHERE id=%s",
                active_order.id
            )
            # 调用平台接口下发开门指令
            call_yoyo_open_door(device_id, duration=5)  # 开锁5秒
            return {"code": 0, "msg": "door opened"}
        else:
            # 非法按门（如已超时未续费），可以选择报警或记录日志
            send_alert_to_admin(room_id, "非法出门请求")
            return {"code": -1, "msg": "no active order"}
    
    return {"code": 0, "msg": "ok"}

4.4.2 调用芯步HTTP接口开门

在需要开门时（无论是用户从内部按触摸开关，还是管理员远程开门），都需要调用芯步平台的设备控制接口。

说明do_output和pulse_mode字段具体名称请参阅芯步对应控制器的接口文档，不同型号可能略有差异。

4.5 用户小程序/APP端集成

为了让用户有更好的体验，在用户离开现场时环节增加主动退出的入口：

用户在小程序端点击“结束订单”时，系统调用上述call_yoyo_open_door()接口主动开门，并结束计费。
触摸开关则作为“备用方案”，防止用户手机没电或小程序卡死。

五、方案优势与效果

维度	传统方案	本方案
计费准确性	无法知道用户何时离开	触摸开门时精确记录离开现场时时间，超时自动加收
安全防护	任何人按开关都能出门/进入	只有有效订单用户按开关才触发开门，非法按门可报警
可追溯性	无记录	每次出门请求都有时间戳和设备ID，可追溯
拓展性	无法远程控门	支持管理员远程开门（如处理紧急情况）

六、常见问题和需要注意的点

Q1：触摸开关按下后，云平台响应慢怎么办？

云控制模式下，整个流程为：触摸信号上报→业务服务器鉴权→平台下发开门指令。网络延迟通常在100-200ms。如果认为偏慢，可以启用芯步支持的局域网直连模式：让业务服务器部署在门店本地，直接通过HTTP调用控制器（跳过云平台中转），延迟可降至10ms以内。

Q2：如果我断网了，还能开门离开现场时吗？

这是一个必须考虑的容灾场景。配置策略：

方案A：在本地控制器中预设“紧急开门”规则，例如连续快速触摸3次开关，控制器直接开门（作为断网逃生方案）。
方案B：采用4G版本的控制器，网络切换至移动网络。

Q3：触摸开关的线最多可以拉多长？

由于是弱电干接点信号，一般不超过20米；如果距离更远，需使用屏蔽线或加装信号中继器。

Q4：如何防止用户在门外通过某种方式触发触摸开关？

触摸出门开关应安装在包间内侧墙面，离开门锁至少半米距离。这是物理安装规范的问题，非技术能解决：确保从门外无法触及即可。

Q5：本方案是否可以拓展到其他共享场景？

完全可以。棋牌室、自习室、共享茶室等场景的逻辑完全一致。只需将“台球室”替换为相应空间，代码无需改动。

七、总结

将“单路触摸出门开关”集成到芯步平台，本质上是将物理世界的开关量转化为云端可编程的事件。这不仅解决了共享台球室“出门权限不可控”的痛点，还实现了计费的精确化和安全事件的全程留痕。

实施本方案的成本增量极低（仅需一个支持IO接口的智能控制器），但运营安全性和计费公平性的提升是显著的。对于正在或计划布局无人值守台球室的运营方而言，这是一项值得投入的基础设施建设。