Hub d'intégrations gérées hors bord - Intégrations gérées pour AWS IoT Device Management

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Hub d'intégrations gérées hors bord

Présentation du processus de déconnexion du SDK Hub

Le processus de désintégration du hub supprime un hub du système de AWS Cloud gestion. Lorsque le cloud envoie une DeleteManagedThingdemande, le processus atteint deux objectifs principaux :

Actions côté appareil :

  • Réinitialisez l'état interne du hub

  • Supprimer toutes les données enregistrées localement

  • Préparez l'appareil en vue d'un éventuel futur réembarquement

Actions côté cloud :

  • Supprimer toutes les ressources cloud associées au hub

  • Déconnexion complète du compte précédent

Les clients commencent généralement à quitter le hub lorsque :

  • Modifier le compte associé au hub

  • Remplacement d'un hub existant par un nouvel appareil

Le processus garantit une transition propre et sécurisée entre les configurations du hub, permettant une gestion fluide des appareils et une flexibilité des comptes.

Schéma de déchargement du hub

Prérequis

  • Vous devez disposer d'un hub intégré. Pour obtenir des instructions, consultez la section Configuration de l'intégration au Hub.

  • Dans le iotmi_config.json fichier situé à l'adresse/data/aws/iotmi/config/, vérifiez que cela s'iot_provisioning_stateaffichePROVISIONED.

  • Vérifiez que les certificats permanents et les clés auxquels il est fait référence iotmi_config.json existent dans les chemins spécifiés.

  • Assurez-vous que l'agent HubOnboarding, le provisionneur et le proxy MQTT sont correctement configurés et exécutés.

  • Vérifiez qu'aucun appareil enfant n'est installé sur le hub. Utilisez l' DeleteManagedThingAPI pour supprimer tous les appareils enfants avant de continuer.

Processus de déconnexion du SDK Hub

Pour quitter le hub, procédez comme suit :

Récupère l'ID hub_managed_thing

Le iotmi_config.json fichier est utilisé pour stocker l'ID d'objet géré pour un hub d'intégrations gérées. Cet identifiant est une information essentielle qui permet au hub de communiquer avec le service d'intégrations AWS IoT gérées. L'ID d'objet géré est stocké dans la section rw (lecture-écriture) du fichier JSON, sous le champ. managed_thing_id Cela se voit dans l'exemple de configuration suivant :

{ "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 } } }

Envoyer la commande au hub externe

Utilisez les informations d'identification de votre compte et exécutez la commande avec les informations managed_thing_id récupérées dans la section précédente :

aws iot-managed-integrations delete-managed-thing \ --identifier HUB_MANAGED_THING_ID

Vérifiez que le hub a été déconnecté

Utilisez les informations d'identification de votre compte et exécutez la commande avec les informations managed_thing_id récupérées dans la section précédente :

aws iot-managed-integrations get-managed-thing \ --identifier HUB_MANAGED_THING_ID

Scénarios de réussite et d'échec

Scénario de réussite

Si la commande de déconnexion du hub a été exécutée avec succès, l'exemple de réponse suivant est attendu :

{ "Message" : "Managed Thing resource not found." }

En outre, l'exemple suivant iotmi_config.json serait observé si la commande de déchargement du hub était réussie. Vérifiez que la section rw contient uniquement iot_provisioning_state et éventuellement des métadonnées. L'absence de métadonnées est acceptable. iot_provisioning_statedoit être NOT_PROVISIONED.

{ "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 } } }

Scénario de défaillance

Si la commande de déconnexion du hub a échoué, l'exemple de réponse suivant est attendu :

{ "Arn" : "ARN", "CreatedAt" : 1.748968266655E9, "Id" : "ID", "ProvisioningStatus" : "DELETE_IN_PROGRESS", "Role" : "CONTROLLER", "SerialNumber" : "SERIAL_NO", "Tags" : { }, "UniversalProductCode" : "UPC", "UpdatedAt" : 1.748968272107E9 }
  • Si tel ProvisioningStatusest le casDELETE_IN_PROGRESS, suivez les instructions de la section de restauration du Hub.

  • Si ProvisioningStatusce n'est pas le casDELETE_IN_PROGRESS, la commande de déconnexion du hub a échoué dans le cloud d'intégrations gérées ou n'a pas été reçue par le cloud d'intégrations gérées. Suivez les instructions de la section Hub Recovery.

  • Si le déchargement a échoué, votre iotmi_config.json fichier ressemblera au fichier d'exemple ci-dessous.

{ "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 } } }

(Facultatif) Après avoir quitté le SDK Hub

Important

Les scénarios suivants répertorient les actions facultatives à effectuer en cas d'échec du SDK du Hub ou si vous souhaitez réintégrer votre hub après le déchargement.

Réembarquement

Si l'offboarding a été un succès, intégrez votre SDK Hub en suivant l'étape 3 : créer un objet géré (approvisionnement de flotte) et suivre le reste du processus d'intégration.

Restauration du hub
Succès de l'offboarding du Device Hub et échec de l'offboarding du Cloud

Si GetManagedThingl'appel d'API ne renvoie pas de Managed Thing resource not found message, mais que le fichier iotmi_config.json est déconnecté. Voir Scénario de réussite pour un exemple de fichier json.

Pour sortir de ce scénario, voir Forcer la suppression.

Le déchargement du hub de périphériques échoue

Ce scénario se produit lorsque le fichier n'iotmi_config.jsonest pas correctement déconnecté. Voir Scénario d'échec pour un exemple de fichier JSON.

Pour sortir de ce scénario, voir Forcer la suppression. S'il n'iotmi_config.jsonest toujours pas déconnecté, le hub doit être réinitialisé aux paramètres d'usine.

Le déchargement du hub d'appareils et le déchargement du cloud échouent

Dans ce scénario, n'iotmi_config.jsonest toujours pas déconnecté et le statut du hub est soitACTIVATED, soit. DISCOVERED

Pour sortir de ce scénario, voir Forcer la suppression. Si la suppression forcée échoue ou n'iotmi_config.jsonest toujours pas déconnectée, le hub doit être réinitialisé aux paramètres d'usine.

Le hub est hors ligne et son statut est DELETE_IN_PROGRESS

Dans ce scénario, le hub est hors ligne et le cloud reçoit une commande de déconnexion.

Pour sortir de ce scénario, consultez la section Forcer la suppression.

Forcer la suppression

Pour supprimer des ressources cloud sans que le terminal n'ait été déconnecté correctement, procédez comme suit. Cette opération peut entraîner une incohérence entre l'état du cloud et celui de l'appareil, ce qui peut entraîner des problèmes lors des opérations futures.

Appelez DeleteManagedThing l'API avec le paramètre du hub managed_thing_id et le paramètre force :

aws iot-managed-integrations delete-managed-thing \ --identifier HUB_MANAGED_THING_ID \ --force

Ensuite, appelez l' GetManagedThing API et vérifiez qu'elle est renvoyéeManaged Thing resource not found. Cela confirme que les ressources du cloud sont supprimées.

Note

Cette approche n'est pas recommandée, car elle peut entraîner des incohérences entre l'état du cloud et celui de l'appareil. Il est généralement préférable de s'assurer que le terminal a été déconnecté correctement avant de tenter de supprimer les ressources du cloud.