怎么在工作台语音播报中对接智能设备来实现语音播放进度控制_解决方案

CATALOG

芯步的开放接口本身是“下发即忘”的单向控制模式，要实现播放进度控制，需要采用“分段播报+状态机”的设计。以下方案从接口选型、分段策略到前端交互，提供一个完整的落地路径。

解决方案：工作台语音播报对接智能设备的播放进度控制

一、背景与挑战

在仓储拣货、SaaS工单处理或车间指令下发等场景中，用户不仅需要智能硬件（如芯步语音音柱、喇叭）发出声音，更需要对播报过程拥有“掌控感”。常见的痛点包括：长文本播报无法中途停止、紧急任务需要插队、以及无法获知播报还剩多少。

由于芯步的接口模型本质上是 “下发即忘” 的异步控制模式（设备执行结果通过回调推送，且设备端通常不支持服务端主动拉取播放进度），要实现进度控制，核心架构必须从 “单次长文本下发” 转变为 “基于状态机的分片断点播报”。

二、核心技术架构

本方案基于芯步开放的 HTTP API 接口，结合业务后端的状态存储与逻辑运算，实现类似“播放器”的控制效果。

硬件层：采用支持 play（播报）、stop（停止）、volume（音量）及 repeat（重复）命令的智能语音设备。
通讯层：使用 https://api.thingboot.com/{AppID}/device/control/ 接口，通过携带 sign 签名的 POST 请求下发指令。
逻辑层：建立任务队列和状态机，管理“播放中”、“暂停”、“停止”等状态。

三、关键实现逻辑：分段播报与 Token 控制

要实现进度控制，核心难点在于如何“暂停”和“恢复”一段长文本。由于设备SDK层面（硬件层）没有直接提供进度百分比回调，我们需要在应用层通过逻辑模拟实现。

具体策略如下：

语义分片：工作台后端在接收到长文本（如1000字的播报任务）时，不直接下发全文，而是根据标点符号（句号、分号）或固定字数，将其切分为若干个小段（Sentence Chunk），并为每个段分配唯一的 ChunkID。
序列化下发
- 播报开始：下发第一段 {"device":"ID", "order":{"play:gbk:16":"第一段内容"}}。
- 进度记录：服务端记录当前播报到了第几个 ChunkID。
- 链式触发：利用芯步的 异步消息推送 功能。当设备成功播报完一段后，云端会推送“指令执行成功”的回调。后端收到回调后，自动下发下一段。
打断与停止（核心控制）
- 当用户在工作台点击“停止”或“暂停”时，后端立即向设备下发 stop 命令：{"device":"ID", "order":{"stop":"1"}}。
- 同时，后端清空该设备的待播报 Queue（队列），记录中断点 Index。

四、具体实施步骤

步骤 1：建立全局任务状态表

在数据库中建立设备播报状态表，用于存储控制所需的元数据：

字段	类型	说明
`device_id`	String	设备唯一ID（对应芯步device参数）
`task_id`	String	当前播报任务ID
`total_chunks`	Int	总分片数
`current_chunk`	Int	当前播到的分片索引
`status`	Enum	IDLE / PLAYING / PAUSED / STOPPED

步骤 2：对接接口实现播发与监听

利用芯步的 MQTT推送 或 HTTP回调 机制来驱动进度更新。

下发播报请求
POST /device/control/ { "device": "820720", "order": {"play:gbk:16": "您有一个新订单，请及时处理"} }
推荐使用 MQTT 方式下发，这样可以在 api/{AppID}/device/control 主题上同步获得下发结果，网络延迟更低。
监听执行结果（异步回调）芯步平台会在设备执行命令后推送消息。我们需要监听 device/response 主题。
- 如果收到 code:200 且 order 状态完成，则触发 MoveToNext（播下一段）。
- 如果收到超时或错误，则触发重试机制。

步骤 3：前端工作台交互实现

工作台前端（Web/桌面应用）通过 WebSocket 与后端保持长连接，实时获取设备状态：

进度展示：后端根据 current_chunk / total_chunks 计算出百分比（如 60%），推送给前端，渲染成进度条。
音量/语速控制：在工作台设置滑块，实时调用芯步接口下发 volume（音量 0-9）和 speed（语速 0-9）指令。由于音量调整通常不需要等待播报完成即可生效，用户体验会非常流畅。

步骤 4：高级控制逻辑

紧急插播（高优先级）当有新任务需要立即播报时，先下发 stop 指令停止当前播报，再下发新的高优先级文本。或者利用 extra 字段携带优先级，但更稳妥的做法是在业务层进行队列管理。
防冲突与重入为防止重复下发，每次下发 play 指令前，需检查设备状态表中的 status 字段。如果状态为 PLAYING，新任务应进入等待队列而非直接下发，避免多个语音叠加或设备报错。

五、方案优势

微观进度可见：解决了芯步默认接口只有“成功/失败”二元状态的问题，实现了百分比进度条。
精准打断：利用 stop 命令结合清空队列，实现了“即说即停”，避免无效播报。
低成本实现：无需修改设备固件，完全基于芯步现有的开放 API（/device/control）和异步推送能力实现。

六、注意事项

异步延迟：设备执行回调会有毫秒级延迟，在 UI 上预留一定的动画缓冲，或者在播报最后一段时主动结束任务状态。
设备离线处理：如果调用接口返回 502（设备不存在或不可用），工作台应提示“设备离线”，并清除待执行的任务队列。
文本编码：播报中文时，请确保 order 中的 play:gbk:16 参数编码正确，避免乱码。

通过上述方案，开发者可以利用芯步标准硬件构建出具备专业级播放控制能力（播放/暂停/进度条）的语音工作台。