共享棋牌室的照明控制看似简单，但要在保留物理按键操作习惯的同时接入远程管理，核心是解决“两路控制”的逻辑——物理按键按下去，云端和App的状态也要同步更新。以下方案基于芯步开放接口，重点拆解如何通过HTTP API和消息推送实现这一闭环。

1. 背景与需求分析

在共享棋牌室（无人值守自助棋牌室）的运营场景中，照明管理是用户感知最直接、安全要求最高的环节。传统改造方案往往只保留远程App控制，忽略了中老年用户群体的操作习惯问题——他们更倾向于进门随手按墙上的物理开关。此外，完全依赖手机App开灯，一旦用户手机没电、信号差或尚未完成订单绑定，将导致极差的消费体验。

本方案的目标是解决以下三个核心矛盾：

1. 保留习惯：物理按键必须随时可用，且响应速度需与普通开关一致（毫秒级）。

2. 状态同步：当用户按下物理按键时，云端必须实时感知状态变化，确保远程App界面（如商家管理端、用户小程序）上的灯光状态实时刷新。

3. 安全与控制：商家需拥有最高权限，即使在物理按键被按下时，订单结束后系统仍能通过云端强制断电平抑。

2. 系统设计

基于芯步开放平台的特性，本方案采用“端-云-管-控”的四层架构。

2.1 硬件选型清单

根据芯步产品库及通用的开放接口标准，我们将选用以下三类硬件：

• 智能三路墙壁开关（执行单元） ：替代传统开关。选用支持芯步协议的 WiFi 版（2.4GHz）智能墙壁开关。该设备具备物理按键触感和电路通断继电器。

• 智能人体存在传感器（逻辑辅助） ：安装在棋牌室吊顶。因为物理按键不具备“上报按键事件”的功能，我们需要通过传感器监测电流或通过逻辑算法来判定物理按键操作，但更高效的做法是直接利用智能开关的回环检测。

  • 说明：芯步的智能开关通常具备“断电记忆”和“状态主动上报”功能。当物理按键被按下时，继电器翻转，设备会主动向云端推送当前状态（power:0或1）。

• 智能包间控制器（可选方案） ：如果需要对空调、麻将机、照明进行总控，可采用类似“统软云”或芯步生态的包间控制器，但针对照明专项，开关类设备成本更低。

2.2 逻辑架构图（文字描述）

• 控制层：物理按键（传统操作） + 微信小程序/商家SaaS（远程操作）。

• 传输层：WiFi 2.4G 直连云端（无需网关，降低故障点）。

• 平台层：芯步开放平台（ThingBoot Open）。负责设备注册、签名验证、消息路由及HTTP API分发。

• 执行层：智能墙壁开关继电器，控制照明回路。

3. 核心功能实现：物理按键与云端双控

为了实现“物理按键按下，云端同步”这一核心诉求，需重点利用芯步平台的两个机制：设备状态主动推送（Webhook） 和 设备下发控制（API）。

3.1 物理按键控制机理

1. 工作原理：智能墙壁开关内部维持常态带电。用户按压物理按键，直接触发MCU（微控制单元）中断。

2. 本地执行：MCU立即驱动继电器吸合/断开，照明瞬间响应。这是物理层面的硬接线，不依赖网络。

