CATALOG

芯步的12路照明控制器支持两种对接方式:私有化部署下的直连HTTP控制(局域网内直接调用)和公有云模式下的消息推送(接收设备状态变更)。本方案利用这两种接口,实现从故障检测到告警通知的完整闭环——本地控制回路保障低延迟指令下发,云端消息推送负责将异常状态触达运维人员。

解决方案:基于HTTP接口的12路照明控制器故障告警通知系统

1. 概述

本方案的目标是利用芯步智能照明控制器12路16A(UNI-KZQ-ZM-12-16A) 的开放HTTP接口,构建一个轻量级的照明回路故障监控与告警系统。

  • 核心逻辑:系统通过定时轮询或状态主动上报,检测各回路(1-12路)的电流、电压及通断状态。当检测到异常(如:开关状态与控制指令不符、电流过载、回路无电流)时,自动触发告警。

  • 推送方式:支持企业微信/钉钉/飞书机器人短信通用Webhook

2. 核心技术架构

该系统主要依赖控制器的两种HTTP通信模式:

  1. 设备控制接口(局域网/云混合):用于下发“查询状态”指令或执行“复位/关断”操作。

  2. 设备状态上报(云端消息推送):配置设备将状态实时推送到你的公网服务器。

3. 实施步骤

3.1 环境准备与接口定位

首先,获取控制器的网络参数。该控制器通过WiFi 2.4G联网[citatin:1]。

  • 本地IP:在控制器的液晶屏或路由器DHCP列表中查找设备IP(例如 192.168.1.100)。

  • 密钥:查找设备配置中的安全密钥(Secret),用于计算签名 sign=md5(secret)

3.2 故障探测机制(两种方案可选)

针对照明回路故障(如灯管损坏、回路跳闸),通常采用方案一实现实时检测,或采用方案二实现定时巡检。

方案一:状态主动上报(推荐,实时性高)在芯步控制台配置HTTP消息推送,将设备状态实时推送到你的服务器接收端

  • 推送地址http://你的服务器IP:端口/api/lighting/callback

  • 接收示例:当回路状态变化时,POST数据格式如下:

方案二:主动定时巡检(适用于局域网纯内网环境)若设备处于纯内网环境,可部署定时任务(如每分钟)轮询设备接口。这里的 {device_ip} 替换为控制器实际IP地址。

  • 请求地址http://{device_ip}/control?sign={md5_signature}

  • 请求方法:POST

  • 请求Body(查询全部状态)

  • 成功返回

3.3 故障逻辑判定(后端业务逻辑)

你的告警服务在接收到上述数据后,需实现以下核心判断逻辑:

故障类型判定条件示例场景
开关故障下发指令为“开启”(power: 1),但回检状态为“关闭”(power: 0继电器黏连或回路断路
光源损坏开关状态为“开启”(power: 1),但电流值 < 阈值(如 < 0.05A)灯管损坏、LED驱动电源烧坏
过载预警电流值 > 额定阈值(如 > 15A)线路短路或接入过大负载
3.4 告警通知实现(以Python Flask示例为例)

可以在服务器上编写一个简单的HTTP接口,用于接收设备上报并发送告警。

3.5 异常自愈与联动(进阶)

当检测到故障且确认为非危险类故障(非短路/过载)时,系统可自动执行一次“复位/重启”操作,即下发指令关闭再开启该回路,以应对驱动器死锁等瞬时故障

  • 控制指令下发POST http://{device_ip}/control?sign=XXX

    延迟 2 秒

4. 关键注意事项

  1. 私有化部署签名:若配置了密码,所有HTTP请求(无论是获取状态还是发送指令)都需要携带 sign 参数。签名算法为 MD5(secret)特别注意:文档不要直接发送明文密码,而是发送其32位小写MD5值。

  2. 消息推送重试机制:芯步的HTTP推送是尽力而为的服务,若你的服务器5秒内无响应(HTTP 200 OK),平台将丢弃该消息不再重试。因此,请一定要确保接收接口逻辑轻量、响应快速(先返回200,再异步处理业务逻辑)。

  3. 内网穿透:若你的告警服务器与控制器不在同一局域网,但控制器通过WiFi连接的是公网SaaS(软件即服务)平台,则无需内网穿透,直接使用云消息推送即可。若你使用纯局域网模式,告警服务器也必须在同一网段下。

5. 总结

通过接入芯步12路照明控制器的 /control 接口(控制与查询)和 设备消息推送(主动上报),可以低成本、高效率地构建照明故障告警系统。该系统不仅能实时发现“灯亮无电流”的隐性故障,还能结合消息推送机制将运维通知直达手机,实现照明系统的数字化运维。