Das Message Queuing Telemetry Transport, kurz MQTT, ist ein offenes Telemetrieprotokoll, das auf TCP/IP aufbaut und ursprünglich für Industriesteuerungen entwickelt worden ist aber aufgrund seiner Zuverlässigkeit und seines sparsamen Umgangs mit Bandbreite und Ressourcen sich auch für den Bereich Internet of Things und Hausautomation eignet, da hier teilweise auch schwächere RISC-Mikroprozessoren zum Einsatz kommen und eine effiziente Datenübertragung daher essentiell ist.

Geschichte

Das Protokoll wurde 1999 von Andy Stanford-Clark (IBM) und Arlen Nipper (Arcom, jetzt Cirrus Link) entwickelt um eine Öl-Pipeline über eine Satelliten-Verbindung in der Wüste zu überwachen. Sie waren damals mit dem Problem konfrontiert, verschiedene Messstellen entlang der Öl-Pipeline durch die Wüste an ein Leitsystem anzubinden. Die zu der Zeit üblichen Protokolle konnten einige der Herausforderungen dieses Projekts nicht abdecken. Unter anderem sollte die vorhandene Bandbreite sehr effizient genutzt werden und dabei wenig Energie verbraucht werden.

Weiterentwicklung und Standardisierung

Seit 1999 hat sich MQTT weiterentwickelt und ist mitterweile bei der Version 3.1.1 angelangt. Es ist außerdem offizieller OASIS und ISO Standard (ISO/IEC 20922:2016) und es wurde bereits 2018 mit MQTT 5 ein Nachfolger spezifiziert. Heute ist das Protokoll Industriestandard wenn es um die Vernetzung für das Internet of Things, Heimautomatisierung oder aber auch Vernetzung im Kontext Industrie 4.0 geht.

Als Telemetrieprotokoll ist es mit MQTT in erster Linie möglich Text und Zahlen zwischen verschiedenen verteilten Geräten (M2M-Kommunikation) zuverlässig zu übetragen und zwar auch bei ungünstigen Bedingungen.

Zentrale Rolle des Brokers

Die Besondernheit von MQTT ist, dass eine zuverlässige Kommunikation zwischen den Kommunikationspartnern (Clients) durch einen zentralen Vermittler (Broker) gewährleistet wird. Der Broker bildet die Schnittstelle für die Kommunikation im Netzwerk. Die Clients kommunizieren nur mit ihm und kennen sich untereinander nicht. Der Broker hat die Aufgabe, Nachrichten anzunehmen und sie an interessierte Clients weiterzugeben.

Publish-Subscribe-Messaging-Muster

MQTT verwendet für seine Kommunikation das Publish-Subscribe-Messaging-Muster.

Hierbei senden die Absender von Nachrichten, die sogennanten Publisher, ihre Nachrichten nicht direkt an bestimmte Empfänger.

Vielmehr veröffentlichen sie nur die Nachricht analog zu einem Broacast. Damit die Nachricht auch irgendwo ankommt, kategorisiert der Publisher seine Nachricht beim Absenden mit einer Klasse. Die verfügbaren Empfänger, die sogennanten Subscriber, erhalten dann die Nachrichten der Klassen für die sie auch angemeldet sind.

Beim Publishen einer Nachricht als Publisher weiß man also nicht wer die Nachricht am Ende erhält oder ob sie überhaupt jemand erhält, da es davon abhängt ob es Subscriber für die gewählte Klasse gibt.

Topics

Bei Topics handelt es sich um die MQTT-spezifische Bezeichnung der bereits angesprochenen Klassen des Publish-Subscribe-Messaging-Musters.

Für den Nachrichtenaustausch zwischen Client und Broker ist die Wahl eines Topics erforderlich. Topics bestehen aus technischer Sicht aus einem UTF-8-String. Dieser UTF-8-String wird logisch in Levels aufgeteilt, was durch einen Slash (Topic Level Seperator) dargestellt wird. Bei dieser logische Aufteilung handelt es sich um eine Baumstruktur ähnlich wie bei Domains oder Dateipfaden.

Topic-Filter

