Geräteregistrierung
Damit ein Gerät eine Verbindung herstellen kann, muss es zuerst im Gerätemanager registriert sein. Mit dem Gerätemanager können Sie Geräte-Registries und die darin enthaltenen Geräte erstellen und konfigurieren. Der Gerätemanager kann über die Cloud Platform Console, gcloud-Befehle oder die REST-API verwendet werden.
Geräte-Registries
Eine Geräte-Registry ist ein Container mit Geräten.
- Jede Geräte-Registry wird in einer bestimmten Cloud-Region erstellt und gehört zu einem Cloud-Projekt.
- Eine Registry wird im Dienst cloudiot.googleapis.com anhand seines vollständigen Namens als
projects/{project-id}/locations/{cloud-region}/registries/{registry-id}
identifiziert. - Die Geräte-Registry ist mit einem oder mehreren Cloud Pub/Sub-Themen konfiguriert, in denen Telemetrieereignisse für alle Geräte in dieser Registry veröffentlicht werden. Ein einzelnes Thema kann zum Sammeln von Daten aus allen Regionen verwendet werden.
- Stackdriver Monitoring wird automatisch für jede Registry aktiviert.
- Die Identitäts- und Zugriffsverwaltung (IAM) kann für die Zugriffssteuerung verwendet werden. Sie gewährt Nutzern die Berechtigung, Geräte abzurufen, bereitzustellen oder vollständig zu verwalten. Beachten Sie, dass Cloud IoT Core dem entsprechenden Dienstkonto für jedes Projekt automatisch die Rolle
cloudiot.serviceAgent
zuweist, um die Veröffentlichung in Pub/Sub-Themen zu aktivieren. - Informationen zur Benennung und Größe von Geräte-Registry-IDs finden Sie unter Anforderungen an Zeichen und Größen.
Weitere Informationen finden Sie in der Referenz zu DeviceRegistry-Ressourcen.
Geräte
Wenn Sie ein Gerät in einer Registry erstellen, definieren Sie das Gerät als Cloud IoT Core-Ressource. Sie können dann Gerätedetails abrufen und einige Attribute steuern.
- Ein Gerät kann für die Kommunikation mit Cloud IoT Core blockiert werden. Das kann hilfreich sein, wenn ein Sensor ausfällt oder ein Gerät falsch konfiguriert ist.
- Gerätezeitstempel zeigen den letzten empfangenen Heartbeat und das letzte empfangene Telemetrieereignis an.
- Jedes Gerät kann anhand seines vollständigen Ressourcennamens identifiziert werden:
projects/{project-id}/locations/{cloud-region}/registries/{registry-id}/devices/{device-id}
oderprojects/{project-id}/locations/{cloud-region}/registries/{registry-id}/devices/{device-numeric-id}
. Im nächsten Abschnitt finden Sie weitere Informationen zur Geräte-ID und zur numerischen ID des Geräts.
Weitere Informationen finden Sie in der Referenz zu Geräteressourcen.
Achten Sie darauf, dass Sie die Kontingente und Limits von Cloud IoT Core beachten, wenn Sie mit Geräten arbeiten.
Gerätekennungen
Jedes Gerät hat die folgenden Kennungen:
- Eine vom Nutzer definierte Geräte-ID. Weitere Informationen zur Benennung und Größe von Geräte-IDs finden Sie unter Anforderungen an Zeichen und Größen.
- Eine vom Server generierte, numerische Geräte-ID. Die numerische Geräte-ID wird automatisch von Cloud IoT Core erstellt. Sie ist global eindeutig und kann nicht bearbeitet werden. Die numerische ID eines Geräts finden Sie auf der Seite Gerätedetails.
- Der vollständige Pfad des Geräts, wie im vorherigen Abschnitt beschrieben.
Gerätemetadaten
Sie können Metadaten für ein Gerät definieren, z. B. Hardware-Fingerabdruck, Seriennummer, Herstellerinformationen oder andere Attribute. Cloud IoT Core interpretiert oder indexiert keine Gerätemetadaten. Theoretisch sind Gerätemetadaten sicherer als der Gerätestatus oder die Gerätekonfiguration, da Gerätemetadaten niemals an ein Gerät oder von einem Gerät gesendet werden. Wenn ein Gerät manipuliert wurde, können die Metadaten also nicht gelesen werden.
Gerätemetadaten sollten sich nicht häufig ändern. Optimale Ergebnisse erzielen Sie, wenn Sie sie nicht öfter als einmal pro Tag aktualisieren.
Sie können bis zu 500 Schlüssel/Wert-Paare definieren, wenn Sie ein Gerät hinzufügen oder bearbeiten. Jeder Schlüssel muss eindeutig sein.
Informationen zu den Benennungs- und Größenanforderungen für Gerätemetadaten finden Sie unter Anforderungen an Zeichen und Größen.
Gerätekonfiguration
Mit Cloud IoT Core können Sie ein Gerät durch Senden einer Gerätekonfiguration steuern. Eine Gerätekonfiguration ist ein beliebiger benutzerdefinierter Blob mit Daten, die von Cloud IoT Core an ein Gerät gesendet werden. Die Daten können strukturiert oder unstrukturiert sein. Es kann auch ein beliebiges Format haben, z. B. beliebige binäre Daten, Text, JSON oder serialisierte Protokollpuffer.
Die Gerätekonfiguration wird von Cloud IoT Core im Speicher beibehalten. Die maximale Größe für Konfigurationsdaten beträgt 64 KB. Weitere Beschränkungen finden Sie unter Kontingente und Beschränkungen.
Die besten Ergebnisse erzielen Sie, wenn sich eine Gerätekonfiguration auf die gewünschten Werte oder Ergebnisse konzentrieren soll und nicht auf eine Folge von Befehlen. Wenn Sie Befehle angeben, können Zwischenkonfigurationsversionen zu Konflikten führen. Außerdem kann der Status eines Geräts nicht wiederhergestellt werden, ohne jede Befehlssequenz seit der ersten Initialisierung des Geräts auszuführen. Wenn in Ihren Konfigurationen Werte und Ergebnisse hervorgehoben sind, können Sie den Gerätestatus einfacher wiederherstellen.
Konfigurationsversionen
MQTT-Bridge
Bei einer MQTT-Verbindung erhält ein Gerät Konfigurationen nur in aufsteigender Reihenfolge der Versionsnummern. Mit anderen Worten, es wird niemals eine Konfiguration gesendet, die älter als die aktuelle Version ist. Wenn das Gerät jedoch noch einmal eine Verbindung zur MQTT-Bridge herstellt, erhält es möglicherweise zuerst erst einmal eine ältere Konfiguration als bei der vorherigen Verbindung. Dies sollte jedoch selten sein, und das Gerät erhält schließlich die neueste Version.
Es kann nicht garantiert werden, dass ein Gerät jedes Konfigurationsupdate erhält, es erhält jedoch immer das neueste Update. Wenn eine Konfiguration schnell aktualisiert wird, erhalten Geräte möglicherweise keine Zwischenversionen.
Beim Ändern einer Gerätekonfiguration können Sie die zu ändernde Versionsnummer angeben. Dies schützt vor dem Überschreiben einer Konfiguration mit gleichzeitigen Änderungen.
HTTP-Bridge
Geräte, die über HTTP verbunden sind, können die lokale Version angeben, also die Konfigurationsversion auf dem Gerät. Cloud IoT Core gibt nur eine neuere Version zurück, wie im Abschnitt zur HTTP-Bridge beschrieben.
Gerätestatus
Informationen zum Gerätestatus erfassen den aktuellen Status des Geräts und nicht die Umgebung. Geräte können ihren Status mit einem beliebigen benutzerdefinierten Blob von Daten beschreiben, die vom Gerät an die Cloud gesendet werden. Die Daten können strukturiert oder unstrukturiert sein. Sie können auch ein beliebiges Format haben, z. B. Binärdaten, Text, JSON oder serialisierte Protokollpuffer.
Einige Beispiele für den Gerätestatus sind der Systemstatus oder die Firmwareversion. Normalerweise werden Informationen zum Gerätestatus nicht häufig aktualisiert.
Unterschiede zwischen Gerätemetadaten, Konfiguration und Status
Durch die gemeinsame Verwendung von Konfiguration und Status können Sie Fragen wie diese beantworten: Was „meint“ das Gerät, was es jetzt tun soll? Wie unterscheidet sich dies von der aktuellen Konfiguration für das Gerät? Im Gegensatz dazu dienen Metadaten in erster Linie als Label oder Kennung für Geräte.
Konfigurationsdaten werden von Cloud IoT Core an das Gerät gesendet. Statusdaten werden vom Gerät an Cloud IoT Core gesendet. Sie können sich eine Konfiguration als externe Anweisung vorstellen, die an ein Gerät gesendet wird, und als Status der internen Darstellung eines Geräts. Konfigurations- und Zustandsdaten können dasselbe Schema und dieselbe Codierung haben oder unterschiedlich sein.
Informationen, die an ein oder von einem Gerät gesendet werden müssen, sollten nicht als Gerätemetadaten gespeichert werden, da die Gerätemetadaten in der Cloud bleiben. Diese Informationen sollten in einer Gerätekonfiguration enthalten sein, wenn Sie sie an ein Gerät senden müssen, oder in Gerätestatusdaten, wenn Sie sie an Cloud IoT Core melden müssen.
Im folgenden Beispiel werden die verschiedenen Verwendungsmöglichkeiten von Metadaten, Konfiguration und Status mithilfe des Szenarios von Geräten in einem Gebäude erläutert:
Angenommen, Sie haben in einem Gebäude in jedem Stockwerk mehrere Geräte. Wenn Sie Geräte im 7. Stock identifizieren möchten, können Sie den Geräten im 7. Stock ein Metadaten-Schlüssel/Wert-Paar
'floor': '7'
hinzufügen. Durch die Anwendung dieser Metadateninformationen können Sie die Geräte identifizieren. Da Metadaten jedoch nicht interpretiert oder indexiert werden, können die Metadaten nur zu Identifizierungszwecken verwendet werden.Wenn Sie den Status der Geräte im Gebäude ändern möchten, können Sie an jedes Gerät eine Gerätekonfiguration senden. Diese Konfiguration würde ein beliebiges Datenblob enthalten, das die gewünschte Temperatur für das Gerät enthält und ob die Beleuchtung des Geräts ein- oder ausgeschaltet ist:
{ temperature: 50 lights: off }
Die Konfiguration allein ändert nicht die Temperatur des Geräts und schaltet die Beleuchtung nicht ein oder aus. Das Gerät muss die Konfiguration interpretieren und eine eigene Logik zur Ausführung des Befehls verwenden. In den nächsten Stunden ändert sich die Gerätekonfiguration nicht, es sei denn, Sie aktualisieren und senden eine neue Konfiguration. Der Status des Geräts sollte sich jedoch ändern, wenn die Temperatur zu- oder abnimmt und die Beleuchtung des Geräts ausschaltet.
Um zu prüfen, ob die Konfiguration korrekt angewendet wurde und sich die Geräte im richtigen Status befinden, kann jedes Gerät seinen Status an Cloud IoT Core melden, unabhängig davon, ob es aktiviert oder ausgeschaltet ist, welche Temperatur es hat und ob seine Temperatur kleiner oder gleich 50 Grad ist.
Die folgende Tabelle zeigt die Hauptunterschiede zwischen Gerätemetadaten, Konfiguration und Status:
Gerätemetadaten | Gerätekonfiguration | Gerätestatus | |
---|---|---|---|
Beschreibung | Definiert und klassifiziert Geräte |
|
Erfasst den aktuellen Status eines Geräts |
Inhalt | Schlüssel/Wert-String-Paare | Beliebiges benutzerdefiniertes Daten-Blob | Beliebiges benutzerdefiniertes Daten-Blob |
Beschränkungen | Schlüssel:
Maximale Gesamtgröße aller Schlüssel/Wert-Paare von Gerätemetadaten: 256 KB |
|
|
Anwendungsfälle | Seriennummer und Herstellerinformationen eines Geräts als Schlüssel/Wert-Paar speichern |
|
Zustand eines Geräts abrufen (z. B. Häufigkeit von Abstürzen) |
Nachrichtenrichtung | – | Nur Cloud IoT Core-zu-Gerät | Nur Gerät-zu-Cloud IoT Core |
Empfohlene Häufigkeit | Nicht häufiger als einmal pro Tag und Gerät | Weniger als 0,1 Abfragen pro Sekunde | Weniger als 0,1 Abfragen pro Sekunde |
Geräteverhalten oder -status mithilfe von Konfigurationsdaten ändern
Wie in der Tabelle oben erwähnt, gelten Konfigurationsdaten für primäre Anwendungsfälle so:
Gewünschten Status als Konfigurationsdaten senden
In Cloud IoT Core gespeicherte Gerätekonfigurationsdaten können verwendet werden, um den Status eines Geräts zu ändern. Die Konfiguration eines Geräts wird beispielsweise so dargestellt:
DeviceConfig
{ firmwareVersionRequest: 1.11 }
Ihr MQTT- oder HTTP-Client könnte diese Konfigurationsdaten als Anweisungen zum Ändern des Gerätestatus interpretieren. Prüfen Sie in diesem Fall, ob das Gerät die Firmwareversion 1.11 hat. Das Gerät kann dann seinen Status an Cloud IoT Core senden, um zu zeigen, welche Firmwareversion es hat:
DeviceState
{ firmwareVersion: 1.11 }
Befehle mit Konfigurations- und Statusdaten modellieren
In Cloud IoT Core gespeicherte Gerätekonfigurationsdaten können zum Modellieren von Gerätebefehlen verwendet werden. Die Konfiguration eines Geräts wird beispielsweise so dargestellt:
DeviceConfig
{ rebootRequested: true }
Ihr MQTT- oder HTTP-Client könnte diese Konfigurationsdaten als Anweisungen zum Ausführen von Aktionen interpretieren. In diesem Fall senden Sie einen Neustartbefehl. Das Gerät kann dann die Ergebnisse anzeigen, indem es seinen Status meldet und anzeigt, dass eine Sekunde seit seinem letzten Neustart vergangen ist:
DeviceState
{ last_reboot: 1 }
Konfigurationsdaten strukturieren
Konfigurationsdaten können auch strukturierter sein und Details zum Ablauf von Befehlen enthalten:
DeviceConfig
{ commands: { id1: { type: REBOOT requestedTimestamp: xxxx expirationTimestamp: yyyy } id2: ... } }
Ihr Client könnte diese Befehle lesen und den Gerätestatus entsprechend aktualisieren und einen Zeitstempel für den Neustart und möglicherweise eine Fehlermeldung angeben.
DeviceState
{ commandResults: { id1: { type: REBOOT completedTimestamp: zzzz errorMessage: >empty< } id2: ... } }
Dieses Modell kann als eine Befehls-und-Antwort-Beziehung zwischen Client und Geräten betrachtet werden. Wenn die Ablaufzeit verwendet wird, achten Sie darauf, dass die Uhr des Geräts synchronisiert ist.