社区公共区域人体感应：如何将吸顶式智能红外感应开关对接到项目中_解决方案

CATALOG

一、背景与需求分析

在智慧社区建设中，公共区域的节能管理与安防监控是两大核心诉求。传统社区中，楼道、地下车库、电梯厅等公共区域常存在“长明灯”现象，造成电力浪费；同时，这些区域的人员活动缺乏有效监测，无法为安防预警、人流分析提供数据支撑。

芯步智能人体存在红外传感器[吸顶]（型号：UNI-CGQ-RT-XD-H） 为解决上述问题提供了硬件基础。该设备采用被动式红外（PIR）技术，可检测8米直径范围内的人体移动，同时具备WiFi直连、HTTP/MQTT双协议支持、私有化部署等特性。本方案的目标是阐述如何将该设备的开放接口对接到现有社区管理平台中，实现“感知-控制-联动-分析”的完整业务闭环。

二、设备核心能力与物模型解析

在对设备进行对接前，必须先理解其“物模型”——即设备能够上报什么状态、接收什么指令、触发什么事件。

2.1 关键状态属性

根据产品手册，该传感器具备以下核心属性

属性名称	标识符	数据类型	值含义	业务价值
红外感应	`infrared_target`	枚举	1=有人，0=无人	判断区域内人员存在状态
红外模块开关	`infrared_enable`	布尔	1=打开，0=关闭	远程启用/禁用感应功能
线路状态	`power`	布尔	1=通路/开，0=断路/关	控制所接灯具或设备通断

2.2 触发事件机制

当设备检测到状态变化时，会自动向平台推送消息

红外状态变化事件（infrared_detect）：当 infrared_target 从0变1或1变0时触发，上报当前有人/无人状态。这是实现实时响应的核心接口。
按钮按下事件（btn1）：用户手动操作设备上的按钮时触发，可用于本地调试或紧急控制。

2.3 可配置参数

设备内置Flash存储配置项，支持个性化设定

红外开机状态（infrared）：设备上电后是否启用红外感应。
有人触发持续时间（infrared_change_1）：检测到有人后，多久上报一次状态变化（可设立即/1秒/2秒/3秒/5秒）。
无人触发持续时间（infrared_change_0）：检测到无人后，延迟多久上报（可设30秒/1分钟/2分钟/5分钟/10分钟）。此参数对节能控制至关重要——延迟太短会导致灯频繁开关，延迟太长则浪费能源。
发现有人/无人时的线路动作（relay_change_1 / relay_change_0）：可配置为“打开/关闭/无动作”，实现感应到人时自动开灯。

设计：在社区楼道场景中，将 infrared_change_0 设为1分钟，relay_change_0 设为“关闭”，即人员离开后1分钟自动关灯，兼顾节能与用户体验。

三、接口对接技术方案

芯步开放平台提供HTTP API和MQTT两种对接方式，两者可混合使用。本方案以HTTP为主进行说明，适用于大多数Web/APP/SaaS项目。

3.1 接口认证机制

所有接口请求需携带签名（sign）和时间戳（ts），防止接口被恶意调用。签名生成算法

sign = MD5( MD5(AppSecret) + ts )

其中：

AppSecret：在芯步控制台“开发设置”中获取的开发者密码
ts：当前Unix时间戳（秒）
运算顺序：先将AppSecret进行MD5加密，得到的字符串后拼接ts，再对整个字符串进行一次MD5

代码示例（Python）

3.2 接收设备上报数据（消息推送）

该传感器为上行消息为主的设备——当检测到人体存在或状态变化时，主动向服务器推送数据。因此，消息接收是整条链路的起点。

配置自建消息服务器在芯步控制台“消息推送”设置中，配置您的服务器URL（如 https://您的域名/api/sensor/callback）。设备上报的事件将以HTTP POST方式发送到此地址。

消息格式示例（红外状态变化）

服务端处理逻辑

3.3 向设备下发指令（控制）

通过HTTP向设备发送控制命令，例如远程关灯、重启设备等。

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

请求方式：POST，Content-Type: application/json

请求体示例

上述命令将关闭该传感器所控制的线路（即关灯）。

完整调用示例（Python）

