吸顶式红外探测器接入的关键在于理解其“事件驱动”的上报机制——设备只在有人/无人状态变化时才推送数据，而非持续上报。以下方案基于芯步的开放接口，说明如何完成设备配置、数据接收解析，以及与业务系统的联动。
1. 产品理解：UNI-CGQ-RT-XD-H 的关键特性
在开发之前，需要先明确这款硬件的特点，这决定了代码逻辑的写法。
即报即用：设备通过 WiFi 2.4G 直连路由器，不需要网关。这意味着你的后端服务器需要直接面对海量设备的并发连接。
核心数据：既然我们关注“存在感应”，那么物模型中的
infrared_target属性就是核心。值为1代表“有人”，0代表“无人”。时机控制：红外感应容易受微小动作干扰。设备参数里的
infrared_change_1（触发“有人”需保持的时间）和infrared_change_0（触发“无人”需保持的时间）非常关键。默认可能是立即或几秒，你可以根据业务场景（比如是办公节能还是安防监控）来调优。
2. 接入架构：HTTP 推送模式
芯步的开放接口分为“下行”（App控制设备）和“上行”（设备上报数据）。对于感应数据，我们关注上行。
推荐采用 设备直连 + HTTP 推送 的极简架构。你不需不断轮询，设备一旦探测到状态变化，数据会瞬间推送到你的服务器。
流程如下
设备通电配网。
设备探测到环境状态改变（例如无人 -> 有人）。
设备将数据发往芯步云端。
云端通过 HTTP POST 请求，将 JSON 数据包转发给你配置的服务器地址（API网关）。
3. 详细实施步骤
3.1 环境准备与设备配置
在芯步开发者后台，你需要完成两件事：
获取凭证：记录下
AppId和AppSecret，后续接口验证需要用到签名。设置推送目标：在“消息推送”设置中，填入你的公网可访问接口地址，例如
https://api.yourdomain.com/ordercallback。这里要选 HTTP 模式，记住必须返回 HTTP 200 状态码才算接收成功。
3.2 接收并解析“有人/无人”数据
这是核心编码部分。你需要写一个 API 接口（这里用伪代码/逻辑示例），专门接收来自芯步云端的 POST 请求。
接收的数据结构示例根据文档，设备上报的消息体结构如下。你会发现，虽然我们只关心红外，但数据结构是统一的，便于扩展。
逻辑处理步骤
验签（可选但）：为了防止伪造数据，你可以验证请求来源的合法性（虽然芯步平台通常有IP白名单，但业务层验签更安全）。
解析参数：提取
device和infrared_target的值。业务联动
如果是
infrared_target=1：触发“存在”逻辑。记录签到时间、开灯、或者通知大屏亮起。如果是
infrared_target=0：触发“离开”逻辑。记录离开时间、关空调、或者触发撤防。
3.3 进阶配置：调优防误报
你会发现红外传感器有时候会误报，或者人静止不动时误判为无人。这时可以利用产品手册 2.3 节的配置项。
配置
infrared_change_1：如果设置成5，意味着目标必须保持“有人”状态 5秒 后，设备才会上报“有人”。这能过滤掉宠物或窗帘飘动引起的干扰。配置
infrared_change_0：如果设置成300(5分钟)，意味着人离开后，需要持续检测 5分钟 无人，才上报“无人”。这对于办公区域特别有用，避免人坐着不动（红外检测不到细微动作）时灯突然灭了。
4. 常见问题与排障
1. 为什么收不到“无人”的数据？很可能是因为 infrared_change_0 的延迟设置。设备探测到无人后，会等待设定的时间窗口，确认这段时间内一直无人，才会上报。请检查配置项的数值设置。
2. 私有化部署（纯局域网）怎么弄？芯步的这款设备支持私有化。如果你部署在内网，设备配置页面里，直接将上报 URL 指向你内网服务器的 IP 地址（例如 http://192.168.1.100:8080/callback）即可。
3. 如何区分“存在”和“移动”？注意，该型号为红外版。红外技术探测的是移动的热源。如果人静止不动（如熟睡、长时间办公），红外传感器可能会判定为“无人”。如果你需要真正的“静态存在感应”，可能需要更换为雷达版（如 UNI-CGQ-RT-XD-F）。雷达版能探测呼吸等细微动作，但从接口接入逻辑上讲，上报的数据格式是统一的。
总结方案
接入芯步的吸顶红外探测器并不复杂，本质是一个 Webhook 的对接。主要工作集中在：
在后台配置好回调地址。
编写一个接口解析
infrared_target字段。根据业务需求配置触发延时。
该方案典型的场景是：当传感器上报 infrared_target:1 时，你的系统立刻通过芯步的下行接口（控制接口）给该房间的灯光控制器发送 power:1 指令，实现人来灯亮。