Convenções do IoT Plug and Play
Os dispositivos de IoT Plug and Play devem seguir um conjunto de convenções quando trocam mensagens com um Hub IoT. Os dispositivos IoT Plug and Play usam o protocolo MQTT para comunicarem com o Hub IoT. O Hub IoT também dá suporte ao protocolo AMQP que está disponível em alguns SDKs de dispositivo IoT.
Um dispositivo pode incluir os módulosou ser implementado em um módulo IoT Edge hospedado pelo runtime do IoT Edge.
Você descreve a telemetria, as propriedades e os comandos que um dispositivo IoT Plug and Play implementa com um modelo de DTDL (Gêmeos Digitais do Azure IDL). Há dois Microsoft SQL Server System CLR Types de modelo mencionados neste artigo:
- Nenhum componente-Um modelo sem componentes. O modelo declara um evento de telemetria, propriedades e comandos como elementos de nível superior na seção de conteúdos da interface principal. Na ferramenta de Internet das Coisas do Azure, esse modelo aparece como um únicocomponente padrão.
- Vários componentes–Um modelo composto por duas ou mais interfaces. Uma interface principal, aparece como ocomponente padrão, com telemetria, propriedades e comandos. Uma ou mais interfaces fornecidas assim como os componentes com mais telemetria, propriedades e comandos.
Para obter mais informações, confira oGuia de modelagem do IoT Plug and Play.
Identificar o modelo
Para divulgar o modelo que ele implementa, um dispositivo ou módulo do IoT Plug and Play inclui a ID do modelo no pacote de conexão MQTT adicionandomodel-id
aoUSERNAME
campo.
Para identificar o modelo de modo que um dispositivo ou módulo implementa, um serviço pode obter a ID do modelo de:
- Obter o campo do dispositivo
modelId
gêmeo. - O campo gêmeo
$metadata.$model
digital. - Notificações de alteração do gêmeo digital.
Telemetria
- A telemetria enviada de um dispositivo sem componente não requer metadados suplementares. O sistema inclui a
dt-dataschema
propriedade. - A telemetria enviada por um dispositivo usando componentes deve adicionar o nome do componente à mensagem de telemetria.
- Ao usar o MQTT, adicione a propriedade
$.sub
com o nome do componente ao tópico de telemetria, o sistema adiciona a propriedadedt-subject
. - Ao usar o AMQP, adicione a propriedade
dt-subject
com o nome do componente como uma anotação de mensagem.
Observação
A telemetria dos componentes requer uma mensagem por componente.
Para obter mais exemplos de telemetria, consulte Payloads > Telemetria
Propriedades somente leitura
Um dispositivo define uma propriedade somente leitura que ele então relata para o aplicativo de back-end.
O exemplo de somente leitura da propriedade do componente
Um dispositivo ou módulo pode enviar qualquer JSON válido a fim de seguir as regras de negócio no DTDL.
DTDL que define uma propriedade em uma interface:
{
"@context": "dtmi:dtdl:context;2",
"@id": "dtmi:example: Thermostat;1",
"@type": "Interface",
"contents": [
{
"@type": "Property",
"name": "temperature",
"schema": "double"
}
]
}
Exemplo do payload da propriedade relatada:
"reported" :
{
"temperature" : 21.3
}
Exemplo da propriedade de diversos componentes somente leitura
O dispositivo ou módulo devem adicionar o{"__t": "c"}
marcador para indicar de que elemento refere-se a um componente.
DTDL que referencia um componente:
{
"@context": "dtmi:dtdl:context;2",
"@id": "dtmi:com:example:TemperatureController;1",
"@type": "Interface",
"displayName": "Temperature Controller",
"contents": [
{
"@type" : "Component",
"schema": "dtmi:com:example:Thermostat;1",
"name": "thermostat1"
}
]
}
DTDL que fixa o componente:
{
"@context": "dtmi:dtdl:context;2",
"@id": "dtmi:com:example:Thermostat;1",
"@type": "Interface",
"contents": [
{
"@type": "Property",
"name": "temperature",
"schema": "double"
}
]
}
Exemplo do payload da propriedade relatada:
"reported": {
"thermostat1": {
"__t": "c",
"temperature": 21.3
}
}
Para obter mais exemplos de propriedade somente leitura, consulte Payloads > Propriedades.
As propriedades graváveis
Um aplicativo de back-end define uma propriedade gravável que o Hub IoT envia para o dispositivo.
O dispositivo ou módulo deve confirmar que recebeu a propriedade enviada a uma propriedade relatada. A propriedade reportada deve incluir:
value
-o valor efetivo da propriedade (normalmente o valor recebido, mas o dispositivo pode decidir o relatório de um valor diferente).ac
-um código de confirmação que usa um código de estado HTTP.av
-uma versão da confirmação que se refere à$version
propriedade desejada. Você pode encontrar este valor no payload JSON da propriedade desejada.ad
-uma descrição de confirmação opcional.
Respostas de confirmação
Ao relatar propriedades graváveis, o dispositivo deve redigir a mensagem de confirmação, usando os quatro campos na lista anterior, a fim de indicar o estado real do dispositivo, conforme descrito na tabela a seguir:
Status(ac) | Version(av) | Value(value) | Description(av) |
---|---|---|---|
200 | Versão desejada | Valor desejado | Valor desejado da propriedade aceito |
202 | Versão desejada | Valor aceito pelo dispositivo | Valor desejado da propriedade aceito, atualização em andamento (deve terminar com 200) |
203 | 0 | Valor definido pelo dispositivo | Conjunto de propriedades do dispositivo, sem refletir nenhuma propriedade desejada |
400 | Versão desejada | Valor real usado pelo dispositivo | Valor desejado da propriedade não aceito |
500 | Versão desejada | Valor real usado pelo dispositivo | Exceção ao aplicar a propriedade |
Quando um dispositivo é iniciado, ele deve solicitar ao dispositivo gêmeo e verificar se há atualizações de propriedades graváveis. Se a versão de uma propriedade gravável aumentar enquanto o dispositivo estava off-line, o dispositivo deve enviar uma resposta de propriedade relatada para confirmar que recebeu a atualização.
Quando um dispositivo inicia pela primeira vez, ele pode enviar um valor inicial de uma propriedade relatada se ele não receber uma propriedade desejada inicial do hub IoT. Nesse caso, o dispositivo pode enviar o valor padrão com av
para 0
e ac
para 203
. Por exemplo:
"reported": {
"targetTemperature": {
"value": 20.0,
"ac": 203,
"av": 0,
"ad": "initialize"
}
}
Um dispositivo pode usar a propriedade reportada para fornecer outras informações ao Hub. Por exemplo, o dispositivo pode responder com uma série de mensagens em andamento,tal como:
"reported": {
"targetTemperature": {
"value": 35.0,
"ac": 202,
"av": 3,
"ad": "In-progress - reporting current temperature"
}
}
Quando o dispositivo alcança a temperatura de destino, ele envia a seguinte mensagem:
"reported": {
"targetTemperature": {
"value": 20.0,
"ac": 200,
"av": 4,
"ad": "Reached target temperature"
}
}
Um dispositivo pode reportar um erro como:
"reported": {
"targetTemperature": {
"value": 120.0,
"ac": 500,
"av": 3,
"ad": "Target temperature out of range. Valid range is 10 to 99."
}
}
Tipo de objeto
Se uma propriedade gravável é definida como um objeto, o serviço deve enviar um objeto completo para o dispositivo. O dispositivo deve reconhecer a atualização enviando informações suficientes de volta ao serviço para que o serviço entenda como o dispositivo foi acionado na atualização. Essa resposta pode incluir:
- O objeto inteiro
- Apenas os campos que o dispositivo atualizou
- Um subconjunto dos campos
Se os objetos forem grandes, considere diminuir o tamanho do objeto incluído na confirmação.
O exemplo a seguir mostra uma propriedade gravável definida como um Object
com quatro campos:
DTDL:
{
"@type": "Property",
"name": "samplingRange",
"schema": {
"@type": "Object",
"fields": [
{
"name": "startTime",
"schema": "dateTime"
},
{
"name": "lastTime",
"schema": "dateTime"
},
{
"name": "count",
"schema": "integer"
},
{
"name": "errorCount",
"schema": "integer"
}
]
},
"displayName": "Sampling range"
"writable": true
}
Para atualizar essa propriedade gravável, envie um objeto completo do serviço semelhante ao exemplo a seguir:
{
"samplingRange": {
"startTime": "2021-08-17T12:53:00.000Z",
"lastTime": "2021-08-17T14:54:00.000Z",
"count": 100,
"errorCount": 5
}
}
O dispositivo responde com uma confirmação semelhante ao exemplo a seguir:
{
"samplingRange": {
"ac": 200,
"av": 5,
"ad": "Weighing status updated",
"value": {
"startTime": "2021-08-17T12:53:00.000Z",
"lastTime": "2021-08-17T14:54:00.000Z",
"count": 100,
"errorCount": 5
}
}
}
Amostra da propriedade do componente não gravável
Quando um dispositivo recebe várias propriedades desejadas em apenas um payload, ele pode enviar as respostas de propriedade relatada a várias cargas ou combinar as respostas em apenas uma carga.
Um dispositivo ou módulo pode enviar qualquer JSON válido a fim de seguir as regras de negócio no DTDL.
DTDL:
{
"@context": "dtmi:dtdl:context;2",
"@id": "dtmi:example: Thermostat;1",
"@type": "Interface",
"contents": [
{
"@type": "Property",
"name": "targetTemperature",
"schema": "double",
"writable": true
},
{
"@type": "Property",
"name": "targetHumidity",
"schema": "double",
"writable": true
}
]
}
Amostra do payload da propriedade desejada:
"desired" :
{
"targetTemperature" : 21.3,
"targetHumidity" : 80,
"$version" : 3
}
Exemplo do payload da propriedade relatada:
"reported": {
"targetTemperature": {
"value": 21.3,
"ac": 200,
"av": 3,
"ad": "complete"
}
}
Exemplo do segundo payload da propriedade relatada:
"reported": {
"targetHumidity": {
"value": 80,
"ac": 200,
"av": 3,
"ad": "complete"
}
}
Observação
Você pode optar por combinar essas duas cargas de propriedade relatadas em uma única carga.
Exemplo da propriedade gravável de vários componentes
O dispositivo ou módulo devem adicionar o{"__t": "c"}
marcador para indicar de que elemento refere-se a um componente.
O marcador é enviado somente para atualizações das propriedades definidas em um componente. As atualizações das propriedades definidas no componente padrão não incluem o marcador, confira aAmostra da propriedade do componente sem gravação.
Quando um dispositivo recebe diversas propriedades relatadas em um único payload, ele pode enviar as respostas de propriedade relatadas entre vários payloads ou combinar as respostas em um único payload.
O dispositivo ou módulo deve confirmar que recebeu a propriedade enviada pela propriedade relatada:
DTDL que referencia um componente:
{
"@context": "dtmi:dtdl:context;2",
"@id": "dtmi:com:example:TemperatureController;1",
"@type": "Interface",
"displayName": "Temperature Controller",
"contents": [
{
"@type" : "Component",
"schema": "dtmi:com:example:Thermostat;1",
"name": "thermostat1"
}
]
}
DTDL que fixa o componente:
{
"@context": "dtmi:dtdl:context;2",
"@id": "dtmi:com:example:Thermostat;1",
"@type": "Interface",
"contents": [
{
"@type": "Property",
"name": "targetTemperature",
"schema": "double",
"writable": true
}
]
}
Amostra do payload da propriedade desejada:
"desired": {
"thermostat1": {
"__t": "c",
"targetTemperature": 21.3,
"targetHumidity": 80,
"$version" : 3
}
}
Exemplo do payload da propriedade relatada:
"reported": {
"thermostat1": {
"__t": "c",
"targetTemperature": {
"value": 23,
"ac": 200,
"av": 3,
"ad": "complete"
}
}
}
Exemplo do segundo payload da propriedade relatada:
"reported": {
"thermostat1": {
"__t": "c",
"targetHumidity": {
"value": 80,
"ac": 200,
"av": 3,
"ad": "complete"
}
}
}
Observação
Você pode optar por combinar essas duas cargas de propriedade relatadas em uma única carga.
Para obter mais exemplos de propriedade gravável, consulte Payloads > Propriedades.
Comandos
Nenhuma interface do componente usa o nome de comando sem um prefixo.
Em um dispositivo ou módulo,com diversas interfaces do componente usam nomes de comando com o seguinte formato:componentName*commandName
.
Para obter mais exemplos de comando, consulte Payloads > Comandos.
Dica
O IoT Central tem suas próprias convenções para implementar Comandos de execução longa e Comandos offline.
Próximas etapas
Agora que você aprendeu sobre as convenções do IoT Plug and Play, aqui estão alguns outros recursos: