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.
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.jsonfichier 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.jsonexistent 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 \ --identifierHUB_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 \ --identifierHUB_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 cas
DELETE_IN_PROGRESS, suivez les instructions de la section de restauration du Hub. -
Si ProvisioningStatusce n'est pas le cas
DELETE_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.jsonfichier 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 foundmessage, mais que le fichieriotmi_config.jsonest 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.DISCOVEREDPour 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_idet le paramètre force :aws iot-managed-integrations delete-managed-thing \ --identifierHUB_MANAGED_THING_ID\ --forceEnsuite, appelez l' GetManagedThing API et vérifiez qu'elle est renvoyée
Managed 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.