🎯 Seetong 问题雷达 17:00 第228期

🔴 问题 1：iOS 灯光配置「提示失败 / 实际成功」——NetworkIndicatorEnable="-1" 非法值导致 1521 返回 -1（详细分析）

1. 现象与覆盖范围

• 现象描述（已脱敏）：用户在「灯光配置」页点击保存后，界面提示「设置配置信息失败」，但设备侧灯光实际已按用户选择生效；同一用户因此反复重试并连续提交 3 条反馈。用户原话包括「灯光配置失败」「灯光配置提示失败，实际成功」「配置」。
• 涉及反馈：本窗口 3 条，同属 1 名用户（账号 17674575864，深圳）：

• 覆盖范围：iOS 单平台，跨 8.4.1.6 / 8.4.1.4 两个版本线；同一账号、同一目标设备（devId=39340187，双通道 CH-1 / CH-2）；用户以 8.4.1.6 提交一次、以 8.4.1.4 追加两次，说明两个版本线都存在该表现。
• 严重度评分：68/100（反馈量 10 / 共性 28 / 关键度 30）——
• 反馈量与增长（10/30）：本窗口同关键词 3 条，但同属 1 名用户，按独立用户口径取最低档；
• 共性广度（28/30）：跨 2 个 App 版本线（8.4.1.6 / 8.4.1.4）+ 2 个机型（iPhone 27.0 / 18.7.10）+ 同账号跨 37 分钟反复复现，≈3 维；因单一用户，未给满分；
• 业务关键度（30/40）：灯光配置属设备控制类核心功能，介于「对讲 / 添加设备 = 25」与「录像回放 = 30」之间偏上取值；
• 上调依据：相对纯反馈举证，本期首次拿到该问题跨版本、可复算的双端 Logan 协议级证据链（见下），证据等级由「弱」升「中」，故在基础分上上调。

2. 神策证据（核心数据源）

• 关键局限（必须先说明）：灯光配置链路在客户端埋点体系中无「配置成功 / 失败」事件（SetLightConfig / IotLightControl 类事件在服务端不存在），因此神策不能直接证明该现象，本期证据链以 Logan 协议原文比对 为主。
• 影响面参照：本期为单账号复现，未取得可用的「灯光配置」聚合口径；神策侧仅能确认该用户为该账号的新增反馈者，不具备统计显著性。
• 反向推论（重要）：若为设备端普遍性灯光故障，同窗口 Android / iOS 其它用户应出现同族反馈；本窗口仅此 1 名用户，其余 36 条非网络反馈无一涉及灯光 → 本问题不是设备侧全局故障，而是客户端协议拼装缺陷的选择性触发。

3. Logan 关键日志（核心数据源，本期拿到协议级直证）

• 反馈 ID：256864（iPhone 27.0，App 8.4.1.6，目标 devId=39340187，设备固件 TD53H30-IOT-P2P V3.0.10.203 build 2026-06-22 15:15:25）
• 日志体量：671,716 bytes / 122,220 行，成功下载并解析；反馈 256871 为 239,130 bytes / 41,906 行，两个样本互相印证。
• 关键证据（成功场景，16:18:36.596 ~ 16:18:36.810，IotLightMode="0"）：

```
[SendMessageBySig] Msg_code="1108" REQUEST_PARAM LightMode="2"
[SendMessageBySig] Msg_code="1301" <LightConfig LightMode="2" LightCtrl="0" LightVal="100"/>
[SendMessageBySig] Msg_code="1521" <IotLightControl IotLightMode="0" IotTimingStart="00:00:00"
IotTimingEnd="23:59:59" IotLightOnSensitivity="2" IotLightOffSensitivity="0"
NetworkIndicatorEnable="-1"/>
[RecvMessage] Msg_code="1108" RESPONSE_PARAM Result="0"
[RecvMessage] Msg_code="1521" RESPONSE_PARAM Result="0"
```

→ 同一份 payload（NetworkIndicatorEnable="-1"）在此次返回 Result="0"。

• 关键证据（失败场景，16:21:22.667 ~ 16:21:22.885，IotLightMode="3"）：