3. 状态上报：继电器动作后，MCU通过WiFi模块向云端发送一条数据包。格式如下（参考芯步接口规范）

   { "device_id": "10086", "timestamp": 1713012345, "status": { "power": 1 // 1代表开启，0代表关闭 } }

4. 云端同步：芯步平台接收到此上报后，触发配置好的HTTP推送，将状态推送到商家的业务服务器。

3.2 云端远程控制机理

当商家在后台点击“强制关灯”或用户点击小程序“开灯”时，业务流程如下：

1. 业务服务器发起HTTP请求到芯步API 。

2. 请求示例（伪代码）：

   • URL: http(s)://api.thingboot.com/{AppId}/device/control/

   • Header: Sign (签名), Ts (时间戳)

   • Body:

     { "device": "10086", "order": {"power": 0} // 0为关闭 }

3. 云端下发：平台验证签名后，通过长连接将指令推送到设备。

4. 设备响应：智能开关执行命令，物理按键位置不变（如按键处于开的位置，但继电器被云端关闭），此时产生“按键位置与实际通断不一致”的情况。

   • 解决方案：这是正常现象。但智能开关支持“回弹式”设计或指示灯状态会根据实际继电器状态显示（灯灭），用户下一次按键时，开关会同步当前状态。

3.3 “三路”独立管理

针对棋牌室环境，通常分为：主照明、氛围灯带、卫生间/吸烟灯。

• 接口参数设计：在芯步控制台中，基于同一个设备ID，利用不同的order参数区分线路。

• 命令示例（假设为三路开关）：

  { "device": "10086", "order": {"power1": 1, "power2": 0, "power3": 1} // 控制三路不同状态 }

  参考业内通用标准，如统软云的power1,power2参数形式。

4. 关键难点解析：状态一致性与防抖动

在集成过程中，需重点解决以下两个工程难点：

4.1 物理按键的“防抖动”与误触发

• 场景：用户快速按压按键，或设备老化导致触点抖动。

• 芯步方案：利用MCU的消抖算法（如延迟10-20ms再次读取电平）。在API层面，设备上报频率受控，防止大量短时上报冲垮业务服务器。

4.2 断电与重连机制

• 场景：棋牌室拉闸导致设备离线，恢复供电后灯常亮，造成浪费。

• 配置：利用芯步的 “上电状态设置” 功能。需在初始化设备时，通过接口配置断电记忆模式为“断电恢复后保持关闭”或“恢复断电前状态”。

• ：在共享场景下，配置为“断电恢复后保持关闭”，配合订单开始的API开灯，避免无人时浪费电。

4.3 物理按键与订单逻辑的联动

• 需求：用户订单未开始或已超时，物理按键即便按下，灯也不该亮（防止蹭座）。

• 实现逻辑

  1. 网关（本地网关或云端策略）需设置联动规则。

  2. 当物理按键按下——设备上报“power:1”——芯步平台触发规则引擎——平台检查业务服务器返回的“房间是否有有效订单”状态。

  3. 如果无订单：平台自动向设备下发“power:0”指令。用户此时会觉得灯闪了一下又灭了，起到了提示作用。

5. 集成实施流程（开发者视角）

针对集成商进行开发对接的步骤如下：

5.1 环境准备与设备配网

1. 在[芯步开放平台] 注册开发者账号，创建应用，获取AppId和AppSecret。

2. 购买设备（智能三路开关）。使用“一键配网”或“AP配网”模式将设备连接至2.4GHz WiFi。

   • 注意：设备支持设定5组WiFi，可确保信号稳定性。

3. 在平台控制台将设备ID绑定到对应的棋牌室房间（例如 Room_101）。

5.2 服务器对接开发

1. 签名算法：按照文档实现 sign = md5(md5(AppSecret) + Ts) 并拼接URL。

2. 控制接口开发

   • 开发一个通用函数 controlDevice(deviceId, powerStatusArray)。

   • 该函数负责组装JSON，发起POST请求。

3. 接收设备上报（Webhook） ：

   • 配置公网回调URL（例如 https://yourdomain.com/api/yoyo_callback）。

   • 当用户按压物理按键时，该URL会收到设备的状态推送。

   • 服务器需更新数据库中的“灯光状态”，并实时通过WebSocket推送到商管前端页面。

5.3 业务逻辑注入

在棋牌室SaaS系统中增加以下逻辑：

• 订单开始：调用芯步接口，打开主照明（power1）、打开插座（如果插座也是智能设备）。

• 订单结束：调用芯步接口，关闭所有power线路。

• 物理按键覆盖：在Webhook处理函数中，增加判断：if (订单状态 != 进行中) { 调用关灯指令; return; }

6. 总结

1. 体验最佳：通过本地物理直连，即使芯步云或门店宽带故障，房内物理按键依然能控制灯光，可靠性高。

2. 响应迅速：命令响应约80-150ms，人体无感知延迟。

3. 成本可控：相比有线中控方案，WiFi直连方案无需布设控制线，利用现有零火线即可，改造成本极低（仅替换开关面板）。

4. 接口友好：标准HTTP API，支持PHP、Java、Python、Node.js等任何后端语言，且支持局域网私有化部署，保障数据安全。

通过上述方案，共享棋牌室不仅能实现现代化的无人管理，还能为用户提供“智能化但不失传统习惯”的无感过渡体验。