如何对接壁挂式红外雷达双鉴传感器来实现智能照明控制_解决方案

CATALOG

这是一个比较落地的场景。芯步的这款壁挂式红外雷达“双模”传感器（UNI-CGQ-RT-H-BG）很有意思——它自带一路继电器输出，实际上本身就能直接控制灯，但你问的是“通过开放接口对接”，说明你们想把判断逻辑放在自己的服务器上，或者要实现更复杂的联动（比如和别的设备配合）。下面我按这个思路来写。

一、我们先聊点“人话”：这个方案到底想解决啥？

兄弟们，咱们做技术的都知道，传统感应灯最大的痛点就是 “误判” 和 “灯下黑”。

普通的红外传感器，你坐在工位上码代码，稍微动作小点，它就以为没人了，“啪”给你把灯灭了，恨不得把你气死。或者大夏天的，空调吹个风，它又误以为有人，灯一直亮着，电费哗哗的。

咱们这次用的 芯步壁挂式红外雷达“双模”传感器，说白了就是 “红外+雷达” 双管齐下。红外负责看“有没有人形热量”，雷达负责看“有没有微动呼吸”。只有两个信号都判定没人，它才敢关灯。

而且，这哥们儿自带HTTP接口，这就好玩了。我们可以不用它的物理继电器硬接线，而是通过WiFi把数据传到你自己写的后端程序里，由你的代码说了算。

二、硬件在物理上怎么接？（看一眼就懂）

在聊代码之前，硬件接线其实特别简单，不过这里分两种玩法，看你需求：

1. 省事玩法（不写代码）：这传感器屁股后面自带了一路AC电源输出（继电器）。你把灯的零火线直接串进这个传感器里，然后在芯步的App里设置一下“有人接通/无人断开”。完事儿，收工。但这种不够“极客”，也不够灵活。

2. 高阶玩法（我们今天的主角）：传感器只负责“感知”，不负责“执行”。你把传感器挂在墙上，通上电（AC 100-250V，注意安全，这是强电！）。把灯的控制器（比如智能开关或交流接触器）单独留着。传感器通过WiFi告诉你的服务器：“有人来了”；你的服务器判断一下，再发指令给智能开关：“把灯打开”。

三、核心对接逻辑：数据怎么“飞”起来？

既然要写解决方案，核心就在于接口对接。芯步的开放机制其实很透明，主要分两步：设备上报 和 服务器下发。

1. 传感器怎么告诉你“有人”？（消息推送）

这哥们儿检测到状态变化时（比如从无人变成有人），会主动往你的服务器踹一脚（HTTP POST请求）。

你需要提前在芯步控制台设置好你的 “消息推送URL” （比如你服务器的API地址： http://你的域名/api/sensor/callback）。

传感器发过来的数据大概长这样（根据文档推测字段，实际以设备上报为准）：

你的服务器要做的事：收到这个请求后，你要写逻辑。

如果 human_body == true 或者 radar == true，说明确认有人。
只有当 两者都是 false（红外没人且雷达没扫到微动），才能判定无人。

2. 你的服务器怎么控制灯？（下发指令）

既然你判断完有人了，怎么开灯？这时候要用到芯步的开放API接口。

你得去芯步开放平台拿到你的密钥：

AppID：你的应用ID
AppSecret：你的开发者密码（别泄露出去）

然后，你需要调用 设备控制 接口。

接口地址（POST请求）：https://api.thingboot.com/{你的AppID}/device/control/?sign={签名}&ts={时间戳}

请求体（Body）：

四、要不要给你点代码片段？（以Python为例）

为了更接地气，假设你用 Flask（一个轻量级Web框架）写一个简单的接收程序，逻辑是：只要雷达或红外人有一个触发，就把灯打开；两个信号都消失持续30秒，再把灯关掉（这30秒延时是为了避免你翻个身灯就灭了）。

import hashlib
import time
import requests
from flask import Flask, request

app = Flask(__name__)

# 配置你的密钥 (在芯步控制台找)
APP_ID = "你的AppID"
APP_SECRET = "你的AppSecret"
# 灯的开关设备ID
LIGHT_DEVICE_ID = "智能开关的设备ID"

# 用来记录无人状态的计时器（生产环境会用Redis或数据库，这里简单写个内存字典）
presence_status = {}

def call_control_light(device_id, power_state):
    """下发指令控制灯的开关"""
    ts = int(time.time())
    # 签名算法:md5(md5(AppSecret) + ts)  具体看官方文档[citation:7]
    md5_secret = hashlib.md5(APP_SECRET.encode()).hexdigest()
    sign_str = md5_secret + str(ts)
    sign = hashlib.md5(sign_str.encode()).hexdigest()

url = f"https://api.thingboot.com/{APP_ID}/device/control/?sign={sign}&ts={ts}"
    payload = {
        "device": device_id,
        "order": {"power": 1 if power_state else 0}
    }
    # 发送指令
    response = requests.post(url, json=payload)
    print(f"控制灯光结果: {response.text}")

@app.route('/api/sensor/callback', methods=['POST'])
def sensor_callback():
    """接收传感器的上报数据"""
    data = request.json
    device_id = data.get('device_id')
    infrared = data.get('status', {}).get('human_body', False)
    radar = data.get('status', {}).get('radar', False)

# 只要有一个传感器检测到，就认为有人
    is_people = infrared or radar

if is_people:
        print(f"设备[{device_id}]检测到有人，开灯")
        call_control_light(LIGHT_DEVICE_ID, True)
        # 重置无人计时器（逻辑略，实际开发中可以用Redis存个标记）
    else:
        print(f"设备[{device_id}]检测到无人，等待30秒确认关灯")
        # 这里起个线程或设置定时任务，30秒后再去请求一次设备状态
        # 如果30秒内又收到"有人"，就取消定时关灯
        # 简单处理:直接关灯会太灵敏，增加延时
    return "OK", 200

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

五、给你几个高阶避坑（小贴士）

在实际项目实施中，我踩过一些坑，这几个小送给你：

关于““双模””的逻辑千万别写反了为啥要“双模”？因为红外容易被环境温度干扰（夏天车里热，红外可能失灵），雷达能穿玻璃但不怕温度。你的业务逻辑里，“判定有人”要用“或”逻辑，只要有一个触发就是有人；“判定无人”要用“与”逻辑，两个都说没人，那才是真的没人。
关于“掉线”问题这玩意儿是WiFi连接的，万一路由器重启了，它怎么重连？芯步的设备一般都有自动重连机制。但你在写服务器逻辑时，如果几小时收不到心跳包，给你的运维发个告警，别等客户投诉了灯不亮你才知道设备离线了。
安全性（签名机制）千万别在公网上裸奔。调用API时一定要按文档把 sign 算对。芯步用的是双重MD5加时间戳，主要是为了防止重放攻击。时间戳 ts 必须是中国时间戳，不然会报 5003 错误。
极速体验如果你觉得云端转发有点延迟（虽然官方说只有80-120ms），你可以看看芯步是否支持局域网通信。如果是本地部署的私有化版本，可以不经过云，直接在局域网里发HTTP命令，那响应速度就跟有线开关没啥区别了。

总结

把这套方案跑通之后，你得到的不仅仅是一个“感应灯”，而是一个智能照明的节点。

你可以随时在服务器上改逻辑，比如：“中午12点到1点午休时间，检测到关灯”、“下班后检测到人，不仅开灯还要给老板发个加班通知”。基于芯步这个开放接口，把传感器当作输入，把灯光当作输出，中间的逻辑全由你掌控。