无人值守空间的空调管理，核心难点在于“人不在、电在烧”——缺乏人体存在数据就无法精准决策。芯步的开放接口恰好解决这个问题：用传感器采集 occupancy 数据，通过 HTTP 接口回调触发空调控制器执行指令。以下方案围绕这个闭环展开。

——基于芯步开放接口的远程控制实践

1. 背景与分析

在办公楼会议室、设备机房、库房、酒店客房、学校教室等场景中，空调常因人员离开后未及时关闭而造成巨大的能源浪费。传统空调管理系统主要面临以下痛点：

芯步的价值定位：芯步开放平台提供标准化的HTTP API接口，支持传感器数据上报、设备远程指令下发，且支持私有化部署。这使得开发者可以快速构建“感知-决策-执行”的智能闭环，实现无人值守空间的空调自动管控。

2. 整体设计

本方案采用 端-云-控 三层架构，以芯步开放平台作为物联网数据中台，打通感知层与控制层。

graph TB
    subgraph "感知层 - 端"
        A1[人体存在传感器
雷达/红外]
        A2[温湿度传感器]
        A3[门窗磁传感器
可选]
    end

    subgraph "平台层 - 云"
        B1[芯步开放平台
ThingBoot Open]
        B2[用户自建应用服务器
策略引擎/业务系统]
    end

    subgraph "控制层 - 控"
        C1[智能空调控制器
红外/继电器]
        C2[分体式空调]
        C3[中央空调风机盘管]
    end

    A1 -- "MQTT/HTTP
状态上报" --> B1
    A2 -- "MQTT/HTTP
状态上报" --> B1
    A3 -- "MQTT/HTTP
状态上报" --> B1
    
    B1 -- "消息推送
（设备状态变更）" --> B2
    
    B2 -- "HTTP API调用
（携带签名+设备ID）" --> B1
    B1 -- "下发控制指令" --> C1
    C1 -- "红外/继电器控制" --> C2
    C1 -- "485/干接点" --> C3

架构说明

• 感知层：部署各类传感器，实时采集空间内的人员占用与环境数据

• 平台层：芯步开放平台承担设备接入、状态汇聚、指令路由；自建服务器承载业务逻辑（如策略判断、能耗统计）

• 控制层：空调控制器接收云端指令，通过红外或继电器方式控制空调启停及温度调节

3. 硬件选型

基于芯步产品体系，如下硬件组合：

3.1 感知类设备

3.2 执行与控制设备

3.3 通信方式选择

芯步设备主要支持 WiFi 2.4G直连 或 LORA网关 两种方式

• WiFi方案：适用于已覆盖无线网络的小型办公空间，部署简单，无需额外网关

• LORA方案：适用于大面积、多房间的复杂建筑（如酒店、学校），具有穿墙能力强、单网关覆盖数百台设备的优势

4. 关键业务流程设计

以下是无人值守空间空调管控的典型业务闭环：

sequenceDiagram
    participant Sensor as 人体存在传感器
    participant Yoyo as 芯步平台
    participant AppSrv as 用户自建服务器
    participant Ctrl as 空调控制器
    participant AC as 空调

    Note over Sensor, AC: 场景1:人员离开，延时关空调
    Sensor->>Yoyo: 上报状态: "无人"
    Yoyo->>AppSrv: 推送设备状态(device=820720, radar=0)
    AppSrv->>AppSrv: 触发无人策略:
延迟15分钟，期间未收到"有人"则执行关机
    AppSrv->>Yoyo: 下发控制指令 POST /device/control/
{"device":820721,"order":{"power":0}}
    Yoyo->>Ctrl: 转发红外码/继电器指令
    Ctrl->>AC: 关闭空调

    Note over Sensor, AC: 场景2:温度超限自动开启空调
    Sensor->>Yoyo: 上报温度: 29℃（高于设定阈值26℃）
    Yoyo->>AppSrv: 推送环境数据
    AppSrv->>AppSrv: 校验是否"有人"
且未到下班时间
    AppSrv->>Yoyo: 下发控制指令: 制冷26℃, 自动风速
    Yoyo->>Ctrl: 执行指令
    Ctrl->>AC: 开启制冷模式

4.1 流程一：无人自动关机（核心节能逻辑）

1. 数据采集：人体存在传感器周期性（如每30秒）检测空间内是否有人，当状态从“有人”变为“无人”时，立即向芯步平台上报

2. 平台推送：芯步平台通过配置的 消息推送URL，将设备状态变更实时转发至用户自建服务器

3. 策略执行：服务器接收到“无人”事件后，启动延迟计时器（5-30分钟可配置）

4. 指令下发：延迟期间若未收到“有人”事件，服务器调用芯步开放接口 device/control，携带签名（sign）和时间戳（ts），向指定空调控制器下发关机指令（{“power”:0}）

5. 容错处理：若网络中断，设备侧支持本地联动规则（需预先在平台配置“无人15分钟→关机”的联动模板）

4.2 流程二：远程预约/定时控制

• 场景：管理员需要在会议开始前30分钟预冷会议室，或下班后统一关闭所有空调

• 实现的方式是：通过自建服务器的管理界面，选择目标空调设备ID，调用芯步接口下发开机指令。支持批量设备控制（循环调用API）

4.3 流程三：基于环境参数的恒温控制

• 场景：空间有人但温度过低或过高

• 实现的方式是：温湿度传感器持续上报数据（如每5分钟），服务器策略引擎判断：若温度 > 26℃且空调处于关闭状态，则指令开机；若温度 < 18℃（冬季）且空调处于制热模式，则指令关机或切换模式

5. 开放接口调用详解

芯步提供标准的HTTP API，任何支持HTTP请求的后端语言（Java、Python、Go、PHP）均可调用。

5.1 接口通用规范

5.2 关键接口示例

以下以 关闭空调 为例：

请求示例

参数说明

• device：空调控制器的设备ID（在芯步控制台获取）

• order.power：1=开机，0=关机

• order.mode：cool(制冷)/heat(制热)/fan(送风)

• order.temp：设定温度（16-30℃范围内有效）

• order.fan_speed：low/mid/high/auto

接收设备状态变更（被动推送）服务器需提供一个公网可访问的URL（如 https://yourserver.com/yoyo/callback），芯步平台在传感器状态变化时，将向该URL推送如下数据：

5.3 私有化部署选项

对数据安全要求较高的用户（如政府机房、军工单位），芯步支持 私有化部署：控制命令可在纯局域网内完成，不经过公网，保障绝对内网安全。

6. 节能策略配置

针对典型的无人值守空间（如会议室、设备间），配置以下策略模板（在自建服务器中实现）：

预期节能效果：根据行业数据，结合“人走关机”与智能温控策略，单台空调年均可减少 20%-30% 的无效运行能耗。

7. 实施步骤

8. 总结

利用芯步智能硬件的开放接口进行无人值守空调管理，本质上是构建了一个 “传感器采集 → 云平台汇聚 → 业务逻辑判断 → 控制器执行” 的数据闭环。与传统的智能插座通断电方案不同，该方案保留了空调原有的调温、调模式等完整功能，且无需拆除现有空调设备。

对于开发者而言，芯步标准的HTTP接口及消息推送机制，极大地降低了集成门槛——只需关注业务策略（如“无人多久关机”），而无需处理底层通信协议与设备配网。结合雷达传感器的静止人体探测能力，该方案能够有效区分“短暂离开”与“真正无人”，在保障用户体验的前提下实现最大幅度的节能，适用于办公楼、学校、酒店、基站机房等多种无人值守或间歇性使用场景。