ericwyuan
80b2fcc40c
fix: 视频时间语义修正 — 绝对时间戳偏移换算 + mtime 起点修正 + 直传超时
...
三处时间语义 bug(时区统一排查的延伸发现):
1. NVIDIA 集锦偏移语义: frame_timestamps 是绝对时间
'YYYY-MM-DD HH:MM:SS'(当日秒 77474s)被直接当视频内偏移用,
seek 超出 30 分钟视频 → 0 帧 → 集锦恒为空 → 视频模式永远降级。
修复: analyze_video 增加 event_start_time 参数,偏移 =
帧时间 - 视频开始时间(跨午夜 +86400);orchestrator 两处
调用点透传。另加 ffprobe 时长过滤跳过超界片段(日志明示),
fps=15 统一 CFR 输出。
2. NAS dispatcher event_start_time: 原用文件 mtime(=录制结束
时刻),真实开始时间应为 mtime - 视频时长,事件时间整体偏移
一个视频周期(~30min)。新增 _probe_duration 用 ffmpeg 解析
Duration(NAS 无独立 ffprobe)。
3. 直传超时: 压缩后 ~19MB 略低于 20MB 分块阈值走直传,
timeout(10,120) 在 1Mbps 下传 19MB 需 ~152s 必超时(task 42
三连败 FAILED)。加大到 (10, 300)。
测试数据陷阱记录: 两轮 0KB/9.47s 集锦异常均为测试时间戳超出
视频时长所致(1801s>1800s),单输入/多输入 concat 行为本身正常。
2026-08-20 17:58:16 +08:00
ericwyuan
3817609d1b
docs: update PROGRESS.md - 时区统一北京时区修复
2026-08-20 17:42:35 +08:00
ericwyuan
795e8acc6c
fix: 时区统一北京时区 — Edge(UTC机器)三处时间处理修复
...
背景: Oracle Edge 机器为 UTC 时区,NAS 与视频均为北京时间,
网页要求统一北京时区。排查结论: NAS 端(北京时间)与 UI(直读
MariaDB)均正确,问题集中在 Edge 端三处。
1. queue_manager: 7 处 datetime('now','localtime') 在 UTC 机器上
写入 UTC 时间(比北京慢8h),全部改为 datetime('now','+8 hours')
2. preprocessor.compute_timestamps: event_start_time 缺失时 fallback
datetime.now() 用了 Edge 本地时间(UTC),改为北京时间
datetime.now(timezone(+8h));带时区的 ISO 输入统一转北京时间
3. nvidia_adapter._ts_to_seconds: 不支持生产格式
'YYYY-MM-DD HH:MM:SS'(split后int抛ValueError全部返回-1),
导致集锦视频永远为空、视频模式永远降级逐帧——上一轮引入的
bug,测试用 HH:MM:SS 格式未暴露。现支持两种格式;drawtext
标签与提示词同步为完整时间戳说明
数据修正: event 17(task 298 手动测试缺 event_start_time)的
frame_timestamp 全为 UTC,按视频文件名真实时间(04:34:10)重算;
Edge 队列存量时间戳 +8h。
验证: 单测三例通过(生产格式解析/fallback北京时间/ISO带时区转换);
task 41 新代码正确写入北京时间 17:36:52。
2026-08-20 17:41:59 +08:00
ericwyuan
4553ec6f07
docs: update PROGRESS.md - NVIDIA原生视频输入切换调研与实现
2026-08-20 17:22:08 +08:00
ericwyuan
55633d3302
feat: NVIDIA 切换到原生视频输入 — nemotron-3-nano-omni + 集锦视频单次调用
...
调研结论: build.nvidia.com 免费托管 API 上 video-llama3-8b 与
qwen2.5-vl-72b 已下线(404),nvidia/nemotron-3-nano-omni-30b-a3b-reasoning
可用(200, 40RPM 免费额度内),原生支持 video_url 输入(MP4 base64)。
实现:
1. nvidia_adapter 新增 analyze_video: 按关键帧时间点截取 ±1.5s 片段
(drawtext 叠加时间戳,连字符避免冒号转义)拼集锦视频,640 宽 CRF28,
base64 后经 video_url 单次调用,输出全 schema JSON(frame_details +
global_summary + entities_json)并归一化对齐时间戳
2. analyze_frames 保留为无视频文件时的降级路径; chat max_tokens
512→2048(reasoning 模型 token 消耗大); timeout 20→120s
3. orchestrator.run_visual_analysis 增加 video_path 参数,fallback 循环
对支持 analyze_video 的适配器优先走视频模式,失败自动降级逐帧
实测(360MB 测试视频, 3 关键帧): 集锦 107KB, 全程 37s, 动态动作识别准确
(走动→坐沙发→坐餐桌),跨片段综合摘要正常 — 显著优于旧逐帧静态识别。
2026-08-20 17:21:33 +08:00
ericwyuan
8a62c46194
docs: update PROGRESS.md - Gemini视觉解析排查结论+业务全流程图
2026-08-20 16:15:28 +08:00
ericwyuan
f4e742481d
fix: json_parser 不再要求模型输出 compute_provider — Gemini 有效响应被误杀
...
根因: validate_schema 把 compute_provider 列为必填并校验非空数组,
但提示词模板从不要求模型输出该字段(它是 orchestrator 在解析成功后
自行填充的内部记账字段)。Gemini 返回完整合法 JSON 时被误判解析失败,
100% 复现。NVIDIA 走单帧轻量解析绕过了该校验,故此前仅 Gemini 受影响。
修复: compute_provider 从必填清单移除,缺失/非法时归一为空数组,
由 format_cloud_result 用实际成功的 provider 覆盖填充。
验证: 单元测试模拟 Gemini 真实输出(无 compute_provider + markdown
fence 包裹)解析通过。
2026-08-20 16:14:27 +08:00
ericwyuan
a2554c9df0
docs: update PROGRESS.md - 视频上传问题根因(网络+逻辑双叠加)与四项修复
2026-08-20 15:36:35 +08:00
ericwyuan
8cb5553beb
fix: Edge端三处修复 — API key丢失致全模型失败 + 失败结果黑洞 + 重派发死锁
...
根因: Edge服务手动重启未source .env,GEMINI/NVIDIA key丢失,
所有视觉模型调用失败("All models failed"),且失败结果永不回传NAS。
1. config_loader: 启动时自动加载.env(export KEY=VALUE),已存在环境变量不覆盖
2. queue_manager.enqueue: FAILED(或已交付SUCCESS)行重置为PENDING复用重跑,
修复 INSERT OR IGNORE + UNIQUE(nas_task_id) 导致的静默忽略死锁
3. get_undelivered_results: 包含FAILED状态,/results构造failed负载,
NAS Poller可感知失败避免僵尸循环空转重传
4. ddl.sql: failure_stage ENUM 增加 'process'(与db_layer valid_stages对齐),
修复 pymysql DataError 1265
验证: task 293(压缩后22MB) NVIDIA降级分析成功→event_id=13;
task 295 全链路成功→event_id=14;NAS端ENUM已同步ALTER
2026-08-20 15:35:40 +08:00
ericwyuan
203b076783
feat: NAS端FFmpeg预压缩 — 根治360MB视频跨境上传超时
...
根因诊断(网络问题,非代码逻辑):
- NAS(中国移动) → Oracle(美国Phoenix) 跨境上行带宽实测仅 0.5-0.9MB/s 且波动大
- 下载方向 3.0MB/s(非对称,典型国际出口拥塞)
- Tailscale P2P: ping 可通(224ms)但持续数据流被阻断(0 B/s, 127s超时)
- 360MB 原始视频上传需 10-20min,任何大分块都会超时
NAS dispatcher:
- 新增 _compress_video: 480p/CRF28/veryfast,静态监控场景实测 ~36x 压缩比
(360MB → ~12MB,上传时间 20min → ~30s)
- ffmpeg 自动探测: CodecPack ffmpeg41(带libx264) > /usr/local/bin > PATH
(Synology 系统 ffmpeg 被裁剪,无 h264 编解码)
- scale 两级滤镜: force_original_aspect_ratio=decrease + trunc(iw/2)*2
(h264 要求偶数尺寸,853x480 会报错)
- 压缩缓存 /tmp/fam_compressed/task_{id}/,源文件未变则重试复用,TTL 24h
- 压缩完成后重置 PROCESSING 状态(重置 stale 回收计时基准)
- 压缩失败回退原始文件分块上传
- _query_uploaded_chunks 失败时记录日志(原静默失败导致全量重传无感知)
Edge api_gateway:
- fix: total_chunks 变更清理旧分块后同步重写 meta.json
(原 bug: meta.json 不更新导致每块上传都触发清理,删除同批新分块死循环)
config:
- stale_timeout 600→1800(覆盖压缩+上传+Edge队列积压总时长)
- 新增 ffmpeg_path / compress_timeout 配置项
2026-08-20 14:59:50 +08:00
ericwyuan
a9a1b1dda5
docs: update PROGRESS.md - 串行上传+5MB分块+看门狗+chunk_size防护
2026-08-20 14:20:00 +08:00
ericwyuan
5915cf4be3
fix: 分块大小减至5MB + Edge端chunk_size变更自动清理 + 断点续传防护
...
NAS dispatcher:
- CHUNK_SIZE 10MB→5MB(~1Mbps上行带宽下可靠传输)
- chunk上传timeout (30,120)→(60,180)(增加连接和读取余量)
- _query_uploaded_chunks 返回 (set, edge_total) 元组
- expected_total != edge_total 时跳过断点续传(防止chunk_size变更导致文件损坏)
Edge api_gateway:
- upload_chunk 检测 total_chunks 变更,自动清理旧分块
- 防止不同chunk_size的旧分块与新分块混合导致assemble后文件损坏
2026-08-20 14:18:29 +08:00
ericwyuan
d6054de060
fix: 分块大小减至10MB + 上传失败确认机制 + 重试前置检查
...
- CHUNK_SIZE 20MB→10MB,CHUNK_THRESHOLD 50MB→20MB,降低单次超时概率
- 新增 _query_uploaded_chunks 独立方法,connect timeout 10s→30s
- 分块上传失败后查询 Edge 确认是否实际收到,避免响应丢失导致不必要重试
- 补全 uploaded_set.add(idx) 防止重复上传已成功分块
- _poll_once 中前置 retry_count 检查,超限任务直接标记 FAILED
2026-08-20 13:55:59 +08:00
ericwyuan
881ea3f470
fix: dispatcher 串行上传 + 看门狗自动重启 + 线程状态真实检测
...
- Dispatcher limit=10→1: 一次只传一个视频,传完再传下一个
- 退避缩短: min(30*(n+1),300)s → 失败后更快重试(原 min(60*(n+1)*2,600)s)
- /api/status: 用 thread.is_alive() 替代 _running 布尔标志
- 三组件(scheduler/dispatcher/poller)添加 is_alive()+check_and_restart()
- app.py 新增 watchdog 线程: 每 60s 检测线程死亡并自动重启
2026-08-20 13:37:07 +08:00
ericwyuan
b6c13a9047
feat: 分块断点续传上传 — 20MB/块 + 分块级重试 + 断点查询
...
Edge 端新增 3 个端点:
- POST /api/edge/video/chunk: 接收单块,保存到 task_{id}/chunk_{index:04d}
- GET /api/edge/video/chunks: 查询已上传分块(断点续传)
- POST /api/edge/video/assemble: 合并全部分块入队
NAS Dispatcher 重写:
- 大文件(>50MB)自动分块上传(20MB/块)
- 每块最多重试 3 次(分块级重试,非整文件级)
- 上传前查询已上传分块,跳过已有的(断点续传)
- 全部上传后调 /assemble 合并入队
- 小文件(<=50MB)走直接上传路径
- max_retries 3→5(文件级重试次数)
- scheduler 切回生产目录
解决: 360MB 视频跨公网单次上传超时/断连问题
2026-08-20 12:27:30 +08:00
ericwyuan
fb4ccb64dc
docs: update PROGRESS.md - 异步队列架构 + e2e验证 + 超时修复
...
新增任务 #43-47:
- SQLite异步队列 + TokenBucket速率限制 (Gemini 1000/NVIDIA 40 RPM, 2x burst)
- NAS Dispatcher enqueue模式 + Poller线程
- 超时分离模式 (10s connect, 60s read) + stale_timeout 600s
- e2e验证: task 312 (5.7MB) 全链路 93s PASS
新增技术决策 #14-16
新增待办 #51 : 生产视频预压缩 (360MB HTTP上传超时)
2026-08-20 12:18:58 +08:00
ericwyuan
4f0f19bccd
fix: dispatcher/poller 超时改为分离模式,stale_timeout 缩短到 10 分钟
...
- dispatcher 上传 timeout 从 300s 改为 (10s connect, 60s read)
避免大文件上传无限阻塞 dispatcher 线程
- poller 拉取 timeout 从 30s 改为 (10s connect, 15s read)
- stale_timeout 从 3600s 缩短到 600s(10 分钟)
更快回收卡死的 PROCESSING 任务
2026-08-20 12:12:19 +08:00
ericwyuan
02da23ef42
feat: 异步任务队列架构 - SQLite队列 + 速率限制 + NAS Poller
...
Edge端:
- 新增 SQLite 异步任务队列 (queue_manager + consumer)
- 新增 TokenBucket 速率限制器 (Gemini 1000 RPM, NVIDIA 40 RPM, burst 2x)
- 新增 /api/edge/video/enqueue + /api/edge/results 端点
- 消费者线程从队列消费任务,按速率限制调用AI模型
- orchestrator 集成 rate_limiter,Gemini优先→NVIDIA兜底
NAS端:
- Dispatcher 重构为 enqueue 模式(上传后立即返回,不等结果)
- 新增 Poller 线程(定期从Edge拉取结果写 MariaDB)
- app.py 启动 Poller,config.yaml 新增 poller 配置
- db_layer 更新 valid_stages 添加 'process'
2026-08-20 12:07:09 +08:00
ericwyuan
a4b9178a59
docs: update PROGRESS.md with NVIDIA/dispatcher fixes + batch processing validation
...
- Task 39: NVIDIA single-frame JSON parsing fix
- Task 40: Gemini timeout + circuit breaker tuning
- Task 41: dispatcher crash on invalid failure_stage
- Task 42: batch processing validated (task 291/297 SUCCESS)
2026-08-20 11:18:22 +08:00
ericwyuan
d75c745b95
fix: dispatcher crash on invalid failure_stage + per-task error isolation
...
Two fixes:
1. db_layer.update_task_status: map invalid failure_stage values (e.g.
'process' from Edge) to 'callback' before DB write, preventing
MariaDB ENUM DataError (1265 "Data truncated")
2. dispatcher._poll_once: wrap each task dispatch in try/except so one
task's failure doesn't skip remaining tasks in the batch
Root cause: Edge returns failure_stage='process' but DB ENUM only allows
download/extract/vlm_visual/vlm_fusion/callback. The DataError crashed
_poll_once(), causing all subsequent PENDING tasks to be skipped.
2026-08-20 11:09:10 +08:00
ericwyuan
853cb21542
fix: NVIDIA single-frame JSON parsing + Gemini timeout/circuit breaker tuning
...
NVIDIA fix:
- Replace parse_vlm_json (requires full schema: global_summary/entities_json/
frame_details/compute_provider) with lightweight _parse_single_frame_json
that only extracts per-frame fields (person/action/clothing/etc)
- Root cause: NVIDIA adapter does per-frame analysis returning single-frame
JSON, but parse_vlm_json rejected it for missing full-schema fields
- Verified: task 297 → 6/6 frames parsed successfully, first SUCCESS
Gemini + circuit breaker tuning:
- Gemini timeout: 30s → 90s (multi-image vision analysis needs more time)
- NVIDIA timeout: 20s → 30s (per-frame API call)
- Circuit breaker threshold: 3 → 5 (less aggressive tripping)
- Circuit breaker cooldown: 600s → 300s (faster recovery)
2026-08-20 11:02:26 +08:00
ericwyuan
2e43afb6b2
docs(README/PROGRESS): 文档收尾,与架构重构代码对齐
...
1. README 8.3 节:fam-core 配置示例更新(video_dir 生产路径 + chat_handler.qa_url),fam-edge 配置示例对齐新架构(role/usage=qa_fallback、gemini-flash-latest、实际 timeout)
2. README 1.3 节:历史视频积压标记已处理(forward-only);吞吐不足表述更新(无本地融合)
3. README 5.3 节:改名为云端结构化输出 JSON Schema,描述适配器解析 + format_cloud_result 校验两阶段
4. README 6.2 节:移除融合 timeout 行,num_predict 更新为 512,已知问题改述为专职问答兜底
5. README 10.5/10.6 节:Gemini 模型名修正为 gemini-flash-latest;NVIDIA 验证状态更新为已验证
6. README 12 节:架构重构与双端部署验证纳入已完成;v1.1 待办移除已完成项 1-5,保留单元测试/Tailscale/daily_summaries
7. PROGRESS.md:服务状态表更新(新架构、qwen2.5:7b);任务进度追加 32-38;技术决策记录追加云端直出直存与 Q&A 降级;聊天链路验证段更新为 run_qa 编排
2026-08-20 10:45:29 +08:00
ericwyuan
babf5b09a9
[架构重构] 移除本地Ollama融合,云端直出JSON直存DB,Q&A三模型降级
...
1. 视频摘要链路:云端VLM直出结构化JSON → Edge format_cloud_result格式化校验 → 直存NAS DB(移除run_text_fusion本地融合)
2. 智能问答链路:Gemini→NVIDIA→Ollama降级,新增chat()纯文本问答方法
3. 适配器重构:base/gemini/nvidia/ollama adapter新增chat();gemini多图单请求结构化JSON;nvidia逐帧调用聚合
4. 端点变更:/api/edge/chat → /api/edge/chat/ask,调orchestrator.run_qa()
5. chat_handler改经Edge Q&A编排,不再直连Ollama
6. 配置更新:ollama_url → qa_url,Ollama role注释改为Q&A兜底
7. README同步更新架构描述、拓扑图、时序图、模块表
2026-08-20 10:21:09 +08:00
ericwyuan
486eee4feb
fix(db): frame_timestamp ISO8601 归一化 + perf(edge): ollama num_predict 1024→512
...
- db_layer._dt_or_none 支持 ISO 8601(带 T/Z/时区偏移) 归一化为 MariaDB DATETIME 标准格式, 修复 1292 Incorrect datetime value
- edge config ollama num_predict 512: qwen2.5:7b 在 ARM 上 1024 token 融合需 200s, 降到 512 加速且输出足够
2026-08-20 09:26:42 +08:00
ericwyuan
d2fd01f134
perf(config): Gemini 视觉单帧 timeout 15→30s
...
实测 gemini-flash-latest 视觉推理免费层排队需 15~30s,15s 频繁超时触发熔断;
调到 30s 后单测通过(返回有效描述)。NVIDIA NIM 仍 20s 稳定可用
2026-08-20 09:14:53 +08:00
ericwyuan
a46da5db81
feat(orchestrator): 视觉 fallback 降级 + 文本融合角色化
...
- run_visual_analysis 仅 vision 角色参与, fallback 顺序降级(Gemini→NVIDIA NIM)首个成功即采用
- run_text_fusion 固定用 role=text 的 Ollama(qwen2.5:7b) 融合, 支持 num_predict
- config 改为多模型池(gemini/nvidia vision + ollama text)
2026-08-20 09:11:44 +08:00
ericwyuan
99d75a4bda
feat(adapter): 云端视觉适配器 + role 角色区分
...
- base_adapter 增加 role 字段(vision/text)与 get_role()
- gemini_adapter 修复 v1beta 下模型名 404(gemini-1.5-flash→gemini-flash-latest), 改逐帧调用
- 新增 nvidia_adapter(openai SDK, 规避 NIM 单次限 1 图逐帧), 注册 adapter_factory
- 视觉分析仅 vision 角色参与, 文本融合交给 role=text 模型
2026-08-20 09:11:44 +08:00
0af541097f
更新 README.md
2026-08-20 01:00:53 +00:00
0045b074a2
更新 README.md
2026-08-20 01:00:05 +00:00
ericwyuan
3a5ea459a2
docs: 需求文档与 README 整合为单一文档
...
- 按当前代码实际状态重写:推送模式架构、自适应关键帧、实际 API 端点
- 补充实测性能基准(30min视频929s)、E2E 验证结果、可靠性加固机制
- 记录已知遗留问题(多图失效/吞吐不足)与 v1.1 计划
- 项目需求文档.md 内容并入后删除
2026-08-20 07:19:55 +08:00
ericwyuan
5adda97829
docs: add real video benchmark results to PROGRESS.md
...
- 30min 360MB video pipeline: 70s transfer + 39s keyframe + 820s AI = 929s total
- FFmpeg fast seek optimization: 180s+ → 33s (6-8x faster)
- AI analysis is the bottleneck: avg 68s/frame, 0.9 tokens/s on ARM CPU
2026-08-20 02:31:06 +08:00
ericwyuan
7ce8aff67c
perf: use FFmpeg fast seek instead of fps filter for frame extraction
...
- Replace single `ffmpeg -vf fps=1/interval` call (full video decode) with
per-frame `ffmpeg -ss <ts> -frames:v 1` calls (keyframe seek)
- 6-8x faster on ARM: 180s+ → 33s for 60 frames from 30min video
- Per-frame timeout 30s (was 120s single call), failed seeks logged and skipped
- Verified end-to-end: 30min 360MB video → 60 candidates → 12 keyframes in 39s
2026-08-20 02:30:17 +08:00
ericwyuan
6a9d1626fb
fix(event-time): event_end_time/frame_timestamp NOT NULL 列兜底
...
- Edge push 模式: event_end_time 未提供时用 start+视频时长推算
- fam-core db_layer: insert_event 空值兜底(end→start→NOW)
- insert_event_detail: frame_timestamp 空值兜底 NOW
解决 1048 Column cannot be null 落库失败
2026-08-20 02:20:01 +08:00
ericwyuan
e7fb0c92bc
docs(readme): 记录 Gemini API Key 与调用示例(gemini-flash-latest,已验证可用)
2026-08-20 02:18:42 +08:00
ericwyuan
c635dd69f1
fix(db): 空字符串datetime归一化为NULL,兼容MariaDB严格模式
...
monitor_events.event_end_time / event_details.frame_timestamp 收到空串时
插入 NULL 而非 '',避免 1292 Incorrect datetime value 报错
2026-08-20 02:10:37 +08:00
ericwyuan
e7c1641b72
fix(dispatcher): resp.json(silent=) 是 Flask API,requests 不支持会抛 TypeError
...
Edge 返回结果解析时 TypeError 逃逸到轮询循环,任务卡死 PROCESSING
2026-08-20 01:59:10 +08:00
ericwyuan
be30b5f875
fix(config): Ollama 超时与 num_predict 按 ARM 实测调整
...
- 实测 1024px 帧视觉编码 ~36s/帧 + ~5 tok/s 生成
- num_predict 500→60: 500 会单帧跑数分钟必触发 240s 超时
- vlm_visual/model timeout 240→600, vlm_fusion 120→300, overall 600→1800
2026-08-20 01:54:32 +08:00
ericwyuan
3a195d69b9
fix(dispatcher): 僵尸PROCESSING任务回收 + fam-core文件日志
...
- db_layer 新增 reclaim_stale_processing: PROCESSING 超过 push_timeout+120s 重置 PENDING
- dispatcher 轮询前先回收僵尸任务(进程重启/Edge重启导致 in-flight 请求丢失的场景)
- logger 增加 fam-core/logs/fam-core.log 文件输出(daemon 模式 stdout 不可见)
2026-08-20 01:42:59 +08:00
ericwyuan
727642d38b
feat: adaptive keyframe count based on video duration
...
- Replace fixed 5-8 keyframe limit with duration-based adaptive sizing
- Candidate frames: clamp(duration_min × 2, 30, 120)
- Keyframe cap: clamp(duration / 150s, 8, 30)
- 30min video → 12 keyframes (was 8), 60min → 24, 120min → 30
- Short videos (<12min) still get floor of 8 keyframes
- Add Ollama keep-alive config doc to PROGRESS.md (OLLAMA_KEEP_ALIVE=-1)
- Update config.yaml and config.yaml.example with new video params
2026-08-20 01:29:14 +08:00
ericwyuan
40944428d1
feat: video analysis switched to push mode (upload whole video, sync response)
...
Rationale: Oracle cannot reach NAS (Tailscale userspace mode on NAS, no TUN),
the old pull+webhook design requires Edge to download video from NAS and
callback to NAS - both blocked. New design is one-way NAS -> Oracle:
- FAM-Edge: new POST /api/edge/video/push endpoint accepts multipart video
upload, reuses existing OpenCV scene-change keyframe selection, analyzes
synchronously and returns the result payload directly in the HTTP response
(no webhook callback). Old /api/edge/video/analyze kept for compatibility.
- FAM-Edge: VideoPreprocessor.save_upload() saves the uploaded file
- FAM-Edge: AIOrchestrator.process_push_task() runs the full pipeline
(health check -> extract -> select -> compress -> VLM -> fusion) and
returns callback-style payload dict
- FAM-Core: Dispatcher rewritten to push mode - reads local video file,
uploads with task metadata (camera_name, event_start_time from file mtime,
known_members_context), applies the result to DB via shared
event_receiver.apply_success_event()
- FAM-Core: event_receiver success logic extracted into reusable
apply_success_event() (used by both webhook route and dispatcher)
- config: edge_url -> /api/edge/video/push, push_timeout 1800s, gunicorn
Edge timeout raised to 1800s for long synchronous analysis
2026-08-20 01:03:48 +08:00
ericwyuan
c596bf7603
feat: FAM-UI deployed on NAS (Streamlit 1.61.1)
...
- Streamlit 1.61.1 + pandas 2.3.3 installed in fam-ui venv (Python 3.10)
- FAM-UI running headless on 0.0.0.0:8501, HTTP 200, health=ok
- config.yaml synced to NAS (core_url + MariaDB unix_socket)
- All 5 services now running: FAM-Core, FAM-Edge, FAM-UI, MariaDB, Ollama
- PROGRESS.md: task 27 complete
2026-08-20 00:36:37 +08:00
ericwyuan
06e1e5a307
docs: update PROGRESS.md with chat proxy, Tailscale status, E2E results
2026-08-20 00:03:57 +08:00
ericwyuan
94a8805045
feat: FAM-Edge chat proxy + PyMySQL migration for FAM-UI + config update
...
- FAM-Edge: add /api/edge/chat proxy endpoint forwarding to local Ollama
(Ollama port 11434 not exposed externally, FAM-Edge acts as reverse proxy)
- FAM-Core config: edge_url and ollama_url switched from Tailscale IP to
Oracle public IP (Tailscale firewall blocking between NAS and Oracle)
- FAM-UI: migrate mysql.connector to PyMySQL (same as FAM-Core)
- FAM-UI: cursor(dictionary=True) replaced with cursorclass=DictCursor
- End-to-end chat verified: FAM-Core -> FAM-Edge proxy -> Ollama -> response
Answer: 今天没有观察到张三 (no events in DB yet, expected)
2026-08-19 23:59:28 +08:00
ericwyuan
c8cd2f2665
fix: MariaDB JSON path compat for name_member + FAM-Core API verified
...
- name_member(): replace MySQL-only JSON_REPLACE/JSON_CONTAINS with wildcard
JSON paths (unsupported in MariaDB 10.11) with Python-side JSON parsing
- FAM-Core venv rebuilt with Python 3.10.20 on NAS
- All API endpoints tested: health, status, member list, unnamed, naming
- POST /api/member/name: 人物A successfully named to 张三
- PROGRESS.md updated with full test results and task completion
2026-08-19 23:48:35 +08:00
ericwyuan
66b499725d
[deploy] FAM-Core + FAM-Edge 服务启动 + Tailscale 跨服务器验证
...
- FAM-Core (NAS:8000): gunicorn 启动成功, scheduler+dispatcher 运行中
- FAM-Edge (Oracle:5000): gunicorn 启动成功, ollama 健康检查通过
- Tailscale 跨服务器连通: Oracle→NAS FAM-Core health=ok
- config.yaml 同步到 Oracle, FAM-Edge /health 返回 healthy_models=[ollama]
- PROGRESS.md 更新服务运行状态表
2026-08-19 23:32:35 +08:00
ericwyuan
47658fa068
[deploy] PyMySQL 替换 + Tailscale 组网 + config.yaml + 路径修复
...
- db_layer.py: mysql-connector-python(19MB) → PyMySQL(45KB), 去掉连接池
- config_loader.py: 修复路径解析 (2级→3级 dirname), FAM-Core + FAM-Edge 均修复
- Tailscale 组网完成: Oracle=100.74.137.126, NAS=100.70.234.39, 互通验证通过
- NAS Python 依赖: flask/gunicorn/pymysql/PyYAML 全部安装成功
- NAS 代码部署: /volume1/web/sentinel-home-ai/, FAM-Core 7 模块导入 PASS
- NAS DB 连接验证: PyMySQL → MariaDB 10.11.11, 6 张表可见, PASS
- config.yaml 创建: FAM-Core + FAM-Edge + FAM-UI (Tailscale IP + 密码)
- requirements.txt: mysql-connector-python → PyMySQL
2026-08-19 23:27:28 +08:00
ericwyuan
e5ac667586
[deploy] NAS MariaDB DDL 执行 + Tailscale 状态 + README 更新
...
- NAS MariaDB 10.11.11 确认可用, root 密码 iLoveJava5!
- DDL 执行成功: sentinel_home_ai 库 + 6 张表 (process_tasks, monitor_events, daily_summaries, event_details, chat_history, family_members)
- NAS Tailscale 已运行, IP: 100.70.234.39
- Oracle Tailscale 1.102.2 已安装, 待用户认证
- README 新增 MariaDB 密码 + Tailscale IP + NAS 型号信息
- PROGRESS.md 更新全部环境状态
2026-08-19 23:08:21 +08:00
ericwyuan
50d83539f6
[deploy] Oracle 环境部署 + 模型基准测试 + OllamaAdapter 优化
...
- Oracle 依赖安装: flask/gunicorn/requests/PyYAML/opencv/numpy 全部成功
- FAM-Edge 全部 8 个模块导入验证 PASS
- llava-phi3 基准测试: 冷启动 109s, 预热无限制 13.35s, 预热+num_predict=30 仅 4.34s PASS
- OllamaAdapter 新增 num_predict 可配置参数 (默认 500)
- config.yaml.example 新增 num_predict 配置项
- 创建 PROGRESS.md 进度追踪文档
2026-08-19 23:01:21 +08:00
ericwyuan
c1bfac59df
fix(requirements): 移除 google-generativeai/openai 硬依赖 - 代码用 requests 直接调 REST API,兼容 Python 3.8
2026-08-19 22:50:30 +08:00
ericwyuan
ba905d2f84
[1.1] 服务器访问信息 - NAS/Oracle SSH 凭证 + Gitea 账号记录到 README
2026-08-19 22:46:31 +08:00