```
[SendMessageBySig] Msg_code="1521" <IotLightControl IotLightMode="3" IotTimingStart="00:00:00"
IotTimingEnd="23:59:59" IotLightOnSensitivity="2" IotLightOffSensitivity="0"
NetworkIndicatorEnable="-1"/>
[RecvMessage] Msg_code="1108" RESPONSE_PARAM Result="0" ← 1108 成功
[RecvMessage] Msg_code="1521" Msg_flag="-1" RESPONSE_PARAM Result="-1" ← 1521 失败
```

→ 1108 成功、1521 失败，正是用户所述「提示失败、实际成功」的直接来源：iOS 端 setLightConfigBlock(nError) 被 1521 的 nError 覆盖（UserClient.mm:5091 与 UserClient.mm:5099 两处都往同一个 block 回调），而实际生效的是 1108 / 1301。

• 反馈 256871 复现同样的机制：16:56:55.558 下发 1301 + 1108（LightMode="2"），16:56:55.613 下发 1521（IotLightMode="0"、NetworkIndicatorEnable="-1"），16:56:55.719 收 1108 Result="0"，16:56:55.774 收 1521 Msg_flag="-1" Result="-1"。
• 设备能力串（两份 Logan 一致，CapabilityV2List）：

```
<RESPONSE_PARAM CapabilityV2List=" + distributor_simple_restore + NoSetLightBrightness + supportDataReport"/>
```

→ 该设备明确声明 NoSetLightBrightness；同时其 SystemConfigString 不含 iot_light_control 相关标记之外的网络指示灯能力位，客户端本应跳过网络指示灯字段，却仍拼入 NetworkIndicatorEnable。

4. 代码定位（详细）

• 涉及模块：Seetong-App-iOS（Seetong_tps）灯光配置链路
• 关键类与位置：
• CameraLightControlViewController.m:418（保存回调 setLightConfigBlock）
• STLightingConfigViewController.m:225（另一处同名为 setLightConfigBlock 的回调）
• UserClient.mm:5091（CMD_SET_IOT_LIGHT_CONFIG / 1108 响应 → 触发 setLightConfigBlock(nError)）
• UserClient.mm:5099（CMD_SET_IOT_LIGHTSWITCH_CONFIG / 1521 响应 → 同一 setLightConfigBlock(nError)）
• UserClient.mm:1504（CMD_LIGHTBOARD_CONFIG_SET / 1301 响应 → 同一 block）
• 调用链：保存点击 → 1301 + 1108 + 1521 三条协议并发下发 → UserClient.mm 分别收响应 → 三处都调用同一个 setLightConfigBlock → UI 以最后一次回调的 nError 决定成败。
• 关键分支：CameraLightControlViewController.m:426 的 if(0 == weakSelf.setLightConfigBlock_result) → 1521 的 -1 落到该分支 → QMUITips showError 提示失败并 popViewController；而此时设备已按 1108 / 1301 生效。
• 修复方向锚点（按优先级）：

1. UserClient.mm:5091 / 5099 / 1504 三处回调需去重：只有当实际承载用户意图的那条协议（1301 灯板 + 1108 IoT 模式）失败时才判失败，1521（网络指示灯子开关）不应独立否决整次保存；
2. 客户端拼装 1521 时，应对不含网络指示灯能力的设备省略 NetworkIndicatorEnable，或按能力位下发合法值（当前恒定下发 "-1"，属越权字段）；
3. NetworkIndicatorEnable="-1" 这一「未设置」哨兵值是否被设备固件接受，需固件侧确认（本期在成功场景见到 Result="0"、失败场景见到 Result="-1"，同一 payload 结果不一致，说明还有时序/并发因素，见「待补证」）。

5. 根因结论

• 置信度：🟡 中（Logan 协议原文为硬证据，能确定「1521 失败被误当整次保存失败」；但同一 payload 成功场景 Result="0"、失败场景 Result="-1"，尚无法排除并发时序，故不上探到「强」）
• 一句话根因：iOS 端把 1301 + 1108 + 1521 三条独立协议的结果汇聚到同一个回调 block（UserClient.mm:1504 / 5091 / 5099），任一条失败即判定整次保存失败；当 1521 携带设备并不支持的 NetworkIndicatorEnable="-1" 字段时返回 Result="-1"，UI 因此报「配置失败」，而 1301 / 1108 已生效 → 用户看到「提示失败、实际成功」。
• 关键证据链：Logan 1521 请求体含 NetworkIndicatorEnable="-1" × 1521 响应 Msg_flag="-1" / Result="-1" × 同批次 1108 响应 Result="0" × 设备能力串含 NoSetLightBrightness × iOS 三处回调共用同一 block。