Es ist Subscribern möglich mithilfe von Wildcards Topic Filter zu erstellen. Dadurch kann beispielsweise mit nur einem Subscription-Request mehreren Topics zugleich gefolgt werden.

Single-Level-Wildcard +

Diese Wildcard kann in jedem beliebigen Topic Level stehen und auch mehrmals vorkommen. Damit lässen sich alle verschiedenen Möglichkeiten eines Topic-Levels auswählen.

Beispielsweise lässt sich bei der bereits vorgestellten Topic-Struktur die Temperatur aller verfügbaren Städte folgendermaßen auswählen:

Multi-Level-Wildcard #

Diese Wildcard kann nur im letzten Topic-Level vorkommen und wählt alle Topics auf der gleichen Ebene aus einschließlich aller Untertopics.

Topics mit $

Eine Besonderheit bei MQTT sind Topics, die mit $ anfangen. Anwendungen dürfen keine Topics nutzen, die diesen Präfix haben, da jene Topics allein für den Broker reserviert sind. Beim Nutzen von Wildcards werden solche Topics ignoriert.

MQTT Control Packet

Das MQTT-Protokoll tauscht sogenannte MQTT Control Packets aus. Das Paket besteht besteht wie gewöhnlich aus Header (Metadaten des Pakets) und Payload (eigentliche Nachricht). Der Header ist aber wiederrum in zwei Teile aufgeteilt: Dem sogennanten Fixed Header, den jedes Paket hat und einem Variable header, welchen nur bestimmte Pakettypen verwenden. Die offizielle Spezifikation ist hier zu finden.

Kontrollpakettypen

MQTT unterscheidet in 14 unterschiedliche Kontrollpakettypen, die zwischen Server und Client ausgetauscht werden. Hier ist die vollständige Übersicht der Pakettypen. Sie haben alle verschiedene Funktionen wie z.B. den Verbindungsauf und -abbau, das Veröffentlichen von Nachrichten und das Subscriben und Unsubscriben von Topics, um die wichtigsten zu nennen.

Quality-of-Service

Quality of Service, kurz QoS ist die Dienstgüte eines Kommunikationskanals. Das Quality-of-Service Level bestimmt die Verbindlichkeit der Zustellung einer Nachricht vom Sender zum Empfänger.

Gerade bei Netzwerken, die keine zuverlässige Datenübertragung bieten, kann dank der QoS-Levels gewählt werden wie zuverlässig die Übertragung der Nachricht sein sollte. Dies wird im Header des Kontrollpakets definiert.

MQTT unterscheidet drei QoS-Level:

• Höchstens eine Zustellung (QoS Level 0)
• Mindestends eine Zustellung (QoS Level 1)
• Genau eine Zustellung (QoS Level 2)

Bei einer Nachricht mit QoS-Level 0 (default) wird das Paket einmal versendet und es gibt keine Garantie, dass die Nachricht beim Empfänger ankommt.

Ab QoS-Level 1 gibt es die Garantie, jedoch werden dafür mehrere Nachrichten an den Empfänger gesendet.

Ab QoS-Level 2, dem letzten Level, hat man außerdem noch die Sicherheit, dass nur eine Nachricht beim Empfänger ankommt und es keine Duplikate gibt.

Retained Messages

Da Clients nur über den Broker miteinander kommunizieren und sich untereinander nicht kennen, kann eine Nachricht verloren gehen, falls bei einem Subscriber-Client die Verbindung unterbricht. Denn der Broker übermittelt die Nachrichten standardmäßig einfach nur in Echtzeit und merkt sich nichts.

Mit dem Setzen der Retain-Flag im Header einer Nachricht wird jedoch die letztgesendete Nachricht für ein entsprechendes Topic beim Broker zwischengespeichert und kann somit bei Neuverbindung eines Subscriber-Clients angefragt werden.

Weitere Themen

Für eine tiefere Einarbeitung in das Thema ist die offizielle Spezifikation des Standards zu empfehlen.

Bezug zum Projekt

Rhasspy und Alice nutzen beide MQTT für die interne Kommunikation zwischen den verschiedenen Komponenten des Techstacks. MQTT als Protokoll allein reicht jedoch nicht, da es ein reines Kommunikationsprotokoll ohne Anwendungslogik ist.

