Befehle zwischen IoT-Anwendung und -Gerät

Anwendungen senden über zwei primäre Mechanismen Befehle an IoT-Geräte: Cloud-zu-Gerät-Nachrichten und direkte Methoden.

• Cloud-zu-Gerät-Nachrichten werden von Anwendungen an gerätespezifische Nachrichtenwarteschlangen auf der IoT-Plattform gesendet, die von Geräten ausgelesen werden können, wenn sie verbunden sind. Die Geräte legen fest, wann die Nachrichten gelesen werden sollen.

• Direkte Methoden werden von Anwendungen mithilfe eines Anforderungs-Antwort-Musters über dedizierte IoT-Geräteendpunkte direkt auf verbundenen Geräten aufgerufen.

In diesem Artikel werden die Merkmale von Cloud-zu-Gerät-Messaging und direkten Methoden erläutert. Außerdem wird in diesem Artikel beschrieben, wie Sie direkte Methoden mit Protokollgateways und verbundenen Standbygeräten verwenden.

Senden von Nachrichten aus der Cloud an Geräte

Anwendungen senden Cloud-zu-Gerät-Befehlsnachrichten für bestimmte Geräte an Azure IoT Hub, wo die Nachrichten in gerätespezifischen Warteschlangen gespeichert werden. IoT Hub übermittelt die Nachrichten unabhängig davon, ob die Geräte verbunden sind, an die gerätespezifischen Warteschlangen.

Die folgenden Überlegungen gelten für die Verwendung von Cloud-zu-Gerät-Nachrichten:

• Nachrichtenwarteschlangen stellen Postfächer für Geräte dar, und die Geräte sind für das Abrufen ihrer Nachrichtenwarteschlangen nach neuen Nachrichten selbst verantwortlich, wenn sie verbunden sind.
• Geräte empfangen Nachrichten auf FIFO-Art (First In First Out, Ausgang in Reihenfolge des Eingangs), sodass Cloud-zu-Gerät-Nachrichten ideal für das sequenzielle Lesen von Nachrichten und Reagieren auf diese sind.
• Nachrichten weisen eine konfigurierbare Ablaufzeit auf, sodass ungelesene Nachrichten am Ende aus der Nachrichtenwarteschlange des Geräts entfernt werden können.
• Für eine zustandsbehaftete Kommunikation können Anwendungen die Nachrichtenübermittlung und -bestätigung mithilfe eines Feedbackempfängers überwachen. Die Anwendung kann mit einem einzelnen Feedbackempfänger alle Nachrichtenwarteschlangen für alle Geräte überwachen.

Direkte Methoden

Anwendungen rufen direkte Methoden direkt auf verbundenen IoT-Geräten auf und erwarten, dass die Geräte die Methoden ausführen und sie beim IoT-Hub registrieren. Der IoT-Hub ruft die direkten Methoden auf verbundenen Geräten über direkte Kanäle auf, und Geräte sind dafür verantwortlich, Funktionen auszuführen und unmittelbare Ergebnisse zurückzugeben.

Berücksichtigen Sie Folgendes, wenn Sie direkte Methoden verwenden:

• Bei direkten Methoden treten Fehler auf, wenn die Verbindung zwischen dem IoT-Hub und dem Gerät vor dem Abschluss der Methode getrennt wird. Anwendungen können Fehler abfangen und behandeln, um Befehle erneut auszugeben.
• Da es keine Warteschlange gibt, müssen Anwendungen, bei denen direkte Methoden sequenziert werden müssen, diese Sequenzierung von Methodenaufrufen selbst so verwalten, dass mit dem Abschluss einer Methode die nächste Methode aufgerufen wird.
• Durch Aufrufen direkter Methoden kann eine Anwendung zwei Timeouts festlegen. Ein Timeout gibt an, wie lange der IoT-Hub vor dem Aufgeben auf das Herstellen einer Verbindung durch ein Gerät warten soll, und das andere Timeout gibt an, wie lange der Aufrufer vor dem Aufgeben auf den Abschluss der Methode warten soll.

Direkte Methoden mit Protokollgateways

IoT-Anwendungen, die Protokollgateways verwenden, können von der Verbindungserzwingung und dem Anforderungs-Antwort-Modell direkter Methoden profitieren. Über Cloud- oder Protokollgateways können Geräte verschiedenster Art eine Verbindung mit IoT Hub herstellen, indem diese im Auftrag der Geräte eine benutzerdefinierte Protokollkommunikation aushandeln. Auf ähnliche Weise können Protokollgateways das Modell direkter Methoden abstrahieren, indem sie die Methoden in gerätekompatible Protokollnachrichten serialisieren.

