Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Durante o ciclo de vida de uma solução de IoT, é comum mover dispositivos entre hubs IoT. Os motivos para essa mudança podem incluir os seguintes cenários:
Geolocalização / GeoLatência: À medida que um dispositivo se move entre locais, a latência da rede é melhorada ao fazer com que o dispositivo migre para um hub IoT mais próximo.
Multilocação: um dispositivo pode ser usado dentro da mesma solução de IoT e reatribuído a um novo cliente ou site do cliente. Esse novo cliente pode ser atendido usando um hub IoT diferente.
Alteração da solução: um dispositivo pode ser movido para uma solução de IoT nova ou atualizada. Essa reatribuição pode exigir que o dispositivo se comunique com um novo hub IoT conectado a outros componentes back-end.
Quarentena: semelhante a uma mudança de solução. Um dispositivo com mau funcionamento, comprometido ou desatualizado pode ser reatribuído a um hub IoT que só pode ser atualizado e voltar a estar em conformidade. Quando o dispositivo estiver funcionando corretamente, ele será migrado de volta para seu hub principal.
O suporte ao reprovisionamento no Serviço de Provisionamento de Dispositivos atende estas necessidades. Os dispositivos podem ser reatribuídos automaticamente a novos hubs IoT com base na política de reprovisionamento configurada na entrada de registro do dispositivo.
Dados de estado do dispositivo
Os dados de estado do dispositivo são compostos pelo gêmeo do dispositivo e pelos recursos do dispositivo. Esses dados são armazenados na instância do Serviço de Provisionamento de Dispositivo e no hub IoT ao qual um dispositivo está atribuído.
Quando um dispositivo é inicialmente provisionado com uma instância do Serviço de Provisionamento de Dispositivo, as seguintes etapas são feitas:
O dispositivo envia uma solicitação de provisionamento para uma instância do Serviço de Provisionamento de Dispositivo. A instância de serviço autentica a identidade do dispositivo com base em uma entrada de registro e cria a configuração inicial dos dados de estado do dispositivo. A instância de serviço atribui o dispositivo a um hub IoT com base na configuração de registro e retorna essa atribuição de hub IoT ao dispositivo.
A instância do serviço de provisionamento fornece uma cópia de todos os dados de estado inicial do dispositivo para o hub IoT atribuído. O dispositivo se conecta ao hub IoT atribuído e inicia as operações.
Com o tempo, as operações do dispositivo e as operações de back-end podem atualizar os dados de estado do dispositivo no hub IoT. As informações de estado inicial do dispositivo armazenadas na instância do Serviço de Provisionamento de Dispositivo permanecem intocadas. Esses dados de estado do dispositivo intocados são a configuração inicial.
Dependendo do cenário, à medida que um dispositivo se move entre hubs IoT, também pode ser necessário migrar o estado do dispositivo atualizado no hub IoT anterior para o novo hub IoT. As políticas de reprovisionamento no Serviço de Provisionamento de Dispositivos podem dar suporte a essa migração.
Políticas de reaprovisionamento
Dependendo do cenário, um dispositivo pode enviar uma solicitação para uma instância de serviço de provisionamento na reinicialização. Ele também suporta um método para acionar manualmente o provisionamento sob demanda. A política de reprovisionamento numa entrada de inscrição determina como a instância do serviço de provisionamento de dispositivos lida com essas solicitações de provisionamento. A política também determina se os dados de estado do dispositivo devem ser migrados durante o reprovisionamento. As mesmas políticas estão disponíveis para inscrições individuais e grupos de inscrição:
Reprovisionar e migrar dados: essa política é o padrão para novas entradas de registro. Esta política atua quando os dispositivos associados à entrada de inscrição enviam uma nova solicitação (1). Dependendo da configuração de entrada de registro, o dispositivo pode ser reatribuído a outro hub IoT. Se o dispositivo estiver alterando hubs IoT, o registro do dispositivo com o hub IoT inicial será removido. As informações atualizadas de estado do dispositivo desse hub IoT inicial são migradas para o novo hub IoT (2). Durante a migração, o status do dispositivo é relatado como Atribuição.
Reprovisionar e redefinir para a configuração inicial: esta política atua quando dispositivos associados à entrada de registro enviam uma nova solicitação de provisionamento (1). Dependendo da configuração de entrada de registro, o dispositivo pode ser reatribuído a outro hub IoT. Se o dispositivo estiver alterando hubs IoT, o registro do dispositivo com o hub IoT inicial será removido. Os dados de configuração inicial que a instância do serviço de provisionamento recebeu quando o dispositivo foi provisionado são fornecidos ao novo hub IoT (2). Durante a migração, o status do dispositivo é relatado como Atribuição.
Essa política geralmente é usada para uma redefinição de fábrica sem alterar os hubs IoT.
Nunca reprovisionar: o dispositivo nunca é realocado para um hub diferente. Esta política é fornecida para gerenciar a compatibilidade com versões anteriores.
Note
O DPS sempre invoca o webhook de alocação personalizada, independentemente da política de reprovisionamento, caso existam novos ReturnData para o dispositivo. Se a política de reprovisionamento estiver definida para nunca reprovisionar, o webhook será chamado, mas o dispositivo não alterará seu hub atribuído.
Enquanto você projeta sua solução e define uma lógica de reprovisionamento, há algumas coisas a considerar. Por exemplo:
- Com que frequência espera que os seus dispositivos sejam reiniciados
- As quotas e limites do DPS
- Tempo de implementação esperado para a sua frota (implementação faseada vs tudo de uma só vez)
- Capacidade de repetição implementada no código do cliente, conforme descrito nas orientações gerais sobre Repetição no Centro de Arquitetura do Azure
Tip
Recomendamos não provisionar em cada reinicialização do dispositivo, pois essa ação pode causar alguns problemas ao reprovisionar vários milhares ou milhões de dispositivos de uma só vez. Em vez disso, você deve tentar usar a API de Pesquisa de Status de Registro de Dispositivo e tentar se conectar com essas informações ao Hub IoT. Se isso falhar, tente reprovisionar, pois as informações do Hub IoT podem mudar. Lembre-se de que consultar o estado de registro conta como um novo registro de dispositivo, portanto, você deve considerar o limite de registro do dispositivo. Considere também a implementação de uma lógica de tentativa apropriada, como por exemplo, back-off exponencial com randomização, conforme descrito na orientação geral de repetição. Em alguns casos, dependendo dos recursos do dispositivo, é possível salvar as informações do Hub IoT diretamente no dispositivo, para se conectar diretamente ao Hub IoT após o primeiro provisionamento usando o DPS. Se você optar por salvar diretamente no dispositivo, implemente um mecanismo de fallback caso ocorram erros específicos do Hub IoT . Por exemplo, considere os seguintes cenários:
- Repita a operação do Hub IoT se o código de resultado for 429 (Muitas solicitações) ou um erro no intervalo 5xx. Não tente novamente se houver outros erros.
- Para erros 429, tente novamente somente após o tempo indicado no cabeçalho Retry-After.
- Para erros 5xx, use um intervalo exponencial, com a primeira tentativa de repetição pelo menos 5 segundos após a resposta.
- Em caso de erros diferentes dos 429 e 5xx, registe-se novamente através do DPS
- Idealmente, você também deve oferecer suporte a um método direto para acionar manualmente o provisionamento sob demanda.
Também recomendamos que se tenha em conta os limites de serviço ao planear atividades como enviar atualizações para a sua frota. Por exemplo, atualizar a frota de uma só vez pode fazer com que todos os dispositivos se registem novamente através do DPS (o que pode facilmente estar acima do limite da quota de registo) - Para esses cenários, considere planear atualizações de dispositivos por fases, em vez de atualizar toda a sua frota ao mesmo tempo.
Gerenciando a compatibilidade com versões anteriores
Antes de setembro de 2018, as atribuições de dispositivos para hubs IoT tinham um comportamento persistente. Quando um dispositivo passava novamente pelo processo de provisionamento, ele era atribuído apenas ao mesmo hub IoT.
Para soluções que dependem desse comportamento, o serviço de provisionamento inclui compatibilidade com versões anteriores. Este comportamento é atualmente mantido para dispositivos de acordo com os seguintes critérios:
Os dispositivos se conectam a uma versão da API antes da disponibilidade do suporte nativo ao reprovisionamento no Serviço de Provisionamento de Dispositivos. Consulte a tabela de API a seguir.
A entrada de inscrição para os dispositivos não possui uma política de reprovisionamento definida.
Essa compatibilidade garante que os dispositivos implantados anteriormente tenham o mesmo comportamento presente durante os testes iniciais. Para preservar o comportamento anterior, não salve uma política de reprovisionamento nessas inscrições. Se uma política de reprovisionamento for definida, a política de reprovisionamento terá precedência sobre o comportamento. Ao permitir que a política de reprovisionamento tenha precedência, os clientes podem atualizar o comportamento do dispositivo sem precisar criar uma nova imagem do dispositivo.
O fluxograma a seguir ajuda a mostrar quando o comportamento está presente:
A tabela a seguir mostra as versões da API antes da disponibilidade do suporte ao reprovisionamento nativo no Serviço de Provisionamento de Dispositivos:
| API REST | C SDK | Python SDK | SDK do Node | SDK de Java | SDK para .NET |
|---|---|---|---|---|---|
| 2018-04-01 e anteriores | 1.2.8 e anteriores | 1.4.2 e anteriores | 1.7.3 ou anterior | 1.13.0 ou anterior | 1.1.0 ou anterior |
Note
É provável que estes valores e ligações mudem. Os SDKs e APIs do Azure IoT são versionados para garantir que os aplicativos e serviços continuem a funcionar à medida que os produtos e APIs evoluem. Recomendamos que você verifique as versões mais recentes dos SDKs e APIs do Azure IoT na documentação de referência para esses SDKs e APIs. Por exemplo, a versão mais recente da API REST do Serviço de Provisionamento de Dispositivos do Hub IoT do Azure é 2021-10-01.