芯步的35A智能断路器支持HTTP接口远程控制，可接入各类软件项目实现电路智能管理。以下方案涵盖接口对接、核心功能实现及执行器模式设计。
1. 背景与需求分析
在现代化的写字楼办公区管理中，电路管理的痛点日益凸显。传统的空气开关（断路器）仅提供过载和短路保护，缺乏对用电数据的感知和远程控制能力，这导致了“长明灯”、下班后空调忘关、违规大功率电器滥用以及无法对每条支路进行精细化能耗统计等问题。引入芯步 35A 智能断路器，通过其开放的 HTTP API 接口，可以将传统的配电箱升级为“智慧用电”系统。
本方案的目标是详细阐述如何将型号为 UNI-DLQ-35A 的智能断路器无缝集成到现有的楼宇管理软件项目中。该设备支持 7000W 额定功率，适用于写字楼的照明回路、插座回路及空调回路 。通过标准 HTTP 请求，开发者能实现对电路状态的实时监控与通断控制。
2. 设备核心能力与技术规格
在开始对接开发前，软件项目团队需明确该硬件的能力边界。芯步 35A 断路器并非简单的“开关”，它是一个带有计算能力的物联网终端。其接口开放能力是双向的：既包括软件向下发指令（控制），也包括设备向上报数据（感知）。
| 类别 | 关键参数 / 能力 | 说明 |
|---|---|---|
| 电气参数 | 额定电流 35A / 功率 7000W | 可直接接入写字楼分支电路，支持阻性负载（照明）和感性负载（电机/空调） |
| 核心功能 | HTTP 远程通断 | 支持在任何联网环境下，通过 API 调用执行“分闸/合闸” |
| 交互模式 | 双向控制 | 支持 APP/Web 远程控制，也保留本地物理按钮操作，且本地按钮可屏蔽 |
| 网络层 | Wi-Fi / 4G | 根据写字楼网络环境选择（ 4G 版以减少网络配置干扰），设备需保持云端在线 |
值得注意的是，设备接口设计采用了极简主义原则。只要设备在线，开发者向其发送标准的 JSON 指令即可改变电路状态，无需关心底层的电气信号转换 。
3. 接入设计与认证机制
3.1 系统架构拓扑
为了实现“软件项目”对硬件的管理，设计上采用 云到端 的直连模式。软件后端服务器充当客户端，芯步的开放平台作为中转桥梁。
控制链路：业务系统后台 → 芯步 API 网关 → (MQTT/HTTP 推送) → 智能断路器。
状态同步：智能断路器状态变更 → 芯步平台 → 配置的 Webhook (回调) → 业务系统数据库。
3.2 签名认证与安全机制
芯步开放接口的安全机制基于 AppID + AppSecret + Sign。这是接入的第一步，也是防止非法操控电路的关键。
软件项目在调用接口时，必须按照规范生成 sign 签名。根据官方定义，签名算法逻辑如下
获取基础参数：从平台控制台获取
开发者密码 (AppSecret)和当前请求的时间戳 (ts)（精确到秒，10位数字）。计算嵌套 MD5
第一步：
str1 = md5(AppSecret)第二步：
sign = md5(str1 + ts)注：这里的
+代表字符串拼接。
携带参数：在 HTTP 请求的 URL 中必须携带
sign和ts。
安全签名过程必须在后端服务器完成，严禁将 AppSecret 暴露在前端 JavaScript 或移动端代码中，否则可能造成整个写字楼电路被恶意控制的安全风险。
4. 核心功能开发与接口集成
4.1 设备初始化与注册
在软件项目中，需要建立“设备资产表”。每台 UNI-DLQ-35A 断路器外壳上印有唯一的 Device ID。
操作流程：运维人员安装设备通电联网后，在管理后台输入 Device ID 进行绑定。软件后端调用“设备状态查询接口”验证设备在线状态。
数据结构设计：数据库中应记录
device_id（设备ID）、location（安装位置，如“10楼东区照明”）、status（当前开关状态 0/1）。
4.2 “向设备下发指令”——电路控制实现
这是业务系统中最核心的功能，用于实现远程分闸与合闸。芯步的接口设计非常灵活，支持 JSON 格式参数 。
接口地址
http(s)://api.thingboot.com/{AppID}/device/control/请求方法：推荐
POST核心逻辑实现
假设我们需要对办公区的“下班断电”场景进行自动化，软件后端应构造如下请求体：
在软件代码中的执行逻辑示例（伪代码）
4.3 设备状态同步与异步消息处理
接口返回的 200 状态码仅代表平台接收到了指令，并不代表电路已经断开 。在写字楼管理中，系统必须实时知道电路的真实状态（例如：是人为按下按钮断开的？还是自动断开的？）。为此，需要配置 消息推送机制。
方案：在芯步控制台中配置 Webhook 地址（即软件系统暴露的一个公网回调接口）。
机制：当断路器状态发生变化（如过载跳闸、手动分闸）时，平台会主动将事件推送到软件后端。
代码实现：软件后端需要开发一个接口来接收这些数据，并解析其中的
device和power状态，更新数据库，并通过 WebSocket 推送到前端界面。
5. 场景化落地与执行器模式设计
为了提高代码的可维护性和业务适应性，在软件项目中针对 35A 断路器引入 执行器模式。即不对业务代码直接暴露硬件接口，而是抽象出业务动作。
5.1 第一种场景：定时策略与无人化管理
写字楼通常有固定的工作时间。
需求：晚上 20：00 自动切断非核心插座电源，早上 08：00 提前 30 分钟通电。
软件实现：利用 Linux 的 Crontab 或 Quartz 定时任务框架，在指定时间调用
control_breaker方法，传入order=0。特殊处理：在断电前 5 分钟，可通过系统向内部员工推送通知，避免因误判导致数据丢失。
5.2 第二种场景：负载监测与超额保护（联动控制）
35A 断路器具备实时功率上报能力。
需求：某会议室私自接入大功率取暖器，导致线路接近 35A 阈值，系统需自动保护并禁止合闸。
软件实现：软件监听 Webhook 上报的实时功率数据。
若
功率 > 7500W持续 3 秒，触发control_breaker指令断开，并标记该回路“故障锁定”。此时若员工在 APP 点击“合闸”，后端先进行业务逻辑判断（是否处于锁定状态），若处于故障状态则拒绝下发指令，并返回“因功率超限已被锁定，请联系管理员”的提示。
5.3 第三种场景：界面可视化与控制日志
在管理软件的前端界面上，利用接口实现：
状态卡片：绿色（合闸）/ 灰色（分闸）。
一键操作：点击按钮触发上述 HTTP 请求。由于 HTTP 请求本身是同步返回 200 但实际动作可能延迟，前端应设计为“乐观锁”模式（点击后立即变灰并显示“指令下发中”，待 Webhook 返回真实状态后修正）。
6. 私有化部署与内网环境考量
对于金融、政府或安全等级较高的写字楼，电路数据通常不允许经过公有云。芯步方案支持 私有化部署。
方案调整：如果客户的软件项目部署在写字楼本地服务器，且希望断路器数据不流出局域网，需要选择支持 MQTT 局域网直连 的固件版本。
技术实现：软件后端不再调用公网 API，而是直接连接局域网内的 MQTT Broker，通过订阅主题
api/{AppID}/device/control实现毫秒级延迟的电路控制。此时，整个用电管理系统是完全物理隔离的。
7. 总结
通过将芯步 35A HTTP 接口断路器集成到软件项目中，写字楼管理者完成了从“被动抢修”到“主动运维”的转型。开发者仅需关注三个核心点：严格的签名安全机制、基于 JSON 的指令下发逻辑 以及 基于 Webhook 的状态同步机制。
这种方案不仅实现了物理电路的数字化孪生，更为后续的能耗分析、节能策略提供了坚实的数据执行基础。对于软件项目而言，集成这样一个智能断路器并不复杂，它就像是调用一个“云端 GPIO 口”，只需要处理简单的 HTTP 协议，就能以极低的代码侵入成本，获得强大的硬件控制能力。