这两年我一直在折腾一套面向独居人群的健康监测系统也就是标题里的 Wellbeing Monitor。做这个项目的初衷很直接家里有老人、亲戚有独居朋友的人应该都有同感——你不可能24小时盯着他们但他们独自在家时万一摔倒、身体突发不适后果可能非常严重。市面上的解决方案不少但绝大多数走的是摄像头路线装在家里让人心理上非常抵触感觉像被监视。所以我做这套系统的核心思路从一开始就定死了Privacy-First隐私优先能不用摄像头就不用用非侵入式传感器完成看不见的守护。这套系统解决的核心问题是在老年人或需要关照的人群保持独立居住Independent Living的前提下让家人或远程照护者能及时获取他们的健康与活动状态并在异常发生时收到报警。它适合三类人参考一是正在为家中老人寻找远程照护方案的普通人二是做智能家居、边缘计算相关开发的技术爱好者三是对传感器选型和隐私保护设计感兴趣的从业人员。接下来我会把这套系统的设计思路、传感器选型、数据处理逻辑、踩过的坑全部拆开讲代码和配置都会给出来。1. 项目概述与设计思路为什么隐私优先不是可选项而是必选项1.1 独立居住场景的真实痛点独立居住听起来是一件好事——代表着自主、自由、不被打扰。但当对象换成老人或术后恢复期的病人时独立就意味着风险。跌倒后无人知晓、夜间离床后长时间未归、连续几天活动量骤降、室内温湿度异常这些情况在独居场景下都可能演变成严重事故。我查过不少养老照护的资料跌倒后若能在15分钟内得到救助后续康复难度会小很多但独居老人跌倒后长时间无法呼救的情况并不少见。所以这套系统的第一优先级目标并不是记录生活而是异常发现与及时告警。它需要做到的是日常不打扰异常时第一个通知到该通知的人。1.2 为什么摄像头方案会被否决最初做技术选型时方案一自然是摄像头加计算机视觉市面上不少产品也这么做。但深入想之后我把它彻底否掉了原因有三层。第一层是心理接受度问题。很多老人对摄像头极度敏感他们会觉得被盯着心理压力大甚至故意避开监控区域这反而让系统失去作用。我见过真实案例某户装了摄像头之后老人宁愿不去客厅活动只在卧室待着结果系统形同虚设。第二层是隐私边界问题。摄像头采集的视频数据一旦落盘无论是存储在云端还是本地都存在被泄露的风险。更麻烦的是即便系统做得再安全让家人随时可以调看视频这件事本身就会让照护关系变得紧张。第三层是数据处理成本。视频流需要持续解码、传输、存储功耗和带宽开销都不小对于一套需要24小时连续运行的系统来说不划算。所以我的决策很明确彻底的隐私优先放弃一切图像采集设备改用非视觉传感器完成全部监测。1.3 整体系统架构这套系统的架构可以拆成四层感知层毫米波雷达、压力传感器、环境温湿度传感器、门磁传感器 传输层本地蓝牙/Sub-GHz无线协议统一汇聚到边缘网关 计算层边缘网关完成数据预处理、状态识别、异常判定 触达层手机App/微信通知推送告警信息家人端不存储原始数据这个架构设计的核心原则是数据尽可能在本地处理只有告警事件和高度抽象的摘要信息才会外发。用一句话概括这个系统是一个会判断的传感器网络而不是一个会录像的监控系统。2. 核心系统拆解传感器怎么选、装在哪、为什么这么装2.1 传感器选型对比与取舍选传感器是整个系统最关键的一步。我给自己立了几个标准不采集图像、被动式或无线主动式感知、低功耗、适合长期部署、价格可控。最终锁定了四类传感器传感器类型探测能力数据特点装在哪毫米波雷达人体存在、微动呼吸引起胸腔起伏、运动轨迹点云/多普勒数据无身份识别能力房间顶角、床头侧上方压力床垫/压电薄膜床上有人与否、体动频率、呼吸/心率压电式可提取低频模拟信号需算法提取周期分量床垫下层环境传感器温湿度、甲醛/VOC空气状态数值型低频数据客厅、卧室墙壁门磁传感器门开关状态开关事件入户门、卫生间门在这几个传感器里毫米波雷达是核心它负责的是人在不在、在动还是不动、姿势是否异常这类最关键的信息。压力传感器是辅助它负责解决雷达在卧室场景下容易误判的问题。环境传感器管的其实是居住环境是否安全健康这个容易被忽视的维度。2.2 毫米波雷达的选型细节毫米波雷达分不同频段24GHz、60GHz、77GHz甚至更高。其中60GHz频段在人体存在检测和微动感知上表现最好因为这个频段的波长约5mm对人体体动、胸腔起伏这样的尺度非常敏感能检测到微米级位移变化。77GHz频段主要做车载距离测算更远但成本高在室内场景不划算。选雷达时看这几个参数探测距离室内单房间场景10米内足够不需要买几十米规格的。多目标检测支持同时跟踪3-4个目标比较理想因为家里可能同时有两个人或者一个人加一只猫。微动检测能力必须具备呼吸检测能力否则无法判断人躺在床上是否正常呼吸。接口形式优先选串口UART输出结构化数据的方便接入边缘网关。我用的是某国产60GHz毫米波雷达模块输出数据包括目标坐标X/Y/Z、运动速度、运动能量、存在状态以及微动的呼吸/心率估算。具体型号就不说了大家在选的时候按上面的参数对照即可价位在百元上下性价比很高。2.3 传感器部署位置与角度这一步是整套系统能否正常工作的关键。我试过好几个摆放方案把经验总结如下卧室场景雷达安装在床的一侧墙壁距离地面约1.5米到2米朝向床铺中心角度向下倾斜15到30度。这样既能覆盖床上区域也能覆盖床边的活动区域。注意不要正对头顶吹夏天会被误判也不要装在空调正对面。压力床垫传感器放在床垫和床板之间也就是床垫下面。如果床垫是弹簧床垫且很厚压电信号的灵敏度会下降建议优先选择薄的硬质床垫或棕垫信号质量会好很多。客厅场景雷达装在电视墙的一个角落斜向覆盖沙发和茶几区域。这个位置选起来有讲究如果正对窗户阳光直射和窗帘晃动会带来干扰如果正对阳台门人进出阳台时的速度变化容易把短暂出门误判成长时间不在。卫生间场景延展可选卫生间是跌倒高发场所但也是隐私敏感度最高的地方。我的方案是只在门口装一个门磁用来统计进入时长如果超过设定阈值比如20分钟自动提醒这算是一个折中但不失有效的方案。2.4 为什么多传感器融合能规避误判只用一个传感器的系统会在某些场景下产生严重误报。比如说毫米波雷达单独工作很容易把静止看书的场景判成无生命存在因为它的运动检测依赖多普勒效应——静止不动就几乎没有回波信号。这时候如果同时有压力传感器在位就可以用来纠正雷达认为没人但压力传感器显示床上有重量那必然是有人安静地躺着。反过来压力传感器单独也无法完成离床检测后的活动追踪。比如老人半夜起来去卫生间但中途在客厅停下坐着休息这个过程只有雷达能持续跟踪。所以我坚持一个原则关键场景至少双传感器覆盖核心判断由融合逻辑完成。3. 从传感器数据到状态判断边缘计算与行为基线3.1 数据处理流程传感器原始数据来了之后不能直接拿来做判断先要经过一个标准化的处理管道数据清洗去除明显异常值比如雷达瞬时速度跳变到10m/s这种物理上不可能的数据对缺失值做插值。事件提取从连续数据流中切分出人物进出房间从床上起身坐下这样的事件。状态识别判断当前室内的人物状态是稳定存在活动离床无存在等。异常判定将状态序列与历史行为基线对比输出告警。在边缘网关上跑这套流程我用的是一块低功耗的ARM开发板CPU占用常年维持在40%以下功耗约3瓦。整机24小时运行的耗电量完全可以接受和路由器差不多量级。3.2 行为基线的建立与更新机制所谓行为基线是指某个居住者正常生活状态的数字画像。独居老人的日常通常非常有规律几点起床、几点做饭、几点出门遛弯、晚上几点上床这些都可以从传感器事件流中自动统计出来。基线建立的算法并不复杂但要做得稳健。我采用的办法是持续采集7天数据按星期对齐周一对比周一、周末对比周末对每个时间段按15分钟为单位切片分别计算活动量均值和存在概率。这样沉淀下来的基线能反映一个人比较真实的日常节律。值得注意的是基线需要动态更新。老人今天可能因为亲戚来访打破了作息明天可能身体不适整体活动量下降了20%。所以每过一周我会用新的数据以指数加权方式更新基线让模型缓慢跟随真实生活节奏而不是死死卡在最初7天的画像里。这部分我贴一段简化后的Python代码展示活动量统计和基线更新的逻辑import numpy as np from collections import defaultdict # 按15分钟切片统计活动量 def compute_activity_volume(events, window15): slices defaultdict(float) for evt in events: minute_idx (evt[timestamp].hour * 60 evt[timestamp].minute) // window slices[minute_idx] evt[motion_energy] return dict(slices) # 更新行为基线指数加权 def update_baseline(old_baseline, new_day_activity, alpha0.3): updated {} for slice_idx in old_baseline: if slice_idx in new_day_activity: updated[slice_idx] (1 - alpha) * old_baseline[slice_idx] alpha * new_day_activity[slice_idx] else: updated[slice_idx] old_baseline[slice_idx] * 0.98 # 时间衰减 return updated这种设计的好处是系统会越用越贴近居住者的真实生活。一个刚做完手术、正在恢复的老人前几天的活动量基线偏低但系统会随着他康复进程逐渐拉高的活动量自适应地更新判断阈值从而避免长期把年轻时的状态作为标准而产生误报。3.3 异常事件分级与决策逻辑异常不能一视同仁地处理。我把异常分成了三个等级对应不同的告警方式等级触发条件告警方式紧急检测到跌倒、呼吸信号消失立即推送电话/短信通知所有紧急联系人关注离床超30分钟、长时间未活动如白天持续4小时无任何活动事件推送App通知提醒家人查看摘要状态提示连续多日活动量下降超过30%、室内温湿度异常每日摘要汇总不单独打扰这样分级的原因是如果所有事件都走紧急通道系统会造成狼来了效应最后反而没人认真对待告警。真正值得立刻打电话的其实只有跌倒和呼吸消失这两类。跌倒检测的实现逻辑我单独说一下。雷达检测跌倒并不直接看坐标而是看目标的运动速度和加速度特征。人体从站立到跌倒整个过程约0.3到0.8秒特征是先有一个竖直方向的快速位移然后是水平方向的突然加速最后是运动能量骤减到接近零倒地后静止。我的判定逻辑伪代码如下def detect_fall(track_history): # 提取最近2秒内的轨迹点 recent track_history[-20:] # 计算垂直方向速度 v_z compute_vertical_speed(recent) # 计算水平加速度 a_xy compute_horizontal_acceleration(recent) # 计算运动能量衰减比 energy_ratio final_energy / peak_energy if v_z -0.8 and a_xy 1.2 and energy_ratio 0.15: return FALL_DETECTED return NO_EVENT这个阈值组合我实测调了很久用一个假人在房间里模拟跌倒和正常弯腰拾物两种动作反复测试后确定的。注意单纯看一个指标容易误判比如蹲下捡东西也会有垂直速度但它没有明显的水平加速和能量骤减而跌倒三者同时具备的特征非常独特。4. 隐私保护设计不是事后加密而是从根上不采集4.1 隐私设计的三条底线讲到隐私优先很多人第一反应是数据加密存储。这远远不够。我理解的隐私优先要守得住三道关口第一采集端去身份化。雷达输出的是坐标点云和运动能量不是图像天然不包含面部信息。压力传感器输出的是重量和体动信号也无法识别身份。这是数据源头上的隐私。第二传输与存储的本地化。原始数据只存在于边缘网关内部不向任何外部服务器传输。家里有没有路由器、能不能联网系统都能独立工作。告警信息外发时也是经过摘要化、脱敏后的文本。第三数据处理流程的透明化。家人端能看到的不是原始数据而是今天活动量正常晚间睡眠质量良好这类语义化描述。如果需要溯源提供的是事件时间线而非原始信号。三条底线缺一不可。我见过一些主打隐私的智能硬件采集端做得干净但数据还是要传到云端做分析这就等于把隐私又交了出去。所以我的边缘网关上直接跑推理模型只有最终判定结果有权限出网关。4.2 数据脱敏与语义化输出在边缘网关内部原始数据保留时间我也做了限制默认只保留48小时之后自动清理。这样即便网关设备被物理拿走了对方能看到的也只有最近两天的数据历史画像不会泄露。关于语义化输出这块我举一个实际例子。有一次系统检测到某位独居老人连续三天夜间频繁离床每次离床都伴随较高的运动能量但持续时间很短。雷达无法知道这个人在做什么于是输出的摘要信息是“近三天夜间离床次数较基线增加约40%每次离床平均时长约4分钟建议关注是否有夜间如厕困难或不适。”这样的描述透露给了家人足够多的信息来做出判断却没有过度窥探私密生活。这在伦理上很重要——监测的目的是守护安全不是把人的生活摊开给家人看。4.3 通信安全设计即使系统坚持本地化告警信息总要走外部网络这部分的传输安全也要做到位。我的边缘网关与外发通道之间使用TLS加密通信服务端只接受结构化的JSON事件不接收任何文件上传。事件体里的意识性字段做了模糊化比如位置信息只包含卧室客厅这样的语义标签不带精确坐标。另外敏感数据在网关存储时使用AES-256加密密钥由硬件唯一标识派生不固化在代码里。这样即使有人取出存储芯片也无法直接读出明文数据。4.4 被监测者的关闭开关隐私保护还有一个容易被忽略的维度——被监测者本人的掌控权。我在系统里专门做了一个实体按钮和网关通过蓝牙连接按下之后就进入“隐私模式”所有传感器暂停采集系统只保留最基本的门磁事件。这个按钮的物理特性很重要因为老人可能不太会用App但他们肯定能找到并按下床头的那个红色按钮。从实际反馈来看这个按钮的存在大大提升了老人对系统的接受度。知道系统的开关捏在自己手里心理戒备会明显降低这反而是让系统最终能被长期开着的一大原因。5. 实操过程记录部署一个房间的完整步骤与参数选择5.1 硬件清单与接线我以部署一个标准卧室加客厅的场景为例列出完整的硬件清单和实际安装参数。设备数量说明毫米波雷达模块2个客厅1个、卧室1个压力床垫传感器1个床垫下方环境温湿度传感器2个客厅、卧室各1个门磁传感器2个入户门、卫生间门边缘网关ARM开发板1台负责数据汇聚和推理电源与网线若干强电供电网线连局域网接线方面雷达模块通过串口转USB接入边缘网关压力传感器通过ADC引脚输入环境传感器用I2C接口读取门磁通过GPIO中断方式接入。这里有个经验之谈所有传感器务必用屏蔽线连接特别是压力传感器的模拟信号线否则旁边有开关电源时信号会被工频干扰淹没。5.2 网关配置与数据采集边缘网关系统使用精简版的Linux发行版我在上面跑了一个容器化的服务栈。采集服务用Python编写通过串口轮询读取雷达数据每100毫秒取一次最新状态环境传感器每5分钟采集一次数值门磁触发时立刻产生事件。# 雷达数据读取示例伪代码保留核心逻辑 import serial ser serial.Serial(/dev/ttyUSB0, 115200, timeout0.1) def read_radar(): line ser.readline() if not line: return None parsed parse_radar_frame(line) # 根据协议解析 return { targets: parsed[target_list], exist: parsed[presence], motion_energy: parsed[energy] }采集到数据后先落本地SQLite数据库每5分钟做一次聚合原始数据仅保留48小时自动清理。同时推理服务订阅数据库的实时事件流当目标状态出现跳变比如从无目标变为有目标时触发状态机更新。5.3 告警推送链路告警推送我用的是现成的消息推送服务在网关上写一个HTTP回调即可。关键是告警的时效和分级因为我发现推送链路上最耗时的往往不是网络而是判定逻辑的犹豫。我的经验是**跌倒检测必须快宁可误报之后再取消也不能漏报后迟迟没有反应。**所以跌倒类告警采用两级确认机制第一级触发后立即推送给紧急联系人同时系统进入10秒的待确认状态如果10秒内雷达还能检测到目标的任何动作哪怕是指尖微动自动撤回告警如果10秒内完全静默告警保持并升级为电话通知。这套先报再撤的设计在实际测试中极大提升了响应速度。有个细节值得注意误撤的告警不要完全静默删除而是以误触发事件记录到日志里方便统计雷达参数是否需要重新标定。5.4 算法参数标定过程传感器数据再干净如果算法阈值不合身判断就会歪掉。标定过程分三步第一步静态背景标定。人离开房间后记录雷达在安静状态下的基线噪声水平我测试的房间大概有0.3到0.6m/s的噪声地板把它作为判断目标是否存在的底噪阈值。第二步单人行为样本采集。让被监测者或者志愿者在房间内完成一组标准动作站立、坐下、行走、躺下、从床上起身、模拟跌倒。每个动作重复20次用来收集该环境下的信号特征分布。第三步阈值微调。把第二步采集到的数据跑一遍判定逻辑查看误报率和漏报率。如果跌倒判定有多次漏检就把加速阈值调低如果正常动作频繁触发误报就提高能量衰减比的门槛。这一步通常需要一两天的迭代才能调到最优。6. 常见问题与排查技巧实录6.1 雷达把家里的宠物判定为目标这是最常遇到的问题。猫狗在雷达眼里就是一个持续运动的小目标会干扰房间内是否有人的判断。我试过通过目标体积过滤但不同宠物体型差异大效果不稳定。最终的解决思路是把雷达的目标坐标和微动数据结合起来看。宠物的胸腔起伏幅度远小于人类呼吸频率也快得多犬类约每分钟15-30次猫约20-40次而人类正常呼吸频率只有12到20次。通过频率特征区分人宠准确率能到九成以上。如果家里还有一只大金毛那就老老实实再接一路红外传感器辅助判断吧。6.2 离床判断延迟设置不当导致的夜间误报压力床垫传感器的离床判断我最初设置的延迟是30秒意思是压力消失超过30秒才判定离床。结果有一晚系统在凌晨3点误报了一次——原因是老人翻了个身身体大面积离开传感器区域压力值短暂掉到了阈值以下。把这个延迟调到60秒后误报就消失了但另一个问题出现了如果老人真的起夜离床动作明明发生了系统却要等60秒才确认现场状态。后来我把方案改成压力消失10秒后先进入疑似离床状态雷达检查卧室区域内是否有站立目标如果雷达确认目标已离开床直接判定离床如果雷达没有发现目标保持疑似直到60秒超时。双传感器交叉确认既保留了快速响应又过滤了翻身造成的假离床。6.3 雷达误把人对着墙壁站着的状态识别成无活动人如果靠墙站着不动雷达的运动能量输出会很低可能被判定为稳定存在但无活动。这个状态本身无害但如果持续好几小时且中间还有动静就可能触发长时间无活动的误告警。排查后发现根因是雷达安装角度过平导致目标靠近墙边时信号从雷达天线侧面漏过。把雷达的俯仰角从10度调整为20度后这个问题基本消失。如果你的安装角度已经固定可以额外加一条逻辑如果检测到目标存在但长时间无活动同时压力传感器和门磁也没有任何事件系统自动延长确认时间避免因为目标贴墙站着看书这种场景打扰家人。6.4 环境传感器温漂引起的异常告警环境传感器冬天靠近暖气片时温度数据会周期性波动有一次系统判定客厅温度异常波动并推送了提示但其实就是暖气自动恒温导致的小幅变化。后来我加了一条规则只有温度在短时间内快速变化超过5度且持续超过10分钟才触发告警同时对数据做2小时滑动平均后再与基线对比。6.5 传感器定期自检任何一种传感器都会老化毫米波雷达的灵敏度、压电薄膜的贴合度都可能衰减。我开发了一个每月自动执行的自检脚本在固定时间让系统发送一条低强度雷达波检测回声是否正常同时提示家人去按一遍压力床垫传感器观察数据曲线是否良好。如果某个传感器连续多次无响应系统会在每日摘要里明确标注某传感器需人工检查这条规则买不了安心但至少不会让设备悄悄失效而不自知。7. 实测中的真实体会与后续可以做成的方向这套系统在我的测试环境里已经连续运行了半年多经历过三次比较严重的误报修复也经历过一次实际有效告警——某次测试中志愿者模拟夜间跌倒系统在3秒内就识别并推送了告警这个速度对我来说是关键指标。我个人的最大体会是**Privacy-First的理念不是限制了系统能力反而推动我找到了更适合场景的技术路径。**摄像头方案看似简单但引入的隐私、存储、带宽问题会让整个系统复杂好几倍。非视觉传感器虽然处理起来更有挑战但换来的信任感是摄像头永远给不了的。老人愿意长期佩戴、家人愿意长期使用这才是这类系统真正能落地的前提。如果有人想在此基础上继续扩展我觉得有两个方向很值得探索。一是把睡眠质量的深层分析做进压力传感器算法里目前压电信号里包含了呼吸和心率的信息理论上可以区分睡眠分期但这需要先积累足量标注数据。二是把多房间部署的传感器数据联动起来比如检测到老人从卧室到卫生间再结合卫生间门磁时长做浴室滞留过长的专项提醒。这需要引入房间级的轨迹跟踪建模数学上比单房间判断复杂不少但对实际照护价值很大。另外如果你也是因为家里有老人而想做这类项目我建议第一套别追求齐全先做卧室加客厅两个房间传感器只买雷达和压力垫两个跑通告警链路后再逐步加装。一口吃不成胖子但试着把第一步走扎实这套系统就能在生活里真正发挥作用了。