怎么接入壁挂式雷达存在感应器来实现定时状态上报_解决方案

CATALOG

芯步的壁挂式雷达传感器通过HTTP协议主动上报状态，要在此基础上实现“定时上报”，核心思路是在您的服务端设置定时任务，定期查询设备状态。以下方案会从设备能力、接口规范和代码实现三个层面展开。

一、技术背景与设备能力分析

在开始开发之前，请先确认您手中的硬件型号。目前的解决方案主要适用于 “智能人体存在雷达传感器2[壁挂]” （型号：UNI-CGQ-RT-L-BG2）。

该设备具备以下关键特性，决定了本方案的可行性：

通讯机制：设备通过 WiFi 2.4G 直连网络，无需网关，这意味着数据可以直达您的服务器。
上报机制：设备支持 “实时状态上报” 。通常，雷达传感器默认配置为“变化上报”，即仅当有人变无人，或无人变有人时，才会向服务器推送数据。
接口协议：开放平台提供标准的 HTTP 接口，这意味着您的服务器既可以被动接收数据，也可以主动下发指令（查询或修改参数）。

二、解决方案设计

为了实现“定时状态上报”，而不是仅在状态变化时上报，我们需要利用 “服务端定时轮询” 的策略。

核心逻辑：雷达传感器虽然不原生支持“定时主动推送”，但它支持 “即时状态查询” 。因此，解决方案是在您的云服务器上部署一个定时任务（Scheduler/Corntab），每隔设定的时间（如5分钟或1小时），主动调用芯步的HTTP接口，向壁挂雷达发送查询指令，读取当前是否有人、环境亮度或具体距离数值。

架构流程图：

配置阶段：在芯步控制台配置好设备，确保设备在线并已将数据上报URL指向您的服务器地址（http(s)://yourdomain.com/api/device/callback）。
定时任务阶段
- 您的服务器Cron Job触发。
- 您的后端服务向 https://api.thingboot.com/{AppId}/device/control/ 发起POST请求，携带签名。
- 下发命令 Order: {"radar_enable": 1} 或读取特定参数（查询命令）。
数据响应阶段
- 雷达传感器通过WiFi返回当前探测到的状态。
- 您的服务器接收数据，存入数据库，并打上当前时间戳。

三、具体实施步骤

第一步：环境准备与设备配网

在使用API之前，通常需要通过官方渠道完成设备的初始化。

注册与登录：访问芯步官网注册开发者账号。
获取凭证：登录后在“物联网控制台”获取您的 AppID（应用ID）和 AppSecret（开发者密码）。这些凭证将用于生成API请求签名。
设备配网：使用“芯步小程序”或“PC控制台”进行配网。
- 注意：手机的WiFi热点和现场WiFi必须为 2.4G频段 ，否则设备无法搜索到网络。
- 将设备配置连接到现场WiFi，并确保设备指示灯常亮（或规律闪烁）表示在线。

第二步：理解开放接口签名规则（鉴权）

调用芯步的HTTP接口或设置私有化服务器时，签名验证是安全的关键。所有请求都需要携带 sign 和 ts 参数。

签名生成算法：

sign = md5( md5(AppSecret) + ts )

ts：当前时间的Unix时间戳（秒级），如 1747212640。
AppSecret：您的开发者密码。
注意：签名必须小写，这是一个典型的“盐值+时间戳”MD5加密模式。

第三步：对接“定时查询”逻辑（核心代码示例）

为了满足“定时上报”，您不需要等待设备发数据，而是主动去要数据。我们将这个过程分为下发查询指令和接收数据两部分。

场景A：服务器定时主动查询（获取当前有人/无人状态）假设您需要每5分钟记录一次环境状态。您的服务器需要编写如下逻辑（以Python/Requests为例）：

import requests
import hashlib
import time
import json

# 配置信息
APP_ID = "您的AppID"
APP_SECRET = "您的AppSecret"
DEVICE_ID = "壁挂雷达的设备ID"  # 如 820720
API_URL = f"https://api.thingboot.com/{APP_ID}/device/control/"

# 1. 生成签名
ts = str(int(time.time()))
# 注意步骤:先加密Secret，再拼接时间戳，再整体加密
sign_str = hashlib.md5(APP_SECRET.encode()).hexdigest() + ts
sign = hashlib.md5(sign_str.encode()).hexdigest()

