便利店设备机柜通常空间有限、发热量大，且多为24小时无人值守运行。将5位总控PDU接入芯步平台，核心价值在于解决两个问题：一是总部可远程重启死机的冷冻设备（如冰柜、咖啡机），避免商品损失；二是通过定时通断控制照明、广告屏等设备，降低非高峰期的能耗。

以下是基于芯步开放接口的完整接入方案。

1. 解决概述

本方案的核心是：以智能PDU为执行单元，以芯步为数据/控制总线，以HTTP API为集成接口。

• 硬件层：便利店机柜内部署 芯步 5位总控智能PDU。该设备支持100-250V宽电压，总额定功率3000W，单孔位支持1500W，完全满足冰柜、微波炉、咖啡机等设备的供电需求。

• 核心能力：PDU通过WiFi（2.4GHz）联网，支持远程总控（一键通断所有端口），并具备电量采集与过载保护功能。

• 交互逻辑：项目服务器（你的SaaS后台）通过调用芯步的OpenAPI，向指定PDU下发 power（开关）指令，实现远程重启或定时策略。

2. 系统架构与接口对接

要将PDU集成到你的项目（如便利店管理后台、手机APP或小程序）中，需经过设备注册、指令下发、状态同步三个环节。

2.1 准备阶段：获取凭证与设备ID

在芯步控制台完成以下准备

1. 注册开发者：获取 AppID 和 AppSecret（开发者密码）。

2. 添加设备：将5位PDU通过“物联网控制台”配置到现场WiFi，获取唯一的 device（设备ID）。

3. 确定指令格式：查阅该PDU的产品手册，确认控制命令为 power（总控）或针对特定端口的命令（如 power1、power2，虽然本款为总控，但接口标准支持分位控制语法）。

2.2 核心接口：下发控制指令

这是项目中最关键的集成步骤。当你需要在后台点击“重启机柜插座”或“关闭广告屏”时，后台服务器需向芯步API发起请求。

• 请求地址： http(s)://api.thingboot.com/{AppID}/device/control/?sign={sign}&ts={ts}

• 请求方法： POST

• 请求头： Content-Type: application/json

• 签名算法（重点） ：为保证安全性，芯步采用双重MD5签名。你需要计算 sign = md5( md5(AppSecret) + ts )。其中，ts 为当前Unix时间戳。

• 代码实现逻辑（伪代码思路） ：

  1. 将你的 AppSecret 进行第一次MD5加密，得到字符串 S1。

  2. 将 S1 与当前时间戳 ts 拼接成新字符串 S1+ts。

  3. 将拼接后的字符串进行第二次MD5加密，得到最终的 sign。

• 请求Body示例（JSON格式） ：假设你需要关闭这台PDU（设备ID为 111111）的所有输出：

注：order中的power字段是该PDU产品的标准定义。若为总控，power:1代表开，power:0代表关。

• 成功响应接口返回 {"code": 200} 仅代表指令已送达平台，不代表设备已执行。若需确认设备真实状态，需监听消息推送。

2.3 状态同步：消息推送机制

由于便利店网络可能存在波动，为了让后台确切知道“命令执行成功了没有”，必须接入芯步的消息推送服务。

• 原理：当PDU成功执行开关动作后，设备会主动上报新状态到云端，芯步会通过HTTP POST将状态消息推送到你预设的服务器地址（Callback URL）。

• 数据用途：更新前端页面上的“插座状态”图标（绿色/灰色），记录操作日志。

3. 业务场景实施

针对便利店的实际痛点，以下是具体的实施方案细节：

第一种场景：设备“死机”自动修复（Remote Reboot）

• 痛点：收银机、路由器或工控机死机，夜间无人处理。

• 方案

  1. 物理连线：将死机率较高的设备（如主路由器）电源插头插入PDU的端口1。

  2. 逻辑实现

     • 后台开发一个“网络检测脚本”或“人工重启按钮”。

     • 人工模式：店员/总部在APP点击“重启路由”，后台调用API：{"power":0}（断电），延时5秒，再调用{"power":1}（通电）。

     • 自动模式：后台定时Ping路由器IP，连续失败3次，自动触发上述断电/通电逻辑。

第二种场景：峰谷时段能源管控（Time Scheduling）

• 痛点：夜间非高峰时段，鲜食柜加热灯、招牌灯箱彻夜长明，浪费电费。

• 方案

  1. 任务配置：你可以不在项目里写定时逻辑，而是直接利用芯步平台自带的“云定时”功能，或者在项目服务器中实现定时器。

  2. 实施

     • 22:00（打烊）：调用API关闭“鲜食展示柜加热”、“招牌灯箱”、“背景音乐”对应的PDU端口。

     • 06:00（备餐）：调用API开启“热水器”、“烤箱”预热。通过这种精细化管理，单店单台PDU每年可节省数百元电费，且降低了线路老化风险。

第三种场景：过载保护与安全预警（Safety Alert）

• 痛点：便利店冬季同时使用多个大功率取暖器导致跳闸。

• 方案：芯步PDU内置电量监测功能。项目实施时，可通过API查询设备状态，或接收设备主动推送的告警。

• 阈值设置：在芯步控制台设置功率上限（如2500W）。一旦检测到超过阈值，PDU自动切断电源，并推送告警消息。你的项目收到告警后，可立即发送短信通知店长：“XX路店机柜功率过高已断电，请检查是否接入违规电器。”

4. 项目实施常见问题与规避

在将PDU接入项目时，针对硬件部署和软件集成，采取以下策略：

问题1：PDU离线怎么办？

• 原因：便利店WiFi路由器不稳定或2.4G信号干扰。

• 方案：在项目中引入“心跳检测”。如果连续10分钟未收到设备的状态推送，判定为离线，后台应通知运维人员。实施时优先使用企业级双频路由器，固定PDU的IP地址，并避免将其与高干扰USB 3.0设备并排放置。

问题2：命令下发成功但设备没反应

• 分析code 200 仅代表云端收到了指令。若设备未执行，通常是因为设备处于离线状态或MQTT连接断开。

• 方案：不要仅依赖同步返回的code，必须实现异步消息推送的接收。只有当设备主动上报“power状态变为0”时，才能在前端显示“关闭成功”。

问题3：多门店管理权限

• 需求：总部运维有所有门店的控制权，但店长只有自己门店的控制权。

• 方案：基于芯步的device（设备ID）进行权限隔离。在你的项目数据库中建立门店表和设备表的映射关系。当店长登录小程序时，后端SQL查询仅检索该门店绑定的device ID，在调用API时动态传入该ID，从而实现数据隔离。

通过上述方案，你可以将5位机柜总控PDU无缝融入便利店数字化管理平台，实现从“人治”到“智治”的跨越。