Wi-Fi AP初期設定の障害復旧設計と受入試験

Wi-Fi設定フローが製品として納品可能になるのは、認証情報の誤り、ルーター不在、設定中断、停電から、ファームウェアの再書込みなしで復旧できるときです。明確な時間境界、確認できる結果、保護された認証情報、意図的に設定へ戻る入口を持つ状態機械として設計します。機器へのHTTP送信成功は、その一段階にすぎません。

本記事は、機器が設定用アクセスポイントを提供した後、顧客のルーターへ接続する方式を扱います。LinuxとMCUの両製品に適用できますが、API詳細はドライバーとSDKによります。時間例と試験はすべて設計上の提案であり、製品の実測値ではありません。

画面を設計する前に成功を定義する

四つの節目を区別します。スマートフォンが候補設定を送信したこと、機器が関連付けと認証を完了したこと、利用可能なIP設定を取得したこと、必要なアプリケーションサービスに到達したことです。ローカルコントローラーでは最後の条件がLAN内での検出かもしれません。クラウド製品では認証付き登録やヘルスチェックかもしれません。どの節目で新設定を確定するかを記載してください。

クラウド障害をWi-Fiパスワード誤りの証拠にしてはいけません。Wi-FiとDHCPが成功してもバックエンドが利用できなければ、「ネットワーク設定済み、サービス利用不可」を独立状態として保持します。それで設置完了としてよいかは製品方針で決め、何度もパスワード画面に戻さないようにします。

対応ルーターの周波数帯、安全方式、SSIDの符号化と長さ、非公開ネットワークの手順、企業ネットワーク要件を定義します。2.4 GHz専用モジュールは再試行しても5 GHz専用ネットワークにつながりません。WPA-Enterprise、上流の認証ポータル、管理された企業ネットワークには、明示的な対応または除外が必要です。

設定変更をトランザクションとして扱う

最後に動作確認できた設定と、試験中の候補を分けて保持します。試行ごとにIDを割り当てます。同じIDの再送は同じ試行の状態を返し、接続処理を並行して開始しないようにします。新しい試行は、古い試行を管理された形で取り消すか置き換えます。

対応するプラットフォームでは、永続保存した正常設定を直ちに上書きせずに候補認証情報を試します。合意した成功条件の後で、版番号付きレコードを原子的に確定します。整合性情報とスキーマ版を記録し、確定中に停電した場合の起動動作を定義してください。保存時暗号化には適切な鍵保管設計が必要であり、認証付き設定の代用にはなりません。

一部のSDK管理機能は、アプリ自身の検証完了前に認証情報を永続化します。例えばESP-IDF 5.2.6のWi-Fiプロビジョニングガイドは、保存情報に基づく設定済み判定と、失敗・再起動時の動作を説明しています。これは版に依存する統合条件です。選択した管理機能のリセット・再設定APIを確認し、その周囲に製品状態モデルを実装します。「認証情報が存在する」と「設置成功」を同一視しないでください。

意図して開く復旧入口を残す

設定を再開する操作を、認証付きコマンド、物理ボタン操作、設置ツールなどから定義します。長押し時間、LED表示、誤って短押ししたときの影響を明記します。ネットワークリセットでは通常、校正値、機器ID、無関係なアプリ設定を保持します。工場出荷状態へのリセットは、明確に表示される別操作です。

提案例として、設定窓を10分間開き、一回のルーター接続に設定可能な期限を設け、期限後は再試行または以前の設定へ戻す方針があります。数値は対応ルーターと設置手順から選ぶ必要があります。初回失敗を理由に、制限のない設定ネットワークを恒久的に開放してはいけません。

設定が自動終了する場合、スマートフォンが結果を確実に知る方法を用意します。接続中の状態照会、切替前の成功証明表示、LED状態、移行先ネットワークでの再検出などが考えられます。TCP切断だけでは、成功とクラッシュを区別できません。

スマートフォンの通信経路消失を想定する

スマートフォンはモバイル通信を優先したり、インターネットのないWi-Fiを離れたり、制限されたポータルブラウザーを表示したりします。対応Android/iOS版を、モバイル通信の有効・無効それぞれで試験します。自動ポータル検出が動かなくても使えるローカルURLまたはアプリ手順を文書化してください。オフライン必須の設定画面を、インターネット上のスクリプトやフォントに依存させないようにします。

