Ładunki telemetrii, właściwości i polecenia

Artykuł
02/06/2024

Model urządzenia definiuje następujące elementy:

Dane telemetryczne wysyłane do usługi.
Właściwości urządzenia synchronizują się z usługą.
Polecenia, które usługa wywołuje na urządzeniu.

Napiwek

Azure IoT Central to usługa zgodna z konwencjami Plug and Play. W usłudze IoT Central model urządzenia jest częścią szablonu urządzenia. Usługa IoT Central obecnie obsługuje język DTDL w wersji 2 z rozszerzeniem usługi IoT Central. Aplikacja usługi IoT Central oczekuje odbierania zakodowanych danych JSON utF-8.

W tym artykule opisano ładunki JSON, które urządzenia wysyłają i odbierają dane telemetryczne, właściwości i polecenia zdefiniowane w modelu urządzenia DTDL.

W tym artykule nie opisano każdego możliwego typu danych telemetrycznych, właściwości i ładunku poleceń, ale przykłady ilustrują typy kluczy.

Każdy przykład przedstawia fragment kodu z modelu urządzenia, który definiuje typ i przykładowe ładunki JSON, aby zilustrować sposób interakcji urządzenia z usługą z obsługą plug and Play, taką jak usługa IoT Central.

Przykładowe fragmenty kodu JSON w tym artykule używają języka Digital Twin Definition Language (DTDL) w wersji 2. Istnieją również pewne rozszerzenia DTDL używane przez usługę IoT Central .

Przykładowy kod urządzenia, który pokazuje niektóre z tych ładunków w użyciu, zobacz Połączenie przykładową aplikację urządzenia IoT Plug and Play działającą w systemie Linux lub Windows do usługi IoT Hub lub samouczek Tworzenie i łączenie aplikacji klienckiej z aplikacją usługi Azure IoT Central.

Wyświetlanie danych pierwotnych

Jeśli używasz usługi IoT Central, możesz wyświetlić nieprzetworzone dane wysyłane przez urządzenie do aplikacji. Ten widok jest przydatny do rozwiązywania problemów z ładunkiem wysłanym z urządzenia. Aby wyświetlić nieprzetworzone dane wysyłane przez urządzenie:

Przejdź do urządzenia ze strony Urządzenia .
Wybierz kartę Nieprzetworzone dane :

W tym widoku możesz wybrać kolumny do wyświetlenia i ustawić zakres czasu do wyświetlenia. W kolumnie Dane niemodelowane są wyświetlane dane z urządzenia, które nie są zgodne z żadną właściwością ani definicjami telemetrii w szablonie urządzenia.

Aby uzyskać więcej porad dotyczących rozwiązywania problemów, zobacz Rozwiązywanie problemów z brakiem wyświetlania danych z urządzeń w usłudze Azure IoT Central.

Telemetria

Aby dowiedzieć się więcej na temat reguł nazewnictwa telemetrii DTDL, zobacz Telemetria DTDL>. Nie można uruchomić nazwy telemetrii przy użyciu _ znaku .

Nie twórz typów telemetrii o następujących nazwach. Usługa IoT Central używa tych nazw zarezerwowanych wewnętrznie. Jeśli spróbujesz użyć tych nazw, usługa IoT Central zignoruje dane:

EventEnqueuedUtcTime
EventProcessedUtcTime
PartitionId
EventHub
User
$metadata
$version

Telemetria w składnikach

Jeśli telemetria jest zdefiniowana w składniku, dodaj niestandardową właściwość komunikatu o nazwie $.sub składnika zgodnie z definicją w modelu urządzenia. Aby dowiedzieć się więcej, zobacz Samouczek: Połączenie aplikacji urządzeń z wieloma składnikami IoT Plug and Play. W tym samouczku pokazano, jak używać różnych języków programowania do wysyłania danych telemetrycznych ze składnika.

Ważne

Aby poprawnie wyświetlić dane telemetryczne ze składników hostowanych w modułach usługi IoT Edge, użyj usługi IoT Edge w wersji 1.2.4 lub nowszej. Jeśli używasz starszej wersji, dane telemetryczne ze składników w modułach usługi IoT Edge są wyświetlane jako _unmodeleddata.