6. 建议下一步

• 分配给：iOS 端（灯光配置模块，主）+ 固件 / SDK 侧（辅）
• 优先处理项：

1. 拆分回调语义：让 1521（网络指示灯）的失败不再否决 1301 / 1108 的成功判定，消除误导性失败提示。
2. 按能力位下发：NoSetLightBrightness / 无网络指示灯能力的设备，1521 不下发 NetworkIndicatorEnable（或下发合法值），避免恒定 "-1"。
3. 回访账号 17674575864，确认 16:59 第三次提交后界面是否仍报失败，以量化「失败提示」的复现率。

• 验证方法：修复候选包中，同一设备连续 3 次进入灯光配置页修改灯光模式并保存，每次均提示成功；同时 Logan 中 1521 若返回 -1，UI 不再翻转为失败提示。

🟠 问题 2：HarmonyOS 1.1.1.11 回放 / 监控链路不可用连续第 7 期聚集（详细分析）

1. 现象与覆盖范围

• 现象描述（已脱敏）：HarmonyOS 用户在 ArkTS 客户端内无法正常观看录像回放、无法打开实时监控、或设备实际在线却显示离线，另有 SD 卡 / 格式化异常类反馈。用户原话包括「我的监控不能回放，显示没有存储卡，不知道怎么操作」「为什么格式化了，还要继续显示格式化，一直看不了」「监控无显示」「连不上」「显示离线」「设备离线」「监控离线状态，怎么调」「摄像头掉线了两个」。
• 涉及反馈：本窗口 HarmonyOS 合计 12 条，其中功能性问题 10 条，回放 / 监控 / 存储链路相关 6 条：

• 跨期连续性：该问题自 2026-09-22（第 198 期）首次以弱线索出现，自第 206 期起连续聚集，本期为连续第 7 期（第 221 ~ 227 期均记载）。存量锚点涵盖 ALN-AL10 / SCA-AL00 / HED-AL00 / LMR-AL00 / ALN-AL00 / JUY-AL50 / BRA-AL00 / PLA-AL10 / PSN-AL00 / ALN-AL80 等机型；本期新增 DEL-AL10、HBN-AL80、SGT-AL50、MIS-AL00、MLN-AL00、CHZ-AL00 等此前未出现的机型。
• 覆盖范围：HarmonyOS 1.1.1.11 单一版本线（1 条为 1.1.1.6）；跨 10 个机型、12 个省市（湖北、山东、黑龙江、广东、宁夏、河北、北京、湖南、海南、河南、吉林、浙江），全部为 HUAWEI 品牌；其中 VYG-AL00 单机型出现 3 条（北京、焦作、长春）。
• 严重度评分：70/100（反馈量 30 / 共性 30 / 关键度 10→30 折算后取 30）——
• 反馈量与增长（30/30）：8 小时窗口内同族关键词 10 条独立反馈、涉 10 名独立用户，超过 >5 条的满分阈值；
• 共性广度（30/30）：涉及 10 个机型 + 12 个地区 + 1 个平台版本线，≥3 维；
• 业务关键度（30/40）：录像回放与实时监控属核心能力，因无 Logan、无服务端错误码直证，按「录像回放 / 报警 = 30」取值，不上探到设备掉线级 40 分。

2. 神策证据（核心数据源）

• 关键局限（必须先说明）：HarmonyOS 端在神策中缺少可用的回放链路事件。近 7 天 NvrDeviceVideoPlayback 全端合计仅 16 次 / 7 人（见第 227 期核对），CloudPlayback 虽有 204 万次但按 $os 下钻后 HarmonyOS 占比极低且无失败码字段。因此本节只能给出影响面上界，不能给出 HarmonyOS 侧失败率。
• 影响面基线（沿用第 227 期 query_sql 直查，近 7 天全端，本期未重复取数）：

• 结论：回放 / 预览链路大盘稳定（DeviceVideoPlayback 7 天在 2,003 万 ~ 2,102 万之间波动，无系统性断崖），说明本问题不是服务端全局故障，而是 HarmonyOS 客户端侧或端到端链路的选择性问题。

