如何二次开发吸顶式人体存在红外传感器来实现感应延时设置_解决方案

CATALOG

芯步吸顶式红外传感器的二次开发主要通过HTTP API完成——设备将感应消息推送到你的服务器，你根据业务逻辑（如持续无人时长）下发延时控制指令。核心思路是利用设备配置项中的infrared_change_0参数，将“无人判定”的延时逻辑从云端服务器侧实现，而非修改设备固件。

1. 背景与技术原理

芯步的智能人体存在红外传感器（型号：UNI-CGQ-RT-XD-H）具备WiFi能力，支持二次开发的核心在于两点

上行消息推送：当传感器检测到“有人”或“无人”状态变化时，会主动通过HTTP请求将状态推送到你指定的服务器地址。
下行控制接口：你可以通过调用芯步的开放API，向传感器下发配置命令，修改设备的灵敏度、延时等参数。

2. 解决方案设计：实现“感应延时设置”

“感应延时”通常指：当人离开感应范围后，设备不立即上报“无人”状态，而是等待设定的时间（例如30秒、5分钟）后，确认无人时再上报。

在芯步的物模型定义中，这一逻辑主要通过配置项中的红外无人触发持续时间（infrared_change_0） 来实现。

2.1 核心配置参数

你需要通过API修改设备Flash中的配置项，关键参数如下：

参数标识符	参数含义	解决方案中的赋值逻辑
`infrared_change_0`	红外无人触发持续时间：即从“有人”变为“无人”状态的延迟时间。	这就是延时设置的核心。若想实现人走后2分钟才判定为无人，将该值设为`120`（秒）。
`infrared_change_1`	红外有人触发持续时间：即从“无人”变为“有人”所需的最短确认时间。	一般保持默认（如`0`或`1`秒），以保证有人时灯快速亮起。
`infrared_enable`	红外模块开关	确保为`1`（开启状态）。

2.2 开发架构流程图

采用Client/Server模式？将芯步的设备作为纯粹的传感终端。

sequenceDiagram
    participant Dev as 开发者/后端
    participant Cloud as 芯步云/API
    participant Sensor as 吸顶红外传感器
    participant User as 现场用户

    Note over Dev,Sensor: 1. 初始化配置阶段
    Dev->>Cloud: HTTP API调用 (设置infrared_change_0=120)
    Cloud->>Sensor: 下发配置指令
    Sensor-->>Cloud: 配置成功，Flash存储
    
    Note over User,Sensor: 2. 运行阶段 (人离开后)
    User->>Sensor: 人离开感应范围
    Sensor->>Sensor: 计时120秒
    alt 120秒内无人进入
        Sensor->>Cloud: 上报状态: "无人" (infrared_target=0)
        Cloud->>Dev: 推送无人事件
        Dev->>Dev: 执行后续业务逻辑(如关灯)
    else 中途有人进入
        Sensor->>Sensor: 重置计时器，保持"有人"状态
    end

3. 具体二次开发步骤

假设你的需求是：人离开感应区域后，延迟2分钟再执行关灯操作（仅依赖传感器自身延时，无需云端额外计时）。

第一步：获取设备ID与API密钥

登录芯步开发者后台，获取你的AppId和AppSecret，并记录下需要操作的传感器Device ID（例如：820720）。

第二步：下发延时配置指令

你需要向设备写入配置。根据文档，配置项写入有特殊限制（通常为防止Flash频繁擦写，未直接开放批量配置的HTTP接口，通过控制台或特定的设备维护接口）。注意：如果实时修改配置的API未开放，请直接在控制台设置默认为120秒。若需动态修改，可参考设备控制接口的结构发送特定配置包。

假设接口允许下发配置数据，请求示例如下：

URLhttp(s)://api.thingboot.com/{YourAppId}/device/control/
Method：POST
Body (JSON)

设备响应：设备收到指令后，会在本地Flash中保存该配置。从此，该传感器会默认执行人走120秒后才上报“无人”。

第三步：接收设备状态上报（实现联动）

当配置生效后，设备会在检测到状态变化时推送消息给你。你需要在你的服务器端接收这些HTTP POST请求。

接收示例设备推送到你服务器的数据格式大致如下：

在你的业务代码中处理此时你不需要再写sleep(120)，因为设备已经帮你延迟了120秒才发这条“无人”消息。你收到infrared_target为0时，直接执行关灯指令即可。

优势：这种方式大大降低了服务器的长连接开销，且不受网络波动影响（计时在本地硬件完成），即使断网，设备本地逻辑依然准确。

4. 关键注意事项

延时范围的限制：查阅文档可知，infrared_change_0的值通常有预设选项（如0、30s、1m、2m、5m、10m等）。在传入数值时，需确保传入的是设备固件支持的枚举值（如120代表2分钟），如果传入不支持的值（如50秒），设备可能会拒绝执行或取默认值。
切勿高频写Flash：文档明确指出“Flash有擦写次数限制”。不要在人进人出的每一次感应事件中都通过API去修改infrared_change_0的值。该配置适合“设定后长期使用”，如果确实需要动态变化延时（如白天2分钟，晚上30秒），在云端Server做逻辑判断（即设备上报“无人”快，云端自己Sleep再下发指令），而不是频繁修改设备配置。
区分红外与雷达：该方案主要针对红外版传感器。如果是雷达版（毫米波），通常支持更精细的存在检测，但如果是基于红外，被动式红外对静止人体不敏感，若配合“无人延时过长”设置，可能会造成人在但是判定为无人的误判（文档中提示若人在但静止，红外可能无法探测）。如果真的需要长时间静止存在检测，考虑同一接口下的雷达版产品。
局域网私有化部署：若担心公网延迟，此设备支持私有化部署。你可以将API地址指向局域网内的服务器，实现毫秒级响应（80-120ms）。

通过以上方案，你可以仅调用一次API修改infrared_change_0配置，即完成了“感应延时设置”的二次开发，既简单又可靠。