Aus diesem Grund implementieren beide das Hermes Protokoll von Snips, das genau für den Anwendungsfall der Sprachsteuerung entwickelt worden ist und sich bewährt hat. Es bietet primär Schnittstellen für die Kommunikation zwischen den einzelnen Komponenten.

Im Folgenden geben wir einen kurzen Einblick in das Hermes Protokoll inklusive der relevanten Topics. Neben den Topics von Hermes hat Alice auch eigene Topics auf die wir eingehen werden.

Snips Hermes Protokoll

Hermes nutzt das MQTT-Protokoll zum Ausstausch von Nachrichten und spezifiziert in Form von Topics Schnittstellen für die einzelnen Komponenten. Darüber hinaus bestimmt es den gesamten Ablauf des Sprachsteuerungsprozesses: von der Aufnahme des Tons, dem Erkennen des Wakewords bis zur Erkennung und Ausführung des Intents, der Dialogführung und dem Sprachfeedback an den Nutzer.

Anwendungsschicht

MQTT baut meist auf TCP (Ausnahme: MQTT-SN) auf und befindet sich daher im TCP/IP-Modell auf der letzten Schicht: der Anwendungsschicht.

Da es aber den TCP/IP-Protokollstack außschließlich um weitere Funktionalität erweitert und im Gegensatz zu den gängigen Protokollen der Anwendungsschicht wie z.B. HTTP keine eigene Anwendungslogik festlegt bzw. kein festgelegtes Format für publizierte Nachrichten hat, muss das MQTT-Protokoll sozusagen um eine Schicht erweitert werden.

Das Hermes Protokoll von Snips macht genau das, es baut auf MQTT auf und definiert eine eigene Anwendungslogik.

Format der Nachricht

Nachrichten, die mit dem Hermes Protokoll versendet werden sind falls sie Informationen enthalten, immer im JSON-Format. Ausgenommen hier sind natürlich Nachrichten, die ihren Payload nicht nutzen und Audioframes, die im WAV-Format versendet werden.

Beispiel einer Nachricht:

{
  "siteId" : "626b9eb0-b26d-4b0b-ab30-332c679b3012"
}

Jede Nachricht enthält mindestends das Feld siteId welches den Adressaten der Nachricht in Form einer UUID angibt.

Dies ist wichtig wenn es mehrere Geräte gibt, die miteinander interagieren. Mit default lässt sich das aktuelle Gerät angeben ohne die UUID zu wissen. Die UUID wird beim Systemstart erzeugt und verändert sich während der Laufzeit nicht.

Ein anderes wichtiges Feld das fast genauso oft vorkommt ist die sessionId. Sie wird vom Dialog Manager beim Erstellen einer neuen Session erzeugt. Dies erfolgt nachdem das Wakeword erkannt worden ist oder eine Session manuell durch eine Nachricht an das Topic hermes/dialogueManager/startSession erzeugt wird.

Sprachsteuerung und das Zusammenspiel der Komponenten

Wie bereits erwähnt bestimmt Hermes nicht nur Schnittstellen für die Kommunikation sondern auch ganz genau den Ablauf des Sprachsteuerungprozesses und wie die einzelnen Komponenten miteinander interagieren. Im Folgenden eine etwas vereinfachte Darstellung in 9 Schritten (es fehlt u.a. dialogueManager/sessionStarted):

Hermes Topics

Hermes-spezifische Topics haben alle ein hermes als Bezeichner des ersten Topic-Levels und lassen sich dadurch leicht erkennen. Das zweite Topic-Level beschreibt immer die zuständige Komponente. Eine vollständige Übersicht der API (Topics inkl. Felder) erhält man hier und hier.

Alice Topics

Alice-spezifische Topics lassen sich ähnlich erkennen, nur dass der Bezeichner des ersten Topic-Levels projectalice ist. Wir haben eine Übersicht der verschiedenen Alice Topics erstellt.

ZigBee2MQTT

ZigBee2MQTT hat auch seine eigenen Topics. Der First-Level-Bezeichner ist zigbee2mqtt und der Second-Level-Bezeichner ist entweder der Broker oder ein Gerät. Für eine ausführliche Auflistung aller Topics ist die offizielle Referenz empfehlenswert.