注意：接口返回200仅代表平台成功接收并下发指令，不代表设备已执行。如需确认执行结果，需监听设备的异步消息推送。

3.4 单设备控制 vs 批量控制

批量控制语法：在device参数中使用逗号或竖线分隔多个设备ID，一次最多支持100台设备。

此特性适用于社区整栋楼的统一控制，如夜间统一熄灯或应急联动。

四、典型业务场景实现

4.1 第一种场景：楼道节能照明（自动感应）

业务需求：人员进入楼道时自动开灯，离开后延时关灯。

实现方案

将传感器配置为“发现有人时线路动作=打开”（relay_change_1=1）
传感器硬件层面已可独立完成感应开灯，但需要云端记录日志
对接后，服务器监听 infrared_detect 事件，记录有人/无人状态及时间戳
可选：服务器动态调整 infrared_change_0 参数，如深夜时段延长关灯延迟至2分钟，提升安全感

联动逻辑图

传感器检测到人 → 设备本地自动开灯（毫秒级响应）
                ↓
              上报事件至云端
                ↓
              记录日志 + 统计人流
                ↓
        人员离开N秒后 → 自动关灯

4.2 第二种场景：安防预警联动

业务需求：非开放时段（如凌晨0-5点）公共区域监测到异常人员活动时，触发安防告警并联动摄像头抓拍。

实现方案

服务器接收 infrared_detect 事件，获取 infrared_target=1（有人）
判断当前时间是否在布防时段内
若触发告警条件：
- 调用第三方摄像头接口（如海康/大华SDK）进行抓拍
- 推送告警消息至物业APP或安保大屏
- 可选：向设备下发指令，打开声光报警器（若外接）

核心代码逻辑

4.3 第三种场景：人流热力图分析（数据运营）

业务需求：统计社区各公共区域不同时段的人流量，为物业资源配置提供数据依据。

实现方案

服务器持续接收 infrared_detect 事件
建立状态机：维护每个设备当前状态（有人/无人），以及上一次状态变化时间
当收到状态从“无人”变“有人”时，记录一次“进入事件”；反之记录“离开事件”
聚合数据生成按小时/日/周的人流统计报表

数据表结构

五、私有化部署与局域网方案

对于对数据安全要求较高的社区（如政府配套小区、高端住宅），芯步支持纯局域网私有化部署。

部署方式

设备通过WiFi连接社区内网的MQTT Broker（如EMQX、Mosquitto）
业务服务器同样部署在内网，订阅设备上报主题，实现数据不外流
控制指令通过内网MQTT发布，无需经过公网API

MQTT主题格式（私有化场景）：

设备上报：api/{AppID}/device/upload
控制指令：api/{AppID}/device/control

此架构的优势在于：断外网情况下系统依然正常运行，且数据完全由社区方掌控。

六、实施注意事项

6.1 设备安装位置规划

PIR红外传感器依靠检测人体移动产生的热辐射变化工作，视线直达是必要条件。在L形走廊、拐角区域，单一传感器存在盲区，需部署多台设备协同。

吸顶安装高度2.5-3.5米，探测直径约8米
楼梯拐角处应分别部署，避免共用
避免正对空调出风口、暖气片等热源，防止误触发

6.2 参数调优

根据实际使用场景调整 infrared_change_0（无人延迟上报时间）：

高频使用区域（如单元门厅）：30秒，响应快
低频使用区域（如地下车库通道）：2-3分钟，减少频繁上报
中间区域（如楼道）：1分钟为平衡值

6.3 故障处理机制

设备离线判断：若超过15分钟未收到任何消息推送，可判定设备离线，触发运维工单
消息去重：同一状态连续上报需做防抖处理，避免重复触发动作
执行结果确认：下发控制指令后，结合后续上报的状态变化确认执行是否成功

七、方案收益总结

维度	传统方式	对接后
照明控制	定时或常亮，年浪费电费显著	按需照明，节能30%-50%
安防响应	事后查看监控录像	实时告警，主动预警
运维效率	人工巡检故障	离线监测+自动工单
数据能力	无	人流热力、时段分布报表

通过芯步吸顶式智能红外感应开关的开放接口对接，社区公共区域可实现从“被动响应”到“主动感知”的转变，在降低能耗的同时提升安全等级与运营效率。