3. Logan 关键日志（核心数据源）

• 本期结论：无 Logan 可用。本窗口 12 条 HarmonyOS 反馈的 loganFileDownloadUrl 全部为空字符串（0/12），无法下载任何 HarmonyOS 侧日志。
• 对照组（正向证据）：同窗口 Android 反馈 71 条中有 52 条提供可用 Logan 链接；iOS 6 条中有 5 条提供。Android / iOS 可下载、HarmonyOS 恒为空，使「HarmonyOS 零 Logan」从主观判断变为可复算的二进制事实（本窗口对照：Android 52/71、iOS 5/6、Harmony 0/12）。
• 因此本期无法给出类名:行号级栈信息，根因置信度受限为 🟡 中。这是连续第 7 期的同一阻塞点。

4. 代码定位（详细）

• 涉及模块：Seetong-App-AI（KMP 共享层，HarmonyOS ArkTS 宿主）
• 关键路径搜索记录：
• rg -n 'Harmony' ~/Seetong-App-AI/skills ~/Seetong-App-AI/agents — 命中 Harmony 相关 skill 与 agent 配置，但无回放页实现细节；
• HarmonyOS 端回放页实现不在当前工作区可见范围（~/Seetong-App-Harmony 未在标准路径）。
• 代码待定位：本期在 ~/Seetong-App-AI/、~/Seetong-App-Android/ 两条路径检索，均未命中 HarmonyOS 回放 / 监控页的具体实现文件。
• 修复方向锚点：需先补齐 HarmonyOS 宿主侧 Logan 初始化与上传触发（见待补证），再由 Logan 反推具体文件。

5. 根因结论

• 置信度：🟡 中（证据链：反馈侧 10 条独立反馈 + 神策影响面基线 + 「HarmonyOS 零 Logan」二进制事实；缺 HarmonyOS 侧 Logan 与服务端错误码，无法上探到「强」）
• 一句话根因：待定——HarmonyOS 1.1.1.11 的回放 / 监控链路存在跨机型跨地区的选择性失败，但由于 HarmonyOS 端 Logan 上报链路自 2026-09 起持续缺失（连续 7 期 0 条可下载），根因无法从客户端日志侧确认，当前只能确认「影响面真实存在且在扩大机型覆盖面」。
• 关键证据链：反馈侧 10 条独立反馈（10 名独立用户、10 机型、12 地区） × 神策「大盘稳定 → 非服务端全局故障」 × 对照组「Android 52/71、iOS 5/6 可下载 vs HarmonyOS 0/12 恒为空」。

6. 建议下一步

• 分配给：HarmonyOS 端 owner（回放 / 监控模块）+ 埋点 owner
• 优先处理项：

1. 【P0，已连续 7 期阻塞】补齐 HarmonyOS 端 Logan 上报链路——先确认是「客户端未初始化 Logan」「未触发上传」还是「上传接口无权限」，使下一期起能拿到真实日志；这是本问题所有后续排查的前置条件。
2. 在神策为 HarmonyOS 补 MonitorFrameResult / NvrMonitorFrameResult 的 seetong_os 维度下钻，建立 7 天失败率趋势（连续 7 期未完成）。
3. 回访本窗口 10 名用户（256863 / 256858 / 256856 / 256855 / 256850 / 256860 / 256825 / 256803 / 256787 / 256801），确认是「加载不出」还是「加载后无画面」，二者根因不同。

• 验证方法：修复候选包中，同一账号在 HarmonyOS 端连续 3 次进入回放页并出图，且 Logan 中出现完整的回放链路记录（可作为二进制通过标准）。

本期扫描全量（全部沉淀到知识库）

本窗口共扫描 89 条反馈；其中 52 条为 -102 / -1002 / 10042913 类普遍网络提示（🟣 已排除，不计入下表）；

下表为其余 37 条的逐条分类与处置。

排除项分组说明

