在共享棋牌室的无人值守场景中，门禁与照明的联动逻辑直接影响用户体验和经营成本。核心挑战在于：用户预订后需要顺畅进入包间，而离开后门店需要自动复位待客。芯步的开放接口采用标准HTTP协议，设备支持公网/局域网直连，无需中间网关即可实现自定义联动控制。以下是具体设计方案。

一、 核心设计

为了实现自定义逻辑，传统的“设备直控”无法满足复杂条件判断（如：既要是订单有效，又得是无人状态）。因此，推荐采用 “云/服务器中心化” 的架构，利用芯步的HTTP接口与消息推送机制，在您的业务后端（SaaS服务端）编写自定义逻辑代码。

架构流程图解：

1. 感知层： 部署芯步的智能包间控制器（控制电路）和传感器（人体存在雷达）。

2. 传输层： 设备通过WiFi 2.4G直连网络，通过HTTP API接收指令，通过消息推送上报状态变更。

3. 逻辑层（您的自有服务器）：

   • 接收数据： 监听传感器上报的“有人/无人”状态。

   • 逻辑判断： 结合订单系统的数据库状态（是否已支付/是否在时段内）进行业务逻辑判断。

   • 下发指令： 调用芯步的设备控制接口，执行开/关灯、开/关锁等操作。

二、 关键设备与接口能力

在编写联动逻辑前，需明确所用设备的具体接口参数。

三、 自定义联动逻辑实战案例

假设您的共享棋牌室有如下业务规则：

• 规则 A (用户入场)： 用户在小程序点击“开始订单” -> 包间灯亮起 -> 门禁断电（解锁） -> 播报“欢迎光临”。

• 规则 B (无人节能)： 用户离开未点结束，系统监测到“无人状态”持续 5分钟 -> 自动关闭空调/灯光，挂起订单。

• 规则 C (超时清场)： 订单结束后，若传感器检测到“有人” -> 强制循环播报提醒，拒绝开门。

1. 自定义逻辑实现：入场联动 (Start Order)

触发点： 用户小程序点击“开房” -> 您的后端生成订单。您的后端操作： 调用芯步HTTP接口，按顺序执行。

• 第一步：开启照明

  POST /{AppId}/device/control/?sign={sign}&ts={ts} { "device": "123456", // 包间控制器ID "order": {"power1": "1"} // 照明线路1闭合 }

• 第二步：解锁门禁注意：电磁锁通常需要断电开锁，使用 reset 命令实现“点动”（先断后通2秒，模拟开门动作）。

  { "device": "123456", "order": {"reset": {"relay": [7], "interval": 2000}} // 对应门禁线路断电2秒后恢复供电 }

• 第三步：TTS语音播报

  { "device": "789012", // 语音音柱ID "order": {"play:gbk:16": "欢迎光临，请尽情享受您的对战时光，如需帮助请呼叫客服。"} }

2. 自定义逻辑实现：无人值守自动节能 (Auto Power Saving)

触发点： 芯步人体传感器实时上报状态。逻辑流程： 传感器检测到“无人” -> 回调您的服务器 -> 服务器延时5分钟检查 -> 下发关灯指令。

• 第一步：接收传感器数据芯步设备在检测到状态变化时，会主动推送数据到您预设的URL。示例接收到的数据：

  { "device": "888888", // 传感器ID "msgid": "xxxx", "data": { "radar_enable": 1, // 雷达模块启用 "radar": 0 // 0=无人，1=有人 } }

• 第二步：后端延时逻辑处理 (伪代码示例)

  # 假设使用 Python (Flask) 接收回调 if radar_status == 0: # 无人状态 # 延迟300秒执行 time.sleep(300) # 再次查询传感器当前状态，确认仍是无人 current_status = query_device_status(device_id) if current_status == 0: # 调用API关闭照明和空调线路 (power1 照明, power4 空调) call_yoyo_api(device_id, {"power1": "0", "power4": "0"})

3. 自定义逻辑实现：门禁与订单状态联动 (Access Control)

场景： 用户在非订单时段无法开门，订单结束即封锁门禁。触发点： 用户扫码开门请求（或刷卡/NFC）。实现逻辑：

1. 用户点击“开门”。

2. 后端检查数据库：该包间是否有进行中且未过期的订单。

3. 条件满足： 下发 reset 指令开门，并联动开灯。

4. 条件不满足：

   • 调用接口播放语音：“订单无效或已过期，请扫码续费。”

   • 不下发开门指令。

4. 自定义逻辑实现：订单结束强制清场 (Force Evacuation)

场景： 订单时间结束，系统尝试断电，但传感器检测到有人（赖着不走）。联动逻辑：

• 动作： 执行关灯指令 {"power1":"0"}。

• 状态检测： 如果传感器上报 "radar":1 (有人)。

• 应对策略：

  • 关闭麻将机电源 {"power5":"0"}。

  • 音柱循环播报：“订单已超时，系统将在1分钟后全屋断电，请收拾物品离开。”

  • 维持门禁常开（或保持解锁状态），方便顾客离开，但不允许重新开启麻将机。

四、 实施注意事项

1. 接口调用机制与重试：由于网络波动可能导致接口调用失败（如关灯指令未送达），您的服务端需要实现重试机制。例如，调用芯步控制接口后未收到成功响应，自动重试3次。

2. 设备状态同步：利用芯步的设备状态上报功能。当有人用手动开关按下墙壁开关时，硬件会主动上报状态变化，您的服务器需监听此消息以更新UI（小程序上的开关状态），避免界面与控制实际脱节。

3. 私有化部署与延时：如果您对数据安全要求比较高，或希望局域网内控制零延时（不经过云端公网），芯步设备支持私有化部署，您可以在门店本地服务器运行核心联动逻辑，这样门禁与照明的响应速度可以达到毫秒级。

五、 总结

通过在您的自有服务器中利用芯步提供的 HTTP控制接口（下行） 和 设备消息推送（上行） ，您可以完全解耦硬件与业务逻辑。这种方案不仅能实现“门禁照明联动”，还能轻松扩展出“根据环境光强自动调光”、“根据雷达传感器判断是否闲置并断电”等高级自定义功能，彻底实现共享棋牌室的无人化、智能化管理。