Telemetria w odziedziczonych interfejsach

Jeśli dane telemetryczne są zdefiniowane w odziedziczonym interfejsie, urządzenie wysyła dane telemetryczne tak, jakby zostało zdefiniowane w interfejsie głównym. Biorąc pod uwagę następujący model urządzenia:

[
    {
        "@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"
    }
]

Urządzenie wysyła dane telemetryczne napięcia miernika przy użyciu następującego ładunku. Urządzenie nie zawiera nazwy interfejsu w ładunku:

{
    "MeterVoltage": 5.07
}

Typy pierwotne

W tej sekcji przedstawiono przykłady pierwotnych typów telemetrii, które urządzenie może przesyłać strumieniowo.

Poniższy fragment kodu z modelu urządzenia przedstawia definicję boolean typu telemetrii:

{
  "@type": "Telemetry",
  "displayName": {
    "en": "BooleanTelemetry"
  },
  "name": "BooleanTelemetry",
  "schema": "boolean"
}

Klient urządzenia powinien wysłać dane telemetryczne w formacie JSON, który wygląda jak w poniższym przykładzie:

{ "BooleanTelemetry": true }

Poniższy fragment kodu z modelu urządzenia przedstawia definicję string typu telemetrii:

{
  "@type": "Telemetry",
  "displayName": {
    "en": "StringTelemetry"
  },
  "name": "StringTelemetry",
  "schema": "string"
}

Klient urządzenia powinien wysłać dane telemetryczne w formacie JSON, który wygląda jak w poniższym przykładzie:

{ "StringTelemetry": "A string value - could be a URL" }

Poniższy fragment kodu z modelu urządzenia przedstawia definicję integer typu telemetrii:

{
  "@type": "Telemetry",
  "displayName": {
    "en": "IntegerTelemetry"
  },
  "name": "IntegerTelemetry",
  "schema": "integer"
}

Klient urządzenia powinien wysłać dane telemetryczne w formacie JSON, który wygląda jak w poniższym przykładzie:

{ "IntegerTelemetry": 23 }

Poniższy fragment kodu z modelu urządzenia przedstawia definicję double typu telemetrii:

{
  "@type": "Telemetry",
  "displayName": {
    "en": "DoubleTelemetry"
  },
  "name": "DoubleTelemetry",
  "schema": "double"
}

Klient urządzenia powinien wysłać dane telemetryczne w formacie JSON, który wygląda jak w poniższym przykładzie:

{ "DoubleTelemetry": 56.78 }

Poniższy fragment kodu z modelu urządzenia przedstawia definicję dateTime typu telemetrii:

{
  "@type": "Telemetry",
  "displayName": {
    "en": "DateTimeTelemetry"
  },
  "name": "DateTimeTelemetry",
  "schema": "dateTime"
}

Klient urządzenia powinien wysłać dane telemetryczne w formacie JSON, który wygląda jak w poniższym przykładzie — DateTime typy muszą mieć format ISO 8061:

{ "DateTimeTelemetry": "2020-08-30T19:16:13.853Z" }

Poniższy fragment kodu z modelu urządzenia przedstawia definicję duration typu telemetrii:

{
  "@type": "Telemetry",
  "displayName": {
    "en": "DurationTelemetry"
  },
  "name": "DurationTelemetry",
  "schema": "duration"
}

Klient urządzenia powinien wysłać dane telemetryczne w formacie JSON, który wygląda jak w poniższym przykładzie — czasy trwania muszą mieć format ISO 8601:

{ "DurationTelemetry": "PT10H24M6.169083011336625S" }

Typy złożone

W tej sekcji przedstawiono przykłady złożonych typów telemetrii, które urządzenie może przesyłać strumieniowo.

Poniższy fragment kodu z modelu urządzenia przedstawia definicję Enum typu telemetrii:

{
  "@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"
      }
    ]
  }
}

