本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 離線受管整合中樞
## Hub SDK 離職程序概觀
中樞卸任程序會從 AWS 雲端 管理系統中移除中樞。當雲端傳送 [DeleteManagedThing](https://docs.aws.amazon.com/iot-mi/latest/APIReference/API_DeleteManagedThing.html) 請求時，程序會完成兩個主要目標：
**裝置端動作**：
+ 重設中樞的內部狀態
+ 刪除所有本機儲存的資料
+ 準備裝置以供未來重新加入
**雲端動作**：
+ 移除與中樞相關聯的所有雲端資源
+ 完成與上一個帳戶的中斷連線
客戶通常會在下列情況下啟動中樞離職：
+ 變更中樞的關聯帳戶
+ 使用新裝置取代現有的中樞
此程序可確保中樞組態之間的乾淨、安全轉換，實現無縫的裝置管理和帳戶彈性。
## 先決條件
+ 您必須擁有已加入的中樞。如需說明，請參閱 [Hub 加入設定](managedintegrations-sdk-v2-cookbook-hubsetup.md)。
+ 在位於 **/data/aws/iotmi/config/** 的 `iotmi_config.json`檔案中，確認 `iot_provisioning_state`顯示 `PROVISIONED`。
+ 確認 中參考的永久憑證和金鑰`iotmi_config.json`存在於其指定的路徑中。
+ 確定 HubOnboarding、Agent、Provisioner 和 MQTT 代理已正確設定並執行。
+ 確認集線器沒有子裝置。使用 [ DeleteManagedThing](https://docs.aws.amazon.com/iot-mi/latest/APIReference/API_DeleteManagedThing.html) API 移除所有子裝置再繼續。
## Hub SDK 離職程序
請依照下列步驟將中樞移出：
### 擷取 hub\_managed\_thing ID
`iotmi_config.json` 檔案用於存放受管整合中樞的受管物件 ID。此識別符是重要資訊，可讓中樞與 AWS IoT 受管整合服務通訊。受管物件 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 \
--identifier {{HUB_MANAGED_THING_ID}}
```
### 確認中樞已離職
使用您的帳戶登入資料，並使用上一節`managed_thing_id`擷取的 執行 命令：
```
aws iot-managed-integrations get-managed-thing \
--identifier {{HUB_MANAGED_THING_ID}}
```
### 成功和失敗案例
#### 成功案例
如果移出中樞的命令成功，預期會有下列範例回應：
```
{
"Message" : "Managed Thing resource not found."
}
```
此外，如果中樞離機命令成功，`iotmi_config.json`則會觀察下列範例。確認 **rw** 區段僅包含 `iot_provisioning_state` 和選用的**中繼資料**。中繼資料不存在****是可接受的。 `iot_provisioning_state` 必須是 **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
}
}
}
```
#### 失敗案例
如果移出中樞的命令失敗，預期會有下列範例回應：
```
{
"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 復原](#hub-recovery)中的指示。
+ 如果 **ProvisioningStatus** 不是 `DELETE_IN_PROGRESS`，則從受管整合雲端中移出中樞的命令會失敗，或者未由受管整合雲端接收。遵循 [Hub 復原](#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：建立受管物件 （機群佈建）](managedintegrations-sdk-v2-cookbook-hubsetup.md#managedintegrations-sdk-v2-cookbook-managedthing) 和其餘的加入程序來加入 Hub SDK。
**Hub 復原**
**裝置中樞離職成功且雲端離職失敗**
如果 [ GetManagedThing](https://docs.aws.amazon.com/iot-mi/latest/APIReference/API_GetManagedThing) API 呼叫未傳回`Managed Thing resource not found`訊息，但檔案已`iotmi_config.json`離線。請參閱範例 json 檔案[的成功案例](#hub-offboarding-success-scenarios)。
若要從此案例中復原，請參閱[強制刪除](#forced-deletion)。
**裝置中樞離職失敗**
當檔案`iotmi_config.json`未正確離職時，就會發生這種情況。請參閱範例 json 檔案的[失敗案例](#hub-offboarding-failure-scenarios)。
若要從此案例中復原，請參閱[強制刪除](#forced-deletion)。如果 `iotmi_config.json` 仍未停止運作，則必須重設集線器。
**裝置中樞離職和雲端離職失敗**
在此案例中， `iotmi_config.json` 仍未停止運作，且中樞狀態為 `ACTIVATED`、 或 `DISCOVERED`。
若要從此案例復原，請參閱[強制刪除](#forced-deletion)。如果強制刪除失敗，或`iotmi_config.json`仍未停止運作，則必須重設集線器。
**中樞離線，中樞狀態為 DELETE\_IN\_PROGRESS**
在此案例中，中樞離線，雲端會收到離職命令。
若要從此案例中復原，請參閱[強制刪除](#forced-deletion)。
**強制刪除**
若要刪除沒有成功裝置中樞離職的雲端資源，請遵循下列步驟。此操作可能會導致雲端和裝置狀態不一致，進而可能導致未來操作發生問題。
使用中樞的 `managed_thing_id`和 **強制**參數呼叫 [ DeleteManagedThing ](https://docs.aws.amazon.com/iot-mi/latest/APIReference/API_DeleteManagedThing) API：
```
aws iot-managed-integrations delete-managed-thing \
--identifier {{HUB_MANAGED_THING_ID}} \
--force
```
接著，呼叫 [ GetManagedThing ](https://docs.aws.amazon.com/iot-mi/latest/APIReference/API_GetManagedThing) API 並確認其傳回 `Managed Thing resource not found`。這會確認雲端資源已刪除。
不建議使用此方法，因為它可能會導致雲端和裝置狀態之間的不一致。在嘗試刪除雲端資源之前，通常最好確保裝置中樞順利移出。