Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Offboard-Hub für verwaltete Integrationen ## Überblick über den Offboard-Prozess des Hub SDK Der Hub-Offboarding-Prozess entfernt einen Hub aus dem AWS Cloud Verwaltungssystem. Wenn die Cloud eine [DeleteManagedThing](https://docs.aws.amazon.com/iot-mi/latest/APIReference/API_DeleteManagedThing.html)Anfrage sendet, werden mit dem Prozess zwei Hauptziele erreicht: **Device-side Aktionen**: + Setzt den internen Zustand des Hubs zurück + Löschen Sie alle lokal gespeicherten Daten + Bereiten Sie das Gerät auf ein mögliches future Re-Onboarding vor **Cloud-side Aktionen:** + Entfernen Sie alle mit dem Hub verknüpften Cloud-Ressourcen + Vollständige Trennung vom vorherigen Konto Kunden initiieren das Offboarding von Hubs in der Regel, wenn: + Das dem Hub zugeordnete Konto ändern + Ersetzen eines vorhandenen Hubs durch ein neues Gerät Der Prozess gewährleistet einen sauberen, sicheren Übergang zwischen Hub-Konfigurationen und ermöglicht so eine nahtlose Geräteverwaltung und Kontoflexibilität. ![Diagramm zum Offboarding von Hubs](https://docs.aws.amazon.com/de_de/iot-mi/latest/devguide/images/iot-managedintegrations-hub-sdk-offboarding-architecture.png) ## Voraussetzungen + Sie müssen über einen integrierten Hub verfügen. Anweisungen finden Sie unter Einrichtung des [Hub-Onboardings](managedintegrations-sdk-v2-cookbook-hubsetup.md). + Vergewissern Sie sich, dass in der `iotmi_config.json` Datei unter **data/awsiotmi/config///**`iot_provisioning_state`angezeigt wird`PROVISIONED`. + Stellen Sie sicher, dass die permanenten Zertifikate und Schlüssel, auf die in der verwiesen wird, in den angegebenen Pfaden `iotmi_config.json` vorhanden sind. + Stellen Sie sicher HubOnboarding, dass Agent, Provisioner und MQTT-Proxy korrekt konfiguriert sind und ausgeführt werden. + Stellen Sie sicher, dass der Hub keine untergeordneten Geräte hat. Verwenden Sie die [ DeleteManagedThing](https://docs.aws.amazon.com/iot-mi/latest/APIReference/API_DeleteManagedThing.html)API, um alle untergeordneten Geräte zu entfernen, bevor Sie fortfahren. ## Offboard-Prozess für das Hub-SDK Gehen Sie wie folgt vor, um den Hub zu entfernen: ### Rufen Sie die hub\_managed\_thing-ID ab Die `iotmi_config.json` Datei wird verwendet, um die verwaltete Ding-ID für einen Managed Integrations Hub zu speichern. Diese Kennung ist eine wichtige Information, die es dem Hub ermöglicht, mit dem AWS IoT Managed Integrations Service zu kommunizieren. Die ID des verwalteten Objekts wird im Abschnitt **rw** (Lese-/Schreibzugriff) der JSON-Datei unter dem Feld gespeichert. `managed_thing_id` Dies ist in der folgenden Beispielkonfiguration zu sehen: ``` { "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 } } } ``` ### Befehl an den Offboard-Hub senden Verwenden Sie Ihre Kontoanmeldeinformationen und führen Sie den Befehl mit den im vorherigen Abschnitt `managed_thing_id` abgerufenen aus: ``` aws iot-managed-integrations delete-managed-thing \ --identifier {{HUB_MANAGED_THING_ID}} ``` ### Stellen Sie sicher, dass der Hub ausgelagert wurde Verwenden Sie Ihre Kontoanmeldeinformationen und führen Sie den Befehl mit den im vorherigen `managed_thing_id` Abschnitt abgerufenen aus: ``` aws iot-managed-integrations get-managed-thing \ --identifier {{HUB_MANAGED_THING_ID}} ``` ### Erfolgs- und Misserfolgszenarien #### Erfolgsszenario Wenn der Befehl zum Offboarden des Hubs erfolgreich war, wird die folgende Beispielantwort erwartet: ``` { "Message" : "Managed Thing resource not found." } ``` Außerdem `iotmi_config.json` würde das folgende Beispiel beobachtet werden, wenn der Befehl zum Offboarding des Hubs erfolgreich war. Stellen Sie sicher, dass der Abschnitt **rw** nur `iot_provisioning_state` und optional **Metadaten** enthält. Das Fehlen von **Metadaten** ist akzeptabel. `iot_provisioning_state`muss **NOT\_PROVISIONED** sein. ``` { "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 } } } ``` #### Fehlerszenario Wenn der Befehl zum Offboarding des Hubs nicht erfolgreich war, wird die folgende Beispielantwort erwartet: ``` { "Arn" : "{{ARN}}", "CreatedAt" : 1.748968266655E9, "Id" : "{{ID}}", "ProvisioningStatus" : "DELETE_IN_PROGRESS", "Role" : "CONTROLLER", "SerialNumber" : "{{SERIAL_NO}}", "Tags" : { }, "UniversalProductCode" : "{{UPC}}", "UpdatedAt" : 1.748968272107E9 } ``` + Falls ja **ProvisioningStatus**`DELETE_IN_PROGRESS`, folgen Sie den Anweisungen unter [Hub-Wiederherstellung](#hub-recovery). + **ProvisioningStatus**Ist dies nicht der Fall`DELETE_IN_PROGRESS`, ist der Befehl zum Offboarding des Hubs entweder in der Managed Integrations Cloud fehlgeschlagen oder wurde von der Managed Integrations Cloud nicht empfangen. [Folgen Sie den Anweisungen unter Hub-Wiederherstellung.](#hub-recovery) + Wenn das Offboarding nicht erfolgreich war, sieht Ihre `iotmi_config.json` Datei wie die folgende Beispieldatei aus. ``` { "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 } } } ``` ## (Optional) Nach dem Offboarding des Hub-SDK **Wichtig** In den folgenden Szenarien sind optionale Maßnahmen aufgeführt, die Sie ergreifen können, wenn das Offboarding des Hub-SDK fehlgeschlagen ist oder wenn Sie Ihren Hub nach dem Offboarding wieder einbinden möchten. **Re-onboard** Wenn das Offboarding erfolgreich war, führen Sie das Onboarding Ihres Hub-SDK wie folgt aus [Schritt 3: Erstellen eines verwalteten Objekts (Flottenbereitstellung)](managedintegrations-sdk-v2-cookbook-hubsetup.md#managedintegrations-sdk-v2-cookbook-managedthing) und dem Rest des Onboard-Prozesses aus. **Hub-Wiederherstellung** **Das Offboarding des Geräte-Hubs war erfolgreich und das Cloud-Offboarding schlägt fehl** Wenn der [ GetManagedThing](https://docs.aws.amazon.com/iot-mi/latest/APIReference/API_GetManagedThing)API-Aufruf keine `Managed Thing resource not found` Nachricht zurückgibt, die Datei aber ausgelagert wurde`iotmi_config.json`. Eine JSON-Beispieldatei finden Sie unter [Erfolgsszenario](#hub-offboarding-success-scenarios). Informationen zur Wiederherstellung nach diesem Szenario finden Sie unter [Löschen erzwingen](#forced-deletion). **Das Offboarding des Geräte-Hubs schlägt fehl** In diesem Szenario wurde die Datei nicht `iotmi_config.json` korrekt ausgelagert. Eine JSON-Beispieldatei finden Sie unter [Fehlerszenario](#hub-offboarding-failure-scenarios). Informationen zur Wiederherstellung nach diesem Szenario finden Sie unter [Löschen erzwingen](#forced-deletion). Wenn `iotmi_config.json` der Hub immer noch nicht ausgelagert ist, muss er auf die Werkseinstellungen zurückgesetzt werden. **Das Offboarding des Geräte-Hubs und das Cloud-Offboarding schlagen fehl** In diesem Szenario `iotmi_config.json` wird immer noch kein Offboarding durchgeführt, und der Hub-Status lautet entweder oder. `ACTIVATED` `DISCOVERED` Informationen zur Wiederherstellung nach diesem Szenario finden Sie unter Löschen [erzwingen](#forced-deletion). Wenn das erzwungene Löschen fehlschlägt oder immer noch nicht offline `iotmi_config.json` ist, muss der Hub auf die Werkseinstellungen zurückgesetzt werden. **Der Hub ist offline und der Hub-Status ist DELETE\_IN\_PROGRESS** In diesem Szenario ist der Hub offline und die Cloud erhält einen Offboarding-Befehl. Informationen zur Wiederherstellung nach diesem Szenario finden Sie unter [Löschen erzwingen](#forced-deletion). **Löschen erzwingen** Gehen Sie wie folgt vor, um Cloud-Ressourcen ohne erfolgreiches Device-Hub-Offboarding zu löschen. Dieser Vorgang kann zu Inkonsistenzen zwischen dem Cloud- und dem Gerätestatus führen, was möglicherweise zu Problemen bei future Vorgängen führen kann. Rufen Sie die [ DeleteManagedThing ](https://docs.aws.amazon.com/iot-mi/latest/APIReference/API_DeleteManagedThing)API mit dem Hub-Parameter `managed_thing_id` und dem **Force-Parameter** auf: ``` aws iot-managed-integrations delete-managed-thing \ --identifier {{HUB_MANAGED_THING_ID}} \ --force ``` Rufen Sie als Nächstes die [ GetManagedThing ](https://docs.aws.amazon.com/iot-mi/latest/APIReference/API_GetManagedThing)API auf und überprüfen Sie, ob sie zurückkehrt`Managed Thing resource not found`. Dies bestätigt, dass die Cloud-Ressourcen gelöscht wurden. Dieser Ansatz wird nicht empfohlen, da er zu Inkonsistenzen zwischen dem Cloud- und dem Gerätestatus führen kann. Im Allgemeinen ist es besser, für ein erfolgreiches Offboarding des Device-Hubs zu sorgen, bevor Sie versuchen, die Cloud-Ressourcen zu löschen.