Die Vielzahl der möglichen Protokolle hatte ich in der ersten Folge schon angesprochen; schauen Sie sich einmal die Grafik an, die verschiedene Protokoll-Ebenen umfasst. Eine feste Größe beim IoT ist, dass ein Knoten mit anderen Knoten über IP kommuniziert; hierzu gehört auch eine IP-Adresse (Unterknoten mit Sensoren/Aktoren können an einen solchen Knoten über ZigBee, Bluetooth usw. angebunden sein, was wir hier einmal beiseitelassen wollen). IP-Adressen gibt es zum Glück genug: Bei der modernen IP-Variante IPv6 ist das Adressfeld 128 bit groß, das ergibt eine Zahl von rund 340.000.000.000.000.000.000.000.000.000.000.000.000 Adressen.

Unterhalb von IP findet man die üblichen Übertragungskanäle für IP-Pakete; so zum Beispiel WLAN (Wifi), Ethernet und die Handynetze. Mit 6LoWPAN gibt es aber auch eine Spezifikation, die eine Schnittstelle zum Low-Power-Funkstandard IEEE 802.15.4 bildet, auf dem beispielsweise auch ZigBee aufsetzt. Vorteil gegenüber den klassischen Internet-Übertragungskanälen ist hier der besonders geringe Energieverbrauch; gerade für batteriebetriebene oder Energy-Harvesting-Sensorknoten ist das wichtig.

Für uns Entwickler interessanter sind allerdings die Protokolle oberhalb von IP. Es ist ja gerade das Schöne an Protokollstapeln, dass es uns dann weniger interessieren muss, wie es untendrunter aussieht. Hauptsache die Übertragung der IP-Pakete funktioniert. Bei kleineren Controllern können wir hierfür zum Beispiel ein Netzwerkmodul mit vorinstallierter Standardfirmware benutzen; für größere Controller/Prozessoren wie zum Beispiel beim Raspberry Pi stehen Betriebssysteme zur Verfügung, die entsprechende Funktionen integriert haben. Das alles ist schon recht ausgereift, denn es wurde ja schon für das klassische Internet entwickelt.

Zwei Protokolle, die auf IP aufsetzen, sind ebenfalls schon lange etabliert: TCP und UDP. Über TCP/IP kommen Webseiten und das Gros der Daten ins Haus, da Webserver und Client (Browser) darüber kommunizieren. Bei einer TCP-Kommunikation handelt es sich immer um eine Verbindung von zwei Teilnehmern, die hier Endpunkt oder Socket heißen. Zu jedem Socket gehört eine IP-Adresse und ein Port. Ein ausgeklügeltes System von Bestätigungen sichert, dass versandte IP-Pakete auch ankommen. Im Gegensatz dazu ist UDP ein ungesichertes Protokoll, das zum Beispiel bei der Audio-Übertragung gute Dienste leistet.

Im Allgemeinen müssen sich Entwickler auch mit den Feinheiten von TCP und UDP nicht herumschlagen. Für alle gängigen Programmiersprachen gibt es (kostenlose) Bibliotheken zur Socket-Programmierung. Mit relativ wenig Einarbeitungs-Aufwand könnten wir uns also schon eine funktionierende Messwerterfassung oder eine Steuerung über das Internet programmieren. Ein selbst erfundenes Anwendungsprotokoll für unser Projekt kann auch sehr einfach ausfallen, wenn nur zwei Teilnehmer beteiligt sind, dann schicken wir im einfachsten Fall nur „ON“, „OFF“ oder eine Zahl als TCP/IP-Nachricht übers Netzwerk. Zwei Beispiele für solche Projekte finden Sie in der kommenden Elektor-Ausgabe 1-2/2016: In „WLAN für Mikrocontroller“ wird ein Board mit LEDs von einem Smartphone aus angesteuert; in „Windows auf dem RaspPi (2)“ stellt eine Siebensegment-Anzeige Zahlen dar, die über das Netzwerk geschickt werden.

Bei der Hausautomatisierung und verwandten Aufgaben gibt es allerdings meist viel mehr Teilnehmer; zum Beispiel liefern verschiedene Sensoren Daten, die auf mehreren Computer-Plattformen dargestellt werden sollen. Wer soll dabei welche Daten erhalten? Man muss sich außerdem Gedanken machen, wie die einzelnen Sensoren und sonstigen Knoten adressiert werden können, ohne sich eine Liste mit langen IP-Adressen merken zu müssen. Aus Gründen des Energiesparens und der Robustheit des Systems wäre es noch wünschenswert, dass Daten auch dann noch abrufbar sind, wenn Sensoren nicht online sind. Glücklicherweise gibt es auf TCP und UDP aufsetzende Protokolle, die hier Lösungen bieten.
Mehr darüber in der nächsten Folge!