Bluetooth Mesh の電池機器：すぐ報告できるのに、制御はすぐ受信できないのはなぜ？

電池式ドアセンサーを想像してください。開けるとスマートフォンにすぐ通知が届くのに、スマートフォンから設定を変えると反映まで待たされます。

同じ機器なのに、送信と受信で待ち時間が違うのはなぜでしょうか。

必ずしも電波が弱い、プログラムが止まったという話ではありません。低消費電力の仕組みを使う Bluetooth Mesh 機器では、自発的な送信と受信待ちが別のリズムで動くことがあります。

答えを先に言えば、ローカルイベントで起きて送信できる一方、睡眠中の下りメッセージは Friend が預かり、機器が取りに来るまで待つことがあるからです。まず経路を分けます。

本稿では、受信待機を減らす方法、Friend の代受け、そして省電力が必要な応答に影響していないかの確認を説明します。

ドアセンサーは仮の説明例で、測定結果ではありません。SIG Mesh の Low Power と Friend を対象にし、SDK、基板、プラットフォームの対応は別途確認します。電池寿命・遅延の実測はしていません。

1. 図で確認：送れることと常時受信できることは別

郵便受けにずっと張り付いていない人を考えてください。用事があれば自分で手紙を出せますが、届いた手紙は隣人に預かってもらい、後で受け取ります。

隣人が Friend、低消費電力機能を使うノードが Low Power Node、LPN です。これは受信のタイミングを説明する比喩であり、配送保証でも、Friend が眠るチップを遠隔起床できるという意味でもありません。

まず確認： イベント報告と遠隔設定の経路を別々に描きます。スマートフォン側にはゲートウェイ、クラウド、キャッシュもあり得ます。待ち時間をすべて Mesh 無線のせいにしません。

2. ボタンは送れるのに、設定変更はなぜ待つ？

Silicon Labs の資料では、LPN は次のポーリングを待たずに送信できます。ボタンやドアの変化で素早く起きるかはハードウェアとアプリ次第です。

• ローカルイベント： 発生 → 起床・処理 → 送信 → 相手側処理。
• 下り： Friend に到着 → LPN の取得待ち → 受信・処理 → 必要なら結果報告。

次のポーリングを待たないことは、端から端まで速い保証ではありません。サンプリング、再試行、上位処理も関係します。下りが遅くても、すべての自発イベントが遅いとは限りません。ドア通知の速さだけで設定の即時反映を約束できません。

まず確認： イベント、送信、Friend の待ち行列、LPN の取得、設定の実反映を記録します。同期していない機器の時刻を直接引き算しません。

3. 送信を減らすだけでは、なぜ省電力にならない？

報告が少ないセンサーでも、受信機が常時動けば電力を使います。

Bluetooth SIG は Low Power を受信機の動作時間削減で説明しています。Friendship を確立すると、Friend が対象メッセージを保存し、LPN が後で取ることで連続受信を減らせます。

ただし Friend は無限の郵便受けではありません。台数、メッセージ、購読の上限は実装と資源次第です。滞留、再送、関係の再確立も消費を増やします。

まず確認： 電流波形が示す動作は、計測、スキャン、送信、取得、Friend 探索のどれかを見ます。データシートの最低スリープ電流だけでは製品を評価できません。

4. PollTimeout を大きくすれば省電力になる？

必ずしもそうではありません。「取りに行く頻度」と「連絡が途絶えて関係が切れるまで」を分けます。

実際のポーリング間隔はスタックとアプリのスケジューリングで決まります。メッセージが残っていれば続けて取得することもあります。

PollTimeout は Friendship 維持のタイムアウトです。所定の要求が届かなければ Friend は関係を終了することがあります。アプリの起床タイマーでも、実測下り遅延でもありません。

ReceiveDelay は LPN の要求から受信開始まで、ReceiveWindow は受信窓に関係します。これらも業務操作の周期そのものではありません。

取得頻度を下げると、一部の下りは一般に長く待ちます。ただし行列、再送、実行も関係するため、単一パラメーターで最大到着時間を保証できません。

