蓝牙 Mesh 电池设备：为什么能及时上报，却不能立即收到控制？

设想一个电池门磁：开门后，手机很快收到了通知；但从手机修改设备设置，却要等一会儿才生效。

同一个设备，为什么“报上来”很快，“发下去”却可能慢？

这不一定是信号差，也不一定是程序卡住了。使用低功耗机制的蓝牙 Mesh 设备，主动发送和等待接收，本来就可能有不同的节奏。

先给答案：设备可以因本地事件醒来发送；但它休眠时，发给它的消息可能先由 Friend 代收，等它主动来取。想弄清等待发生在哪里，就要把这两条路径分开。

这篇解决三个问题：设备怎样少监听、Friend 怎样代收消息，以及怎样检查省电是否影响了需要的响应。

上述门磁是解释机制的假设场景，不是实测案例。以下讨论 SIG Mesh 的 Low Power 与 Friend 机制，具体 SDK、板卡和平台能力需分别核对；本文没有续航或延迟测试结果。

一、先看这张图：发得出去，不等于随时收得到

把设备想成一个不必一直守着收件箱的人：有事时，它可以主动出门送信；别人寄来的信，则可以先由邻居代收，等它来取。

这里的“邻居”就是 Friend，使用低功耗功能的节点叫 Low Power Node，简称 LPN。这个比喻只解释接收节奏，不代表消息一定能送到，也不代表 Friend 可以远程唤醒休眠芯片。

你先查什么？ 把“事件上报”和“远程改设置”分别画出实际路径。手机端可能还有网关、云端和缓存，不要把所有等待都算在 Mesh 无线上。

二、为什么按钮按下能发，手机改设置却要等？

根据芯科文档，LPN 可以主动发送 Mesh 消息，不必等到下一次取消息时才发送。按钮或门磁事件能否及时唤醒设备，则由硬件和应用实现决定。

所以，两种操作应该分开看：

• 本地事件上报：事件触发 → 唤醒处理 → 发送 → 对端处理。
• 远程下行：消息到达 Friend → 等待 LPN 取消息 → 收到并处理 → 必要时报告结果。

主动发送不需要额外等下一次轮询，不等于端到端必然很快；它还可能遇到采样延迟、无线重试和上层处理等待。

反过来，下行慢，也不代表所有主动事件都慢。门磁能及时报告开门，不能单凭这一项就承诺手机修改参数也会马上生效。

你先查什么？ 分别记录本地事件、设备发送、Friend 排队、LPN 取消息和应用生效的时间点。没有对齐时钟时，别直接相减不同设备的时间戳。

三、省电为什么不只是“少发几条消息”？

一个传感器很久才上报一次，如果接收机一直在听，也未必省电。

Bluetooth SIG 对 Low Power 功能的解释，重点在降低接收机开启时间。LPN 与 Friend 建立关系后，可以减少持续监听，由 Friend 缓存符合条件的消息，再按接收时序取回。

但 Friend 不是无限邮箱：它能服务多少节点、缓存多少消息、容纳多少订阅项，受具体实现和资源限制。消息积压、无线重试和反复建链，还可能增加电量开销。

你先查什么？ 先看电流曲线里设备到底在做什么：采样、扫描、发送、取消息，还是一直找 Friend。不要只盯芯片手册的最低休眠电流。

四、把 PollTimeout 调大，就能更省电吗？

不一定。这里要分清“多久去取一次”和“多久没联系就失效”。

实际轮询间隔由协议栈和应用调度决定；当前还有待取消息时，也可能继续轮询。

PollTimeout是 Friendship 的维护超时约束。Friend 在规定时间内没有收到相应请求，可能结束这段关系。它不是应用的唤醒定时器，更不是实测下行延迟。

ReceiveDelay 关心 LPN 发出请求到开始监听前的等待；ReceiveWindow 关心接收窗口。它们同样不能直接当作业务操作周期。

如果减少实际取消息的频率，一部分下行消息通常要等更久。但排队、重试和应用执行还会影响结果，不能只用一个参数承诺最迟多久必达。

你先查什么？ 同时核对应用轮询策略、协议维护参数和实际抓到的时序；不要看到一个 timeout 字段，就把它当成唯一调节项。