Klient urządzenia powinien wysłać dane telemetryczne w formacie JSON, który wygląda jak w poniższym przykładzie. Możliwe wartości to 0, 1i 2 , które są wyświetlane w usłudze IoT Central jako Item1, Item2i Item3:

{ "EnumTelemetry": 1 }

Poniższy fragment kodu z modelu urządzenia przedstawia definicję Object typu telemetrii. Ten obiekt ma trzy pola z typami dateTime, integeri 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"
            }
          ]
        }
      }
    ]
  }
}

Klient urządzenia powinien wysłać dane telemetryczne w formacie JSON, który wygląda jak w poniższym przykładzie. DateTime typy muszą być zgodne ze standardem ISO 8061. Możliwe wartości Property3 to 0, 1i, które są wyświetlane w usłudze IoT Central jako Item1, Item2i Item3:

{
  "ObjectTelemetry": {
      "Property1": "2020-09-09T03:36:46.195Z",
      "Property2": 37,
      "Property3": 2
  }
}

Poniższy fragment kodu z modelu urządzenia przedstawia definicję vector typu telemetrii:

{
  "@type": "Telemetry",
  "displayName": {
    "en": "VectorTelemetry"
  },
  "name": "VectorTelemetry",
  "schema": "vector"
}

Klient urządzenia powinien wysłać dane telemetryczne w formacie JSON, który wygląda jak w poniższym przykładzie:

{
  "VectorTelemetry": {
    "x": 74.72395045538597,
    "y": 74.72395045538597,
    "z": 74.72395045538597
  }
}

Poniższy fragment kodu z modelu urządzenia przedstawia definicję geopoint typu telemetrii:

{
  "@type": "Telemetry",
  "displayName": {
    "en": "GeopointTelemetry"
  },
  "name": "GeopointTelemetry",
  "schema": "geopoint"
}

Uwaga

Typ schematu punktu geograficznego jest częścią rozszerzenia usługi IoT Central do języka DTDL. Usługa IoT Central obecnie obsługuje typ schematu punktu geograficznego i typ semantyczny lokalizacji w celu zapewnienia zgodności z poprzednimi wersjami.

Klient urządzenia powinien wysłać dane telemetryczne w formacie JSON, który wygląda jak w poniższym przykładzie. Usługa IoT Central wyświetla wartość jako pinezkę na mapie:

{
  "GeopointTelemetry": {
    "lat": 47.64263,
    "lon": -122.13035,
    "alt": 0
  }
}

Typy zdarzeń i stanów

W tej sekcji przedstawiono przykłady zdarzeń telemetrii i stanów, które urządzenie wysyła do aplikacji usługi IoT Central.

Uwaga

Typy schematów zdarzeń i stanów są częścią rozszerzenia usługi IoT Central do języka DTDL.

Poniższy fragment kodu z modelu urządzenia przedstawia definicję integer typu zdarzenia:

{
  "@type": [
    "Telemetry",
    "Event"
  ],
  "displayName": {
    "en": "IntegerEvent"
  },
  "name": "IntegerEvent",
  "schema": "integer"
}

Klient urządzenia powinien wysłać dane zdarzenia jako dane JSON, które wyglądają jak w poniższym przykładzie:

{ "IntegerEvent": 74 }

Poniższy fragment kodu z modelu urządzenia przedstawia definicję integer typu stanu:

{
  "@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"
      }
    ]
  }
}

Klient urządzenia powinien wysłać stan w formacie JSON, który wygląda jak w poniższym przykładzie. Możliwe wartości stanu liczby całkowitej to 1, 2lub 3:

{ "IntegerState": 2 }

Właściwości

Aby dowiedzieć się więcej o regułach nazewnictwa właściwości DTDL, zobacz Właściwość DTDL>. Nie można uruchomić nazwy właściwości przy użyciu _ znaku .

Właściwości w składnikach

Jeśli właściwość jest zdefiniowana w składniku, zawijaj właściwość w nazwie składnika. Poniższy przykład ustawia element maxTempSinceLastReboot w składniku thermostat2 . __t Znacznik wskazuje, że ta sekcja definiuje składnik:

{
  "thermostat2" : {  
    "__t" : "c",  
    "maxTempSinceLastReboot" : 38.7
    } 
}

Aby dowiedzieć się więcej, zobacz Samouczek: tworzenie i łączenie aplikacji klienckiej z aplikacją usługi Azure IoT Central.

Typy pierwotne

W tej sekcji przedstawiono przykłady typów właściwości pierwotnych wysyłanych przez urządzenie do usługi.

Poniższy fragment kodu z modelu urządzenia przedstawia definicję boolean typu właściwości:

{
  "@type": "Property",
  "displayName": {
    "en": "BooleanProperty"
  },
  "name": "BooleanProperty",
  "schema": "boolean",
  "writable": false
}

Klient urządzenia powinien wysłać ładunek JSON, który wygląda jak w poniższym przykładzie jako zgłoszona właściwość w bliźniaczej reprezentacji urządzenia:

{ "BooleanProperty": false }

Poniższy fragment kodu z modelu urządzenia przedstawia definicję long typu właściwości:

{
  "@type": "Property",
  "displayName": {
    "en": "LongProperty"
  },
  "name": "LongProperty",
  "schema": "long",
  "writable": false
}

Klient urządzenia powinien wysłać ładunek JSON, który wygląda jak w poniższym przykładzie jako zgłoszona właściwość w bliźniaczej reprezentacji urządzenia:

{ "LongProperty": 439 }

Poniższy fragment kodu z modelu urządzenia przedstawia definicję date typu właściwości:

{
  "@type": "Property",
  "displayName": {
    "en": "DateProperty"
  },
  "name": "DateProperty",
  "schema": "date",
  "writable": false
}

Klient urządzenia powinien wysłać ładunek JSON, który wygląda jak poniższy przykład jako zgłoszona właściwość w bliźniaczej reprezentacji urządzenia. Date typy muszą być zgodne ze standardem ISO 8061:

{ "DateProperty": "2020-05-17" }

Poniższy fragment kodu z modelu urządzenia przedstawia definicję duration typu właściwości:

{
  "@type": "Property",
  "displayName": {
    "en": "DurationProperty"
  },
  "name": "DurationProperty",
  "schema": "duration",
  "writable": false
}

Klient urządzenia powinien wysłać ładunek JSON, który wygląda jak w poniższym przykładzie jako zgłoszona właściwość w bliźniaczej reprezentacji urządzenia — czasy trwania muszą być zgodne z normą ISO 8601:

{ "DurationProperty": "PT10H24M6.169083011336625S" }

Poniższy fragment kodu z modelu urządzenia przedstawia definicję float typu właściwości:

{
  "@type": "Property",
  "displayName": {
    "en": "FloatProperty"
  },
  "name": "FloatProperty",
  "schema": "float",
  "writable": false
}

Klient urządzenia powinien wysłać ładunek JSON, który wygląda jak w poniższym przykładzie jako zgłoszona właściwość w bliźniaczej reprezentacji urządzenia:

{ "FloatProperty": 1.9 }

Poniższy fragment kodu z modelu urządzenia przedstawia definicję string typu właściwości:

{
  "@type": "Property",
  "displayName": {
    "en": "StringProperty"
  },
  "name": "StringProperty",
  "schema": "string",
  "writable": false
}

Klient urządzenia powinien wysłać ładunek JSON, który wygląda jak w poniższym przykładzie jako zgłoszona właściwość w bliźniaczej reprezentacji urządzenia:

{ "StringProperty": "A string value - could be a URL" }

Typy złożone

W tej sekcji przedstawiono przykłady złożonych typów właściwości wysyłanych przez urządzenie do usługi.

Poniższy fragment kodu z modelu urządzenia przedstawia definicję Enum typu właściwości:

{
  "@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"
      }
    ]
  }
}

Klient urządzenia powinien wysłać ładunek JSON, który wygląda jak poniższy przykład jako zgłoszona właściwość w bliźniaczej reprezentacji urządzenia. Możliwe wartości to 0, 1i, które są wyświetlane w usłudze IoT Central jako Item1, Item2i Item3:

