Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Hub di integrazioni gestite fuori bordo
## Panoramica del processo offboard di Hub SDK
Il processo di offboarding dell'hub rimuove un hub dal Cloud AWS sistema di gestione. Quando il cloud invia una [DeleteManagedThing](https://docs.aws.amazon.com/iot-mi/latest/APIReference/API_DeleteManagedThing.html)richiesta, il processo raggiunge due obiettivi principali:
**Device-side azioni**:
+ Reimposta lo stato interno dell'hub
+ Eliminare tutti i dati salvati localmente
+ Prepara il dispositivo per potenziali future reonboarding
**Cloud-side azioni**:
+ Rimuovi tutte le risorse cloud associate all'hub
+ Disconnessione completa dall'account precedente
I clienti in genere avviano l'offboarding dall'hub quando:
+ Modifica dell'account associato all'hub
+ Sostituzione di un hub esistente con un nuovo dispositivo
Il processo garantisce una transizione pulita e sicura tra le configurazioni dell'hub, consentendo una gestione senza interruzioni dei dispositivi e la flessibilità dell'account.
## Prerequisiti
+ È necessario disporre di un hub integrato. Per istruzioni, consulta Configurazione dell'[Hub onboarding](managedintegrations-sdk-v2-cookbook-hubsetup.md).
+ Nel `iotmi_config.json` file che si trova in**//data/awsiotmi/config/**, verifica che `iot_provisioning_state` sia visualizzato. `PROVISIONED`
+ Verificate che i certificati e le chiavi permanenti a cui si fa riferimento in `iotmi_config.json` esistano nei percorsi specificati.
+ Assicuratevi che Agent HubOnboarding, Provisioner e il proxy MQTT siano configurati e funzionanti correttamente.
+ Verificate che l'hub non abbia dispositivi secondari. Utilizza l'[ DeleteManagedThing](https://docs.aws.amazon.com/iot-mi/latest/APIReference/API_DeleteManagedThing.html)API per rimuovere tutti i dispositivi secondari prima di procedere.
## Processo offboard di Hub SDK
Segui questi passaggi per uscire dall'hub:
### Recupera l'ID hub\_managed\_thing
Il `iotmi_config.json` file viene utilizzato per memorizzare l'ID dell'oggetto gestito per un hub di Managed Integrations. Questo identificatore è un'informazione fondamentale che consente all'hub di comunicare con il servizio AWS IoT Managed Integrations. L'ID dell'oggetto gestito è memorizzato nella sezione **rw** (lettura-scrittura) del file JSON, sotto il campo. `managed_thing_id` Questo è visibile nella seguente configurazione di esempio:
```
{
"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
}
}
}
```
### Invia il comando all'hub esterno
Usa le credenziali del tuo account ed esegui il comando con quanto `managed_thing_id` recuperato nella sezione precedente:
```
aws iot-managed-integrations delete-managed-thing \
--identifier {{HUB_MANAGED_THING_ID}}
```
### Verifica che l'hub sia stato disattivato
Usa le credenziali del tuo account ed esegui il comando con i `managed_thing_id` dati recuperati nella sezione precedente:
```
aws iot-managed-integrations get-managed-thing \
--identifier {{HUB_MANAGED_THING_ID}}
```
### Scenari di successo e fallimento
#### Scenario di successo
Se il comando di offboard dell'hub ha avuto esito positivo, è prevista la seguente risposta di esempio:
```
{
"Message" : "Managed Thing resource not found."
}
```
Inoltre, il seguente esempio `iotmi_config.json` verrebbe osservato se il comando hub offboarding avesse esito positivo. **Verificate che la sezione **rw** contenga solo `iot_provisioning_state` e facoltativamente metadati.** L'assenza di **metadati** è accettabile. `iot_provisioning_state`deve essere **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
}
}
}
```
#### Scenario di fallimento
Se il comando di offboard dell'hub non ha avuto esito positivo, è prevista la seguente risposta di esempio:
```
{
"Arn" : "{{ARN}}",
"CreatedAt" : 1.748968266655E9,
"Id" : "{{ID}}",
"ProvisioningStatus" : "DELETE_IN_PROGRESS",
"Role" : "CONTROLLER",
"SerialNumber" : "{{SERIAL_NO}}",
"Tags" : { },
"UniversalProductCode" : "{{UPC}}",
"UpdatedAt" : 1.748968272107E9
}
```
+ In caso **ProvisioningStatus**affermativo`DELETE_IN_PROGRESS`, segui le istruzioni in [Hub recovery](#hub-recovery).
+ In caso contrario`DELETE_IN_PROGRESS`, il comando per l'offboard dell'hub non **ProvisioningStatus**è riuscito nel cloud Managed Integrations o non è stato ricevuto dal cloud Managed Integrations. [Segui le istruzioni in Hub Recovery.](#hub-recovery)
+ Se l'offboarding non ha avuto successo, il `iotmi_config.json` file avrà l'aspetto del file di esempio riportato di seguito.
```
{
"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
}
}
}
```
## (Facoltativo) Dopo l'offboarding di Hub SDK
**Importante**
I seguenti scenari elencano le azioni opzionali da intraprendere dopo l'offboarding di Hub SDK non riuscito o se desideri riavviare l'hub dopo l'offboarding.
**Re-onboard**
Se l'offboarding ha avuto successo, esegui l'onboard dell'Hub SDK seguendo la [Fase 3: Crea un dispositivo gestito (approvvigionamento della flotta) e il resto del processo](managedintegrations-sdk-v2-cookbook-hubsetup.md#managedintegrations-sdk-v2-cookbook-managedthing) di onboard.
**Ripristino dell'Hub**
**L'offboarding dell'hub del dispositivo è riuscito e l'offboarding sul cloud non riesce**
Se la chiamata [ GetManagedThing](https://docs.aws.amazon.com/iot-mi/latest/APIReference/API_GetManagedThing)API non restituisce il `Managed Thing resource not found` messaggio, ma il file viene offboardato. `iotmi_config.json` Vedi [Scenario di successo](#hub-offboarding-success-scenarios) per un file json di esempio.
Per eseguire il ripristino da questo scenario, consulta [Eliminazione forzata](#forced-deletion).
**L'offboarding dell'hub del dispositivo non riesce**
Questo scenario si verifica quando l'offboard del file non `iotmi_config.json` viene eseguito correttamente. Vedi [Scenario di errore](#hub-offboarding-failure-scenarios) per un file json di esempio.
Per eseguire il ripristino da questo scenario, consulta [Eliminazione forzata](#forced-deletion). Se non `iotmi_config.json` è ancora stato scollegato, è necessario ripristinare le impostazioni di fabbrica dell'hub.
**L'offboarding dell'hub del dispositivo e l'offboarding sul cloud non riescono**
In questo scenario, non `iotmi_config.json` è ancora stato effettuato l'offboarding e lo stato dell'hub è o. `ACTIVATED` `DISCOVERED`
Per recuperare da questo scenario, consulta Eliminazione [forzata](#forced-deletion). Se l'eliminazione forzata fallisce o non `iotmi_config.json` viene ancora effettuata l'offboard, è necessario ripristinare le impostazioni di fabbrica dell'hub.
**L'hub è offline e lo stato dell'hub è DELETE\_IN\_PROGRESS**
In questo scenario, l'hub è offline e il cloud riceve un comando di offboarding.
Per recuperare da questo scenario, vedi Eliminazione [forzata](#forced-deletion).
**Eliminazione forzata**
Per eliminare le risorse cloud senza che l'offboarding dell'hub del dispositivo abbia esito positivo, procedi nel seguente modo. Questa operazione può causare incongruenze tra gli stati del cloud e del dispositivo, causando potenzialmente problemi con le operazioni future.
Chiama l'[ DeleteManagedThing ](https://docs.aws.amazon.com/iot-mi/latest/APIReference/API_DeleteManagedThing)API con l'hub `managed_thing_id` e il parametro **force**:
```
aws iot-managed-integrations delete-managed-thing \
--identifier {{HUB_MANAGED_THING_ID}} \
--force
```
Quindi, chiama l'[ GetManagedThing ](https://docs.aws.amazon.com/iot-mi/latest/APIReference/API_GetManagedThing)API e verifica che ritorni`Managed Thing resource not found`. Ciò conferma che le risorse cloud vengono eliminate.
Questo approccio non è consigliato, in quanto può portare a incongruenze tra lo stato del cloud e quello del dispositivo. In genere è meglio assicurarsi che l'offboarding dell'hub del dispositivo avvenga correttamente prima di tentare di eliminare le risorse cloud.