自定义Movesense固件中LogBook获取数据的字节流偏移问题

我之前也碰到过这个问题，在处理Movesense LogBook的描述符和数据字节流时，HTTP_CONTINUE的偏移确实容易踩坑。结合官方文档和实际调试经验，给你梳理下正确的实现方式：

首先明确核心问题：当请求/Logbook/byId/<Id>/Descriptors或/Logbook/byId/<Id>/Data返回HTTP_CODE_CONTINUE时，下一次GET请求的偏移必须对应服务端已经传输的总字节数，而不是自己盲目累加片段长度。

正确的偏移获取方式 #

你在ByteStream.h里看到的几个方法，作用分别是：

• length()：当前返回的这一段字节流的长度
• transmitted()：从流开始到当前片段为止，服务端已经传输的总字节数（这个才是我们需要的！）
• fullSize()：整个字节流的总大小（如果服务端能提前知道的话）

所以你的回调逻辑应该改成直接用transmitted()的结果作为下一次请求的偏移，而不是自己累加length()——因为transmitted()是服务端维护的准确值，不会因为中间的片段丢失或重复请求出问题。

修正后的代码示例 #

if (resultCode == whiteboard::HTTP_CODE_CONTINUE) {
    const whiteboard::ByteStream &byteStream = rResultData.convertTo<const whiteboard::ByteStream &>();
    // 直接取服务端跟踪的已传输总字节数作为下一次请求的偏移
    uint32_t nextOffset = byteStream.transmitted();
    // 发起下一次GET请求，注意替换成你实际要请求的资源（Descriptors或Data）
    asyncGet(WB_RES::LOCAL::MEM_LOGBOOK_BYID_LOGID_DESCRIPTORS(), 
             AsyncRequestOptions::Empty, 
             currentEntryIdToFetch, 
             nextOffset);
    return;
}

额外注意事项 #

1. 必须持续请求直到结束：步骤3和4的字节流请求一定要循环发起，直到收到HTTP_OK或者错误响应，否则LogBook服务会一直处于“流处理中”的锁定状态，后续请求都会失败。
2. 首次请求偏移设为0：第一次发起Descriptors或Data的GET请求时，偏移参数要传0，之后每次用transmitted()的结果递推。
3. 区分Entries和字节流的逻辑：/Logbook/Entries用的是StartAfterId参数，而字节流用的是偏移量，不要搞混了。

内容的提问来源于stack exchange，提问作者sisyphus