# 2. 构建请求参数
# 这里的关键是 order 命令。根据开放平台文档，查询雷达状态或保持雷达开启是 radar_enable
# 如果是查询存在状态，通常通过查询参数或下发特定读取指令，部分设备支持直接上报，若需强制读取，尝试下发空命令或标准查询。
# 注意:device/control 接口通常用于控制，如果只是要获取最新上报的数据，检查您的消息回调服务是否收到了新数据。
# 如果您强制想要设备马上回复"当前状态"，部分固件支持 radar_enable 带参，或者采用 MQTT 方式订阅。
# 此处演示主动控制逻辑，实际应用中，若设备支持读取参数如 {"get":"radar"}，请参考对应命令集。
order_data = { "radar_enable": 1 }  # 确保雷达模块开启，如果设备持续上报，此步骤可不做，直接依靠回调。

params = {
    'sign': sign,
    'ts': ts
}
headers = {'Content-Type': 'application/json'}
body = {
    'device': DEVICE_ID,
    'order': json.dumps(order_data)  # 注意文档中 order 是 JSON 字符串格式
}

# 3. 发起请求
response = requests.post(API_URL, params=params, headers=headers, data=json.dumps(body))

print(response.json())
# 返回示例: {"code":200, "msg":"ok", "data":{...}}

注意：上述代码主要演示了如何调用API控制设备。为了实现“定时上报”，更常见的做法是：

配置设备回调URL：在控制台设置您的服务器地址。
设备自动上报：当雷达探测到状态变化时，它会主动POST数据到您的URL。
定时任务记录：如果您需要定时记录（即使状态无变化），您可以在您的服务器上设置一个定时任务，直接将设备最后一次上报的状态写入数据库，而不需要每次都去“问”设备。

场景B：配置消息接收服务器（私有化部署）这是实现“上报”的最佳实践。您需要提供一个公网可访问或局域网的HTTP接口。

接收地址http(s)://您的域名/api/receive
设备行为：当有人进入（presence: 1）或离开（presence: 0）时，设备会立刻向该地址推送消息。
您的任务：在代码中解析JSON，获取设备ID和状态，存入MySQL/Redis。

第四步：数据存储与定时任务构建

既然设备能实时上报了，如何实现“定时状态上报”的需求呢？需求本质：用户希望有一个历史记录表，显示“14:00 无人”、“14:05 有人”。

实现方案

开启设备的实时上报功能。
在您的服务器端数据库中，不只在状态变化时存储，而是创建一个定时器（比如每5分钟）。
Timer触发：每当定时器到点，您的服务器就查询当前内存中存储的最后的设备状态，并将其记录到历史表中。

伪代码逻辑：

四、常见问题与调试

设备一直离线怎么办？
- 检查配网时输入的WiFi密码是否正确。
- 确认路由器未开启AP隔离，且WiFi名称为英文/数字（部分特殊字符可能导致兼容问题）。
- 确认WiFi频段是2.4G，而非5G。
为什么我只在有人/无人切换时收到数据，而不是定时收到？
- 这是正常的。该雷达传感器默认是“事件触发型”。如果需要强制定时数据，请遵循本方案第二部分（定时任务主动查询或定时记录最后状态）。
HTTP请求返回“5006 bad sign”
- 检查签名算法。注意是 md5(md5(APP_SECRET) + ts)，不是 md5(APP_SECRET + ts)。先打印出中间变量进行比对。
关于私有化部署
- 如果您的系统运行在纯内网，不连接外网，需要采购支持私有化部署的固件版本。芯步支持此类部署，此时API地址将指向您自己的局域网服务器地址。

五、总结

通过“壁挂式雷达存在感应器”实现定时状态上报，核心不在于改变硬件的行为，而在于软件逻辑的灵活适配。

硬件层：利用芯步开放的HTTP接口，确保设备快速配网及数据连通。
应用层：利用设备“状态变化实时推送”的特点，通过服务器端的定时任务/定时器逻辑，将“触发型数据”转化为“轮询型数据记录”。
优势：这种混合模式既节省了设备电量与网络流量（不需要高频无效上报），又满足了业务系统对时间序列数据的记录需求。