まず確認： アプリの取得方針、関係維持設定、実際のタイミングを照合します。timeout という名前だけで唯一の調整項目と考えません。

5. 照明を切るとセンサーが余計に電力を使うのはなぜ？

Friend 対応の照明が電池ノードを支えていても、機械スイッチで完全に電源を切れば、その受信関係は通常どおり続きません。

Silicon Labs は Friend または LPN の再起動後に再確立が必要と説明しています。電波境界で切断と再確立を繰り返しても消費が増えます。探索をビジーループで続けず、実装に合ったバックオフと復旧を設計します。

配置も重要です。Bluetooth SIG の入門資料では Friend Request は中継されません。通常の通信がマルチホップだからといって、任意の段数越しに Friend を発見できるわけではありません。

Friend、Relay、業務ゲートウェイは別の役割です。 中継対応だけでは LPN 向け保存を保証せず、ゲートウェイという名前でも Friend を提供するとは限りません。電池ノードが常時中継すべきとも決めつけません。

まず確認： 候補の機能、直接到達性、電源の使われ方を確認して停電試験をします。旧行列の移行や切替の無停止動作を前提にしません。

6. 電池寿命を語る前に製品の平均電流を測る

省電力モードと寿命の間には製品全体があります。センサー、レギュレーター、LED、デバッガー、ログも影響します。計測、操作、報告、取得、再試行、探索を負荷に含めます。

平均電流 ≈ 各状態の「電流 × 時間」の総和 ÷ 総観測時間。

同じ電池側の条件なら、使用可能容量（mAh）÷ 平均電流（mA）≈ 動作時間（時間） が概算です。電圧変換は効率を考慮するか、整合したエネルギーで計算し、変換前後を混ぜません。

これは保証ではありません。温度、劣化、自己放電、パルス供給能力、終止電圧で使える容量は変わります。

まず確認： 正常運転と異常復旧を分けて測ります。設定直後、好条件、無通信の短時間波形は全周期を代表しません。低残量での電圧降下と通信異常も観察します。

7. 試作機用にこの表を残す

これは技術的な確認で認証試験ではありません。隔離環境を使い、頻度、許容待ち時間、成功条件を先に決めます。

現象	優先して見る点	急いで決めつけないこと
報告できるが設定が遅い	両経路、ポーリング、行列、反映	必ず電波が悪い
スリープは低電流なのに消耗	計測、受信、送信、再試行、周辺回路	電池やチップ交換で解決
Friend の電源断後に異常	関係喪失、バックオフ、再確立、復旧	行列移行と無感切替が保証される
設定連打で予想外の状態	行列上限、アプリ処理、最終状態	過去の全命令が永久保存される
グループメッセージが欠ける	モデルと Friend の購読、負荷	マルチキャストなら全台成功
低残量で時々切れる	送信電圧、電源能力、復旧	公称容量をすべて使える

基板、SDK、設定、位置、観測時間を記録し、機器情報は匿名化します。NetKey、AppKey、DevKey、秘密鍵を公開しません。

選定は次の問いから始められます。

• たまの自発報告が中心か： LPN と Friend を評価し、実負荷を測る。
• 下りを適時受信する必要があるか： 許容待ちを決め、省電力予算と合わせて検証する。
• 長期待機、即時受信、常時中継を全部要求するか： 寿命を約束する前に目標の両立を確認する。

単に Bluetooth Mesh が電池対応かではなく、いつ起き、何をし、今は受信できないときどうするかが重要です。その後で動作時間を議論できます。

関連：Bluetooth Mesh の選定・受け入れチェックリスト。

資料と適用範囲

• Bluetooth SIG: Bluetooth Mesh Networking: Friendship、2017-08-24。基礎の歴史的入門資料で、現行の適用仕様の代わりではありません。
• Silicon Labs: Bluetooth Mesh Node Power Consumption, 11.0.1。送信、受信窓、復旧、電力の説明。実際の SDK を確認してください。

資料確認日：2026-11-06。文書分析と技術的提案であり、実測経験や未検証の電池寿命、遅延、容量の保証ではありません。