芯步的开放接口基于HTTP协议,标准化的签名认证和JSON指令格式让二次开发门槛较低。针对小型商铺照明场景,延时通断控制可以通过“传感器触发→服务器逻辑判断→指令下发”的链路实现。以下是具体方案:
解决方案:基于芯步开放接口的小型商铺照明延时通断控制系统
1. 概述与选型
在小型商铺(如便利店、服装店、咖啡厅)场景中,照明延时控制主要应用于卫生间、试衣间、库房、打烊渐熄等场景。
核心逻辑:当传感器检测到“无人”状态或接收到“关闭”指令时,不立即断电,而是进入倒计时(如30秒、5分钟),计时结束后下达断电指令。
推荐硬件组合
核心控制器智能开关/通断器(支持芯步协议,用于控制具体照明回路)。
触发传感器智能人体存在传感器(如雷达传感器,用于判断是否有人)或 智能面板/按键(用于手动触发延时关闭)。
现有产品参考:根据芯步开放平台文档,其雷达传感器支持上报
radar_enable状态,且设备支持标准的power指令控制。
2. 接口对接架构
芯步的设备高度依赖 HTTP API 进行控制。本方案的对接架构分为三层:
设备层:智能开关(执行器) + 人体传感器(信号源)。
网络层:设备通过 WiFi 2.4G 直连云端或局域网服务器(支持私有化部署,保证店铺断网时仍可本地联动)。
应用层:商家的后台系统(或小程序/Web端)接收设备上报的事件,执行延时逻辑,下发指令。
接口流程示意
传感器探测到“无人” 传感器上报状态至应用服务器 服务器启动计时(Delay 30s) 服务器调用芯步控制接口 智能开关执行“断电”动作。
3. 核心功能实现逻辑
要实现延时通断,重点不在于硬件本身,而在于服务端对HTTP接口的调用逻辑。
3.1 第一种场景:人来灯亮、人走后延时关(卫生间/库房)需要用到 人体存在传感器 和 智能开关。
第1步:设置传感器上报 URL。在芯步控制台配置消息推送地址,指向您的私有服务器。
第2步:服务器接收“有人”事件。传感器通过接口(如
radar_enable=1)推送数据到服务器。第3步:执行开灯。服务器调用
device/control/接口,下发{"device":"设备ID", "order":{"power":1}}打开照明。同时,清除或重置该设备当前的延时任务。第4步:服务器接收“无人”事件(
radar_enable=0)。第5步:启动延时计时器(如设置
delay_time = 30秒)。第6步:执行关灯。计时结束后,再次调用控制接口下发
{"order":{"power":0}}。
3.2 第二种场景:手动按键关灯,但延迟熄灭(试衣间/卧室)有时候用户按了“关”键立刻陷入黑暗体验不佳,需要留出离开的时间。
逻辑:当智能面板按下“关”时,服务器不直接发关灯指令,而是启动计时器(如60秒),60秒后再发关灯指令。
补充:这需要在代码层维护一个状态机,如果在60秒内又重新按了“开”,必须取消之前的延时任务。
4. API 关键调用细节
接口地址
http(s)://api.thingboot.com/{AppId}/device/control/?sign={sign}&ts={ts}请求方式:
POST,Content-Type: application/json签名机制:利用
AppId和App Secret生成sign,加上时间戳ts防止重放攻击。指令下发示例(Python 伪代码逻辑)
5. 针对小型商铺的延时策略优化
嵌套防抖逻辑:防止传感器频繁触发。如果设备每秒上报多次“无人/有人”,会导致服务器频繁创建计时任务。在服务器内存中设置 “连续无人N秒后才开始计时” 的逻辑,或者利用芯步设备自身的去抖机制。
远程配置延时时长:利用开放接口,商家老板可以在手机小程序上滑动滑块(如设置延迟为5-600秒),后台接收到配置后,更新该场景的延时参数变量。
本地联动优先:虽然HTTP接口响应很快(约80-120ms),但如果商铺网络不稳定,启用芯步的局域网私有化模式,让传感器和开关在局域网内通过API直接通信,无需经过外网,延时更低且断网可用。
6. 常见问题排查
设备不在线:调用接口前,需通过设备状态查询接口确认
device.status为online。WiFi设备掉线是延时控制失效的主要原因。指令执行延时:注意HTTP请求的超时设置。如果在高峰期有大量设备联动,使用异步任务队列(如RabbitMQ)来处理关闭指令,避免HTTP线程阻塞。
通过以上配置,你可以在芯步的开放架构上,灵活构建具备专业级逻辑的商铺照明系统。