ESP32でのWi-Fiセットアップテストの自動化

Wi-Fi対応の新しいコネクテッド製品を顧客が最初に行うことは、Wi-Fiセットアップを完了させることです。そのため、製品の他の部分がどのように変化しても、常に信頼性が高く、毎回機能する必要があります。これはGroundrunシステムで実現できることです。セットアップしてみましょう。 セットアップ まず、ESP32のオーバー・ザ・エア（OTA）アップデートのテストで行ったのと同じように、ハードウェアをループに組み込む必要があります。このテストでは、EspressifのESP32-C6開発ボードを使用しました。Groundrunを使えば、ループに組み込むのは簡単です。次のように行います。 Androidフォン Groundrunリグ ESP32-C6開発ボード ESP32-C6開発ボードとAndroidフォンは、どちらもUSBでGroundrunリグに接続されます。 ESP32-C6ボードをUSBでGroundrunリグに接続します。 AndroidフォンをUSBで同じGroundrunリグに接続します。 これで完了です。 Wi-Fiコミッショニング コネクテッドデバイスでWi-Fiネットワークをセットアップするにはいくつかの方法があり、ESP32ファミリーはそれらの範囲をサポートしています。 Bluetooth。 フォンはBluetooth Low Energy経由でボードとペアリングし、ネットワーク名とパスワードを直接送信します。 Soft AP。 ボードは一時的なWi-Fiネットワークを起動し、フォンはそのネットワークに参加して実際の認証情報を送信してから、ボードが実際のネットワークに接続します。 Wi-Fiキャプティブポータル。 Soft APと同じネットワークですが、フォンはホテルのWi-Fiログインページのように、認証情報を入力するためのウェブページに直接リダイレクトされます。アプリは不要です。 SmartConfig。 Espressif独自の技術で、ESP32上でESP-Touch v2として実行され、ESP-IDF SDKに組み込まれています。フォンはホームネットワークに接続したまま、認証情報をエンコードされたパケットのストリームとしてブロードキャストします。まだどのネットワークにも接続されていないボードは、プロミスキャスモードで傍受してそれらを取得します。 WPS（Wi-Fi Protected Setup）。 Wi-Fi Allianceの業界標準です。ルーターのボタンを押すと、ボードはルーターと直接認証情報をネゴシエートして参加できます。 私たちの目標は、これらすべてをテストすることです。 フォンはホームネットワークに接続したまま、認証情報をエンコードされたパケットのストリームとしてブロードキャストします。まだどのネットワークにも接続されていないボードは、プロミスキャスモードで傍受してそれらを取得します。 スマートフォンアプリ 典型的なケースでは、すでにスマートフォンアプリがあります。この場合、Wi-Fi接続方法を示すための簡単なものが必要だったので、Claudeに簡単なアプリを開発してもらいました。各メソッドに対して、正しいバイトを正しいタイミングで送信するだけで、それ以上の機能は必要ありません。アプリは見栄えが良くなくても構いません。実際、見栄えは良くありません。 アプリのホーム画面、各メカニズムに1つのボタン。 ファームウェア 既存のコネクテッド製品の場合、ファームウェアはすでに書かれています。この場合、AI開発ツールがそれを理解できるように、ベストプラクティスに従う必要があります（コネクテッド製品開発でAIコーディングエージェントの使用を開始する方法を参照）。Groundrunシステムは、ESP32ファームウェアを扱うためのスキルを提供することでここで役立ち、上記の各Wi-Fiセットアップメカニズムを実装したコードファイルを作成しました。Claude Codeはリグとそのハードウェアにアクセスできるため、この作業を独立して行います。私たちはそれに計画、目標、停止条件を与えるので、それが目指すものといつ停止するかを知っています。 結果として得られたファームウェアコードは次のようになります（これはWPSメカニズムです）。 ```c void app_main(void) { ESP_ERROR_CHECK(nvs_flash_init()); ESP_ERROR_CHECK(esp_netif_init()); ESP_ERROR_CHECK(esp_event_loop_create_default()); esp_netif_t *sta_netif = esp_netif_create_default_wifi_sta(); assert(sta_netif); wifi_init_config_t cfg = WIFI_INIT_CONFIG_DEFAULT(); ESP_ERROR_CHECK(esp_wifi_init(&cfg)); ESP_ERROR_CHECK(esp_event_handler_register(WIFI_EVENT, ESP_EVENT_ANY_ID, &wifi_event_handler, NULL)); ESP_ERROR_CHECK(esp_event_handler_register(IP_EVENT, IP_EVENT_STA_GOT_IP, &got_ip_event_handler, NULL)); ESP_ERROR_CHECK(esp_wifi_set_mode(WIFI_MODE_STA)); /* Read any Wi-Fi credentials esp_wifi's own config store already holds * (WIFI_STORAGE_FLASH, the default -- backed by NVS) BEFORE starting * the driver. A freshly mass-erased board has none; a board that * already completed WPS once and rebooted does. */ wifi_config_t stored_config; memset(&stored_config, 0, sizeof(stored_config)); esp_err_t get_config_err = esp_wifi_get_config(WIFI_IF_STA, &stored_config); bool has_stored_creds = (get_config_err == ESP_OK) && (stored_config.sta.ssid[0] != '\0'); ESP_ERROR_CHECK(esp_wifi_start()); if (has_stored_creds) { esp_wifi_connect(); } else { start_wps(); } } ``` ユーザーフローの設定 ここでのユーザーフローは単純です。ユーザーがアプリを開き、Wi-Fiパスワードを入力し、ESP32がネットワークに参加します。方法はそれぞれ異なるため、5つの方法すべてに固有のパスがあり、Groundrunのフロービルダーにステップバイステップで記述されています。 フロービルダーでのSmartConfigフロー、ステップリストとして。 同じフロー、インストーラー、アプリ、ボード間のシーケンス図として。 ClaudeがGroundrunスキルセットを使用してマッピングを行い、各フローはClaude Codeが単独で再度実行できるものです。 テストの実行 これで全てが稼働しているので、Groundrunコーディネーターでのインタラクティブな実行と、継続的インテグレーション（CI）の回帰テスト実行の両方でWi-Fiセットアップフローを実行できます。システムに変更を加えるたびに回帰テストを実行します。この部分は堅固でなければなりません。 回帰実行には、同じパイプラインで実行されるアップデートシナリオと共に、5つのWi-Fiセットアップ方法すべてがグリーンになっているものが含まれています。これらの回帰実行には、ESP32でのOTAアップデートを意図的に壊すという記事で説明したオーバー・ザ・エア・アップデートテストも含まれています。 タイミング 各CI実行は自動的に時間計測され、コーディネーターは各ステップを個別に記録するため、フラッシュ、アプリのインストールと起動、メカニズムの実行、ボードが参加したことを確認するまでの待機時間など、各フェーズに費やされた時間を分解できます。 フラッシュ+ブート アプリのインストール/起動 APセットアップ メカニズム パス-待機 ティアダウン 0秒 25秒 50秒 75秒 125秒 150秒 101秒 Bluetooth 124秒 Soft AP 63秒 キャプティブポータル 74秒 SmartConfig 45秒 WPS フェーズごとに内訳された、メソッドごとの平均シナリオ時間。 グラフは、フラッシュとブートがSmartConfigを除いてほぼ同じコスト（22〜24秒）であることを示しています。SmartConfigは、ブロードキャストを監視するために使用する2番目のボードもフラッシュするため、そのフェーズは37秒になります。それ以降は、メカニズムセグメントはメソッドごとに大きく異なるため、単独で比較する価値があります。 0秒 15秒 30秒 45秒 60秒 75秒 90秒 53秒 Bluetooth 77秒 Soft AP 38秒 キャプティブポータル 11秒 SmartConfig 6秒 WPS メカニズムステップのみに費やされた平均時間。 このように分離すると、Soft APのメカニズム時間はWPSの約13倍になり、システムダイアログとマルチスクリーンフローがその理由を裏付けています。SmartConfigとWPSはどちらも15秒未満に収まり、Bluetooth、Soft AP、キャプティブポータルよりもはるかに短いです。 奇妙な点 5つの方法を並行してテストしたことで、それらの間の実際の違いが明らかになりました。キャプティブポータルは5つの中で最もトリッキーです。フォンが表示するサインインページは数秒しか開かず、フォンのオペレーティングシステム自体がいつ閉じるかを正確に決定します。フォーム全体をそのウィンドウ内に記入して送信しないと、認証情報はボードに到達しません。BluetoothとSoft APはどちらも、フォンがボードのネットワークに参加する前にシステムポップアップをトリガーしますが、そのポップアップが表示されるまでに数秒かかる場合があり、その間フォンはボードをスキャンします。私たちのテストはそれを待ちます。WPSはアプリを全く必要としません。ボタンを押すと、ルーターとボードが直接認証情報を交換します。SmartConfigはテストで他の4つよりも顕著に遅く、時にはそれよりもはるかに遅く、単一の原因を特定できないまれな失敗もありました。WPSのテストでは、ルーター役も務める必要がありました。私たちのリグは独自のテンポラリWi-Fiネットワークを起動します（ボードの無線が5GHzに届かないため2.4GHzにピン留めされています）。その後、各実行後にそれを破棄します。 結論 ユーザーがWi-Fi対応のコネクテッド製品で最初に行うことは、セ