Полезные данные телеметрии, свойств и команд
Модель устройства определяет следующее:
- Данные телеметрии устройства отправляются в службу.
- Свойства устройства синхронизируются со службой.
- Команды, вызываемые службой на устройстве.
Совет
Azure IoT Central — это служба, которая соответствует соглашениям самонастраивающийся. В IoT Central модель устройства является частью шаблона устройства. IoT Central в настоящее время поддерживает DTDL версии 2 с расширением IoT Central. Приложение IoT Central ожидает получения данных JSON в кодировке UTF-8.
В этой статье описываются полезные данные JSON, которые устройства отправляют и получают для телеметрии, свойств и команд, определенных в модели устройства DTDL.
В статье не описаны все возможные типы телеметрии, свойств и полезных данных команд, но в примерах показаны ключевые типы.
В каждом примере показан фрагмент кода из модели устройства, который определяет тип и пример полезных данных JSON для иллюстрации того, как устройство должно взаимодействовать с самонастраивающийся ознаменующей службой, например IoT Central.
Пример фрагментов JSON в этой статье использует язык определения цифровых двойников (DTDL) версии 2. Существуют также некоторые расширения DTDL, которые использует IoT Central .
Пример кода устройства, в котором показаны некоторые из этих полезных данных, см. в Подключение пример приложения IoT самонастраивающийся устройства, работающего в Linux или Windows, для Центр Интернета вещей руководства по созданию и подключению клиентского приложения к руководству по приложению Azure IoT Central.
Просмотр необработанных данных
Если вы используете IoT Central, вы можете просмотреть необработанные данные, которые устройство отправляет в приложение. Это представление полезно для устранения неполадок, связанных с полезными данными, отправленными с устройства. Для просмотра необработанных данных, отправляемых устройством:
Перейдите на устройство со страницы Устройства.
Перейдите на вкладку Необработанные данные:
В этом представлении можно выбрать отображаемые столбцы и задать диапазон времени для просмотра. В столбце Unmodeled data (Немоделированные данные) отображаются данные с устройства, которые не соответствуют ни одному из определений свойств или телеметрии в шаблоне устройства.
Дополнительные советы по устранению неполадок см. в статье "Устранение неполадок, почему данные с устройств не отображаются в Azure IoT Central".
Телеметрия
Дополнительные сведения о правилах именования телеметрии DTDL см. в статье DTDL > Telemetry. Невозможно запустить имя телеметрии с помощью символа _
.
Не создавайте типы телеметрии со следующими именами. IoT Central использует эти зарезервированные имена внутренне. Если вы попытаетесь использовать эти имена, IoT Central будет игнорировать данные:
EventEnqueuedUtcTime
EventProcessedUtcTime
PartitionId
EventHub
User
$metadata
$version
Телеметрия в компонентах
Если данные телеметрии определены в компоненте, добавьте настраиваемое свойство сообщения с именем $.sub
и именем компонента, определенным в модели устройства. Дополнительные сведения см. в руководстве. Подключение самонастраивающийся нескольких приложений устройств с несколькими компонентами. В этом руководстве показано, как использовать различные языки программирования для отправки данных телеметрии из компонента.
Внимание
Чтобы правильно отобразить данные телеметрии из компонентов, размещенных в модулях IoT Edge, используйте IoT Edge версии 1.2.4 или более поздней. Если вы используете более раннюю версию, данные телеметрии из компонентов в модулях IoT Edge отображаются как _unmodeleddata.
Телеметрия в унаследованных интерфейсах
Если данные телеметрии определены в наследуемом интерфейсе, устройство отправляет данные телеметрии, как если бы оно определено в корневом интерфейсе. Учитывая следующую модель устройства:
[
{
"@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"
}
]
Устройство отправляет данные телеметрии счетчика напряжения с помощью следующей полезных данных. Устройство не включает имя интерфейса в полезные данные:
{
"MeterVoltage": 5.07
}
Примитивные типы
В этом разделе показаны примеры примитивных типов телеметрии, которые устройство может передавать.
В следующем фрагменте кода из модели устройства показано определение типа телеметрии boolean
:
{
"@type": "Telemetry",
"displayName": {
"en": "BooleanTelemetry"
},
"name": "BooleanTelemetry",
"schema": "boolean"
}
Клиент устройства должен отправить данные телеметрии как JSON, который выглядит так, как показано в следующем примере:
{ "BooleanTelemetry": true }
В следующем фрагменте кода из модели устройства показано определение типа телеметрии string
:
{
"@type": "Telemetry",
"displayName": {
"en": "StringTelemetry"
},
"name": "StringTelemetry",
"schema": "string"
}
Клиент устройства должен отправить данные телеметрии как JSON, который выглядит так, как показано в следующем примере:
{ "StringTelemetry": "A string value - could be a URL" }
В следующем фрагменте кода из модели устройства показано определение типа телеметрии integer
:
{
"@type": "Telemetry",
"displayName": {
"en": "IntegerTelemetry"
},
"name": "IntegerTelemetry",
"schema": "integer"
}
Клиент устройства должен отправить данные телеметрии как JSON, который выглядит так, как показано в следующем примере:
{ "IntegerTelemetry": 23 }
В следующем фрагменте кода из модели устройства показано определение типа телеметрии double
:
{
"@type": "Telemetry",
"displayName": {
"en": "DoubleTelemetry"
},
"name": "DoubleTelemetry",
"schema": "double"
}
Клиент устройства должен отправить данные телеметрии как JSON, который выглядит так, как показано в следующем примере:
{ "DoubleTelemetry": 56.78 }
В следующем фрагменте кода из модели устройства показано определение типа телеметрии dateTime
:
{
"@type": "Telemetry",
"displayName": {
"en": "DateTimeTelemetry"
},
"name": "DateTimeTelemetry",
"schema": "dateTime"
}
Клиент устройства должен отправить данные телеметрии как JSON, который выглядит так, как показано в следующем примере, — типы DateTime
должны быть в формате ISO 8061:
{ "DateTimeTelemetry": "2020-08-30T19:16:13.853Z" }
В следующем фрагменте кода из модели устройства показано определение типа телеметрии duration
:
{
"@type": "Telemetry",
"displayName": {
"en": "DurationTelemetry"
},
"name": "DurationTelemetry",
"schema": "duration"
}
Клиент устройства должен отправить данные телеметрии как JSON, который выглядит так, как показано в следующем примере — длительность должна быть в формате ISO 8601:
{ "DurationTelemetry": "PT10H24M6.169083011336625S" }
Сложные типы
В этом разделе показаны примеры сложных типов телеметрии, которые устройство может передавать.
В следующем фрагменте кода из модели устройства показано определение типа телеметрии 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"
}
]
}
}
Клиент устройства должен отправить данные телеметрии как JSON, который выглядит так, как показано в следующем примере. Возможные значения: 0
, 1
и 2
, которые отображаются в IoT Central как Item1
, Item2
и Item3
:
{ "EnumTelemetry": 1 }
В следующем фрагменте кода из модели устройства показано определение типа телеметрии Object
. Этот объект содержит три поля с типами dateTime
, integer
и 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"
}
]
}
}
]
}
}
Клиент устройства должен отправить данные телеметрии как JSON, который выглядит так, как показано в следующем примере. Типы DateTime
должны соответствовать стандартам ISO 8061. Возможные значения: Property3
, 0
и 1
, которые отображаются в IoT Central как Item1
, Item2
и Item3
:
{
"ObjectTelemetry": {
"Property1": "2020-09-09T03:36:46.195Z",
"Property2": 37,
"Property3": 2
}
}
В следующем фрагменте кода из модели устройства показано определение типа телеметрии vector
:
{
"@type": "Telemetry",
"displayName": {
"en": "VectorTelemetry"
},
"name": "VectorTelemetry",
"schema": "vector"
}
Клиент устройства должен отправить данные телеметрии как JSON, который выглядит так, как показано в следующем примере:
{
"VectorTelemetry": {
"x": 74.72395045538597,
"y": 74.72395045538597,
"z": 74.72395045538597
}
}
В следующем фрагменте кода из модели устройства показано определение типа телеметрии geopoint
:
{
"@type": "Telemetry",
"displayName": {
"en": "GeopointTelemetry"
},
"name": "GeopointTelemetry",
"schema": "geopoint"
}
Примечание.
Тип схемы геоточечных точек является частью расширения IoT Central для DTDL. В настоящее время IoT Central поддерживает тип схемы Геоточка и тип семантики Расположение для обеспечения обратной совместимости.
Клиент устройства должен отправить данные телеметрии как JSON, который выглядит так, как показано в следующем примере. IoT Central отображает значение в виде отметки на карте:
{
"GeopointTelemetry": {
"lat": 47.64263,
"lon": -122.13035,
"alt": 0
}
}
Типы событий и состояний
В этом разделе приведены примеры событий телеметрии и состояний, которые устройство отправляет в приложение IoT Central.
Примечание.
Типы схем событий и состояний являются частью расширения IoT Central для DTDL.
В следующем фрагменте кода из модели устройства показано определение типа события integer
:
{
"@type": [
"Telemetry",
"Event"
],
"displayName": {
"en": "IntegerEvent"
},
"name": "IntegerEvent",
"schema": "integer"
}
Клиент устройства должен отправить данные телеметрии как JSON, который выглядит так, как показано в следующем примере:
{ "IntegerEvent": 74 }
В следующем фрагменте кода из модели устройства показано определение типа события 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"
}
]
}
}
Клиент устройства должен отправить данные телеметрии как JSON, который выглядит так, как показано в следующем примере. Возможные значения целочисленного состояния — 1
, 2
или 3
:
{ "IntegerState": 2 }
Свойства
Дополнительные сведения о правилах именования свойств DTDL см. в разделе "Свойство DTDL>". Невозможно запустить имя свойства с помощью символа _
.
Свойства в компонентах
Если свойство определено в компоненте, заключите свойство в имя компонента. В следующем примере значение задается параметре maxTempSinceLastReboot
компонента thermostat2
. __t
Маркер указывает, что этот раздел определяет компонент:
{
"thermostat2" : {
"__t" : "c",
"maxTempSinceLastReboot" : 38.7
}
}
Узнать больше можно в статье Руководство. Создание клиентского приложения и его подключение к приложению Azure IoT Central.
Примитивные типы
В этом разделе показаны примеры примитивных типов свойств, которые устройство отправляет в службу.
В следующем фрагменте кода из модели устройства показано определение типа свойства boolean
:
{
"@type": "Property",
"displayName": {
"en": "BooleanProperty"
},
"name": "BooleanProperty",
"schema": "boolean",
"writable": false
}
Клиент устройства должен отправить полезные данные JSON, как в следующем примере, в виде сообщаемого свойства для двойника устройства:
{ "BooleanProperty": false }
В следующем фрагменте кода из модели устройства показано определение типа свойства long
:
{
"@type": "Property",
"displayName": {
"en": "LongProperty"
},
"name": "LongProperty",
"schema": "long",
"writable": false
}
Клиент устройства должен отправить полезные данные JSON, как в следующем примере, в виде сообщаемого свойства для двойника устройства:
{ "LongProperty": 439 }
В следующем фрагменте кода из модели устройства показано определение типа свойства date
:
{
"@type": "Property",
"displayName": {
"en": "DateProperty"
},
"name": "DateProperty",
"schema": "date",
"writable": false
}
Клиент устройства должен отправить полезные данные JSON, как в следующем примере, в виде сообщаемого свойства для двойника устройства. Типы Date
должны соответствовать стандартам ISO 8061:
{ "DateProperty": "2020-05-17" }
В следующем фрагменте кода из модели устройства показано определение типа свойства duration
:
{
"@type": "Property",
"displayName": {
"en": "DurationProperty"
},
"name": "DurationProperty",
"schema": "duration",
"writable": false
}
Клиент устройства должен отправить полезные данные JSON, как в следующем примере, в виде сообщаемого свойства для двойника устройства — длительность должна соответствовать стандарту ISO 8601:
{ "DurationProperty": "PT10H24M6.169083011336625S" }
В следующем фрагменте кода из модели устройства показано определение типа свойства float
:
{
"@type": "Property",
"displayName": {
"en": "FloatProperty"
},
"name": "FloatProperty",
"schema": "float",
"writable": false
}
Клиент устройства должен отправить полезные данные JSON, как в следующем примере, в виде сообщаемого свойства для двойника устройства:
{ "FloatProperty": 1.9 }
В следующем фрагменте кода из модели устройства показано определение типа свойства string
:
{
"@type": "Property",
"displayName": {
"en": "StringProperty"
},
"name": "StringProperty",
"schema": "string",
"writable": false
}
Клиент устройства должен отправить полезные данные JSON, как в следующем примере, в виде сообщаемого свойства для двойника устройства:
{ "StringProperty": "A string value - could be a URL" }
Сложные типы
В этом разделе показаны примеры сложных типов свойств, которые устройство отправляет в службу.
В следующем фрагменте кода из модели устройства показано определение типа свойства 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"
}
]
}
}
Клиент устройства должен отправить полезные данные JSON, как в следующем примере, в виде сообщаемого свойства для двойника устройства. Возможные значения: 0
и 1
, которые отображаются в IoT Central как Item1
, Item2
и Item3
:
{ "EnumProperty": 1 }
В следующем фрагменте кода из модели устройства показано определение типа свойства Object
. Этот объект содержит два поля с типами string
и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"
}
]
}
}
Клиент устройства должен отправить полезные данные JSON, как в следующем примере, в виде сообщаемого свойства для двойника устройства:
{
"ObjectProperty": {
"Field1": 37,
"Field2": "A string value"
}
}
В следующем фрагменте кода из модели устройства показано определение типа свойства vector
:
{
"@type": "Property",
"displayName": {
"en": "VectorProperty"
},
"name": "VectorProperty",
"schema": "vector",
"writable": false
}
Клиент устройства должен отправить полезные данные JSON, как в следующем примере, в виде сообщаемого свойства для двойника устройства:
{
"VectorProperty": {
"x": 74.72395045538597,
"y": 74.72395045538597,
"z": 74.72395045538597
}
}
В следующем фрагменте кода из модели устройства показано определение типа свойства geopoint
:
{
"@type": "Property",
"displayName": {
"en": "GeopointProperty"
},
"name": "GeopointProperty",
"schema": "geopoint",
"writable": false
}
Примечание.
Тип схемы геоточечных точек является частью расширения IoT Central для DTDL. В настоящее время IoT Central поддерживает тип схемы Геоточка и тип семантики Расположение для обеспечения обратной совместимости.
Клиент устройства должен отправить полезные данные JSON, как в следующем примере, в виде сообщаемого свойства для двойника устройства:
{
"GeopointProperty": {
"lat": 47.64263,
"lon": -122.13035,
"alt": 0
}
}
Типы свойств, доступных для записи
В этом разделе показаны примеры типов свойств, доступных для записи, получаемых устройством из службы.
Если свойство, доступное для записи, определено в компоненте, сообщение о требуемом свойстве содержит имя компонента. В следующем примере показано сообщение, запрашивающее устройство обновить targetTemperature
в компоненте thermostat2
. __t
Маркер указывает, что этот раздел определяет компонент:
{
"thermostat2": {
"targetTemperature": {
"value": 57
},
"__t": "c"
},
"$version": 3
}
Дополнительные сведения см. в статье Подключение самонастраивающийся нескольких приложений устройств компонентов Интернета вещей.
Устройство или модуль должны подтвердить, что они получили свойство, отправив передаваемое свойство. Передаваемое свойство должно включать в себя:
value
— фактическое значение свойства (обычно полученное значение, однако устройство может передать другое значение).ac
— код подтверждения, использующий код состояния HTTP.av
— версия подтверждения, относящаяся к$version
требуемого свойства. Это значение можно найти в полезных данных JSON требуемого свойства.ad
— необязательное описание подтверждения.
Дополнительные сведения об этих полях см. в статье самонастраивающийся ответы > на подтверждение соглашений Интернета вещей
В следующем фрагменте кода из модели устройства показано определение типа, доступного для записи свойства string
:
{
"@type": "Property",
"displayName": {
"en": "StringPropertyWritable"
},
"name": "StringPropertyWritable",
"writable": true,
"schema": "string"
}
Устройство получает следующие полезные данные от службы:
{
"StringPropertyWritable": "A string from IoT Central", "$version": 7
}
Устройство должно отправлять следующие полезные данные JSON в службу после обработки обновления. Это сообщение содержит номер версии исходного обновления, полученного от службы.
Совет
Если служба является IoT Central, она помечает свойство как синхронизированное в пользовательском интерфейсе при получении этого сообщения:
{
"StringPropertyWritable": {
"value": "A string from IoT Central",
"ac": 200,
"ad": "completed",
"av": 7
}
}
В следующем фрагменте кода из модели устройства показано определение типа, доступного для записи свойства Enum
:
{
"@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"
}
]
}
}
Устройство получает следующие полезные данные от службы:
{
"EnumPropertyWritable": 1 , "$version": 10
}
Устройство должно отправлять следующие полезные данные JSON в службу после обработки обновления. Это сообщение содержит номер версии исходного обновления, полученного от службы.
Совет
Если служба является IoT Central, она помечает свойство как синхронизированное в пользовательском интерфейсе при получении этого сообщения:
{
"EnumPropertyWritable": {
"value": 1,
"ac": 200,
"ad": "completed",
"av": 10
}
}
Команды
Дополнительные сведения о правилах именования команд DTDL см. в разделе "Команда DTDL>". Невозможно запустить имя команды с помощью символа _
.
Если команда определена в компоненте, имя команды, получаемой устройством, содержит имя компонента. Например, если команда называется getMaxMinReport
и вызывается компонент с именем thermostat2
, устройство получает запрос на выполнение команды с именем thermostat2*getMaxMinReport
.
В следующем фрагменте кода из модели устройства показано определение команды, которая не имеет параметров и не ждет, что устройство возвратит какое-либо значение:
{
"@type": "Command",
"displayName": {
"en": "CommandBasic"
},
"name": "CommandBasic"
}
Устройство получает пустые полезные данные в запросе и должно вернуть пустой пакет полезных данных в ответе с кодом HTTP-ответа 200
, чтобы указать на успешное выполнение.
В следующем фрагменте кода из модели устройства показано определение команды, которая не имеет параметров и не ждет, что устройство возвратит какое-либо целочисленное значение:
{
"@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"
}
Устройство получает целочисленное значение в качестве полезных данных запроса. Устройство должно вернуть целочисленное значение в качестве полезных данных ответа с кодом HTTP-ответа 200
, чтобы указать на успешное выполнение.
В следующем фрагменте кода из модели устройства показано определение команды, которая не имеет параметров и ждет, что устройство возвратит объект. В этом примере оба объекта имеют целочисленные и строковые поля:
{
"@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"
}
В следующем фрагменте кода показаны примеры полезных данных запроса, отправленных на устройство:
{ "Field1": 56, "Field2": "A string value" }
В следующем фрагменте кода показаны примеры полезных данных ответа, отправленных на устройство. Используйте код ответа HTTP 200
, чтобы указать на успешное выполнение:
{ "Field1": 87, "Field2": "Another string value" }
Совет
IoT Central имеет собственные соглашения для реализации длительных команд и автономных команд.
Следующие шаги
Теперь, когда вы узнали о полезных данных устройства, рекомендуемый следующий шаг — прочитать руководство разработчика устройств.