Telemetría, propiedades y cargas de comandos
Un modelo de dispositivo define lo siguiente:
- La telemetría que un dispositivo envía a un servicio.
- Las propiedades que un dispositivo sincroniza con un servicio.
- Los comandos a los que el servicio llama en un dispositivo.
Sugerencia
Azure IoT Central es un servicio que sigue las convenciones de Plug and Play. En IoT Central, el modelo de dispositivo forma parte de una plantilla de dispositivo. Actualmente, IoT Central admite DTDL v2 con una extensión de IoT Central. Una aplicación de IoT Central espera recibir datos JSON con codificación UTF-8.
En este artículo, se describen las cargas de JSON que los dispositivos envían y reciben en relación con la telemetría, las propiedades y los comandos definidos en un modelo de dispositivo DTDL.
En el artículo no se describen todos los tipos posibles de cargas de telemetría, propiedades y comandos, pero los ejemplos muestran los tipos de claves.
En cada ejemplo se muestra un fragmento de código del modelo de dispositivo que define el tipo y las cargas JSON de ejemplo para ilustrar cómo debería interactuar el dispositivo con un servicio compatible con Plug and Play como IoT Central.
Los fragmentos de código JSON de ejemplo de este artículo usan la versión 2 de lenguaje de definición de gemelos digitales (DTDL). También hay algunas extensiones de DTDL que IoT Central usa.
Para ver un ejemplo de código de dispositivo que muestre algunas de estas cargas en uso, consulte el tutorial Conexión una aplicación de dispositivo IoT Plug and Play de ejemplo que se ejecuta en Linux o Windows a IoT Hub o el tutorial Creación y conexión de una aplicación cliente a una aplicación de Azure IoT Central.
Visualización de datos sin procesar
Si usa IoT Central, puede ver los datos sin procesar que un dispositivo envía a una aplicación. Esta vista es útil para solucionar problemas con la carga enviada desde un dispositivo. Para ver los datos sin procesar que envía un dispositivo:
Vaya al dispositivo en la página Dispositivos.
Seleccione la pestaña Datos sin procesar:
En esta vista, puede seleccionar las columnas que se van a mostrar y establecer el intervalo de tiempo que desea ver. La columna Datos no modelados muestra datos del dispositivo que no coinciden con ninguna de las definiciones de telemetría o propiedades de la plantilla de dispositivo.
Para ver más sugerencias para la solución de problemas, consulte el artículo sobre cómo solucionar el problema de que los dispositivos no se muestren en Azure IoT Central.
Telemetría
Para obtener más información sobre las reglas de nomenclatura de telemetría de DTDL, consulte DTDL > Telemetría. El nombre de telemetría no puede comenzar con el carácter _.
No cree tipos de telemetría con los nombres siguientes. IoT Central usa estos nombres reservados internamente. Si intenta usar estos nombres, IoT Central omitirá los datos:
EventEnqueuedUtcTimeEventProcessedUtcTimePartitionIdEventHubUser$metadata$version
Telemetría en componentes
Si la telemetría está definida en un componente, agregue una propiedad de mensaje personalizado denominada $.sub con el nombre del componente tal y como se haya definido en el modelo de dispositivo. Para más información, consulte Tutorial: Conexión de un dispositivo IoT Plug and Play aplicaciones de múltiples componentes. En este tutorial se muestra cómo usar diferentes lenguajes de programación para enviar telemetría desde un componente.
Importante
Para mostrar correctamente la telemetría de los componentes hospedados en los módulos de IoT Edge, use la versión IoT Edge 1.2.4 o posterior. Si usa una versión anterior, la telemetría de los componentes de los módulos de IoT Edge se muestra como _unmodeleddata.
Telemetría en interfaces heredadas
Si la telemetría se define en una interfaz heredada, el dispositivo envía la telemetría como si estuviera definida en la interfaz raíz. Dado el siguiente modelo de dispositivo:
[
{
"@id": "dtmi:contoso:device;1",
"@type": "Interface",
"contents": [
{
"@type": [
"Property",
"Cloud",
"StringValue"
],
"displayName": {
"en": "Device Name"
},
"name": "DeviceName",
"schema": "string"
}
],
"displayName": {
"en": "Contoso Device"
},
"extends": [
"dtmi:contoso:sensor;1"
],
"@context": [
"dtmi:iotcentral:context;2",
"dtmi:dtdl:context;2"
]
},
{
"@context": [
"dtmi:iotcentral:context;2",
"dtmi:dtdl:context;2"
],
"@id": "dtmi:contoso:sensor;1",
"@type": [
"Interface",
"NamedInterface"
],
"contents": [
{
"@type": [
"Telemetry",
"NumberValue"
],
"displayName": {
"en": "Meter Voltage"
},
"name": "MeterVoltage",
"schema": "double"
}
],
"displayName": {
"en": "Contoso Sensor"
},
"name": "ContosoSensor"
}
]
El dispositivo envía la telemetría de la tensión del medidor mediante la siguiente carga. El dispositivo no incluye el nombre de la interfaz en la carga:
{
"MeterVoltage": 5.07
}
Tipos primitivos
En esta sección se muestran ejemplos de los tipos de telemetría primitivos que un dispositivo puede transmitir.
El siguiente fragmento de código de un modelo de dispositivo muestra la definición de un tipo de telemetría boolean:
{
"@type": "Telemetry",
"displayName": {
"en": "BooleanTelemetry"
},
"name": "BooleanTelemetry",
"schema": "boolean"
}
Un cliente de dispositivo debe enviar la telemetría como JSON con un aspecto similar al del ejemplo siguiente:
{ "BooleanTelemetry": true }
El siguiente fragmento de código de un modelo de dispositivo muestra la definición de un tipo de telemetría string:
{
"@type": "Telemetry",
"displayName": {
"en": "StringTelemetry"
},
"name": "StringTelemetry",
"schema": "string"
}
Un cliente de dispositivo debe enviar la telemetría como JSON con un aspecto similar al del ejemplo siguiente:
{ "StringTelemetry": "A string value - could be a URL" }
El siguiente fragmento de código de un modelo de dispositivo muestra la definición de un tipo de telemetría integer:
{
"@type": "Telemetry",
"displayName": {
"en": "IntegerTelemetry"
},
"name": "IntegerTelemetry",
"schema": "integer"
}
Un cliente de dispositivo debe enviar la telemetría como JSON con un aspecto similar al del ejemplo siguiente:
{ "IntegerTelemetry": 23 }
El siguiente fragmento de código de un modelo de dispositivo muestra la definición de un tipo de telemetría double:
{
"@type": "Telemetry",
"displayName": {
"en": "DoubleTelemetry"
},
"name": "DoubleTelemetry",
"schema": "double"
}
Un cliente de dispositivo debe enviar la telemetría como JSON con un aspecto similar al del ejemplo siguiente:
{ "DoubleTelemetry": 56.78 }
El siguiente fragmento de código de un modelo de dispositivo muestra la definición de un tipo de telemetría dateTime:
{
"@type": "Telemetry",
"displayName": {
"en": "DateTimeTelemetry"
},
"name": "DateTimeTelemetry",
"schema": "dateTime"
}
Un cliente de dispositivo debe enviar la telemetría como JSON con un aspecto similar al del ejemplo siguiente; los tipos DateTime deben tener el formato ISO 8061:
{ "DateTimeTelemetry": "2020-08-30T19:16:13.853Z" }
El siguiente fragmento de código de un modelo de dispositivo muestra la definición de un tipo de telemetría duration:
{
"@type": "Telemetry",
"displayName": {
"en": "DurationTelemetry"
},
"name": "DurationTelemetry",
"schema": "duration"
}
Un cliente de dispositivo debe enviar la telemetría como JSON con un aspecto similar al del ejemplo siguiente; las duraciones deben tener el formato ISO 8061:
{ "DurationTelemetry": "PT10H24M6.169083011336625S" }
Tipos complejos
En esta sección se muestran ejemplos de los tipos de telemetría complejos que un dispositivo puede transmitir.
El siguiente fragmento de código de un modelo de dispositivo muestra la definición de un tipo de telemetría Enum:
{
"@type": "Telemetry",
"displayName": {
"en": "EnumTelemetry"
},
"name": "EnumTelemetry",
"schema": {
"@type": "Enum",
"displayName": {
"en": "Enum"
},
"valueSchema": "integer",
"enumValues": [
{
"displayName": {
"en": "Item1"
},
"enumValue": 0,
"name": "Item1"
},
{
"displayName": {
"en": "Item2"
},
"enumValue": 1,
"name": "Item2"
},
{
"displayName": {
"en": "Item3"
},
"enumValue": 2,
"name": "Item3"
}
]
}
}
Un cliente de dispositivo debe enviar la telemetría como JSON con un aspecto similar al del ejemplo siguiente. Los valores posibles son 0, 1y 2, que se muestran en IoT Central como Item1, Item2 y Item3:
{ "EnumTelemetry": 1 }
El siguiente fragmento de código de un modelo de dispositivo muestra la definición de un tipo de telemetría Object. Este objeto tiene tres campos con tipos dateTime, integer y Enum:
{
"@type": "Telemetry",
"displayName": {
"en": "ObjectTelemetry"
},
"name": "ObjectTelemetry",
"schema": {
"@type": "Object",
"displayName": {
"en": "Object"
},
"fields": [
{
"displayName": {
"en": "Property1"
},
"name": "Property1",
"schema": "dateTime"
},
{
"displayName": {
"en": "Property2"
},
"name": "Property2",
"schema": "integer"
},
{
"displayName": {
"en": "Property3"
},
"name": "Property3",
"schema": {
"@type": "Enum",
"displayName": {
"en": "Enum"
},
"valueSchema": "integer",
"enumValues": [
{
"displayName": {
"en": "Item1"
},
"enumValue": 0,
"name": "Item1"
},
{
"displayName": {
"en": "Item2"
},
"enumValue": 1,
"name": "Item2"
},
{
"displayName": {
"en": "Item3"
},
"enumValue": 2,
"name": "Item3"
}
]
}
}
]
}
}
Un cliente de dispositivo debe enviar la telemetría como JSON con un aspecto similar al del ejemplo siguiente. Los tipos DateTime deben cumplir con la norma ISO 8061. Los valores posibles para Property3 son 0 y 1, que se muestran en IoT Central como Item1, Item2 y Item3:
{
"ObjectTelemetry": {
"Property1": "2020-09-09T03:36:46.195Z",
"Property2": 37,
"Property3": 2
}
}
El siguiente fragmento de código de un modelo de dispositivo muestra la definición de un tipo de telemetría vector:
{
"@type": "Telemetry",
"displayName": {
"en": "VectorTelemetry"
},
"name": "VectorTelemetry",
"schema": "vector"
}
Un cliente de dispositivo debe enviar la telemetría como JSON con un aspecto similar al del ejemplo siguiente:
{
"VectorTelemetry": {
"x": 74.72395045538597,
"y": 74.72395045538597,
"z": 74.72395045538597
}
}
El siguiente fragmento de código de un modelo de dispositivo muestra la definición de un tipo de telemetría geopoint:
{
"@type": "Telemetry",
"displayName": {
"en": "GeopointTelemetry"
},
"name": "GeopointTelemetry",
"schema": "geopoint"
}
Nota:
El tipo de esquema geopoint forma parte de la extensión de IoT Central a DTDL. Actualmente, IoT Central admite el tipo de esquema geopoint y el tipo semántico location para la compatibilidad con versiones anteriores.
Un cliente de dispositivo debe enviar la telemetría como JSON con un aspecto similar al del ejemplo siguiente. IoT Central muestra el valor como una chincheta en un mapa:
{
"GeopointTelemetry": {
"lat": 47.64263,
"lon": -122.13035,
"alt": 0
}
}
Tipos de eventos y estados
En esta sección se muestran ejemplos de eventos y estados de telemetría que un dispositivo envía a una aplicación de IoT Central.
Nota:
Los tipos de esquema event y state forman parte de la extensión de IoT Central a DTDL.
El siguiente fragmento de código de un modelo de dispositivo muestra la definición de un tipo de evento integer:
{
"@type": [
"Telemetry",
"Event"
],
"displayName": {
"en": "IntegerEvent"
},
"name": "IntegerEvent",
"schema": "integer"
}
Un cliente de dispositivo debe enviar los datos del evento como JSON con un aspecto similar al del ejemplo siguiente:
{ "IntegerEvent": 74 }
El siguiente fragmento de código de un modelo de dispositivo muestra la definición de un tipo de estado integer:
{
"@type": [
"Telemetry",
"State"
],
"displayName": {
"en": "IntegerState"
},
"name": "IntegerState",
"schema": {
"@type": "Enum",
"valueSchema": "integer",
"enumValues": [
{
"displayName": {
"en": "Level1"
},
"enumValue": 1,
"name": "Level1"
},
{
"displayName": {
"en": "Level2"
},
"enumValue": 2,
"name": "Level2"
},
{
"displayName": {
"en": "Level3"
},
"enumValue": 3,
"name": "Level3"
}
]
}
}
Un cliente de dispositivo debe enviar el estado como JSON con un aspecto similar al del ejemplo siguiente. Los valores de estado entero posibles son 1, 2 o 3:
{ "IntegerState": 2 }
Propiedades
Para obtener más información sobre las reglas de nomenclatura de propiedades de DTDL, consulte DTDL > Propiedad. El nombre de propiedad no puede comenzar con el carácter _.
Propiedades en componentes
Si la propiedad está definida en un componente, encapsule la propiedad en el nombre del componente. En el ejemplo siguiente se establece la propiedad maxTempSinceLastReboot en el componente thermostat2. El marcador __t indica que esta sección define un componente:
{
"thermostat2" : {
"__t" : "c",
"maxTempSinceLastReboot" : 38.7
}
}
Para más información, consulte Tutorial: Creación y conexión de un aplicación cliente a una aplicación de Azure IoT Central.
Tipos primitivos
En esta sección se muestran ejemplos de tipos de propiedad primitivos que un dispositivo envía a un servicio.
En el siguiente fragmento de código de un modelo de dispositivo se muestra la definición de un tipo de propiedad boolean:
{
"@type": "Property",
"displayName": {
"en": "BooleanProperty"
},
"name": "BooleanProperty",
"schema": "boolean",
"writable": false
}
Un cliente de dispositivo debe enviar una carga JSON similar a la del ejemplo siguiente como una propiedad notificada en el dispositivo gemelo:
{ "BooleanProperty": false }
En el siguiente fragmento de código de un modelo de dispositivo se muestra la definición de un tipo de propiedad long:
{
"@type": "Property",
"displayName": {
"en": "LongProperty"
},
"name": "LongProperty",
"schema": "long",
"writable": false
}
Un cliente de dispositivo debe enviar una carga JSON similar a la del ejemplo siguiente como una propiedad notificada en el dispositivo gemelo:
{ "LongProperty": 439 }
En el siguiente fragmento de código de un modelo de dispositivo se muestra la definición de un tipo de propiedad date:
{
"@type": "Property",
"displayName": {
"en": "DateProperty"
},
"name": "DateProperty",
"schema": "date",
"writable": false
}
Un cliente de dispositivo debe enviar una carga JSON similar a la del ejemplo siguiente como una propiedad notificada en el dispositivo gemelo. Los tipos Date deben cumplir con la norma ISO 8061:
{ "DateProperty": "2020-05-17" }
En el siguiente fragmento de código de un modelo de dispositivo se muestra la definición de un tipo de propiedad duration:
{
"@type": "Property",
"displayName": {
"en": "DurationProperty"
},
"name": "DurationProperty",
"schema": "duration",
"writable": false
}
Un cliente de dispositivo debe enviar una carga JSON similar a la del ejemplo siguiente como una propiedad notificada en el dispositivo gemelo; las duraciones deben cumplir con la duración de la norma ISO 8601:
{ "DurationProperty": "PT10H24M6.169083011336625S" }
En el siguiente fragmento de código de un modelo de dispositivo se muestra la definición de un tipo de propiedad float:
{
"@type": "Property",
"displayName": {
"en": "FloatProperty"
},
"name": "FloatProperty",
"schema": "float",
"writable": false
}
Un cliente de dispositivo debe enviar una carga JSON similar a la del ejemplo siguiente como una propiedad notificada en el dispositivo gemelo:
{ "FloatProperty": 1.9 }
En el siguiente fragmento de código de un modelo de dispositivo se muestra la definición de un tipo de propiedad string:
{
"@type": "Property",
"displayName": {
"en": "StringProperty"
},
"name": "StringProperty",
"schema": "string",
"writable": false
}
Un cliente de dispositivo debe enviar una carga JSON similar a la del ejemplo siguiente como una propiedad notificada en el dispositivo gemelo:
{ "StringProperty": "A string value - could be a URL" }
Tipos complejos
En esta sección se muestran ejemplos de tipos de propiedad complejos que un dispositivo envía a un servicio.
En el siguiente fragmento de código de un modelo de dispositivo se muestra la definición de un tipo de propiedad Enum:
{
"@type": "Property",
"displayName": {
"en": "EnumProperty"
},
"name": "EnumProperty",
"writable": false,
"schema": {
"@type": "Enum",
"displayName": {
"en": "Enum"
},
"valueSchema": "integer",
"enumValues": [
{
"displayName": {
"en": "Item1"
},
"enumValue": 0,
"name": "Item1"
},
{
"displayName": {
"en": "Item2"
},
"enumValue": 1,
"name": "Item2"
},
{
"displayName": {
"en": "Item3"
},
"enumValue": 2,
"name": "Item3"
}
]
}
}
Un cliente de dispositivo debe enviar una carga JSON similar a la del ejemplo siguiente como una propiedad notificada en el dispositivo gemelo. Los valores posibles son 0 y 1, que se muestran en IoT Central como Item1, Item2 y Item3:
{ "EnumProperty": 1 }
En el siguiente fragmento de código de un modelo de dispositivo se muestra la definición de un tipo de propiedad Object. Este objeto tiene dos campos con tipos string y integer:
{
"@type": "Property",
"displayName": {
"en": "ObjectProperty"
},
"name": "ObjectProperty",
"writable": false,
"schema": {
"@type": "Object",
"displayName": {
"en": "Object"
},
"fields": [
{
"displayName": {
"en": "Field1"
},
"name": "Field1",
"schema": "integer"
},
{
"displayName": {
"en": "Field2"
},
"name": "Field2",
"schema": "string"
}
]
}
}
Un cliente de dispositivo debe enviar una carga JSON similar a la del ejemplo siguiente como una propiedad notificada en el dispositivo gemelo:
{
"ObjectProperty": {
"Field1": 37,
"Field2": "A string value"
}
}
En el siguiente fragmento de código de un modelo de dispositivo se muestra la definición de un tipo de propiedad vector:
{
"@type": "Property",
"displayName": {
"en": "VectorProperty"
},
"name": "VectorProperty",
"schema": "vector",
"writable": false
}
Un cliente de dispositivo debe enviar una carga JSON similar a la del ejemplo siguiente como una propiedad notificada en el dispositivo gemelo:
{
"VectorProperty": {
"x": 74.72395045538597,
"y": 74.72395045538597,
"z": 74.72395045538597
}
}
En el siguiente fragmento de código de un modelo de dispositivo se muestra la definición de un tipo de propiedad geopoint:
{
"@type": "Property",
"displayName": {
"en": "GeopointProperty"
},
"name": "GeopointProperty",
"schema": "geopoint",
"writable": false
}
Nota:
El tipo de esquema geopoint forma parte de la extensión de IoT Central a DTDL. Actualmente, IoT Central admite el tipo de esquema geopoint y el tipo semántico location para la compatibilidad con versiones anteriores.
Un cliente de dispositivo debe enviar una carga JSON similar a la del ejemplo siguiente como una propiedad notificada en el dispositivo gemelo:
{
"GeopointProperty": {
"lat": 47.64263,
"lon": -122.13035,
"alt": 0
}
}
Tipos de propiedad grabables
En esta sección se muestran ejemplos de tipos de propiedad grabable que un dispositivo recibe de un servicio.
Si la propiedad grabable está definida en un componente, el mensaje de propiedad deseado incluirá el nombre del componente. En el ejemplo siguiente se muestra el mensaje que solicita que el dispositivo actualice la propiedad targetTemperature en el componente thermostat2. El marcador __t indica que esta sección define un componente:
{
"thermostat2": {
"targetTemperature": {
"value": 57
},
"__t": "c"
},
"$version": 3
}
Para más información, consulte Conexión de un dispositivo IoT Plug and Play aplicaciones de múltiples componentes.
El dispositivo o módulo debe confirmar que recibió la propiedad mediante el envío de una propiedad notificada. La propiedad notificada debe incluir:
value: el valor real de la propiedad (normalmente el valor recibido, pero el dispositivo puede decidir informar de un valor diferente).ac: un código de confirmación que usa un código de estado HTTP.av: una versión de confirmación que hace referencia a la$versionde la propiedad deseada. Puede encontrar este valor en la carga de JSON de la propiedad deseada.ad: una descripción de confirmación opcional.
Para más información sobre estos campos, consulte Convenciones de IoT Plug and Play > Respuestas de confirmación
En el siguiente fragmento de código de un modelo de dispositivo se muestra la definición de un tipo de propiedad string grabable:
{
"@type": "Property",
"displayName": {
"en": "StringPropertyWritable"
},
"name": "StringPropertyWritable",
"writable": true,
"schema": "string"
}
El dispositivo recibe la siguiente carga del servicio:
{
"StringPropertyWritable": "A string from IoT Central", "$version": 7
}
El dispositivo debe enviar la siguiente carga JSON al servicio después de que este procese la actualización. Este mensaje incluye el número de versión de la actualización original recibida del servicio.
Sugerencia
Si el servicio no es IoT Central, marca la propiedad como sincronizada en la interfaz de usuario al recibir este mensaje:
{
"StringPropertyWritable": {
"value": "A string from IoT Central",
"ac": 200,
"ad": "completed",
"av": 7
}
}
En el siguiente fragmento de código de un modelo de dispositivo se muestra la definición de un tipo de propiedad Enum grabable:
{
"@type": "Property",
"displayName": {
"en": "EnumPropertyWritable"
},
"name": "EnumPropertyWritable",
"writable": true,
"schema": {
"@type": "Enum",
"displayName": {
"en": "Enum"
},
"valueSchema": "integer",
"enumValues": [
{
"displayName": {
"en": "Item1"
},
"enumValue": 0,
"name": "Item1"
},
{
"displayName": {
"en": "Item2"
},
"enumValue": 1,
"name": "Item2"
},
{
"displayName": {
"en": "Item3"
},
"enumValue": 2,
"name": "Item3"
}
]
}
}
El dispositivo recibe la siguiente carga del servicio:
{
"EnumPropertyWritable": 1 , "$version": 10
}
El dispositivo debe enviar la siguiente carga JSON al servicio después de que este procese la actualización. Este mensaje incluye el número de versión de la actualización original recibida del servicio.
Sugerencia
Si el servicio no es IoT Central, marca la propiedad como sincronizada en la interfaz de usuario al recibir este mensaje:
{
"EnumPropertyWritable": {
"value": 1,
"ac": 200,
"ad": "completed",
"av": 10
}
}
Comandos
Para obtener más información sobre las reglas de nomenclatura de comandos de DTDL, consulte DTDL > Comando. El nombre de comando no puede comenzar con el carácter _.
Si el comando está definido en un componente, el nombre del comando que recibe el dispositivo incluirá el nombre del componente. Por ejemplo, si el comando se denomina getMaxMinReport y el componente se denomina thermostat2, el dispositivo recibe una solicitud para ejecutar un comando denominado thermostat2*getMaxMinReport.
El siguiente fragmento de código de un modelo de dispositivo muestra la definición de un comando que no tiene ningún parámetro y que no espera que el dispositivo devuelva nada:
{
"@type": "Command",
"displayName": {
"en": "CommandBasic"
},
"name": "CommandBasic"
}
El dispositivo recibe una carga vacía en la solicitud y debe devolver una carga vacía en la respuesta con un código de respuesta HTTP 200 para indicar que la operación se ha realizado correctamente.
El siguiente fragmento de código de un modelo de dispositivo muestra la definición de un comando que tiene un parámetro entero y que espera que el dispositivo devuelva un valor entero:
{
"@type": "Command",
"request": {
"@type": "CommandPayload",
"displayName": {
"en": "RequestParam"
},
"name": "RequestParam",
"schema": "integer"
},
"response": {
"@type": "CommandPayload",
"displayName": {
"en": "ResponseParam"
},
"name": "ResponseParam",
"schema": "integer"
},
"displayName": {
"en": "CommandSimple"
},
"name": "CommandSimple"
}
El dispositivo recibe un valor entero como la carga de la solicitud. El dispositivo debe devolver un valor entero como la carga de respuesta con un código de respuesta HTTP 200 para indicar que la operación se ha realizado correctamente.
El siguiente fragmento de código de un modelo de dispositivo muestra la definición de un comando que tiene un parámetro de objeto y que espera que el dispositivo devuelva un objeto. En este ejemplo, ambos objetos tienen campos de cadena y enteros:
{
"@type": "Command",
"request": {
"@type": "CommandPayload",
"displayName": {
"en": "RequestParam"
},
"name": "RequestParam",
"schema": {
"@type": "Object",
"displayName": {
"en": "Object"
},
"fields": [
{
"displayName": {
"en": "Field1"
},
"name": "Field1",
"schema": "integer"
},
{
"displayName": {
"en": "Field2"
},
"name": "Field2",
"schema": "string"
}
]
}
},
"response": {
"@type": "CommandPayload",
"displayName": {
"en": "ResponseParam"
},
"name": "ResponseParam",
"schema": {
"@type": "Object",
"displayName": {
"en": "Object"
},
"fields": [
{
"displayName": {
"en": "Field1"
},
"name": "Field1",
"schema": "integer"
},
{
"displayName": {
"en": "Field2"
},
"name": "Field2",
"schema": "string"
}
]
}
},
"displayName": {
"en": "CommandComplex"
},
"name": "CommandComplex"
}
El siguiente fragmento de código muestra una carga de solicitud de ejemplo enviada al dispositivo:
{ "Field1": 56, "Field2": "A string value" }
El siguiente fragmento de código muestra una carga de respuesta de ejemplo enviada desde el dispositivo. Use un código de respuesta HTTP 200 para indicar que la operación se ha realizado correctamente:
{ "Field1": 87, "Field2": "Another string value" }
Sugerencia
IoT Central tiene sus propias convenciones para implementar Comandos de ejecución prolongada y Comandos sin conexión.
Pasos siguientes
Ahora que ha obtenido información sobre las cargas de dispositivo, se recomienda leer la guía para desarrolladores de dispositivos.
Comentarios
Proximamente: Ao longo de 2024, retiraremos gradualmente GitHub Issues como mecanismo de comentarios sobre o contido e substituirémolo por un novo sistema de comentarios. Para obter máis información, consulte: https://aka.ms/ContentUserFeedback.
Enviar e ver os comentarios