ESP32 唤醒成功，离线命令为什么没有执行？

connor

ESP32 唤醒成功，离线命令为什么没有执行？


设备听到唤醒词、亮了灯，接着却没有执行“打开卧室灯”。把这次故障直接归为“离线识别不准”，可能跳过了真正断开的交接。唤醒事件不等于命令 ID，更不等于设备动作。本文针对 ESP-SR 的 WakeNet、AFE、MultiNet 组合路径，给出一份现场排障记录。开头的中文口令是设问；后文引用的 ESP-Skainet 英文示例没有演示中文命令。本文也没有实体板卡、识别率或时延实测。
唤醒发生，命令阶段启动了吗？

官方英文示例中，feed_Task 向 AFE 送音频，detect_Task 从 AFE fetch 取结果。唤醒发生后，示例会清理 MultiNet 状态；单通道路径在 WAKENET_DETECTED 后设置 wakeup_flag，多通道路径则等 WAKENET_CHANNEL_VERIFIED。只有标志生效后，才把 res->data 送给 multinet->detect。这说明只记录“唤醒成功”还不够：还要证明命令检测循环真的开始。
现场先记录本次 wakeup_state、通道数、命令阶段标志、第一帧送入 detect 的时刻。唤醒到了但标志没打开，检查状态分支和多通道确认；标志打开却没有 detect 调用，检查任务调度、AFE fetch 返回和数据队列。不要先改识别词条。
灯亮了，只是应用选择展示了一个事件

用户看到亮灯，通常会理解成设备已经准备听命令；代码里的亮灯却可能绑定在最早的唤醒事件上，而命令阶段要等后续条件成立。这个时间差就是排障需要拆出的第一处边界。可以给同一轮记录三个时刻：检测到唤醒、命令窗口实际打开、首个有效音频帧交给 MultiNet。如果 UI 提示出现在窗口之前，用户立即说出的命令可能落在业务尚未接收的区间。这里是应用设计假设，不是对官方示例时延的测量。
初始化记录固定通道配置与模型版本，再核对当前分支所等的事件：单通道触发条件不能误套多通道，当前配置不会产生的确认事件也不能一直等待。后面的构造序列会展示同一次唤醒在通道确认前后的不同结果。
再检查命令窗口如何关闭。用户取消、音频错误、识别超时和执行完成，都可能使应用退出当前阶段；退出之后是否重新允许唤醒，必须按业务设计明确。如果上一轮关闭窗口后标志没有恢复，下一次亮灯可能来自另一个路径，而 MultiNet 始终没有拿到帧。连续两轮短命令可以暴露这种状态交接，单次开机成功却覆盖不到。这里建议的是状态记录与复测，不要求另建复杂调度系统。
还有一种假设是检测任务被网络、日志或设备动作同步调用占住。唤醒标志已经打开，输入帧却迟迟未消费。应记录任务实际取得帧的进度，而不是只记录标志赋值。若发现阻塞，就先定位占用时间和队列积压，再考虑分离长操作。任务优先级的变化可能影响调度，但不能替代对命令窗口和音频连续性的证明。
AFE 有声音，MultiNet 收到合规帧了吗？

乐鑫 MultiNet 文档规定：输入是 AFE 处理后的 16 kHz、16 bit、单声道音频；MultiNet 帧长必须等于 AFE fetch 帧长，传入字节数对应 mu_chunksize * sizeof(int16_t)。官方示例也断言 get_samp_chunksize 与 get_fetch_chunksize 相等，并把 res->data 交给 detect。
因此“麦克风有波形”不是足够的证据。记录两端 chunksize、样本格式、实际缓冲区、fetch 错误码和对应帧序号；不要把采集端的多通道原始交织数据当成 AFE 的单声道 fetch 结果。帧长不符或传错缓冲区时，先修交接，再比较识别表现。
合规的含义，是实际指针和实际范围一致

初始化时 chunksize 相同，是必要检查；运行时真正传进 detect 的内容仍要核对。应用可能在多个缓冲之间切换，把采集缓冲、处理后缓冲或上一帧缓冲传错。记录生产者、消费者和采样范围，比打印一个指针地址更有解释力。地址只能说明当时用了哪块内存，不能证明该块内存仍属于当前音频，也不能证明它包含正确通道。
长度检查也需要区分样本数与字节数。若接口要求固定个数的 int16_t 样本，业务复制和发送范围应围绕同一个约定计算；不能一个地方按样本数分配，另一个地方按字节数写入。本文沿用官方文档已经说明的输入合同，不凭 size 或 chunk 名称推断其他接口的单位。跨版本接入时，查当前头文件与示例的实际调用，避免把旧版本经验带进新构建。
交接记录需要帧序号；断裂时查队列丢弃，重复时查重试或缓存复用。本地例子会将重复与断裂留作失败输入，即使存在命令 ID，也不把它们当作连续交接的证明。
保存可重放输入，才有条件比较识别修改