Topicübersicht

Für eine grobe Übersicht aller Topics haben wir außerdem eine eigene Seite in unsere Dokumentation erstellt.

Implementationen

Es gibt verschiedene (Open-Source) Implementationen des MQTT-Protokolls. Eine Übersicht der verschiedenen Broker und Clients findet man hier und in ausführlicherer Form hier.

Broker

Der beliebteste Implementation eines Broker ist Moquitto von Eclipse. Die Implementation ist Open-Source und läuft sehr zuverlässig auf dem Rapsberry Pi. Er wird standardmäßig bei Alice und Rhasspy verwendet.

Clients

Es gibt für eine ganze Reihe von Programmiersprachen verschiedene Implementationen des MQTT-Clients. Darüber hinaus gibt es noch gerätespezifische Client-Implementationen wie z.B. für die Arduino Plattform.

Da Alice in Python entwickelt wird benutzt es die Python-Library paho-mqtt.

Clients für Endanwender

Um sich mit dem Protokoll vertraut zu machen aber auch beim Debuggen als Entwickler kann es außerdem hilfreich sein ein MQTT-Client für Endanwender zu nutzen. Neben MQTT CLI, welches sich über die Kommandozeile steuern lässt, gibt es auch grafische Anwendungen wie z.B. MQTT.fx. Beide Clients sind Open Source und in Java programmiert und sind daher plattformunabhängig. Alternativen findet man in diesem Artikel.

Um smarte Geräte/Gegenstände im Haushalt anzusteuern und in einem Netzwerk zusammenzuschließen gibt es verschiedene Schnittstellen und Standards. Es wird einerseits unterschieden in offene Standards und geschlossene Systeme und andererseits in kabelgebundene und kabellose Lösungen. In unserer Dokumentation behandeln wir ausschließlich Funkstandards und fokussieren uns dabei auf den Open-Source Standard ZigBee.

Offene Standards

Neben proprietären Smart Home Systemen gibt es viele Hersteller, die in ihren Geräten offene Standards implementieren. Dadurch lassen sich Geräte verschiedenster Hersteller mit dem selben Protokoll ansteuern. Die Standards ZigBee und Z-Wave haben sich durchgesetzt und sind weit verbreitet. Darüber hinaus verwenden einige Systeme auch WLAN oder Bluetooth.

Interoperabilität

Wenn ein Hersteller sich für einen offenen Standard entscheidet, ganz gleich ob WLAN, Bluetooth, ZigBee oder Z-Wave. Dann sind diese Geräte erst einmal mit Geräten, die auf einen anderen Standard setzen inkompatibel. Es gibt jedoch Versuche Interoperabilität zu erreichen indem man zwischen den verschiedenen Funkstandards übersetzt. Mehr dazu unter dem Punkt ZigBee-Gateways. Außerdem kann es zum Beispiel auch sein, dass selbst ZigBee-Geräte nicht miteinander kompatibel sind da gerade in der Vergangenheit je nach Anwendungsfall unterschiedliche ZigBee-Spezfikationen genutzt werden können.

ZigBee Logo

ZigBee ist ein offener Funkstandard, der sich besonders für die Vernetzung von Geräten im Smart-Home-Bereich eignet, da er unterschiedlichste Geräte auf kurzen Strecken äußerst energieeffizent und zuverlässig miteinander verbindet. Durch seine Energieeffizienz eignet sich ZigBee besonders für batteriebetriebene Geräte, welche jahrelang verwendet werden können ohne das ständige Wechseln von Akkus.

In der Praxis beträgt die Funkreichweite je nach Leistung und baulicher Umgebung zwischen 10 und 20 Metern, theoretisch aber (unter idealen Bedingungen) bis zu 100 Meter. Zigbee-Netze können verschiedenen Netztopologien entsprechen. Durch das Bilden eines Mesh-Netzwerks, in dem Endgeräte Signale weiterleiten, kann die Reichweite beispielsweise erweitert werden.

ZigBee wird seit 2002 von der ZigBee-Allianz entwickelt. Die erste Version des Standards ist 2004 erschienen.

