© best_vector/Shutterstock.com
Teil 2: Ereignis als Trigger - Mit kleinem Hebel ein großes Rad bewegen

IoT for Runaways


Am Ende des ersten Teils der Serie übertrugen wir Knopfereignisse vom Prozessrechner in die Cloud. Dies mag durchaus interessant sein, lässt sich aber auch von Hand bewerkstelligen. In diesem Teil der Serie nutzen wir fortgeschrittene Möglichkeiten des Azure IoT Hubs, um unsere Ereignisse mit zusätzlicher Verarbeitungslogik auszustatten.

Ist die Verfügbarkeit von fast unbegrenzter Rechenleistung in der Cloud attraktiv, so lässt sich ein einfacher Event Bus notfalls auch mit der Hand zusammenstellen. In diesem Teil der Serie erweitern wir unseren kleinen Eventverarbeitungsverbund um fortgeschrittene Szenarien wie automatisches Routen und Ausliefern von Ereignissen. Zudem unternehmen wir erste Schritte in die Welt von komplett Cloud-getriebenen Systemen, die aufseiten des Entwicklers keine Server mehr voraussetzen.

An dieser Stelle müssen wir eine kleine Änderung vornehmen: Aufgrund der zu bearbeitenden Themenmenge bleibt der Raspberry Pi diesmal kalt. Adaptieren Sie das Sendeprojekt ein wenig, um sicherzustellen, dass die Events auch durch Anklicken von Knöpfen am Bildschirm ausgelöst werden können.

Senden mit Pfiff

Unsere Arbeit beginnt mit dem Entfernen der GPIO-Ansteuerungslogik, die im Programm EventSender durch zwei Buttons ersetzt wird. Wer ein neues Projekt anlegen möchte, muss darauf achten, sein Gerät beim IoT Hub unter Nutzung des Konfigurators anzumelden; IoT Hubs nehmen Informationen nur von Endstellen entgegen, die im Backend als zulässige Kommunikationspartner angelegt sind.

Bei der Realisierung von Nachrichtensortiersystemen muss man als Erzeuger des Servers seit jeher abwägen: Ermöglicht man eine genaue Analyse der Pakete (Stichwort Deep Packet Inspection), braucht man sehr viel Rechenleistung. Im Fall von für „Dritte“ vorgesehenen Systemen, wie dem Azure IoT Hub, ist die Situation insofern noch schwieriger, als man nicht weiß, was für Payload-Informationen der PT-Entwickler in seinem Programm unterbringt. Microsoft löst dieses Problem auf eine sehr interessante Art und Weise (Listing 1).

Listing 1

private void CmdSend_Click(object sender, RoutedEventArgs e) { var telemetryDataPoint = new { deviceId = "TamsRPI", whichPin = 1 }; var messageString = JsonConvert.SerializeObject(telemetryDataPoint); var message = new Message(Encoding.ASCII.GetBytes(messageString)); message.Properties.Add("level", "sending"); deviceClient.SendEventAsync(message); }

Der je nach Konfiguration bis zu 256 Kilobyte lange Messagestring entsteht hier durch die Serialisierung eines JSON-Objekts: Sie können in der Praxis allerdings auch auf so gut wie jede andere Methode setzen, solange die angelieferten Informationen stringartig und nicht zu lang sind. Die eigentlichen für die Sortierungslogik relevanten Nachrichten werden dann in einem separaten Teil der Message untergebracht. Wir schreiben hier nur ein einziges Attribut namens Level ein, das einen Stringwert entgegennimmt.

Da wir die „Sortierung“ von Nachrichten demonstrieren möchten, ist ein zweiter Button erforderlich, der folgenden Event Handler eingeschrieben bekommt:

private void CmdWarn_Click(object sender, RoutedEventArgs e) { . . . message.Properties.Add("level", "warning"); deviceClient.SendEventAsync(message); }

Der hier durch Punkte (...) abgekürzte Rest des Codes ist mehr oder weniger identisch: Der Autor serialisiert einige zusätzliche Attribute. Wichtig ist nur, dass wir im Properties-Attribut für den Wert Level nur den String warning einfügen. Das Resultat sind also zwei separate „Nachrichtenklassen“ (Abb. 1).

hanna_1.tif_fmt1.jpgAbb. 1: Die beiden Nachrichten werden auf Serverseite nur durch ihre Properties unterschieden

Wer das Programm im vorliegenden Zustand ausführt und mit dem aus dem vorherigen Teil bekannten Receiver verbindet, sieht, dass das Anklicken der beiden Buttons zur Ausgabe der Nachricht führt. Die Properties-Attribute werden von der Empfangslogik derzeit nicht ausgewertet – dies ist insofern vernünftig, als sie eigentlich für die „Katalogisierung“ der Daten im Backend vorgesehen sind.

Teile mich auf!

Eines der wichtigsten Attribute von auf Azure basierenden Lösungen ist, dass das Microservices-Pattern konsequent umgesetzt wird: Eine Azure-Lösung ist ein aus mehreren Programmteilen zusammengesetztes Softwaresystem, das Aufgaben im Verbund realisiert. Zur Verarbeitung bzw. Auswertung der im Properties-Attribut angelieferten Informationen benötigen wir einen Service Bus: Stellen Sie sich dieses Element wie eine Art Ereignisverarbeitungsschleife vor. Um sie anzulegen, benötigen wir Informationen – spezifischerweise muss der Bus am selben Ort und in derselben Subscription sein, die auch für den IoT Hub ausgewählt wurde. Diese Informationen finden...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang