怎样二次开发吸顶式雷达存在感应器以实现节能模式联动_解决方案

CATALOG

吸顶式雷达存在感应器的二次开发价值在于：它不只是“人来灯亮、人走灯灭”，而是可以通过开放接口与业务系统深度集成，实现微动保持、多级节能、分组联动等精细控制。以下方案基于芯步的物模型和HTTP接口，展示如何搭建一套可落地的节能联动系统。

1. 背景与目标

在许多商业及办公场景（如写字楼办公室、会议室、卫生间、地下车库），照明与空调常因人员忘记关闭而造成巨大能源浪费。传统的红外传感器无法检测静止人体（如办公人员静坐），容易导致“误关灯”的不良体验。

本方案基于芯步智能人体存在雷达传感器[吸顶]（型号 UNI-CGQ-RT-XD-L）及其开放 HTTP 接口，通过二次开发搭建一套高精准、低延迟、可私有化部署的节能联动系统。

核心目标：

该设备采用毫米波雷达技术，具备比普通红外或微波雷达更强大的探测能力：

芯步为该传感器提供了标准的 HTTP 接口，支持二次开发

为了实现“节能模式联动”，需要搭建一个轻量级的 IoT 服务端。架构分为三层：

感知层
- 吸顶雷达传感器：采集人体存在数据。
- 执行器：智能插座/开关（控制灯光、加湿器）、空调控制器（控制温度/模式）、窗帘电机。
传输层/云层
- 消息服务器（自建）：接收传感器的 HTTP 推送。
- 业务逻辑引擎：处理“有人/无人”逻辑，判断延时时间，下发联动指令。
管理端
- 提供后台配置界面，允许管理员设置各区域的“无人延时时长”（如会议室 10 分钟，走廊 1 分钟）。

首先需要在芯步控制台或通过接口配置传感器的消息推送 URL。

传感器状态变化时会主动上报数据。服务端需解析 JSON 数据包。

接收到的数据示例（推测逻辑）：

服务端处理逻辑（伪代码）：

当系统判定无人状态持续时间（如 5 分钟）已满，需向关联的执行器下发关闭指令。

API 调用详情

请求地址http(s)://api.thingboot.com/{AppId}/device/control/?sign={sign}&ts={ts}
请求方式POST
请求体 (JSON)

为了极致节能，可以利用雷达传感器的雷达开关（radar_enable）命令，实现“深度睡眠”模式。

浅度节能（无人 0-10 分钟）
- 操作：关闭灯光、关闭显示器/排插电源。
- 状态：雷达传感器处于高灵敏度持续探测状态，随时准备人来自动开灯。
深度节能/待机（无人 10 分钟以上，如午休时段）
- 操作：关闭空调（新风系统）、关闭非必要电源。
- 操作下发命令关闭雷达模块的探测功能（radar_enable = 0）。
- 触发唤醒：由于雷达已关闭，需通过其他方式唤醒？不推荐完全关闭，降低雷达灵敏度而非彻底关闭。
- 替代方案：保持雷达低功耗运行，但联动调高空调设定温度（夏天 26℃ → 28℃），而不是粗暴关机，避免设备频繁启停损耗。

场景描述：某办公室安装了一台吸顶雷达传感器，覆盖 4 个工位，并联动 2 盏 LED 灯盘和 1 台壁挂空调。

联动

9:00：员工进入，雷达检测到 占用（Occupied） 。服务器收到消息，立即下发指令给灯和空调：{"power":1} 。灯光亮起，空调启动。
12:00-13:00：员工外出吃饭。传感器检测到无人，服务器启动 10 分钟延时定时器。
12:10：延时结束，服务器下发 {"power":0} 关闭灯光；下发空调设定温度调整为 26°C（节能模式）。
13:00：员工返回，雷达瞬间检测到存在（静态人体也能激活），服务器记录 “有人”，立即下发指令恢复照明和空调运行。
19:00：员工下班。系统判定无人超过 30 分钟，进入深度节能状态。服务器下发指令彻底断电。

防抖处理（Debounce）
- 雷达传感器在无人/有人边界可能会出现状态“抖动”（频繁上报 0/1）。
- 解决方案：在业务服务端程序里做“防抖”处理，例如连续收到 3 次“无人”信号，才判定为真的无人，避免临时出门拿快递导致空调瞬间关机又开机。
私有化部署（局域网）
- 对于学校教室或保密单位，所有流量需走内网。
- 芯步支持私有化，二次开发时应配置 API 请求地址为内网 IP，不依赖外网，保证断网时联动依然正常。
设备配置（物模型）
- 利用 配置项 中的 relay_change_1 和 relay_change_0。
- 实际上，可以直接在设备端设置“发现无人时线路动作”为关闭，将部分联动逻辑下沉到设备层（边缘计算），减少服务器压力。