Verbreitung durch ZigBee Light Link

Mit der Veröffentlichung des Anwendungsprofil ZigBee Light Link im Jahre 2012 gelang der Durchbruch. Die erste erste Generation der Philips Hue Beleuchtung ist im gleichen Jahr erschienen und verwendete das Anwendungsprofil als technische Grundlage. Auch andere smarte Beleuchtungssysteme wie Ikea Tradfri und Osram Lightify setzten auf die Technologie. Dadurch gelang eine weite Verbreitung von ZigBee-Geräten im Markt.

ZigBee-Allianz

Philips, Ikea und Innr/Ledvance (Osram/Lightify) sind neben über 200 anderen Unternehmen Teil der ZigBee-Allianz. Sie haben das gemeinsame Ziel einen IoT-Standard zu entwickeln und verwenden ihn auch für eigenproduzierte Geräte. Eine Liste der Mitglieder der ZigBee-Allianz ist hier zu finden.

Anwendungsprofile und unterschiedliche Spezifikationen

In der Vergangenheit gab es unterschiedliche Spezifikationen von ZigBee, die nicht miteinander kompatibel waren und meist nur auf einen speziellen Anwendungsfall optimiert waren.

Vor der Verbreitung von ZigBee und der Entstehung der verschiedenen Anwendungsprofile für ZigBee wie z.B. Light Link im Jahre 2012, gab es schon einige verschiedene Spezifikationen.

ZigBee Pro z.B. ist im Jahre 2007 erschienen und optimierte das ZigBee-Protokoll. Es bot eine verbesserte Sicherheit im Vergleich zu der bisherigen Spezifikation und eine größere Auswahl an Netztopologien.

Darüber hinaus gab es verschiedene Spezifikationen und Module, die für bestimmte Zwecke entwickelt worden sind. Zu nennen wäre da Green Power, Rf4ce und ZigBee IP.

Je nach Einsatzgebiet der Geräte gab es verschiedene Anwendungsprofile: ZigBee HA (HomeAutomation) für Heizungssysteme, ZigBee SE (SmartEnergy) für SmartMeter und ZigBee LL (Ligh Link) für Beleuchtungssysteme.

ZigBee 3

ZigBee 3.0 wurde 2015 von der ZigBee Allianz angekündigt und hatte zum Ziel die einzelnen unterschiedlichen Spezifikationen in einem Standard zusammenzuführen und somit eine hohe Interoperabilität zwischen verschiedenen Geräten zu gewährleisten. Bei der Entwicklung wurde außerdem darauf Wert gelegt den Standard möglichst abwärtskompatibilität zu den bestehenden Spezifikationen zu machen.

Zu einem Standard wurden Anwendungsprofile wie HomeAutomation und Light Link aber auch die unterschiedlichen Spezifiaktionen wie ZigBee Pro, Green Power, ZigBee IP und RF4CE zusammengefasst. Mit diesem Standard ist es daher möglich Geräte unterschiedlicher Hersteller und Einsatzzwecke im gleichen Netzwerk zu verwenden, falls der Hersteller fremde Geräte zulässt.

Seit 2018 rüsten einiger Hersteller bereits im Markt erhältliche Geräte per Software-Update mit dem neuen Protokoll nach. Neue Geräte unterstützen ZigBee 3.0 mittlerweile von Haus aus.

Netzwerktopologie und Akteure im Netz

Für den Aufbau eines Smart-Home-Systems gibt es im ZigBee-Standard drei unterschiedliche Gerätearten. Das sind End Devices, Router und Coordinators. Diese lassen sich in drei Topologien miteinander vernetzen: Stern, Baum und Mesh.

Ein ZigBee-Netzwerk hat immer nur einen Coordinator und ggf. mehrere Router und End Devices.

End device

Endgeräte (ZigBee-End-Devices auch ZED) haben keine verwaltende Funktion im Netzwerk. Sie sind in der Regel bateriebetriebene Geräte und Sensoren und können in den Schlafmodus versetzt werden. Sie melden sich an einen Router an und können ausschließlich mit ihm kommunizieren. Dies ist üblicherweise der nächstgelegene Router. Falls diese Router offline geht, geht für eine Weile auch die Verbindung zu all seinen Kindern verloren. Nach einem Timeout versuchen Endgeräte einen neuen Parent-Router zu finden. Manche Geräte wie Xiaomi-Geräte versuchen keinen neuen Parent-Router zu finden und bleiben daher unerreichbar falls der Router nicht wieder online geht.

