PanWatch这个名字，是我去年折腾了大半年才跑顺的一个业余项目代号，全称可以理解为“Panorama Watch”——全景观察。起因特别简单：家里养了只猫，白天上班总担心它翻垃圾桶、乱啃电线，可市面上那些家用摄像头要么画质感人，要么云端功能要长期订阅，用起来总有一种“东西是租来的”憋屈感。于是我就想自己攒一套全景监护系统，把家里关键区域都覆盖进去，手机随时能看，异常了能通知我，所有数据存本地、不依赖任何厂商云。这套系统我做出来后顺手命名为PanWatch，前前后后踩了不少坑，也总结出一套可复用的搭建方案。这篇就完整分享一下PanWatch从需求拆解、硬件选型、软件链路到落地上线的全过程，适合想自己动手做家庭监控、宠物看护、小店安防的人参考，也适合对本地化视频服务、AI事件检测感兴趣的开发者。
1. PanWatch到底解决什么问题：设计思路的完整拆解
做这种系统，最容易犯的错误就是一上来先买设备、装App，等用了一周才发现画质不行、覆盖不全、告警乱响。PanWatch我在动手前先把需求一条条写在纸上，你只有知道自己到底要“看什么、什么时候看、多清晰地看”，后面选方案才不会翻车。
1.1 核心需求拆解：看得全、看得快、看得懂
先说“看得全”。家里不是一个平面，猫会去客厅、阳台、厨房，一个固定摄像头永远有盲区。市面上常见的云台摄像头虽然能转头，但它是单点机动，一次只能看一个方向，而且云台转动有噪音、有机械寿命问题，真正需要“同时掌握多个区域状态”的场景下并不合适。PanWatch要的是“全景”——进门的瞬间就想看到猫咪在哪个房间、有没有异常。
再说“看得快”。从发现异常到掏出手机，如果App冷启动要5秒、拉流要3秒，那猫早就从垃圾桶上跳下来了。所以低延迟是硬指标，目标是从事件发生到手机弹出通知控制在3秒以内，点开画面到看清内容不超过1秒。这个指标直接决定了后面是选RTSP还是WebRTC，也决定了转码层不能加太多。
最后是“看得懂”。光有画面还不够，得有“事件触发”能力。人不在家时，最关心的是“有没有异常动静”，而不是一直盯着静态画面。PanWatch需要做运动检测，甚至能区分“人影”和“猫影”。前两个需求决定硬件和架构，“看得懂”这一步决定了软件链路要引入什么AI组件。
1.2 全景方案怎么选：固定广角、鱼眼还是多路拼接
为了实现全景，我对比过三种路线。
第一种是单鱼眼摄像头。一颗180度甚至360度的鱼眼镜头确实能覆盖大空间，但画面畸变非常严重，边缘的人脸基本认不出，而且鱼眼镜头必须配合软件做畸变校正和PTZ电子放大，否则那画面看了就头晕。鱼眼方案适合“只需要知道大概全貌”的场景，比如会议室、店铺，但要看清细节就力不从心。
第二种是一个云台机做巡航。实时性差就算了，更关键的是云台来回扫的时候，经常在关键事件发生时恰好扫到别处，回放时只能看到“事后现场”，事件前因一概不知。
第三种，也是我最终选择的——多路固定广角摄像头 + 软件画面拼接。每个摄像头负责一个区域，用相对广角的镜头覆盖单面墙壁到对面墙壁，然后用算法把多个画面拼成一个全景视图。这样既没有云台的机械延迟，也没有单鱼眼的严重畸变，单路画面细节还能保持1080P甚至更高。缺点是需要多一路供电和布线，但家庭场景下这个成本完全可接受。
选型定下来之后，整体架构也就顺理成章。PanWatch分成三个层级：最底层是采集端，由多个摄像头组成；中间是边缘计算主机，负责拉流、转封装、录像、跑AI检测；最上层是客户端，包括手机App、浏览器和可选的小屏终端。这样设计的好处是摄像头的算力需求降到最低，所有难点集中到一台机器上，后续升级检测模型只需要动主机，不用动摄像头。
1.3 为什么不直接用现成家用摄像头：本地化的价值
其实市面上几百块的智能摄像头已经能看、能录、能报警，PanWatch的意义在哪？关键就在于“数据主权”和“功能可扩展”。云厂商的方案通常把视频流先传上云，再通过他们的服务器中转给手机，一旦断网或者厂商停止服务，设备就变成砖。而且很多家用摄像头存在隐私隐患，你永远不知道厂商在后端拿视频做了什么。
自己做PanWatch，所有视频流都只在局域网里传输，录像存本地硬盘，AI检测在本地边缘主机上完成，手机在家走局域网直接访问，出门才通过加密隧道连回家里。整个过程不依赖任何厂商的服务，设备生命周期完全掌握在自己手里。对于在意隐私、喜欢折腾的人来说，这种掌控感是无价的。
还有一点很实际：现成摄像头能做的只有“看”，而PanWatch这套架构能做的还有很多，比如联动智能家居开灯、识别特定声音报警、统计猫的作息规律。这些后续扩展只能靠开放平台和自建系统来实现。
2. 硬件选型与参数详解：我把踩坑经验都写在参数里
PanWatch的硬件清单并不复杂：若干广角摄像头、一台边缘计算主机、一台路由器、一块存储硬盘。但每一个选型背后都有讲究，我挑几个关键点说。
2.1 摄像头怎么挑：传感器比像素重要
很多人买摄像头只看“800万像素”“4K超清”，实际上对监控场景来说，传感器的靶面尺寸和低照度能力往往更关键。同样标称400万像素，1/2.5英寸的传感器和1/1.8英寸的传感器在暗光环境下的表现天差地别。PanWatch选的是1/1.8英寸传感器的型号，配合f/1.6光圈，晚上不开补光灯的情况下也能看到轮廓。
另外要注意的就是镜头角度。我实测下来，家用房间用2.8mm焦距的镜头比较合适，水平视野大概能到100度左右，一颗就能覆盖一面墙到另一面墙。焦距再短（比如1.8mm）视野更大，但畸变明显；焦距太长（比如6mm）透视感太强，近处物体一扑过来就像怼到脸上，观感非常不适。
支持协议方面，强烈建议买支持标准RTSP协议的摄像头，避开那些只有私有云协议的消费级产品。韩国的、国内的很多ODM摄像头都支持RTSP，价格在100元到300元之间，画质足够。ONVIF协议也建议支持，虽然实现上多一步，但方便以后接其他NVR软件。
2.2 边缘计算主机：树莓派、小主机还是NAS
PanWatch的“大脑”主机，需要同时跑流媒体服务、录像存储、AI检测，甚至偶尔还要转码，这个负载不低。我最初用的是树莓派4B，跑两个1080P的RTSP拉流和Frigate检测，CPU占用率一直在80%左右，夏天散热不好会降频，画面偶尔卡顿。后来换成了二手迷你小主机，配置是N5105处理器、8G内存、128G SSD，这套组合跑四路1080P加两路AI检测都很轻松，整机功耗才15瓦左右，电费几乎可以忽略。
如果你手上已经有群晖或威联通NAS，也可以承担这个角色，但注意NAS的基础CPU（比如ARM架构的）做AI推理会比较吃力，最好选x86架构、带核显的型号。核显在硬件转码方面优势很大，后面如果想做多路低延迟推流，绝对用得上。
2.3 供电与网络：最容易翻车的隐藏工程
摄像头供电我推荐用POE供电方案，也就是一根网线同时供网和供电，不需要在吊顶附近再留插座。但很多成品摄像头是DC圆头供电，要改造POE就得买POE分离器，或者直接用支持POE供电的摄像头型号。PanWatch用的三台摄像头走了POE交换机，每路预算多了几十块钱，但排线清爽很多，停电恢复后也能自动回来。
网络方面必须强调一点：有线和无线的可靠性差距巨大。之前偷懒用WiFi连接两台摄像头，结果微波炉一开，画面就马赛克甚至断流。无线2.4G频段在居住环境里干扰非常严重，5G频段穿墙又不行。所有固定摄像头一律走有线网线，边缘主机也接有线，只有手机在用无线。这样系统长期运行的稳定性才有保证。
存储盘我挂了一块4TB的监控级硬盘，叠瓦式的低价盘别买，一定要选CMR技术的监控盘，否则24小时连续写入下性能会逐渐劣化，半年后就开始掉速。写入量方面实测下来，4路1080P、连续录制的话，一天大概产生160GB到200GB数据，4TB大概能存20天，已经足够滚动覆盖了。
3. 软件链路核心实现：从RTSP拉流到手机弹通知
硬件只是骨架，PanWatch真正有意思的地方在软件。这一节我把“采集—转流—检测—通知”这条完整数据链路讲明白，并给出能直接抄的配置。
3.1 流媒体服务：用mediamtx统一管理所有视频源
摄像头本身有RTSP地址，但不同品牌的地址格式不一样，直接对接不方便，而且手机浏览器原生不支持RTSP播放。PanWatch在中间加了一层流媒体网关，我选定mediamtx（原rtsp-simple-server）。它非常轻量，支持RTSP拉流入、转成RTMP、HLS、WebRTC等协议出，还自带录制功能。
我主机上是用Docker运行mediamtx的，核心配置如下：
# docker-compose.yml 片段 services: mediamtx: image: bluenviron/mediamtx:latest container_name: mediamtx restart: unless-stopped network_mode: host volumes: - ./mediamtx.yml:/mediamtx.yml - /mnt/recordings:/recordings command: mediamtx mediamtx.ymlmediamtx的自定义路径配置非常灵活，可以把不同摄像头的RTSP源统一映射成有意义的路径名：
# mediamtx.yml 片段 paths: kitchen: source: rtsp://192.168.1.101:554/user=admin&password=xxx&channel=1&stream=0.sdp? livingroom: source: rtsp://192.168.1.102:554/stream1 balcony: source: rtsp://192.168.1.103:554/main这样客户端只需要访问rtsp://主机IP:8557/kitchen就可以看厨房画面，语义清晰，配置集中。后续加摄像头只需要在配置里加一行，不用改任何客户端代码。
3.2 多路画面拼接：用Motion Matrix实现“全景视口”
既然PanWatch追求全景，我需要把三个独立画面拼成一个统一视图。这块我用的是开源项目Motion Matrix，它可以把多个RTSP流接入同一个页面，以网格或自定义布局展示，还能做画面同步和低延迟控制。在浏览器里打开它的管理界面，添加各路流地址就完成拼接，不用写前端代码。
不过你要注意，画面拼接并不是简单地把三个视频并排摆。不同摄像头画面的亮度、色温、白平衡有差异，并排摆放会显得很割裂。Motion Matrix支持对每路画面做微调，我在配置里统一开启了弱光补偿，尽量让三路画面亮度接近。至于更复杂的“无缝拼接成一张长图”，目前实现成本太高，实际意义不大——人眼在监控场景里更习惯“分屏全景”，而不是一张没有任何边界的超宽画面。
3.3 事件检测：Frigate让“看得懂”成为现实
PanWatch的事件检测用的是Frigate，一个本地化AI监控NVR软件。它基于TensorRT和OpenCV的YOLO模型做对象识别，能区分人、猫、狗、汽车等，还能配置区域屏蔽和事件过滤。装它之前我试过字节跳动的Motion检测，但“有动静就报警”的体验太糟糕，窗外风吹树叶动一下都要弹通知；换成Frigate之后，只有检测到“人形”或“兽形”才告警，误报率大幅下降。
Frigate的Docker部署配置也分享一下：
# docker-compose.yml 片段 services: frigate: image: ghcr.io/blakeblackshear/frigate:stable container_name: frigate restart: unless-stopped privileged: true shm_size: "128mb" volumes: - ./config.yml:/config/config.yml - /etc/localtime:/etc/localtime:ro - /mnt/frigate_media:/media/frigate ports: - "8971:8971"Frigate的配置文件里，我把客厅和厨房的检测区域做了划分，只检测画面中的可控区域，屏蔽天花板和窗户区域：
# config.yml 片段 detectors: ov0: type: openvino device: CPU model: path: /openvino-model/ssdlite_mobilenet_v2.xml cameras: kitchen: ffmpeg: inputs: - path: rtsp://127.0.0.1:8557/kitchen roles: - detect - record objects: track: - person - cat zones: floor: coordinates: 0.1,0.1,0.9,0.1,0.9,0.9,0.1,0.9模型我用的是OpenVINO推理引擎下的SSDLite MobileNet V2，准确率不算顶级，但胜在CPU资源占用低。后面如果加装Intel的神经计算棒（NCS2），还能换YOLOv7模型，检测精度进一步上升而CPU占用基本不动。
3.4 告警通知：不看订阅制的云推送，自己写一个Webhook
Frigate检测到事件后，PanWatch需要把消息推到我手机上。我选择了自建微信推送通道——更准确地说，是借助一个开源的微信推送项目，通过Webhook把通知推到微信里。Frigate原生支持Webhook事件，配置非常简单，在config.yml里加上：
notify: enabled: true webhook: http://127.0.0.1:8080/notify?label={label}&camera={camera_name}&event={event_id} events: - person - cat我的1680端口跑着一个几十行的FastAPI小服务，收到Webhook后组装一条消息，转发给微信机器人接口。Frigate的Webhook模板里 {label} 和 {camera_name} 会自动替换成“person”和“客厅”，这样我手机收到的就是“客厅检测到人形目标，请查看”这样的一句话。
这里有个经验：一定要在通知里带上一个事件截图缩略图。从Frigate的事件快照接口拉一张JPEG图拼进推送内容，人眼判断是否需要处理的速度会快很多。如果只给纯文本通知，每次都得点进App看图，时间久了就懒得看了，告警也就不起作用了。
4. 完整部署实操：从零到稳定运行的5个步骤
下面就是PanWatch从零搭起来的具体流程。每一步都是我实际跑过的，按这个顺序走，半天时间就能稳定上线。
4.1 第一步：组网与设备固定IP
先把摄像头、POE交换机、边缘主机、路由器都接好，然后建议把摄像头和主机的IP固定下来。直接在路由器后台为每个设备的MAC地址绑定IP，比在摄像头系统里配置静态IP更好管理。PanWatch的规划很简单：摄像头从 .101 到 .103，边缘主机固定在 .10，之后所有软件配置都基于这组IP写死，不会出现设备重拨后IP漂移导致服务找不到源的问题。
组网完成后别急着装软件，先做一件事：用VLC播放器直接打开摄像头的RTSP地址，确认每路流都能出图、声音是否正常。此处排查掉编码、账号、传输协议的问题，后面软件层就会顺利很多。
4.2 第二步：部署流媒体与录像服务
在边缘主机上安装Docker，然后新建一个项目目录，把前面给的mediamtx配置和compose文件放进去，执行docker compose up -d即可。之后用FFmpeg做一次连通性测试：
ffmpeg -i rtsp://127.0.0.1:8557/kitchen -t 5 -c copy /tmp/test.mp4能正常生成文件，说明mediamtx拉流成功。同时我打开了mediamtx的录制功能，这样即使后续Frigate挂掉，原始录像还有一份兜底。
Frigate的config.yml里要注意设置record: retain的天数，比如保留7天就需要在媒体存储上预留足够空间。我实测发现Frigate的录制是按事件和连续录制两种模式走的，建议连续录制加事件标记，这样查找关键片段时不会漏，回放体验也流畅。
4.3 第三步：接入AI检测并调优阈值
Frigate部署好后，先让它跑24小时，不要急着开告警。这个阶段的任务是观察误报类型。我前三天收到的误报里，60%是门口光线变化造成的“虚拟人影”，40%是猫咪跳跃时被识别成“人形”。解决方法是调低检测灵敏度、增大最小检测帧数和置信度阈值。
Frigate里调节阈值有两个关键参数：threshold（置信度）和min_score（最小得分）。我把person类的阈值从默认0.5调到0.7，cat类从0.5调到0.6之后，误报明显下降。另一个技巧是给每台摄像头画好“detect zone”，把路过的光影区域排除掉，只保留下班回家必经的门口区域和猫活动频繁的猫爬架区域，这样既能满足异常感知，又把系统噪音降到最低。
4.4 第四步：客户端接入与远程安全访问
局域网内，手机浏览器直接访问 mediamtx的Web页面或 Motion Matrix的页面即可看全部分屏。但如果出门在外，还需要一个安全的远程方案。PanWatch的做法是在家里云服务器上部署一套反向代理，通过一条加密隧道把家里主机的流媒体端口映射到云端，手机上用这个云端域名访问。这样做法有几个前提：必须开启HTTPS、必须加访问认证、必须限制白名单；否则摄像头画面直接在公网裸奔，后果不堪设想。
反向代理我用的是Nginx，配置了一个带身份认证的location块，用户名密码用htpasswd生成。这里的核心原则是：远程访问的一切流量都必须加密，且绝不能把摄像头的原始RTSP端口直接暴露到公网。很多人的摄像头被恶意扫描到，就是因为默认端口和弱密码直接暴露在公网上。
4.5 第五步：开机自启与故障恢复
所有容器都配置了restart: unless-stopped，但为了应对极端情况，我在crontab里加了一条定时任务，每5分钟检查一次关键服务状态，发现死亡就拉起重启：
*/5 * * * * /usr/bin/docker ps --format '{{.Names}}' | grep -q 'frigate' || /usr/bin/docker compose -f /opt/panwatch/docker-compose.yml up -d这步做完，PanWatch才算真正进入“无人值守”状态。我出差一周，回家后发现猫跳上餐桌的一幕被完整录下来了，系统全程没有一丝卡顿，体验远好于预期。
5. 实际运行中的典型问题与排查技巧实录
再稳的系统也有各种小毛病。PanWatch运行的这半年里，我记录了一批典型问题，都整理成了一份速查表，遇到类似情况照着排查就能快很多。
5.1 画面卡顿、延迟忽高忽低怎么排查
卡顿优先查三个环节：网络、转码、存储写入。我遇到过一个问题：四路流全部开启录像后，画面延迟从1秒涨到5秒，边缘主机CPU占用超过90%，硬盘IO也接近饱和。最后一查，问题出在Frigate每路都要独立拉一遍RTSP源，等于同一路流被拉了三次（mediamtx转发一次、Frigate检测一次、录像再写一次）。这个问题的标准解法是让Frigate从mediamtx的统一入口拉流，而不是直连摄像头，减少摄像头侧的带宽压力。调整配置后，摄像头每路只需要输出一路流，CPU占用立刻降下来，延迟回到1秒内。
还有一类卡顿来自MicroSD卡回放或网络扫描——不过PanWatch没有用摄像头的内存卡，所有录像统一走边缘主机硬盘，卡顿基本被隔离在主机这侧，排查范围一下子缩小了很多。
5.2 夜间噪点多、画面涂抹感强
家用摄像头晚上不开补光灯时，画面往往全是噪点。我发现PanWatch里的三台摄像头里，两台在凌晨两点的画面基本没法看。起初以为是摄像头性能不行，试了几种参数后才发现是我把“夜视模式”设置成了“自动”但环境光在临界值附近来回跳变——一会儿切红外、一会儿切彩色，噪点反而比固定模式更严重。
我的解决方法：直接手动固定为“日夜切换”阈值，并打开“降低噪点”选项。如果不行就开启摄像头的“智能补光”，或者干脆在房间里加一个智能感应小夜灯，用环境光照亮而不是靠摄像头的红外灯。红外的寿命有限，距离也衰减严重，物理加光是最省事的方案。
5.3 画面畸变和心理适应问题
广角镜头边缘的线条会明显弯曲，门框、墙角都是弧形的，一开始自己看着都有点迷。好在固定广角的畸变是稳定规律的，可以用ffmpeg的lenscorrection滤镜做反畸变校正。我搞了个自动化脚本，每天夜里把前一天的录像重新跑一遍反畸变，生成校正后的回放版。代价是边缘部分会裁掉一圈，但整体观感自然很多。
不过畸变校正会引入额外算力消耗，不是必须，建议只在回放时开启，实时画面保持原始广角就好。居家环境看个全貌足够，为了“人眼舒适”牺牲太多清晰度得不偿失。
5.4 隐私与安全自查清单
最后这个话题要重点说。做一个家庭监控系统，最不能回避的就是隐私安全。我给自己定了几条铁律，也建议参考照做：
- 所有摄像头只在局域网内工作，禁止直接暴露公网。
- 远程访问只走加密隧道和HTTPS，并且启用强密码和IP白名单。
- 系统里的所有默认口令全部改掉，包括摄像头出厂密码和软件后台密码。
- 在处理视频时注意遮蔽相邻邻居、访客的面部，需要保存的视频素材不包含无关人员。
- 在自己家里安装监控前，一定要告知同住家人，在合法居住空间内使用，决不能用于任何窥探他人隐私的用途。
- 摄像头安装位置避开洗手间、卧室等私密区域，只覆盖公共活动空间。
技术本身是中立的，PanWatch的所有能力都应该用在保护自己家的安全和便捷上。在分享这些配置的同时，也必须一再强调：任何监控系统都必须建立在合法、透明、尊重隐私的前提之上。
结尾的小技巧与后续打算
PanWatch跑到现在，我最满意的一点是它已经把“监控”这件事从“偶尔看一眼”变成了“真正用得上的安全助手”。上个月我出差，家里保洁阿姨按约定时间来打扫，Frigate识别出人形并推送了通知，我点开视频确认是正常保洁后才放心，这种“人在外地、心里有底”的感觉，就是这套系统最大的价值。
如果学了这篇文章后也想搭一套，我唯一的建议是：第一步不要追求完美，先用最简单的两路摄像头加一个容器跑起来，把链路打通，再逐步加AI、加拼接、加告警。很多朋友一开始就规划七八路摄像头加多台主机，结果折腾一个月还没跑通，热情全耗完了。小步快跑，先让系统动起来，后续的优化都有方向。
PanWatch后续我还想加两个扩展：一是接入Home Assistant，实现“检测到人回家”自动开灯、开空调；二是训练一个针对猫叫声的音频检测模型，万一猫咪被卡住或者异常叫喊时也能及时知道。这些都是现有架构上自然生长出来的能力，也是自建系统最大的乐趣所在。希望这篇分享能给想折腾自己一套监控系统的人一些参考。