APとSTAの共存には無線固有の制限があります。ESP32の文書では共通のホームチャネルを使い、STA側が優先されます。そのため別チャネルのルーターへの接続が設定側の通信に影響し得ます。メーカーのWi-Fiドライバーガイドを参照し、実際のSDK・モジュール版で確認してください。Linuxチップセットもドライバー対応のインターフェース組合せが必要です。APとSTAの単独実演から同時動作を推定せず、試験します。

状態取得エンドポイントは再接続に耐える設計にします。最新の試行結果をHTTP接続とは独立して保存し、試行ID、段階、安全な理由コードを返します。古いブラウザータブが新しい成功済み設定を上書きしないようにしてください。

認証情報の転送と診断を保護する

機器ごとの登録用秘密情報など、製品に適した認証付き登録方式を使います。オープンAPと未認証パスワードフォームの組合せは重要な設定経路を露出させます。通信保護と機器ID確認を一緒に検討してください。信頼・発見の設計がない無作為な自己署名証明書は、設置担当者に警告を無視する習慣を付けるだけになりかねません。

Wi-Fiパスワードを出力するサンプルログを流用してはいけません。段階、経過時間、SDK切断理由、再試行数、ファームウェア版、匿名化したネットワークIDを記録します。診断出力を制限し、不要になった一時候補認証情報は削除します。試行数と同時セッションを制限し、二台のスマートフォンが同じ機器を設定するときの制御権を定義してください。

理由ごとに対処は異なります。認証拒否なら認証情報や安全方式を確認します。対応APがなければ帯域、距離、非公開SSID、検索方針を確認します。DHCPタイムアウトはアドレスサービスやLANを示します。TLS・登録失敗はアプリ経路であり、時計、証明書、アカウント方針が関係し得ます。

試験表で復旧を証明する

試験	期待する復旧	残す証拠
誤ったパスワードの後に正しいものを入力	再書込みやID消去なしで新試行を受理	試行ID、理由、最終接続状態
接続途中でルーターが消失	有界タイムアウト、旧正常設定または設定入口を復旧可能	段階時系列、試行・資源カウンター
関連付け成功後にDHCPを遮断	アドレス障害を認証障害と別表示	Wi-FiイベントとDHCPキャプチャ
ネットワーク正常、クラウド接続先不在	サービス障害を識別し、方針に従い有効Wi-Fi設定を保持	秘密情報を含まないIP・DNS・アプリ状態
受信、試験、確定中に停電	有効な旧/新設定または明確な復旧モードで起動	起動ログ、レコード版、整合性検査
一台目がAPを離れ二台目が参加	試行制御権を保持し、最新結果を取得可能	クライアント表示と同時要求の挙動
設定期限切れと物理ネットワークリセット	期限で閉鎖し、許可された操作で校正値を失わず再開	無線スキャン、ボタン/LED記録、設定比較

任意時刻だけでなく、状態遷移の前後で故障を繰り返します。ルーターのチャネル変更、弱電界、無線とアプリの同時負荷も含めます。全試行に対する復旧成功数、全失敗、利用可能状態までの時間を記録してください。平均だけでは不十分です。少数でも終わらない試行があればサポートコストを大きく左右します。

簡潔な診断インターフェースを提供する

次の状態文書はアプリケーション契約の例であり、SDK APIではありません。理由と段階の語彙はスマートフォンアプリとともに版管理してください。

{
  "schema": 1,
  "attempt_id": "setup-0042",
  "phase": "waiting_for_ip",
  "result": "pending",
  "elapsed_ms": 12400,
  "reason": null,
  "can_retry": false
}

試行期限には単調時刻を使い、時計補正が再試行を不意に延長・短縮しないようにします。ウォッチドッグは処理停止を検出すべきですが、外部ルーターがないだけで正常な機器を再起動させるべきではありません。繰り返す失敗の間、メモリーとソケット使用量を追い、一回の実演で見えないリークを検出します。

初期設定の納品物全体を合意する

Obeitaの機器接続サービスは、機器・スマートフォン・ルーターの統合範囲を整理するために利用できます。納品済みESP32 Wi-Fi/Bluetoothゲートウェイ事例はAP/STA関連の取り組みを示しますが、独立したMeshの役割は本設定フローの実装・認定済み証拠ではありません。

モジュールとSDKの版、対象スマートフォン一覧、対応ルーター・安全方式、現行エラーログ、必要な設置手順をご提供ください。納品には正常系の設定画面だけでなく、状態定義、スマートフォン表示エラー、認証情報処理、リセット仕様、再現可能な障害試験を含めます。