Telemetría, propiedades y cargas de comandos
Un modelo de dispositivo define lo siguiente:
- Telemetría que un dispositivo envía a un servicio.
- Propiedades que un dispositivo se sincroniza con un servicio.
- Comandos a los que llama el servicio 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 codificados con UTF-8.
En este artículo se describen las cargas JSON que los dispositivos envían y reciben para la telemetría, las propiedades y los comandos definidos en un modelo de dispositivo DTDL.
El artículo no describe todos los tipos posibles de telemetría, propiedad y carga de comandos, pero los ejemplos ilustran los tipos clave.
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 el dispositivo debe interactuar con un servicio compatible con Plug and Play, como IoT Central.
En los fragmentos de código JSON de ejemplo de este artículo se usa Digital Twin Definition Language (DTDL) V2. También hay algunas extensiones dtDL que IoT Central usa.
Para ver código de dispositivo de ejemplo que muestra algunas de estas cargas en uso, consulte el Conectar tutorial creación y conexión de 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 la 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 obtener más sugerencias de solución de problemas, consulte Solución de problemas de por qué los datos de los dispositivos no aparecen 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: Conectar aplicaciones de dispositivos de varios componentes de IoT Plug and Play. 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 telemetría de voltaje 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 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 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 de punto geográfico 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 de evento y estado 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 propiedades 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 de punto geográfico 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 propiedades grabables que recibe un dispositivo 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 Conectar aplicaciones de dispositivos de varios componentes de IoT Plug and Play.
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 Las 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 procesar la actualización. Este mensaje incluye el número de versión de la actualización original recibida del servicio.
Sugerencia
Si el servicio es IoT Central, marca la propiedad como sincronizada en la interfaz de usuario cuando recibe 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 procesar la actualización. Este mensaje incluye el número de versión de la actualización original recibida del servicio.
Sugerencia
Si el servicio es IoT Central, marca la propiedad como sincronizada en la interfaz de usuario cuando recibe 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 dispositivos, los pasos siguientes sugeridos son leer la guía para desarrolladores de dispositivos.