怎样对接4路包间电器覆盖控制器MINI来实现包间设备运行时长统计_解决方案

CATALOG

芯步的“4路包间电器覆盖控制器MINI”本身具备完整的HTTP API接口，可以独立实现设备控制和状态查询。但要做“运行时长统计”，核心挑战在于：设备不会主动上报“空调开了多久”，需要开发者自行设计统计逻辑。以下方案基于其开放接口，给出完整的技术实现路径。

1. 背景与目标

在共享棋牌室、茶室、琴房等无人值守场景中，电费核算、设备损耗分析以及防止“跑单”（设备未结账却仍在运行）是痛点。利用芯步智能包间控制器MINI（型号：UNI-KZQ-BJ-MINI），开发者可通过其开放的HTTP API接口，对接自有SaaS系统，实现对包间内4路电器（照明/麻将机/门锁/空调）的独立运行时长统计，为精细化运营提供数据支持。

2. 硬件与接口能力

本方案基于控制器MINI的以下技术特性进行设计

4路独立控制：第1路（照明/16A）、第2路（麻将机/16A）、第3路（门禁/10A）、第4路（空调/30A）。
接口形态：支持标准的 HTTP API（适用于任何编程语言），支持局域网和公网访问，响应时间约80-120ms。
工作模式：设备通过WiFi 2.4GHz直连云端或私有服务器，无需额外网关。

3. 总体设计架构

为了实现准确的时长统计，不能仅仅依赖“定时查询”，采用 “事件触发记录 + 轮询校准” 的混合架构。

数据流向：

业务触发：用户小程序下单 -> 商家SaaS系统 -> 调用API（接通第4路空调、第2路麻将机）。
状态感知
- 主动上报模式（推荐）：设备状态变化实时推送到自有服务器。
- 被动轮询模式：SaaS系统每隔5分钟调用API查询设备当前状态。
计时逻辑：系统记录每次“通电”与“断电”指令的数据库时间戳，计算出时长。

4. 接口对接与签名鉴权

所有控制与查询指令均需通过签名鉴权。芯步采用动态MD5签名机制，具体对接流程如下：

4.1 签名算法

在调用 https://api.thingboot.com/{AppId}/device/control/ 之前，必须计算 sign 参数。算法步骤：

将开发者的 AppSecret 进行MD5加密：Secret_MD5 = md5(AppSecret)
拼接时间戳：SignStr = Secret_MD5 + ts （ts为Unix时间戳）
最终签名：sign = md5(SignStr)

4.2 下发控制指令

场景示例： 用户下单，系统自动打开包间的空调（第4路）和麻将机（第2路）。

请求地址POST https://api.thingboot.com/YourAppId/device/control/?sign=xxxx&ts=当前时间戳
请求Body

业务逻辑映射：系统接收到订单开始时间，在数据库记录 start_time = now()，并执行上述API。

5. 时长统计的具体实现机制

由于单纯的HTTP请求是“短连接”，无法实时获知物理断电（如用户通过遥控器关空调或强制拔卡），因此方案分为两种场景实施：

5.1 方案一：基于业务逻辑的“软统计”（推荐）

适用场景：无人值守门店，通过平台控制电器开关，物理开关被禁用或封闭。逻辑流程

开始计时：商户系统调用API下发 power=1 指令（开启）。API返回成功。
持续供电：系统定时任务守护状态（每10分钟调用 /device/status 接口验证一次，防止网络丢包导致状态不同步）。
结束计时：订单结束，系统调用API下发 power=0 指令（关闭）。
时长计算Duration = 关闭时间戳 —— 开启时间戳。
数据存储：将时长（秒/毫秒）绑定该订单号，存入MySQL/InfluxDB。

优点：算法简单，与物理开关脱钩，杜绝用户物理偷电。缺点：若网络中断导致指令未执行，记录会失真（需增加“心跳校验”机制解决）。

5.2 方案二：基于“状态轮询”的精确统计

适用场景：允许用户使用墙面物理开关干预设备，或需要检测异常断电。逻辑流程

定时任务：SaaS系统设定Cron Job（如 */1 * * * * 每分钟执行）。
状态查询：轮询调用API获取当前各路继电器的实际通断状态。
差值累加
- 建立一张 device_power_log 内存表。
- 如果上一轮状态是 0，本轮状态是 1，记录开始时间点。
- 如果上一轮状态是 1，本轮状态是 0，计算这一段的差值，累加到总时长。