原始麦克风音频用于诊断采集与前端，真正交给 MultiNet 的处理后音频用于诊断命令识别。两者都可以保留，但必须标明来源，不能用原始音频回放结果替处理后链路结论背书。假设现场口令失败，而同一段处理后输入离线复放成功，那么下一步应查现场输入的时序和应用状态；若复放仍失败，则可以进一步检查模型、语言与活动词表。
重放时还要固定帧组织方式与检测窗口。一个完整文件如果一次性送入，与现场分帧连续送入不是相同交接。应按当前接口要求划分帧，并保留从进入命令阶段到结束的状态序列。本文没有运行这个重放实验，因而只把它作为区分问题层级的方法，不报告任何复放准确率或处理速度。
识别在运行，词表和状态也要核对

MultiNet 支持运行时增删改命令，但文档明确：调用 esp_mn_commands_update() 后，修改才会生效；缓存命令与活动命令是两份需要区分的视图。打印当前活动词表、命令 ID、模型和语言，再用该模型支持的口令测试。官方文档还提醒命令词不支持中英文混写，也不能含阿拉伯数字或特殊字符。只看到配置文件写了某个词，不能断言运行模型已经启用它。
检测循环至少记录三种状态。DETECTING 表示尚未命中；DETECTED 时读取 get_results 的 command_id、phrase_id 与概率，并核对 ID 是否在活动词表中；TIMEOUT 表示命令窗口里未识别到目标词，示例重新启用 WakeNet。超时不等于已经识别但设备没动作。单次和连续识别模式的退出条件可能不同，复测前要锁定实际配置。
配置中的命令，和模型正在用的命令分开看

一个常见假设是界面已显示新增词条，但运行模型仍使用更新前的词表。界面来自业务缓存，检测来自活动词表，两者各自正确也可能彼此不一致。记录更新调用的结果，并输出当前活动条目，才能证明配置改动已经跨过生效边界。测试人员只拿配置文件截图，无法证明运行设备已加载那份配置。
命令 ID 与口令也需要作为一组绑定。假设两条短语都映射到“开灯”，识别返回的 phrase_id 可以帮助解释听到哪条短语，而应用动作应按其既定 ID 映射处理。若代码错误地把短语序号当作业务命令 ID，识别可能成功但动作错位。这里不是说官方接口会返回错误 ID，而是提醒应用不能因为两个字段都是整数就混用它们。
语言约束应在声学实验之前检查。中文设问需要实际中文模型和合法词条支撑；官方英文示例只能证明英文示例中的交接流程。不能把它打印出 command_id 的截图贴到中文产品验收里，宣称中文口令已验证。对含数字、品牌名或中英文混写的业务表达，也要先确认当前模型与配置允许的表示，再讨论用户说法如何映射；本文不为不支持的词形设计猜测性的替代规则。
状态序列比一条最终日志更能解释失败

持续 DETECTING 与最终 TIMEOUT 都不是根因标签：它们需要与输入帧、活动词表和窗口时刻一起解释。声音质量差、词表不匹配可能走同一结果；没有帧时，应用等待超时甚至不能冒充模型已返回 TIMEOUT。
遇到 DETECTED 时，先保存返回结果，再交给业务执行。执行耗时较长的产品应明确识别阶段此刻是否退出，是否仍消费后续帧，以及重复命中如何处理。这些属于应用控制选择，不能由“模型有连续识别能力”自动推出业务应该无限连续执行。若命令阶段已关闭，后续结果也要按轮次确认归属，避免旧轮次结果触发新轮次的动作。
概率值可用于理解本次模型输出，但不能直接变成跨模型通用的质量分数。本文没有当前模型的概率校准实验，不设置一个看起来精确的通用门槛。先确认结果属于正确活动词条，再结合失败样本设计同条件对照；否则提高门槛可能只是隐藏输入或映射错误，降低门槛则可能把更多不相关结果交给动作层。