ota-deployment-guardian について
ESP32、Nano ESP32、Uno R4 WiFi の OTA 更新を計画・トラブルシューティングするスキルです。更新経路の維持、検出やアップロードの問題診断、展開前の復旧計画確認を重視します。
主な機能
- 01ボード別の OTA ガイダンス
- 02ネットワーク検出とポートのトラブルシューティング
- 03スケッチ更新後の OTA 経路確認
- 04ロールバックと復旧の計画
- 05ボードとコアのバージョン確認
- 06セキュリティと保守の適用範囲
活用シーン
- 01ネットワークポートが消える問題の診断
- 02更新後に OTA が止まる原因の確認
- 03リモート機器展開のロールバック計画
- 04到達性とアップロード検出の切り分け
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ wedsamuel1230/ arduino-skills --skill ota-deployment-guardianインストール後、Claude Code で/ota-deployment-guardianを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/discovery-and-network-ports.mdota-safe-sketch.mdrecovery-and-rollback.md詳細
OTA デプロイガーディアン
デバイスをリモートで更新する際、更新経路を失うと大きな損失につながる場合に、このスキルを使用します。
リソース
references/ota-safe-sketch.md- スケッチ側で最低限必要な OTA の契約とガードレールreferences/discovery-and-network-ports.md- IDE、mDNS、IP 到達性、消失するネットワークポートのトリアージreferences/recovery-and-rollback.md- ロールアウトの安全性、ロールバック、最終手段となる復旧計画../../docs/board-support/uno-r4-family.md- Uno R4 Minima と Uno R4 WiFi のボードファミリーに関する注意事項
使用する場面
以下のような依頼で、このスキルを使用します。
- ESP32、Nano ESP32、または Uno R4 WiFi への OTA アップロード
- ネットワークポートが一時的に表示されたあと、消える
- IDE からデバイスに ping は通るが、アップロードできない
- リモートの気象観測所や設置済みボードを更新可能な状態に保つ
- OTA デプロイ後にデバイスが自ら使用不能になるのを防ぐ
後日 OTA デプロイを予定していることがユーザーに明らかな場合を除き、通常の作業台での USB アップロードには、このスキルを使用しないでください。
ワークフロー
- ボードファミリーを確認します。
- ESP32 または Nano ESP32 ->
references/ota-safe-sketch.mdを開きます - Uno R4 WiFi ->
../../docs/board-support/uno-r4-family.mdも開きます
- ESP32 または Nano ESP32 ->
- ディスカバリーの失敗とスケッチの失敗を切り分けます。
- ping は通るがネットワークポートが消える ->
references/discovery-and-network-ports.mdを開きます - OTA が一度は成功したが、新しいスケッチの実行後に使えなくなる -> 新しい
スケッチが
ota-safe-sketch.mdの OTA 経路を引き続き実装しているか確認します
- ping は通るがネットワークポートが消える ->
- ロールアウトを提案する前に、復旧経路、ロールバック戦略、USB 経由で利用可能な状態を保つべきものについて、
references/recovery-and-rollback.mdを確認します。 - 以前は OTA が機能していたものの、後から不安定になった場合は、コアバージョンの変更も要因として考慮します。
セキュリティと保守の境界
シークレット、署名済みイメージ、依存関係のバージョン、段階的なロールアウト、ロールバック、脆弱性への対応、廃止については、ルーターの接続デバイス向けセキュリティリファレンスを使用してください。このスキルに記載されたボード固有の OTA 手順だけでは、デバイスがセキュアブートや認証済み更新に対応していること、または現場に設置したデバイスを復旧できることの証明にはなりません。対象デバイスで、これらの対策を確認してください。
基本ルール
- スケッチが OTA 経路を維持していない限り、新しいスケッチの書き込み後も OTA が利用可能だと想定しないでください。
- 到達性と OTA のディスカバリーを区別します。ping が成功しても、IDE がデバイスを検出してアップロードできるとは限りません。
- 復旧コストの高いリモートデバイスでは、少なくとも1つの復旧経路を予備として確保します。
- Uno R4 WiFi では、ボードファミリー固有の注意事項を明示します。WiFi 側の動作モデルは、通常の ESP32 ボードとは異なります。
検証
- スケッチが起動後も意図したネットワークに接続し、OTA 経路を提供し続けることを確認します。
- 障害がディスカバリーのみ、アップロードのみ、またはデバイス全体への到達性の喪失のどれに当たるか確認します。
- リモートデプロイでは、更新を推奨する前にロールバック計画または物理的な復旧計画を確認します。
- ボードまたはコアのバージョンが最近変更された場合、原因がユーザーコードにあると結論づける前に、正確なバージョンを記録します。
統合
- コマンドラインからのアップロードやポートの確認が必要な場合は、
arduino-cli-skillと併用します。 - OTA 経路の障害が USB 接続時以外、または現場の電源条件下でのみ発生する場合は、
field-power-and-connectivity-triagerと併用します。 - OTA スケッチ自体がビルドできない場合は、
error-message-explainerと併用します。
共通の出力要件
Arduino スキル共通の契約に従い、前提条件、必要なツールとバージョン、実装手順、証明段階ごとのテストと証拠、既知の制限事項、復旧とセキュリティに関する注意事項を記載します。
コメント
Markdown 対応