Router

Router (kurz ZR) haben eine verwaltende Funktion im Netzwerk. Sie leiten den Traffic der verschiedenen Knoten im Netzwerk weiter. Router sind nicht in der Lage zu schlafen, daher sind batteriegetriebene Geräte nicht als Router geeignet. Router sind sogennante Gate-Keeper des Netzwerks: d.h. sie sind dafür verantwortlich neue Geräte in das Netzwerk zu integrieren. Indem die Router den einzelnen Komponenten eine eindeutige Adresse geben, stellen sie sicher, dass keine Informationen verloren gehen. Verschiedene Router lassen sich hierarchisch in einer Baumstruktur oder dynamisch in einem Mesh-System miteinander verbinden.

Coordinator

Koordinatoren (kurz ZC) sind spezielle Router. Sie starten die Netzwerke mit vorgegebenen Einstellungen und funktionieren im Anschluss ganz normal als Router.

Topologien

Die Stern-Topologie sieht einen Koordinator und mehrere Endgeräte vor. Die Endgeräte können nicht direkt miteinander kommunizieren, sondern nur über den Koordinator. Fällt dieser zentrale Knoten aus, ist kein Datenaustausch mehr möglich.

In der Baum-Topologie gibt es einen Koordinator, wenige Router und Endgeräte. Jedes Endgerät (Kind) kommuniziert mit dem jeweiligen Router (Elternteil), die Router mit dem Koordinator in einer Baumstruktur.

In der Mesh-Topologie sind die Router zusätzlich untereinander vernetzt. Das ermöglicht viele alternative Pfade, um Daten von einem Knoten A zu einem Knoten B zu transportieren. Aus diesem Grund nutzen die meisten ZigBee betriebenen Smart-Home-Systeme Mesh-Netzwerke. Bis zu 65.000 Knoten sind erlaubt. Anderseits benötigen Router mehr Energie als einfache Endgeräte. Das mindert die Lebensdauer der Batterien.

ZigBee-Gateways

Ein jedes ZigBee-System besitzt eine Basis-Station. Je nach Hersteller Gateway, Hub oder Bridge genannt. Wie bereits erwähnt ist ZigBee 3.0 grundsätzlich interoperabel. Es ist also technisch möglich Geräte verschiedener Hersteller in einem Netzwerk miteinander zu verbinden. Jedoch können sich Hersteller von Gateways auch dagegen entscheiden um Kunden an ihr Ecosystem zu binden. Eine Anbindung an die eigene Cloud gehört oft auch dazu.

Interoperabilität mit anderen Standards

ZigBee-Geräte lassen sich zudem nicht ohne Weiteres mit WLAN-, Bluetooth- oder Z-Wave-Geräten koppeln, da diese eine andere Sprache sprechen. Manche ZigBee-Gateways wie die Philips Hue Bridge oder der SmartThings Hub können jedoch zwischen den verschiedenen Funkstandards übersetzen.

Alternative ZigBee-Gateways

Anstelle eines dedizierten Geräts als Gateway ist es beispielsweise möglich ein eigenes herstellerunabängiges Gateway mithilfe eines speziellen USB-Sticks und eines Raspberry Pis zu betreiben.

Netzwerkadapter von Texas Instruments

Es können z.B. einige Netzwerkadapter von Texas Instruments genutzt werden um ein eigenes ZigBee-Gateway zu betreiben. Das gängigste und außerdem preiswerteste Beispiel dafür ist der USB-Stick CC2531 der ursprünglich zur Netzwerkanalyse dient aber zu einem ZigBee-Gateway umfunktioniert werden kann. Bei Händlern aus Fernost ist er schon ab Preisen von ungefähr 5 Euro erhältlich.

Es ist nötig ihn mit der passenden Firmware zu bespielen. Dazu wird der Texas Instruments CC Debugger und ein passendes Adapterkabel benötigt.

