一、背景与需求分析

1.1 业务痛点

连锁门店、商铺在日常运营中常面临以下问题：

• 能源浪费：闭店后空调、照明、展示设备忘记关闭，造成电费损失

• 安全隐患：非营业时间设备通电，增加电气火灾风险

• 管理盲区：总部无法实时掌握各门店的“三关一闭”（关水、关电、关气、闭门）执行情况

1.2 核心需求

实现“人走断电”的自动化控制，需满足：

• 实时探测店内是否有人存在

• 探测到无人后自动执行断电指令

• 支持远程监控和异常告警

• 与现有软件系统（如门店管理系统、SaaS平台）无缝集成

二、整体技术架构

本方案采用“端-云-用”三层架构，基于芯步开放平台实现红外探测器与软件项目的对接：

┌─────────────────────────────────────────────────────────────┐
│                      应用层（软件项目）                        │
│  门店管理系统 / 小程序 / 总部大屏 / App / 第三方SaaS平台       │
└─────────────────────────────────────────────────────────────┘
                              ↕ HTTP/HTTPS API + Webhook
┌─────────────────────────────────────────────────────────────┐
│                    芯步开放平台（云端）                     │
│         设备管理 │ 消息推送 │ 指令下发 │ 规则引擎              │
└─────────────────────────────────────────────────────────────┘
                              ↕ WiFi / 4G / 局域网
┌─────────────────────────────────────────────────────────────┐
│                       终端设备层                              │
│   吸顶式红外探测器 │ 智能插座/智能断路器 │ 其他执行设备         │
└─────────────────────────────────────────────────────────────┘

芯步的智能硬件开放HTTP接口，适用于任何支持HTTP请求的编程语言（Java、Python、Go、PHP、Node.js等），可接入Web、App/小程序、窗体软件、SaaS/低代码平台等多种形式的软件项目。

三、硬件选型与部署

3.1 核心设备选型

备选方案：若门店已有Modbus协议的485型红外探测器（如PR-3000-HW-N01型），可通过DTU（如有人DR154）将Modbus-RTU协议转换为MQTT/HTTP协议接入平台。

3.2 部署位置规划

1. 探测器安装：吸顶安装于门店主要活动区域（营业区、收银台、库房通道），避开空调出风口、热源、直射阳光

2. 执行器配置：将核心用电设备（照明总闸、展示屏电源、空调插座）接入智能断路器/智能插座

3. 网络覆盖：确保WiFi信号覆盖所有设备安装位置

四、软件对接核心流程

4.1 对接准备工作

1. 注册芯步开放平台账号：访问芯步开放平台完成开发者注册，获取AppId和AppSecret

2. 添加设备：在物联网控制台中添加红外探测器和智能插座，获取各设备的唯一DeviceId

3. 配置消息推送地址：设置您的服务器HTTP/HTTPS回调URL，用于接收设备上报的数据

4.2 接口调用流程

芯步的接口调用需携带签名进行身份验证，标准流程如下：

1. 生成签名 sign = MD5(AppId + AppSecret + Timestamp)
2. 构造请求URL:http(s)://api.thingboot.com/{AppId}/device/control/?sign={sign}&ts={Timestamp}
3. 发送POST请求，携带JSON数据体

参考数据格式

（注：power=1为开启，power=0为关闭）

4.3 数据上行：接收红外探测器的状态

红外探测器检测到“有人/无人”状态变化时，芯步平台会主动向您配置的服务器地址推送消息。

消息推送格式示例

您的软件项目需要实现一个接收此消息的HTTP接口，解析data中的radar_enable字段即可获得人体存在状态。

4.4 数据下行：下发断电指令

当软件项目判断需要执行断电时，调用设备控制接口：

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

请求方法：POST

请求体

响应示例

五、业务逻辑实现

5.1 “人走断电”触发规则设计

为保证控制逻辑的可靠性，采用双重确认机制

触发条件:
1. 红外探测器上报"无人"状态（radar_enable = 0）
2. 连续检测周期内（如5分钟）持续为"无人"
3. （可选）结合门店营业时间配置，非营业时段生效

执行动作:
→ 向智能插座/断路器下发"关断"指令（power=0）
→ 记录操作日志（时间、门店、执行结果）
→ 如执行失败，触发重试机制（最多3次）

延时确认的代码逻辑示意（伪代码）

5.2 智能联动扩展

除人走断电外，可利用同一套架构实现更多节能场景：

六、高级功能实现

6.1 私有化部署（数据安全场景）

对于对数据安全要求较高的连锁企业，芯步支持私有化部署方案：设备可直接连接至企业内部服务器，所有数据运行在纯局域网环境，不经过公有云。

• 需在企业内部部署ThingBoot私有化服务

• 设备WiFi配置指向内网服务器地址

• 适用场景：金融门店、高端零售、政府示范项目

6.2 与门店管理系统的集成

将接口封装为门店管理系统的功能模块：

1. API网关封装：在总部系统中封装芯步接口，统一管理门店设备：

2. 数据看板设计：在总部后台展示各门店“三关一闭”执行情况

• 绿色：已断电

• 黄色：待确认（延时中）

• 红色：未断电/异常

3. 报表统计

• 各门店每日/每月用电量统计（通过设备在线时长估算）

• 断电执行成功率分析

• 异常告警趋势图

6.3 多门店集中管理

通过芯步平台的多设备管理能力，可实现：

• 设备分组：按区域（华东区/华北区）、按品牌线（高端店/标准店）分组管理

• 批量操作：一键闭店（同时关闭指定门店组的全部电源）

• 分级权限：店长（仅查看本店）、区域经理（查看所辖区域）、总部（全局管理）

七、实施步骤与周期

八、技术要点

8.1 检测可靠性保障

• 避免误判：吸顶式探测器安装高度3-3.5米效果最佳；避开空调/冰箱等温度变化源

• 盲区补充：对于复杂布局的门店，可部署多个探测器覆盖不同区域

• 防休眠设计：部分红外探测器对静止人体不敏感，推荐选用毫米波雷达版，可检测呼吸微动

8.2 网络与通信

• 断网保护：设备支持本地联动规则，可在断网时维持基础的“人走断电”逻辑

• 重连机制：设备自动重连WiFi，无需人工干预

• 协议选择：芯步设备支持WiFi直连，无需网关，降低部署复杂度和成本

8.3 数据安全

• 签名验证：所有API请求需携带签名，防止非法调用

• 数据加密：生产环境使用HTTPS协议传输

• 访问控制：在企业服务端做二次鉴权，不直接暴露API密钥

九、预期效益

本方案基于芯步开放平台的HTTP接口能力，通过“消息推送+指令下发”的异步交互模式，可实现吸顶式红外探测器与任意软件项目的无缝对接。开发者无需关心底层通信协议，专注于业务逻辑即可快速构建门店能源管理解决方案。如需进一步的技术文档，可参考芯步开放平台官方开发文档。