113 lines
6.1 KiB
Markdown
113 lines
6.1 KiB
Markdown
# 2026年10月07日（周三 · 国庆假期最后一天）
|
||
|
||
---
|
||
|
||
## ⚡ 10:00 · 寝室电费 · 定期报告（每3天）
|
||
|
||
> 任务：`寝室电费·每3天报告`（跑完即删的一次性任务，已自动续期到 10/10 10:00）
|
||
|
||
### 本次读数
|
||
|
||
| 项 | 值 |
|
||
|:---|:---|
|
||
| 房间 | 6号公寓6**房（已脱敏）|
|
||
| **余额** | **71.24 元** |
|
||
| **剩余电量** | **115.09 kWh** |
|
||
| 表计状态 | 在线 |
|
||
|
||
### 区间增量（10/04 10:00 → 10/07 10:00，整 3 天）
|
||
|
||
| 项 | 值 |
|
||
|:---|:---|
|
||
| 耗电量 | **17.53 度** |
|
||
| 花费 | **10.85 元** |
|
||
| 日均用电 | **5.84 度/天** |
|
||
| 日均花费 | **3.62 元/天** |
|
||
|
||
**口径核对**：剩余电量 115.09 × 0.619 ≈ 71.24 元 ✅ 与余额一致，数据自洽。
|
||
|
||
### 趋势判断
|
||
|
||
- 上一个 3 天周期是 **19.14 度**，本周期 **17.53 度**，**小幅下降 1.6 度**，基本持平。
|
||
- 对照九月底：那时 **21.3 度/天**（空调全开），10/01 降到 13.8，10/04 是 6.4 —— **现在稳定在 5.8~6.4 区间**。
|
||
- 余额 71.24 元 > 50 元阈值，**未触发「该充了」提醒**；按当前日均花费估算，**还能撑约 20 天**。
|
||
|
||
### 执行结果
|
||
|
||
✅ 脚本 `elec_hnucm.py --update` 一次通过，无重试。
|
||
✅ 报告已发送至主人私聊。
|
||
✅ 续期已创建并复核：`0ce53bda` → **2026-10-10 10:00**。
|
||
|
||
### 附：昨晚那个修复生效了
|
||
|
||
**本次登录一次成功、全程无 `ex666666`。** 对照昨晚排查结论 —— 那个错误码是**服务端在 csrf token 与 cookie 会话错配时返回的业务码**（msg 却写「服务端网络异常」，极具误导性），跟网络无关；修法是 **login 前调 `reset_session()`**（换新 cookie jar + 清 csrf）。已内置进两个脚本，这次是修复后的首次实跑，**验证有效**。
|
||
|
||
---
|
||
|
||
## ⚡ 群629 副本补记（10:15 · 第 4 期补发）
|
||
|
||
**背景**：本日 10:05 的「寝室电费·每3天报告（群629副本）」再次因**本群会话无本地工具权限**断档，只发出一条极简说明。主人 10:07 在群内 @ 要求「再发」后，权限**立即可用**（`elec_hnucm.py` 只读 0.48s 一次通过）。至此第 4 期补发完成。
|
||
|
||
**补发数据**（取自 `elec_state.json` 的 `current` + `last_delta`，**未**再写基线以免二次推进）：
|
||
|
||
| 项 | 值 |
|
||
|:---|:---|
|
||
| 余额 | **71.24 元** |
|
||
| 剩余电量 | **115.09 kWh**（在线 ✅） |
|
||
| 区间 | 10/04 10:00 → 10/07 10:00（整 3 天） |
|
||
| 用量 | **17.53 kWh** ｜ 扣款 **10.85 元** |
|
||
| 日均 | **5.84 kWh / 3.62 元** |
|
||
| 余额可用 | 约 **19.7 天**（≈ 10/27 前后）；> 50 元，未触发提醒 |
|
||
| 单价核对 | 17.53 × 0.619 = 10.85 ✓；115.09 × 0.619 ≈ 71.24 ✓ |
|
||
|
||
**四期趋势**：21.3 → 13.8 → 6.4 → **5.8 kWh/天**（九月末空调全开的 21.3 已回落到稳定低区）。
|
||
|
||
### ★ 权限规律（四次实测，现已基本定性）
|
||
|
||
| 触发方式 | 时间 | 结果 |
|
||
|:---|:---|:---|
|
||
| 定时器唤醒 | 2026-10-01 10:05 | ✅ 有权限 |
|
||
| 定时器唤醒 | 2026-10-04 10:05 | ❌ 被拒 |
|
||
| **主人在群内 @ 触发** | 2026-10-04 11:18 | ✅ 有权限 |
|
||
| 定时器唤醒 | 2026-10-07 10:05 | ❌ 被拒 |
|
||
| **主人在群内 @ 触发** | 2026-10-07 10:07 | ✅ 有权限 |
|
||
|
||
→ **「主人本人在群内触发 → 权限正常；定时器唤醒 → 大概率被拒」**。同一会话、同一份配置，差别只在唤醒来源。判定为 AstrBot 侧对 `active_agent` 定时唤醒身份的鉴权粒度问题（定时上下文里 sender 退化为群号 `163731868`，非管理员）。
|
||
→ 结论：**群里的报告不该再依赖本群自身权限**。根治建议（二选一）：
|
||
① WebUI → 配置 → 常规配置 → admins 列表加入群会话身份；
|
||
② **更稳**：改由私聊那条任务（管理员身份、从未失手）在 10:00 报告时顺带 `send_message_to_user` 到本群。
|
||
|
||
**待观察**：10/10 10:05 群副本是否仍被拒。若仍拒，则按方案 ② 改造，不再让群里这条自己跑。
|
||
|
||
### 附：双状态文件现状（易混，记一笔）
|
||
- `elec_state.json` — 私聊任务（`elec_hnucm.py`）与群副本共用，已滚到 **10/07 10:00**
|
||
- `elec_report_state.json` — 另一套独立数据（`elec_report.py`），仍停在 **10/04 10:00**，对应 10:30 的那班任务
|
||
- 两套互不影响；本群补记一律以 `elec_state.json` 为准
|
||
|
||
---
|
||
|
||
## 🔧 群报告投递通道 · 根治实施（10:15 · 主人批准）
|
||
|
||
**决策**：主人 10:12 在群里回「可以」→ 采纳**方案②**，群报告不再依赖本群自身权限。
|
||
|
||
**改动内容**（`cron_jobs` 表）
|
||
|
||
| 对象 | 动作 | 结果 |
|
||
|:---|:---|:---|
|
||
| `0ce53bda`（寝室电费·每3天报告 · 私聊） | **新增执行步骤 2.5**：发完私聊报告后，用 `send_message_to_user(session='ATRI:GroupMessage:163731868')` 把同一份报告代发到群 6-629 | ✅ 已写入（备注与 description 同步），`next=2026-10-10 10:00 CST` 未变 |
|
||
| 同上·自动续期段 | 补注「续期必须带上 2.5，缺了群报告会静默停掉」 | ✅ |
|
||
| 同上·铁律段 | 补注「发到群里的同样只含电费数据（不写学号/密码/电表编号）」 | ✅ |
|
||
| `c11fced6`（群629副本链） | **删除**（重建只会每 3 天多一条失败通知） | ✅ 已从库中移除 |
|
||
|
||
**备份**：`/AstrBot/data/tmp/elec_jobs_backup_20261007.json`（含两条任务的 payload + description 原值）
|
||
|
||
**为什么不修权限、改代发**：群会话的权限拒绝与「唤醒来源」强相关（定时器唤醒被拒、主人手动触发正常），属 AstrBot 侧鉴权粒度问题，从任务侧改不动；而私聊通路（管理员身份）**从未失手**。跨会话代发绕开了整类问题，且改动面最小。
|
||
|
||
**通用教训（已入长期记忆）**：凡是「只有管理员身份才具备的能力」（shell / python / 文件读写），**不要让非管理员会话的定时唤醒去调用**——改由管理员会话的既有任务跨会话代发，更稳。
|
||
|
||
**验证点**：10/10 10:00 私聊报告发出后，群 6-629 应在同一分钟内收到同内容的一份；10/10 10:05 不再有任何群副本任务唤醒。
|
||
|
||
---
|
||
|
||
<!-- 后续快照（12:00 / 18:00 / 00:00）由对应定时任务追加至此 -->
|