五、灯一断电，传感器为什么可能更费电？

假设一盏支持 Friend 的灯为电池节点代收消息，但用户会用机械开关把灯彻底断电。Friend 不在了，原来的接收关系也就不能继续照常使用。

芯科文档提醒：Friend 或 LPN 重启后需要重新建立关系；信号边缘反复丢失、重建，也会增加功耗。找不到合适 Friend 时，不停忙循环搜索不是省电策略，需要按实现设计退避与恢复。

建立关系还需要合适的无线位置。Bluetooth SIG 的入门资料说明，Friend Request 不经中继，不能因为普通消息可以多跳，就假设 LPN 能隔着任意多跳找 Friend。

另外，Friend 不等于 Relay，也不等于业务网关。设备支持中继，不代表支持给 LPN 缓存；叫“网关”的设备，也不保证开放 Friend 功能。电池节点同样不该被默认要求持续替别人转发。

你先查什么？ 核对候选 Friend 的功能、直接可达性和供电习惯，再试断电恢复。不假设旧队列会自动迁移，或更换 Friend 一定无缝。

六、先测平均电流，再讨论一颗电池能用多久

低功耗模式和目标续航之间，还隔着整台产品。

传感器、稳压器、指示灯、调试器和日志都可能影响功耗。正常采样、用户操作、上报、取消息、失败重试与搜索建链，也应计入业务负载。

一个简单的测量思路是：

平均电流 ≈ 各状态“电流 × 时间”的总和 ÷ 总观察时间。

用同一电池侧的口径粗估时：可用容量（mAh）÷ 平均电流（mA）≈ 使用小时数。 有电压转换就要考虑效率，或用一致的能量口径，不能混用两侧参数。

这个结果还不是续航保证。温度、老化、自放电、脉冲放电能力和截止电压都会影响可用电量。

你先查什么？ 分开测正常运行与异常恢复。刚配好、信号很好、没有业务的一小段低电流，不能代表整个使用周期；低电量时也要观察电压跌落与通信是否异常。

七、把这张清单留给样机测试

下面是工程检查建议，不是认证测试；在隔离环境里操作，先约定业务频率、允许等待和成功条件，再记录结果。

看到的现象	优先检查什么	别急着下的结论
能上报，但下发设置要等	上行与下行路径、轮询和排队、生效时间	蓝牙信号一定不好
休眠电流很低，整机却费电	采样、监听、发送、重试和整机外围	换电池或换芯片就能解决
Friend 断电后表现异常	关系丢失、退避、重新建立和恢复结果	队列必然迁移、切换一定无感
连续改参数后结果不符预期	Friend 队列限制、应用处理、最终状态	缓存会永久保留每条历史命令
组消息收不全	模型订阅、Friend 订阅列表、负载	组播等于所有节点都成功
低电量时偶发失联	发射时电压、供电能力、恢复行为	标称容量一定能全部用完

日志记录板卡、SDK、参数、位置和观察窗口，设备身份脱敏，不公开 NetKey、AppKey、DevKey 或设备私钥。

选型时也可以先做一个简单判断：

• 以偶发主动上报为主：值得评估 LPN 与 Friend，但仍要测真实负载。
• 需要及时收到下行命令：先约定允许等待，再验证接收策略和电池预算。
• 既想长期待机，又要求随时接收和持续转发：先检查这些目标是否相容，而不是先承诺续航。

蓝牙 Mesh 能不能用电池，答案不只是“支持低功耗”。更有用的问题是：设备什么时候醒、醒来做什么、消息暂时收不到时怎么办？ 把这三个问题写清楚，才有依据讨论能用多久。

延伸阅读：蓝牙 Mesh 选型与验收清单。

资料与适用范围

• Bluetooth SIG：Bluetooth Mesh Networking: Friendship，2017-08-24。用于基础机制，属于历史入门资料，不替代当前项目版本规范。
• Silicon Labs：Bluetooth Mesh Node Power Consumption，11.0.1。用于主动发送、接收窗口、关系恢复和功耗建议，以实际 SDK 为准。

资料核对日期：2026-11-06。本文是资料分析与工程建议，不把假设场景写成实测经历，也不提供未经验证的续航、延迟或容量保证。