5.3 方案三：基于消息推送的实时统计（高级-需私有化部署）

适用场景：高并发、对数据实时性要求比较高的场景（非SaaS模式）。依据：芯步设备支持私有化部署，可将数据上报至自建的MQTT服务器。实现

在服务器部署EMQX等Broker。
设备注册至私有Broker，状态变化时主动推送 connect 或 disconnect 事件。
服务端监听特定Topic，收到“断开”事件时立即结算，无需轮询。

6. 数据库模型设计

建立以下两张核心表来支撑统计功能：

表1：运行记录表 (device_running_log)

字段名	类型	说明
`id`	bigint	自增主键
`device_id`	varchar	控制器ID
`channel`	tinyint	路由(1-4)
`order_id`	varchar	关联的订单号
`start_time`	datetime	本次通电开始时间
`end_time`	datetime	本次断电结束时间
`duration_sec`	int	总运行秒数
`power_consumption`	float	估算能耗（功率kw * 时长h）

表2：实时心跳表 (device_heartbeat)用于方案二中的快速判定：

字段名	类型	说明
`device_id`	varchar	控制器ID
`channel_4_status`	tinyint	当前空调(0/1)
`last_update_time`	datetime	最后状态更新时间

7. 具体实施步骤

第一阶段：环境准备与配置

登录芯步控制台，获取 AppID 和 AppSecret。
在现场部署控制器MINI，接好4路线路（特别注意：第3路接门锁电磁铁，需配合整流模块；第4路接空调使用30A继电器）。
将设备添加至控制台，记下 Device ID。

第二阶段：开发时长统计模块（Python伪代码示例）

import requests
import hashlib
import time

class YoyoStats:
    def __init__(self, app_id, app_secret, device_id):
        self.app_id = app_id
        self.app_secret = app_secret
        self.device_id = device_id
        # 假设使用Redis存储当前状态
        self.redis_client = redis.StrictRedis()

def _gen_sign(self, ts):
        # 1. md5(appSecret)
        secret_md5 = hashlib.md5(self.app_secret.encode()).hexdigest()
        # 2. 拼接时间戳
        sign_str = secret_md5 + str(ts)
        # 3. md5最终签名
        return hashlib.md5(sign_str.encode()).hexdigest()

def query_status_and_calc(self):
        ts = int(time.time())
        sign = self._gen_sign(ts)
        
        url = f"https://api.thingboot.com/{self.app_id}/device/status/"
        params = {‘sign’: sign, ‘ts’: ts, ‘device’: self.device_id}
        
        response = requests.get(url, params=params).json()
        # 假设返回的status中power4表示空调状态
        current_status = response[‘data’][‘power4’] 
        last_status = self.redis_client.get("device:aircon:status")
        
        if last_status is not None and last_status == b‘0’ and current_status == 1:
            # 刚刚开启了空调
            self.redis_client.set("device:aircon:start_time", time.time())
        elif last_status is not None and last_status == b‘1’ and current_status == 0:
            # 刚刚关闭了空调
            start = float(self.redis_client.get("device:aircon:start_time"))
            duration = time.time() - start
            # 存入数据库
            db.insert_running_log(channel=4, seconds=duration)

第三阶段：异常处理与防作弊

断网续传：利用设备的离线缓存能力，或者自行设计补偿机制（如每晚凌晨同步一次总运行时长）。
时长核算：对于第3路（门锁），时长统计逻辑应为“开门时长”，而不是通电时长。结合人体传感器（芯步生态产品）辅助判断包间是否真正有人，避免用户打开空调后离开现场时导致的浪费，系统可设定“无人自动断电”策略。

8. 预期效果与运营价值

电费精准分摊：根据不同设备（空调、麻将机）的运行时长，自动计算每单的电费成本。
设备寿命预警：当麻将机单日运行时长超过24小时（意味着电机过热）或空调连续运行超长时，系统自动发送维护通知。
异常报警：如果订单已结束且结账，但第4路（空调）状态为1，系统将自动强制执行 power4=0 指令，物理断电防止逃单。

9. 总结

通过对接芯步4路控制器的开放接口，开发者无需关心底层硬件协议，只需专注于业务逻辑层的计时算法。优先采用“方案一（业务逻辑统计）+ 定时心跳查询（方案二辅助）”的组合模式，以最低的服务器资源占用实现高精度的包间设备运行时长统计。对于拥有技术团队且注重数据隐私的项目，可启用私有化MQTT方案以获得设备主动上报的实时体验。