{ "EnumProperty": 1 }

Poniższy fragment kodu z modelu urządzenia przedstawia definicję Object typu właściwości. Ten obiekt ma dwa pola z typami string i 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"
      }
    ]
  }
}

Klient urządzenia powinien wysłać ładunek JSON, który wygląda jak w poniższym przykładzie jako zgłoszona właściwość w bliźniaczej reprezentacji urządzenia:

{
  "ObjectProperty": {
    "Field1": 37,
    "Field2": "A string value"
  }
}

Poniższy fragment kodu z modelu urządzenia przedstawia definicję vector typu właściwości:

{
  "@type": "Property",
  "displayName": {
    "en": "VectorProperty"
  },
  "name": "VectorProperty",
  "schema": "vector",
  "writable": false
}

Klient urządzenia powinien wysłać ładunek JSON, który wygląda jak w poniższym przykładzie jako zgłoszona właściwość w bliźniaczej reprezentacji urządzenia:

{
  "VectorProperty": {
    "x": 74.72395045538597,
    "y": 74.72395045538597,
    "z": 74.72395045538597
  }
}

Poniższy fragment kodu z modelu urządzenia przedstawia definicję geopoint typu właściwości:

{
  "@type": "Property",
  "displayName": {
    "en": "GeopointProperty"
  },
  "name": "GeopointProperty",
  "schema": "geopoint",
  "writable": false
}

Uwaga

Klient urządzenia powinien wysłać ładunek JSON, który wygląda jak w poniższym przykładzie jako zgłoszona właściwość w bliźniaczej reprezentacji urządzenia:

{
  "GeopointProperty": {
    "lat": 47.64263,
    "lon": -122.13035,
    "alt": 0
  }
}

Typy właściwości zapisywalnych

W tej sekcji przedstawiono przykłady zapisywalnych typów właściwości odbieranych przez urządzenie z usługi.

Jeśli właściwość zapisywalna jest zdefiniowana w składniku, żądany komunikat właściwości zawiera nazwę składnika. W poniższym przykładzie pokazano komunikat z żądaniem aktualizacji targetTemperature urządzenia w składniku thermostat2 . __t Znacznik wskazuje, że ta sekcja definiuje składnik:

{
  "thermostat2": {
    "targetTemperature": {
      "value": 57
    },
    "__t": "c"
  },
  "$version": 3
}

Aby dowiedzieć się więcej, zobacz Połączenie aplikacji urządzeń z wieloma składnikami IoT Plug and Play.

Urządzenie lub moduł powinien potwierdzić, że odebrał właściwość, wysyłając zgłoszoną właściwość. Zgłoszona właściwość powinna zawierać następujące elementy:

value - rzeczywista wartość właściwości (zazwyczaj odebrana wartość, ale urządzenie może zdecydować się zgłosić inną wartość).
ac — kod potwierdzenia, który używa kodu stanu HTTP.
av — wersja potwierdzenia, która odwołuje się do $version żądanej właściwości. Tę wartość można znaleźć w ładunku JSON żądanej właściwości.
ad — opcjonalny opis potwierdzenia.

Aby dowiedzieć się więcej o tych polach, zobacz Konwencje > dotyczące potwierdzania i konwencji IoT Plug and Play

Poniższy fragment kodu z modelu urządzenia przedstawia definicję typu właściwości zapisywalnej string :

{
  "@type": "Property",
  "displayName": {
    "en": "StringPropertyWritable"
  },
  "name": "StringPropertyWritable",
  "writable": true,
  "schema": "string"
}

Urządzenie odbiera następujący ładunek z usługi:

{  
  "StringPropertyWritable": "A string from IoT Central", "$version": 7
}

Urządzenie powinno wysłać następujący ładunek JSON do usługi po zakończeniu procesu aktualizacji. Ten komunikat zawiera numer wersji oryginalnej aktualizacji otrzymanej z usługi.

Napiwek

