24路智能远程电源控制器采用“API驱动、业务系统调用”的二次开发模式，核心是通过HTTP接口下发控制指令，将设备控制能力无缝集成到你的业务系统中。以下从接口基础、单路/批量控制、时序控制、事件联动几个维度展开。

解决方案：基于芯步开放接口对24路智能远程电源控制器的二次开发

1. 总览

芯步的 24 路智能远程电源控制器（通常属于其“智能通用控制器”系列，如 UNI-KZQ-TY-24）支持交直流输出，具备独立的 HTTP 开放接口。其核心二次开发模式是 “API 驱动”，即开发者无需关注底层通信原理，只需调用标准的 HTTP 请求，即可在任何业务系统（Web、App、小程序、桌面软件）中实现对 24 路电源的独立控制、状态查询及复杂逻辑编排。

2. 核心技术基础

在开始二次开发前，需明确以下技术对接基础：

• 接口协议：HTTP/HTTPS (支持 Post/Get 方法)。

• 数据格式：JSON。

• 鉴权方式：签名验证 (Sign) + 时间戳 (Ts)。（开发测试阶段可开启调试模式绕过签名验证，以加快开发速度）。

• 核心命令结构：通过 device（设备ID）和 order（指令集）下发控制命令。

3. 二次开发实现方案

二次开发主要是通过编程语言（如 Python, Java, Node.js, Go, PHP 等）构造并发送 HTTP 请求。以下是针对 24 路设备的具体开发逻辑，覆盖单控、组控、逻辑控制等场景。

3.1 基础请求封装

任何语言的开发都应先封装一个公共函数，该函数负责处理 AppID、签名计算和请求发送。

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

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

• 请求体 (Body)

  { "device": "设备的唯一ID", "order": {} }

• 签名算法： sign = md5( md5(AppSecret) + ts )

3.2 单路独立控制 (精细化控制)

24 路设备的每一路通常对应一个独立的参数键，标准参数命名通常为 power1 至 power24。

• 控制场景：只打开第8路连接的灯光设备。

• 下发指令

  { "device": "24路设备ID", "order": { "power8": "1" // "1" 代表接通/闭合， "0" 代表断开/释放 } }

3.3 批量并发控制 (多路同时操作)

对于需要同时开启或关闭多路电源的场景（如机房服务器同时重启某几排机柜），可使用 batch 参数，避免多次网络请求，提高效率。

• 控制场景：同时关闭第 1, 3, 5, 7 路输出。

• 下发指令

  { "device": "24路设备ID", "order": { "batch": { "relay": [1, 3, 5, 7], // 指定操作的线路数组 "power": "0" // 0=断开，1=接通 } } }

3.4 时序逻辑控制 (点动/互锁)

在工业场景中，往往需要“临时通电”或“先断后通”的逻辑。

• 点动控制（先通后断）： 适用于控制门禁锁、电磁阀等。例如给第 2 路通电 500 毫秒后自动断开。

  { "device": "设备ID", "order": { "point": { "relay": [2], // 控制第2路 "interval": 500 // 单位:毫秒，先通电，500ms后断电 } } }

• 脉冲复位（先断后通）： 适用于让某些网络设备重启。例如断开第 5 路，等待 3 秒后再重新接通。

  { "device": "设备ID", "order": { "reset": { "relay": [5], "interval": 3000 // 先断电，保持3秒，再重新通电 } } }

3.5 基于事件的联动 (自动化闭环)

这是更深度的二次开发，通常结合传感器或业务逻辑实现。

• 开发思路

  1. 触发源：用户的订单支付成功（业务系统）、温湿度传感器检测到高温（物联感知）、或门禁刷脸成功。

  2. 逻辑运算：业务服务器执行 if (temp > 50) then action。

  3. 执行动作：调用上述 API，向 24 路控制器发送 powerX=0 切断过热设备电源。

• 应用案例：在共享充电柜中，用户支付成功后 -> 服务器自动调用 API 控制 24 路控制器中的某一路接通直流电源给充电仓供电。

4. 关键开发

1. 关于“24路”的参数确认虽然标准逻辑是 power1 到 power24，但在芯步的具体固件版本中，对于超过 8 路的设备，命名规则可能延续标准。开发者在收到设备后，先通过控制台手动点击“开启第 24 路”，然后查看浏览器开发者工具中的 Network 请求，确认该路的具体 JSON 键名（例如可能是 power24 或 relay24），以这为准。

2. 异步反馈处理（重要）API 请求返回 {"code":200} 仅代表云端已收到指令，不代表设备实际执行成功（设备可能离线）。

   • 解决方案：如果需要强反馈（如确认继电器确实吸合了），需要配置 消息推送。在开放平台设置回调 URL，当设备执行命令后，云端会主动推送执行结果到你的服务器，这才是真正的“执行成功”凭证。

3. 网络环境适配由于设备直接连接 WiFi 2.4G，不依赖网关。因此二次开发时需考虑网络的稳定性。如果部署在工厂或实验室局域网，且要求高安全性，可申请 私有化部署 方案，将 API 接口部署在内网服务器上，实现纯局域网控制。

5. 二次开发集成场景示例

假设你正在开发一个智慧养殖环境控制系统

• 硬件接入：24 路控制器连接 24 个禽舍的通风扇和加湿器。

• 二次开发代码逻辑

  import requests def set_device_power(device_id, channel, action): url = f"http://api.thingboot.com/AppID/device/control/?sign=xxx&ts=xxx" payload = { "device": device_id, "order": {f"power{channel}": "1" if action else "0"} } response = requests.post(url, json=payload) return response.json() # 业务逻辑:当温度传感器上报温度 > 30度 且 湿度 > 70% if temp > 30 and humidity > 70: # 调用二次开发接口，开启第 3、5、7 路通风扇 for ch in [3,5,7]: set_device_power("KZQ_24_001", ch, True) print("环境过热过湿，已触发通风排湿")

通过以上方案，开发者可以将芯步的 24 路电源控制器作为一个标准的“网络继电器模组”纳入任何业务流程中，高效实现多路能源管理与设备自动化。