如何二次开发壁挂式远程监测雷达烟雾传感器以实现定时状态上报_解决方案

CATALOG

芯步的这款壁挂式雷达烟雾传感器本身是事件触发上报的——有人闯入或烟感报警才推数据。但很多场景（仓库、机房）需要定期知道“设备还活着吗？环境正常吗？”。这篇方案写一下怎么通过二次开发实现定时状态上报，代码示例用Python，方便快速验证。

1. 为什么需要“定时上报”？

这款传感器本身是事件触发上报的——也就是说，只有检测到人、烟雾浓度超标、或者环境变化比较大的时候，它才会往你服务器推数据。

这就带来一个问题：如果一切正常，它就“沉默”了。你怎么知道它是真的正常，还是已经掉线、死机、被人拆走了？

所以，定时状态上报不是为了替代事件报警，而是做心跳监测和常态化数据采集。比如：

每隔5分钟报一次当前的烟雾浓度值（哪怕为0）
每隔1分钟报一次雷达探测状态（有人/没人）
顺便把电池电量、信号强度也带上来

这样你在后台就能清晰地看到：“哦，设备还在，一切正常”。

2. 整体思路

要实现这个功能，说白了就是让你的服务器主动“问”设备，而不是干等着设备“说”。

不过有个小问题：芯步的公开文档里，设备端似乎没有直接暴露“定时上报间隔”这个配置项。那怎么办？两条路：

方案A（推荐，更简单）：服务端主动轮询你写个定时任务（比如cron、Jenkins、或者代码里的定时器），每隔一段时间调用芯步的API，去查询设备状态或读取传感器数值。相当于你的服务器当“闹钟”，到点就去敲门。

方案B（更实时，但门槛稍高）：利用云平台定时任务芯步平台支持给设备创建定时任务，你可以设置每天早上8点让设备执行一次“状态自检并上报”。但这个依赖于平台功能，而且定制性可能不如自己写代码灵活。

我们今天重点讲方案A，因为：

完全可控，代码想怎么改就怎么改
不依赖设备固件是否支持定时上报
你甚至可以把数据存到数据库、画成图表、触发联动

3. 准备工作（很关键，一定要做对）

在写代码之前，你需要去芯步的控制台拿到三样东西：

AppID：你的应用ID，在“开发设置”里找
AppSecret：你的应用密钥，千万别泄露，跟密码一样重要
设备ID：就是那个壁挂传感器的ID，在设备列表里能看到，通常是一串数字，比如 1878

另外，你需要有一个公网可访问的服务器（或者内网穿透也行），用来跑你的定时脚本。不过既然是轮询，你的电脑只要能联网、能调API，就能跑，不一定要公网IP。

4. 最头疼的一步：签名计算（其实不难）

芯步的API用了双层MD5签名，看着唬人，其实逻辑很简单。官方给的规则是：

sign = md5( md5(AppSecret) + ts )

其中ts是当前Unix时间戳（秒）。

我用Python写个例子，你就明白了：

小提示：时间戳必须是你请求那一刻的秒级时间戳，并且前后误差不能太大（一般是5分钟内），否则服务器会认为签名过期。

5. 核心代码：实现定时状态上报

接下来我们写一个完整的脚本，它会每隔60秒去查询一次设备状态（这里以控制命令query_state为例，具体命令需要查你这款产品的“产品手册”）。

import hashlib
import time
import json
import requests
import schedule  # 需要安装:pip install schedule

# --- 配置区域 ---
APP_ID = "你的AppID"
APP_SECRET = "你的AppSecret"
DEVICE_ID = "你的设备ID"  # 比如 "1878"
API_BASE_URL = f"https://api.thingboot.com/{APP_ID}/device/control/"

# --- 签名生成函数 ---
def generate_sign(app_secret, ts):
    md5_secret = hashlib.md5(app_secret.encode()).hexdigest()
    sign_str = md5_secret + str(ts)
    return hashlib.md5(sign_str.encode()).hexdigest()

# --- 查询设备状态的核心函数 ---
def query_device_state():
    try:
        ts = int(time.time())
        sign = generate_sign(APP_SECRET, ts)
        
        # 构造请求URL
        url = f"{API_BASE_URL}?sign={sign}&ts={ts}"
        
        # 构造请求body（这里假设查询状态的命令是{"query":"state"}，具体请查阅产品手册）
        # 注意:不同产品的查询命令不一样，有的可能是{"radar_enable":1}之类的
        payload = {
            "device": DEVICE_ID,
            "order": {"query": "state"}  # ← 这里要替换成真实的查询命令
        }
        
        headers = {'Content-Type': 'application/json'}
        
        # 发送请求
        response = requests.post(url, json=payload, headers=headers, timeout=10)
        
        if response.status_code == 200:
            data = response.json()
            # 在这里处理返回的状态数据
            print(f"[{time.strftime('%Y-%m-%d %H:%M:%S')}] 设备状态上报成功")
            print(f"返回数据: {json.dumps(data, indent=2, ensure_ascii=False)}")
            
            # 你可以把数据存到数据库，或者做其他处理
            # save_to_database(data)
            # check_alerts(data)
        else:
            print(f"请求失败，HTTP状态码: {response.status_code}")
            
    except Exception as e:
        print(f"发生异常: {e}")

# --- 主程序:定时执行 ---
if __name__ == "__main__":
    print("启动壁挂式传感器定时上报服务...")
    
    # 立即执行一次
    query_device_state()
    
    # 每隔60秒执行一次（你可以改成300秒、600秒等）
    schedule.every(60).seconds.do(query_device_state)
    
    # 无限循环
    while True:
        schedule.run_pending()
        time.sleep(1)

6. 进阶玩法：不只是查状态

既然你已经打通了API，那能干的事情就多了：

1. 主动读取雷达和烟雾数值如果设备的查询接口能返回具体的传感器数值，你就可以把这些数据存到数据库，然后画个趋势图，看看一天中哪个时段人员活动频繁，或者烟雾浓度有没有缓慢升高的趋势。

2. 联动其他设备比如，你查到烟雾浓度超过阈值，马上调用芯步的另一个API，去控制智能插座断电、或者打开排风扇。这就是最简单的“联动规则”。

3. 心跳检测 + 离线告警如果连续3次定时查询都失败了（设备无响应），那基本可以判定设备掉线了。这时候你可以通过企业微信、钉钉、或者发邮件给自己报警。

7. 几个容易踩的坑

命令格式不对：不同产品的order命令不一样，有的需要传{"power":1}，有的是{"radar_enable":1}，还有的是{"query":"something"}。一定要去产品手册里确认，别凭感觉猜。
时间戳单位：芯步用的是秒级时间戳，不是毫秒。别拿new Date().getTime()直接除1000忘记取整。
签名大小写：MD5的结果通常是32位小写十六进制字符串。如果你的签名死活不对，检查一下是不是输出了大写，统一转成小写再试试。
轮询频率别太高：别设置成1秒一次。一是可能会被API限流，二是设备也没必要响应那么频繁。一般场景下，30秒到5分钟足够了。

8. 总结

通过服务端主动轮询的方式，你完全可以把这款“被动上报”的壁挂传感器，改造成一个“定时主动汇报”的可靠监控点。核心就是三件事：

学会签名（双层MD5，固定套路）
找到正确的查询命令（翻产品手册）
写个定时任务（cron、schedule库、或者Windows计划任务）

这样一来，你的后台不仅能收到烟雾报警这样的突发事件，还能定期知道“一切正常”，心里就有底多了。如果你的设备支持具体的数值读取，甚至可以在此基础上做数据分析和可视化展示，那就更专业了。