翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
オフボードマネージド統合ハブ
Hub SDK オフボードプロセスの概要
ハブオフボーディングプロセスは、 AWS クラウド 管理システムからハブを削除します。クラウドが DeleteManagedThing リクエストを送信すると、プロセスは 2 つの主要な目的を達成します。
デバイス側のアクション:
ハブの内部状態をリセットする
ローカルに保存されたすべてのデータを削除する
今後の再オンボーディングに備えてデバイスを準備する
クラウド側のアクション:
ハブに関連付けられているすべてのクラウドリソースを削除する
前のアカウントからの完全な切断
お客様は通常、次の場合にハブオフボーディングを開始します。
ハブの関連アカウントの変更
既存のハブを新しいデバイスに置き換える
このプロセスにより、ハブ設定間のクリーンで安全な移行が保証され、シームレスなデバイス管理とアカウントの柔軟性が可能になります。
前提条件
-
オンボーディングされているハブが必要です。手順については、「ハブのオンボーディング設定」を参照してください。
-
/data/aws/iotmi/config/ にある
iotmi_config.jsonファイルで、 にiot_provisioning_stateが表示されていることを確認しますPROVISIONED。 -
で参照される永続的な証明書とキーが、指定されたパス
iotmi_config.jsonに存在することを確認します。 -
HubOnboarding、Agent、Provisioner、および MQTT プロキシが正しく設定され、実行されていることを確認します。
-
ハブに子デバイスがないことを確認します。 DeleteManagedThing API を使用して、続行する前にすべての子デバイスを削除します。
Hub SDK オフボードプロセス
ハブをオフボードするには、次の手順に従います。
hub_managed_thing ID を取得する
iotmi_config.json ファイルは、マネージド統合ハブのマネージドモノ ID を保存するために使用されます。この識別子は、ハブが AWS IoT Managed Integrations サービスと通信できるようにする重要な情報です。マネージド型モノ ID は、JSON ファイルの rw (読み取り/書き込み) セクションの managed_thing_idフィールドの下に保存されます。これは、次のサンプル設定で確認できます。
{ "ro": { "iot_provisioning_method": "FLEET_PROVISIONING", "iot_claim_cert_path": "PATH", "iot_claim_pk_path": "PATH", "UPC": "UPC", "sh_endpoint_url": "ENDPOINT_URL", "SN": "SN", "fp_template_name": "TEMPLATENAME" }, "rw": { "iot_provisioning_state": "PROVISIONED", "client_id": "ID", "managed_thing_id": "ID", "iot_permanent_cert_path": "CERT_PATH", "iot_permanent_pk_path": "KEY", "metadata": { "last_updated_epoch_time": 1747766125 } } }
オフボードハブにコマンドを送信する
アカウントの認証情報を使用して、前のセクションでmanaged_thing_id取得した で コマンドを実行します。
aws iot-managed-integrations delete-managed-thing \ --identifierHUB_MANAGED_THING_ID
ハブがオフボードされたことを確認する
アカウントの認証情報を使用して、前のセクションでmanaged_thing_id取得した で コマンドを実行します。
aws iot-managed-integrations get-managed-thing \ --identifierHUB_MANAGED_THING_ID
成功と失敗のシナリオ
成功シナリオ
ハブをオフボードするコマンドが成功した場合、次のサンプルレスポンスが期待されます。
{ "Message" : "Managed Thing resource not found." }
さらに、ハブオフボーディングコマンドが成功した場合、次のサンプルが観察iotmi_config.jsonされます。rw セクションに iot_provisioning_stateとオプションでメタデータのみが含まれていることを確認します。メタデータがないことは許容されます。 は NOT_PROVISIONED iot_provisioning_stateである必要があります。
{ "ro": { "iot_provisioning_method": "FLEET_PROVISIONING", "iot_claim_cert_path": "PATH", "iot_claim_pk_path": "PATH", "UPC": "1234567890101", "sh_endpoint_url": "ENDPOINT_URL", "SN": "1234567890101", "fp_template_name": "test-template" }, "rw": { "iot_provisioning_state": "NOT_PROVISIONED", "metadata": { "last_updated_epoch_time": 1747766125 } } }
失敗シナリオ
ハブをオフボードするコマンドが失敗した場合、次のサンプルレスポンスが期待されます。
{ "Arn" : "ARN", "CreatedAt" : 1.748968266655E9, "Id" : "ID", "ProvisioningStatus" : "DELETE_IN_PROGRESS", "Role" : "CONTROLLER", "SerialNumber" : "SERIAL_NO", "Tags" : { }, "UniversalProductCode" : "UPC", "UpdatedAt" : 1.748968272107E9 }
-
ProvisioningStatus が の場合は
DELETE_IN_PROGRESS、「Hub recovery」の手順に従います。 -
ProvisioningStatus が でない場合
DELETE_IN_PROGRESS、ハブをオフボードするコマンドが Managed Integrations クラウドで失敗したか、 Managed Integrations クラウドで受信されませんでした。「Hub recovery」の手順に従ってください。 -
オフボードが失敗した場合、
iotmi_config.jsonファイルは以下のサンプルファイルのようになります。
{ "ro": { "iot_provisioning_method": "FLEET_PROVISIONING", "iot_claim_cert_path": "PATH", "iot_claim_pk_path": "PATH", "UPC": "123456789101", "sh_endpoint_url": "ENDPOINT_URL", "SN": "123456789101", "fp_template_name": "test-template" }, "rw": { "iot_provisioning_state": "PROVISIONED", "client_id": "ID", "managed_thing_id": "ID", "iot_permanent_cert_path": "PATH", "iot_permanent_pk_path": "PATH", "metadata": { "last_updated_epoch_time": 1747766125 } } }
(オプション) Hub SDK をオフボーディングした後
重要
以下のシナリオでは、Hub SDK のオフボーディング後に実行するオプションのアクションが失敗した場合、またはオフボーディング後にハブを再オンボーディングする場合に実行するアクションを一覧表示します。
- 再オンボード
-
オフボーディングが成功した場合は、ステップ 3: マネージド型モノを作成する (フリートプロビジョニング) と、残りのオンボードプロセスに従って Hub SDK をオンボードします。
- ハブリカバリ
-
- デバイスハブのオフボーディングが成功し、クラウドオフボーディングが失敗する
-
GetManagedThing API コールが
Managed Thing resource not foundメッセージを返さないが、ファイルがiotmi_config.jsonオフボードされている場合。サンプル JSON ファイルの「成功シナリオ」を参照してください。このシナリオから復旧するには、「強制削除」を参照してください。
- デバイスハブのオフボーディングが失敗する
-
このシナリオでは、ファイルが正しくオフボード
iotmi_config.jsonされません。サンプル JSON ファイルの「失敗シナリオ」を参照してください。このシナリオから復旧するには、「強制削除」を参照してください。がまだオフボードされていない場合
iotmi_config.jsonは、ハブを工場出荷時リセットする必要があります。 - デバイスハブのオフボーディングとクラウドオフボーディングが失敗する
-
このシナリオでは、
iotmi_config.jsonはオフボードされず、ハブステータスはACTIVATED、、または のいずれかですDISCOVERED。このシナリオから復旧するには、「強制削除」を参照してください。強制削除
iotmi_config.jsonが失敗した場合、またはオフボードされていない場合は、ハブを工場出荷時リセットする必要があります。 - ハブがオフラインで、ハブのステータスが DELETE_IN_PROGRESS である
-
このシナリオでは、ハブはオフラインで、クラウドはオフボーディングコマンドを受け取ります。
このシナリオから復旧するには、「強制削除」を参照してください。
- 強制削除
-
デバイスハブのオフボーディングが成功せずにクラウドリソースを削除するには、次の手順に従います。このオペレーションでは、クラウドとデバイスの状態の間に不整合が発生し、将来のオペレーションで問題が発生する可能性があります。
ハブの
managed_thing_idおよび force パラメータを使用して DeleteManagedThing API を呼び出します。aws iot-managed-integrations delete-managed-thing \ --identifierHUB_MANAGED_THING_ID\ --force次に、GetManagedThing API を呼び出し、 が返されることを確認します
Managed Thing resource not found。これにより、クラウドリソースが削除されたことを確認します。注記
クラウドとデバイスの状態の間に不整合が生じる可能性があるため、このアプローチはお勧めしません。通常、クラウドリソースを削除する前に、デバイスハブのオフボーディングを成功させることをお勧めします。