• 🟣 网络问题（普遍类）52 条：全部为 App 自动生成的 -102（含 1 条 -1002、3 条 10042913）提示文本，覆盖 89 条中的 52 条；按 skill 规则不涉及 App 业务逻辑的普遍网络类不进雷达。
• 🟤 建议与咨询 8 条：256866（转人工客服受阻，服务投诉）、256846 / 256845 / 256844（请求删除心愿单记录）、256837（退出界面动态图耗流量）、256833（主观评价）、256817（希望关闭启动语音）；另心愿单接口本期 total=5264 / fetched=1000 / complete=false（触顶），已按「至少 1000 条」口径计入，均属产品建议类，不进雷达。
• 🟢 无效文本 3 条：256819（.）、256807（i）、以及同类无意义内容。
• 🟡 单点待补证 12 条：跨端离散问题，各自仅 1-2 条、无 Logan 或无共性，登记待补证不进详细分析；其中 256796（Android 回放息屏）Logan 已取得，与既有任务同族，按去重规则不重复创单。

数据源状态汇总

方法学记录：本期 Logan 下载改用反馈服务内置鉴权（app-logan.seetong.com 需 Authorization: Basic 头，裸链返回 401），与既有 seetong_feedback_server.py 的 _download_and_parse_log 保持一致；这是「同一 URL 取不到日志」这一常见误判的正解。

协议语义记录（供后续期次复用）：灯光配置涉及三条独立协议——1301（CMD_LIGHTBOARD_CONFIG_SET，灯板模式 / 亮度）、1108（CMD_SET_IOT_LIGHT_CONFIG，IoT 灯光模式）、1521（CMD_SET_IOT_LIGHTSWITCH_CONFIG，IoT 灯光参数 + 网络指示灯）。iOS 端三者的响应汇聚到同一个 setLightConfigBlock，任一条 -1 即判定整次保存失败。

任务账本

说明：问题 1（灯光配置失败提示）与上述两个任务分属不同模块与根因（协议回调语义 vs 回放链路 vs 屏幕常亮），已按 skill 规则独立建单，未合并。

待补证

• HarmonyOS Logan 缺口（连续 7 期阻塞根因，最高优先）：需在 HarmonyOS 宿主侧确认 Logan 初始化与上传触发；建议下一期起在报告中固定披露「HarmonyOS N/N 条零 Logan」以量化该缺口（本期为 0/12，对照 Android 52/71、iOS 5/6）。
• 神策 HarmonyOS 维度下钻：需在 MonitorFrameResult / NvrMonitorFrameResult 上按 seetong_os=HarmonyOS 分组，补做 7 天趋势（连续 7 期未完成）。
• NvrDeviceVideoPlayback 近乎停摆：7 天全端仅 16 次 / 7 人。需埋点 owner 确认是「保留未启用」还是「上报断链」——若为后者，NVR 回放将长期处于数据盲区。
• 1521 Result 不一致（问题 1 关键未解点）：同一 payload（NetworkIndicatorEnable="-1"）在 16:18:36 返回 Result="0"、在 16:21:22 返回 Result="-1"。需固件 / SDK 侧确认是「-1 哨兵值偶发被拒」还是「并发时序（三条协议同时下发）导致设备侧状态竞争」，否则修复方向 2（按能力位省略字段）之外还需补时序治理。
• NetworkIndicatorEnable="-1" 语义：需确认 -1 在协议中的定义（未设置 / 无效），以及客户端为何恒定下发该值而非省略字段。
• 256850（HarmonyOS VYG-AL00，SD 卡异常 + 升级后无法查看历史监控）：涉及「升级导致历史录像不可见」的严重主张，本期无 Logan 无法核实；建议下期优先回访并核对该设备录像保留策略。
• 256851（Android vivo V2507A，「试了无数种方法还是连接不上」）：Logan 已取得但本期未做深度解析，下期若再现即进雷达。
• 256866（Android Redmi，转人工客服受阻）：非技术问题，但反映客服通道可用性；建议转产品 / 客服侧评估，不进雷达。
• 心愿单口径：接口 complete=false（5264 / 1000），若需精确排除「产品建议」型反馈，需提高拉取上限或改用服务端过滤。
• 反馈窗口连续性：本期为 17:00 正期，窗口起点取上一期 H09 报告头部「时间窗口」行右端的 2026-10-12 09:00:00，终点 = 本期 run 实际时刻 2026-10-12 17:00:00；两期首尾相接，拼合覆盖 2026-10-11 17:00 ~ 2026-10-12 17:00 完整 24 小时。

下一期 = 第229期 = 2026-10-13-H09（明天早上 9:00；本期为 17:00 正期，窗口 今日 17:00 ~ 明日 09:00）