1. Die Anwendung ruft die direkte Methode im Namen des Geräts auf dem Protokollgateway auf.
2. Für die Methodenimplementierung übersetzt das Gateway die Methode in ein gerätespezifisches Protokoll und sendet die Nachricht an das Gerät. Das Gerät nimmt Änderungen an der Cloudimplementierung nicht wahr.
3. Wenn das Gerät die Nachricht abschließt und antwortet, übersetzt das Gateway den gerätespezifischen Status in die Methodenantwort.
4. Der IoT-Hub schließt die direkte Methode ab, indem er ein Methodenergebnis für den Aufrufer ausfüllt.

Das Open-Source-Projekt für das Azure-Protokollgateway übersetzt direkte Methoden nativ in MQTT-Protokollnachrichten, ist problemlos erweiterbar und veranschaulicht dieses Programmiermodell für andere Protokolladapter.

Verbundene Standbygeräte

IoT-Befehlsszenarien können verbundene Standbygeräte einschließen, die sich außerhalb des aktiven Zustands in einem Energiesparmodus mit geringer Leistung befinden. Mechanismen wie der mobile Textnachrichtendienst (Short Message Service, SMS) können Aktivierungssignale senden, um diese Geräte in einen voll funktionsfähigen Zustand zu versetzen.

1. Die Anwendung sendet mithilfe der ServiceClient-API Befehle an Geräte. Eine Instanz von ServiceClient kann für mehrere Geräte Nachrichten senden und Methoden aufrufen.
2. Die Anwendung sendet über das SMS-Gateway des mobilen Anbieters außerdem SMS-Aktivierungsaufrufe an Standbygeräte.
3. Bei der Reaktivierung verwenden Standbygeräte die DeviceClient-API, um eine Verbindung mit IoT Hub herzustellen und Befehle zu empfangen. Eine Instanz von DeviceClient stellt ein einzelnes Gerät dar, das mit IoT Hub verbunden ist.

Verwenden direkter Methoden zum Ermitteln des Geräteverbindungsstatus

Das Senden unnötiger Aktivierungsnachrichten über SMS-Gateways ist kostspielig. Bevor Sie tatsächliche Befehle an ein Gerät senden, verwenden Sie die Verbindungs- und Methodentimeouts, um zu ermitteln, ob das Gerät verbunden ist, und senden Sie ggf. eine Reaktivierung.

    TimeSpan connTimeOut = FromSeconds(0); // Period to wait for device to connect.
    TimeSpan funcTimeOut = FromSeconds(30); // Period to wait for method to execute.

    while (true) {
        // Send the command via direct method. Initially use a timeout of zero
        // for the connection, which determines whether the device is connected to
        // IoT Hub or needs an SMS wakeup sent to it.

        var method = new CloudToDeviceMethod("RemoteCommand", funcTimeOut, connTimeOut);
        methodInvocation1.SetPayloadJson(CommandPayload);

        var response = await serviceClient.InvokeDeviceMethodAsync(deviceId, method);

        // [DeviceNotConnected] represents a return value from the CloudToDeviceMethod
        // method. That method is not implemented in this sample.
        if (response == [DeviceNotConnected] && connTimeOut == 0) {
            // The device is not currently connected and needs an SMS wakeup. This
            // device should wake up within a period of < 30 seconds. Send the wakeup
            // and retry the method request with a 30 second timeout on waiting for
            // the device to connect.

            connTimeOut = FromSeconds(30); // Set a 30 second connection timeout.
            SendAsyncSMSWakeUpToDevice(); // Send SMS wakeup through mobile gateway.
            continue; // Retry with new connection timeout.
        } else {
            // The method either succeeded or failed.
            ActOnMethodResult(var);
            break;
        }
    }

Um einfach die Konnektivität zu überprüfen, implementieren Sie über eine leere Methode mit einem Verbindungstimeout von null einen einfachen Ping. Beispiel:

var method = new CloudToDeviceMethod("Ping", 0, 0);

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

• Jason Wadsworth | Principal Software Engineer

Nächste Schritte

• Der Leitfaden zur C2D-Kommunikation bietet szenariobasierte Anleitungen zu den Einsatzgebieten von Cloud-zu-Gerät-Nachrichten oder direkten Methoden.

Zugehörige Ressourcen

• IoT-Geräte, -Plattform und -Anwendungen
• Skalieren von IoT-Lösungen mit Anwendungsstempeln