Как получить полное устройство-близнец с устройства iot с помощью Python IoT Hub Device SDK - PullRequest
0 голосов
/ 28 января 2019

Я пишу приложение Azure iot для устройства с помощью IoT Hub Device SDK на python.

Я использую требуемые свойства состояния двойника устройства в своем приложении и обновляю их с помощью device_twin_callback () при изменениях двойника устройства, приходящих из лазури.Однако при повторной инициализации моего устройства (например, при перезагрузке) я получаю начальное состояние двойного устройства, указанное в DPS, а не текущее двойное состояние концентратора IoT.

Есть ли способ восстановить текущее состояние двойника устройства при повторной подготовке с помощью SDK IoT Hub Device в Python?

Единственное решение, которого я хотел бы избежать, - это сохранить последнее состояние устройствав файле.

1 Ответ

0 голосов
/ 29 января 2019

Есть ли способ получить текущее состояние двойника устройства при повторной подготовке с помощью IoT Hub Device SDK в python?

Ваш вопрос не в точности.Нет других способов получить текущее состояние двойника устройства, только REST API Service - Get Twin и связанный с ним Python API iothub_twin_method.get_twin.

Двойник устройствавключенные в данные о состоянии устройства данные для повторной подготовки зависят только от выбора Reprovisioning policies, как показано ниже.

  • Повторное предоставление и миграцияданные : эта политика используется по умолчанию для новых записей о регистрации.Эта политика действует, когда устройства, связанные с записью регистрации, отправляют новый запрос (1).В зависимости от конфигурации записи о регистрации, устройство может быть переназначено другому концентратору IoT.Если устройство меняет концентраторы IoT, регистрация устройства с начальным концентратором IoT будет удалена.Обновленная информация о состоянии устройства из этого исходного концентратора IoT будет перенесена в новый концентратор IoT (2).Во время миграции состояние устройства будет отображаться как Назначение.

  • Повторное предоставление и сброс к исходной конфигурации : эта политика действует, когда устройства связаны с записью регистрации.отправить новый запрос обеспечения (1).В зависимости от конфигурации записи о регистрации, устройство может быть переназначено другому концентратору IoT.Если устройство меняет концентраторы IoT, регистрация устройства с начальным концентратором IoT будет удалена.Первоначальные данные конфигурации, полученные экземпляром службы предоставления, когда устройство было подготовлено, передаются в новый концентратор IoT (2).Во время миграции состояние устройства будет отображаться как Назначение.Эта политика часто используется для возврата к заводским настройкам без изменения концентраторов IoT.

  • Никогда повторно не назначать : устройство никогда не переназначается на другой концентратор.Эта политика предназначена для управления обратной совместимостью.

При использовании Azure IoT SDK для Python политика повторной подготовки задается параметрами update_hub_assignment и migrate_device_data из ReprovisionPolicy объекта, см. Пояснение ниже.

The behavior of the service when a device is re-provisioned to an IoT hub.
All required parameters must be populated in order to send to Azure.
:param update_hub_assignment: Required. When set to true (default), the
 Device Provisioning Service will evaluate the device's IoT Hub assignment
 and update it if necessary for any provisioning requests beyond the first
 from a given device. If set to false, the device will stay assigned to its
 current IoT hub. Default value: True .
:type update_hub_assignment: bool
:param migrate_device_data: Required. When set to true (default), the
 Device Provisioning Service will migrate the device's data (twin, device
 capabilities, and device ID) from one IoT hub to another during an IoT hub
 assignment update. If set to false, the Device Provisioning Service will
 reset the device's data to the initial desired configuration stored in the
 corresponding enrollment list. Default value: True .
:type migrate_device_data: bool

И объект ReprovisionPolicy является свойством, инициализированным в EnrollmentGroup или IndividualEnrollment объект.

Поэтому, пожалуйста, попробуйте изменить комбинацию параметров update_hub_assignment и migrate_device_data из ReprovisionPolicy, чтобы удовлетворить ваши потребности.В противном случае ваш обходной путь для кэширования исторических данных - единственное решение.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...