ConBee II Stick

Eine weitere Alternative, die leistungsfähiger aber auch teurer ist, ist der ConBee II Stick von Phoscon.

Weitere Adapter

Eine Übersicht von kompatiblen Adaptern findet man hier.

Zigbee2MQTT

Mit Zigbee2MQTT ist es möglich üblichen Geräten im Netzwerk (LAN) über das MQTT-Protokoll eine Schnittstelle zum ZigBee-Netzwerk zu bieten.

Vergleich zu anderen Funkstandards

WLAN: Der herkömmliche WLAN-Standard WiFi 5 überträgt Daten mehr als tausendmal schneller als ZigBee, verbraucht aber auch viel Strom. Das ist bei der Videoübertragung einer smarten Überwachungskamera wegen der hohen Datenmenge notwendig. Ein batteriebetriebener Thermostat, der lediglich die Temperatur sendet, benötigt dagegen keine so große Bandbreite und profitiert von einem sparsameren Funkstandard wie ZigBee.

Bluetooth: Es bietet ebenfalls eine höhere Datenübertragungsrate als ZigBee, allerdings mit einer geringeren Reichweite. Aus diesem Grund dominiert Bluetooth vor allem bei drahtlosen Kopfhörern und Wearables, die Signale in einem Umkreis von wenigen Metern senden. Bei Sensoren in verschiedenen Räumen hat ZigBee ganz klar die Nase vorne.

Z-Wave: Es ist im Smart-Home-Bereich der Hauptkonkurrent von ZigBee. Das energiearme Protokoll kommt ebenfalls bei vielen Sensoren und Leuchtmitteln zum Einsatz, bietet eine hohe Kompatibilität und wie ZigBee eine hohe Reichweite dank Mesh-Netzwerken. Allerdings besitzt das US-Unternehmen Silicon Labs die Rechte für die Technologie. Anders als ZigBee handelt es sich bei Z-Wave also nicht um einen Open Source Standard. Dadurch können Hersteller das Protokoll nicht anpassen.

EnOcean: Kommt ausschließlich bei ultra-energiearmen Sensoren zum Einsatz, die durch Temperaturunterschiede und Bewegungen Strom generieren und damit ohne Batterien und externe Stromquellen auskommen. Auch ZigBee 3.0 unterstützt mit der Spezifikation Green Power diese Funktion. Insgesamt ist EnOcean weniger verbreitet als ZigBee.

Bewertung

Vorteile von ZigBee

• Geringer Energieverbrauch: Sensoren und andere Smart-Home-Geräte kommen jahrelang mit ihren Batterien aus.- Hohe Kompatibilität: Die ZigBee Allianz zählt mehrere hundert Mitglieder, darunter Hersteller wie Osram, IKEA, Belkin und Signify. Ab ZigBee 3.0 lassen sich Smart-Home-Produkte verschiedener Hersteller leichter vernetzen.
• Open Source Code: Der ZigBee-Code steht jedem zur Verfügung. Herstellern steht damit frei, zusätzliche Funktionen in ihre Produkte zu implementieren.
• Hohe Reichweite: In Mesh-Netzwerken verhalten sich die Knoten als Repeater. In großen Häusern und Wohnungen verbessert sich damit die Reichweite im Vergleich zu WLAN signifikant.

Nachteile von ZigBee

• Kompatibilität unter ZigBee Geräten: Der Open Source Code war vor allem in der Vergangenheit unter dem Aspekt der Kompatibilität von Nachteil. Da jeder Hersteller zusätzliche Spezifikationen implementierte, sind ältere ZigBee-Geräte unterschiedlicher Marken nicht zwingend miteinander kompatibel. Seit der Einführung von ZigBee 3.0 ist der Standard jedoch einheitlicher geworden.
• Kompatibilität mit anderen Funkstandards: Wer ZigBee-Smart-Home-Produkte mit WLAN- oder Bluetooth-Geräten vernetzen will, benötigt ein Gateway. Da viele Smart-Home-Systeme wie HomeKit oder Google Home auf WLAN setzen, müssen Nutzer die Kosten für einen Gateway einplanen.