Jeśli usługa jest usługą IoT Central, oznacza ona właściwość jako zsynchronizowaną w interfejsie użytkownika po odebraniu tego komunikatu:

{
  "StringPropertyWritable": {
    "value": "A string from IoT Central",
    "ac": 200,
    "ad": "completed",
    "av": 7
  }
}

Poniższy fragment kodu z modelu urządzenia przedstawia definicję typu właściwości zapisywalnej 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"
      }
    ]
  }
}

Urządzenie odbiera następujący ładunek z usługi:

{  
  "EnumPropertyWritable":  1 , "$version": 10
}

Urządzenie powinno wysłać następujący ładunek JSON do usługi po zakończeniu procesu aktualizacji. Ten komunikat zawiera numer wersji oryginalnej aktualizacji otrzymanej z usługi.

Napiwek

Jeśli usługa jest usługą IoT Central, oznacza ona właściwość jako zsynchronizowaną w interfejsie użytkownika po odebraniu tego komunikatu:

{
  "EnumPropertyWritable": {
    "value": 1,
    "ac": 200,
    "ad": "completed",
    "av": 10
  }
}

Polecenia

Aby dowiedzieć się więcej na temat reguł nazewnictwa poleceń DTDL, zobacz DtDL Command (Polecenie DTDL>). Nie można uruchomić nazwy polecenia przy użyciu _ znaku .

Jeśli polecenie jest zdefiniowane w składniku, nazwa polecenia, które otrzymuje urządzenie, zawiera nazwę składnika. Jeśli na przykład polecenie jest wywoływane getMaxMinReport , a składnik jest wywoływany thermostat2, urządzenie odbiera żądanie wykonania polecenia o nazwie thermostat2*getMaxMinReport.

Poniższy fragment kodu z modelu urządzenia przedstawia definicję polecenia, które nie ma parametrów i które nie oczekuje, że urządzenie zwróci coś:

{
  "@type": "Command",
  "displayName": {
    "en": "CommandBasic"
  },
  "name": "CommandBasic"
}

Urządzenie odbiera pusty ładunek w żądaniu i powinno zwrócić pusty ładunek w odpowiedzi z 200 kodem odpowiedzi HTTP, aby wskazać powodzenie.

Poniższy fragment kodu z modelu urządzenia przedstawia definicję polecenia, które ma parametr całkowity i oczekuje, że urządzenie zwróci wartość całkowitą:

{
  "@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"
}

Urządzenie otrzymuje wartość całkowitą jako ładunek żądania. Urządzenie powinno zwrócić wartość całkowitą jako ładunek odpowiedzi z 200 kodem odpowiedzi HTTP, aby wskazać powodzenie.

Poniższy fragment kodu z modelu urządzenia przedstawia definicję polecenia z parametrem obiektu i oczekuje, że urządzenie zwróci obiekt. W tym przykładzie oba obiekty mają pola liczb całkowitych i ciągów:

{
  "@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"
}

Poniższy fragment kodu przedstawia przykładowy ładunek żądania wysłany do urządzenia:

{ "Field1": 56, "Field2": "A string value" }

Poniższy fragment kodu przedstawia przykładowy ładunek odpowiedzi wysłany z urządzenia. 200 Użyj kodu odpowiedzi HTTP, aby wskazać powodzenie:

{ "Field1": 87, "Field2": "Another string value" }

Napiwek

Usługa IoT Central ma własne konwencje implementowania długotrwałych poleceń i poleceń offline.

Następne kroki

Teraz, po zapoznaniu się z informacjami o ładunkach urządzeń, sugerowane następne kroki polega na przeczytaniu przewodnika dla deweloperów urządzeń.

Share via

Ładunki telemetrii, właściwości i polecenia

Wyświetlanie danych pierwotnych

Telemetria

Telemetria w składnikach

Telemetria w odziedziczonych interfejsach

Typy pierwotne

Typy złożone

Typy zdarzeń i stanów

Właściwości

Właściwości w składnikach

Typy pierwotne

Typy złożone

Typy właściwości zapisywalnych

Polecenia

Następne kroki

Dodatkowe zasoby