|
|
783c633a15
|
feat: 时效判定结构化下沉到后端，修复状态映射漏掉 offline
背景：此前「滞后几天」在后端（calculate_offset）和前端（Dashboard.vue 自算
diffDays/diffHours）各有一套实现，阈值与粒度都不同，跨日必然打架 —— 昨天
23:00 的数据在次日 01:00 查看，后端说「滞后 1 天」，前端标「昨日数据」。
services/time_utils.py:
- 新增 staleness_of()，统一返回 {level, days, text}，level 分
unknown / ok / yesterday / lagging / severe 五级。
- 日期解析改用正则抠 YYYY-MM-DD，分隔符兼容 - / _，因此 ISO 的
2026-09-15T08:30:00Z、2026/09/15、2026_09_15 都能识别。
原来的 split(' ')[0] + strptime('%Y-%m-%d') 遇到 ISO T 或斜杠会直接返回
「时间解析失败」，而 82 爬虫的 target_time 是原样透传接口返回值的，格式
不可控。
- calculate_offset 保留为兼容入口，内部委托 staleness_of。
models.py:
- to_dict() 新增 stale_level / stale_days。
- 修复状态映射：白名单原来只有 ['离线','异常','已离线']，漏了 'offline'，
而 /add_device 创建手动设备写的正是 status='offline'，导致手动添加的设备
被映射成 online、在面板上永远显示「在线」。改为大小写归一后比对，并纳入
unknown/未知。
实测：本地库 status 分布由 online:103/offline:2 修正为 online:99/offline:6。
|
2026-09-15 17:10:53 +08:00 |
|
|
|
15f79e69ad
|
fix: 控制台强制 UTF-8，避免 emoji 打印异常拖垮采集事务
Windows 中文控制台默认 cp936(GBK)，而 app.py / services.core / crawler_106 /
crawler_82 大量使用 emoji 打印日志。print 一旦抛 UnicodeEncodeError，异常会
落进采集任务的 try 块，导致整个事务被 rollback 并报“数据写入失败”，表现就是
定时采集长期静默不落库。
实测：在 GBK 管道下 create_app() 直接崩在 app.py 的 emoji print 上。
- app.py 顶部（所有业务 import 之前）强制 stdout/stderr 为 UTF-8。
- 比常见写法多两层守卫：encoding 可能为 None（.lower() 会 AttributeError），
PyInstaller --noconsole 或重定向时可能没有 buffer —— 这两个恰好是我们要防的
场景。替换前先 flush，否则旧缓冲区里未写出的内容会随旧对象一起丢。
- 保留原始流引用，防止被 GC 回收时连带关闭底层 buffer。
- auto_monitor_job 瘦身：入库细节全部交给 ingest_device_data。
同时补入 device_monitor.spec（此前未纳入版本管理）与一次性清洗脚本
fix_fake_time.py。
|
2026-09-15 17:05:43 +08:00 |
|
|
|
d66e2826e1
|
refactor: 抽出统一入库管道，合并定时与手动两条重复路径
问题：app.py:auto_monitor_job（定时）和 routes/api.py:run_monitor（手动）
各自维护了一份几乎相同但细节不一致的写入逻辑，同一条数据经不同入口落库后
latest_time / source / offset / file_count 可能不同。
- 新增 services/time_utils.py：calculate_offset 下沉到无依赖模块，避免
db_ingest 与 routes.api 互相 import 形成循环。routes/api.py 里 re-export
一次，保证 app.py 原有的 from routes.api import calculate_offset 不失效。
- 新增 services/db_ingest.py:ingest_device_data()，承载全部入库细节，只
add/flush 不 commit，事务边界交给调用方。
- routes/api.py:run_monitor 瘦身为「触发爬虫 -> 调管道 -> 提交」。
- models.py:to_dict() 的 offset 改为读取时用 calculate_offset(latest_time)
实时计算，不再读 offset 列。该列是写入时刻的快照，采集一停摆就整体失真
（库里停在 2026-02-06，offset 却仍显示“当天”）。列保留但已废弃，
不执行 ALTER TABLE DROP COLUMN。
入库语义（db_ingest）：
- 只有爬虫拿到真实业务时间才更新主表 latest_time，拿不到就保留上一个有效值
（冻结），不再回退到 current_time。
- DeviceHistory 单独用 history_time：主表回答“数据到什么时候”，历史回答
“什么时候采过”。
- 历史表 json_data 改存本次增量切片，不再复制主表那份越滚越大的累积 JSON。
- 主表 json_data 改为覆盖式更新以切断无限膨胀，但保留 APP_OWNED_KEYS
（bound_iccid / is_whitelist）—— 这两个键由 /bind_device_card 和
/toggle_whitelist 写入，按原方案直接覆盖会清空所有设备-流量卡绑定。
|
2026-09-15 17:05:38 +08:00 |
|
|
|
1412b0ed0b
|
fix: 爬虫不再用运行时刻伪造数据时间
crawler_106:
- find_closest_item 原来用 abs(now - item) 取“离现在最近”，服务端只要存在
未来日期的目录就会被选中。改为只保留不晚于当前时间的项，再取最新那个。
- 目录名只有日期，按当天 00:00 参与比较。不能用 23:59:59，否则“今天”的目录
会大于当前时刻而被当成未来剔除，永远只取到昨天的数据。
- 文件 modified 带 Z 表示 UTC，不带时区的按东八区补上。原来 .replace(tzinfo=None)
会让 naive/aware 比较抛异常，被 except 静默吞掉，导致所有文件被丢弃。
- target_time 不再用「目录日期 + datetime.now()」拼接（那写进库的是爬虫跑批
时刻，而 calculate_offset 只取日期部分，等于在骗前端）。改为从最终文件路径
正则提取真实记录时间，正则没命中时退化到文件修改时间。
- 正则放宽：兼容 /Data 与 /data、前导斜杠、扩展名大小写。
crawler_82:
- 基础数据包的 target_time 默认值不再用 datetime.now()。
- d_list 为空时原为字符串 "N/A"，它是真值，会通过入库层的 if target_date
判断，把设备主表已冻结的有效时间覆盖掉。改为 None。
爬虫层只负责解析真实记录时间，解析不出来就留 None；如何入库交给
services/db_ingest 决定（离线时冻结上一个有效时间）。
|
2026-09-15 17:05:31 +08:00 |
|
|
|
51deee1493
|
自动写入修改，除了文件个数外，其他信息不展示问题
|
2026-02-08 10:53:00 +08:00 |
|
|
|
f167bbc2f2
|
修改自动爬取时间为17点，修改自己动爬取未写入的问题，写入存在线程阻碍导致无法写入进去，以进行修改，测试成功
|
2026-02-06 10:08:49 +08:00 |
|
|
|
4cb503089e
|
修改自动爬取时间为17点，修改自己动爬取未写入的问题
|
2026-02-05 09:25:00 +08:00 |
|
|
|
fb52536898
|
修改自动爬取时间为17点
|
2026-02-03 17:40:36 +08:00 |
|
|
|
e093ae9633
|
修改新增加文件数量的查询功能
|
2026-02-03 17:15:42 +08:00 |
|
|
|
195c3f8fa4
|
增加流量卡状态信息，对流量信息上提进行调整，取消超过500MB进行的警告整行标黄和上提功能，仅保留流量数字标黄
|
2026-01-22 10:55:41 +08:00 |
|
|
|
cb567b2c7d
|
当自动爬取的时候前端没有传输设备绑定和iccid的关系，导致后端没有接收到，现在修改逻辑
|
2026-01-16 13:14:56 +08:00 |
|
|
|
9b7799b827
|
当自动爬取的时候前端没有传输设备绑定和iccid的关系，导致后端没有接收到，现在修改逻辑
|
2026-01-15 14:06:38 +08:00 |
|
|
|
f043983d24
|
时间显示异常
|
2026-01-14 14:42:33 +08:00 |
|
|
|
9ebfd79414
|
成功添加哈士奇业务以及白名单功能创建
|
2026-01-13 16:43:34 +08:00 |
|
|
|
fe21532741
|
添加哈士奇sim卡业务
|
2026-01-13 14:50:23 +08:00 |
|
|
|
e2333ea9b8
|
数据异常处理
|
2026-01-12 15:57:34 +08:00 |
|
|
|
ffbd494b7b
|
打包上传的2.0版本
|
2026-01-09 12:48:50 +08:00 |
|
