ZigBee

Allgemeines

ZigBee ist eine Spezifikation für drahtlose Netzwerke mit geringem Datenaufkommen, wie beispielsweise Hausautomation, Sensornetzwerke oder Lichttechnik. Der Schwerpunkt von ZigBee liegt in kurzreichweitigen Netzwerken (bis 100 Meter). Es sind via vermaschtem Netz (auch Meshnetzwerk) aber auch Reichweiten von mehreren Kilometern möglich.

Die Spezifikation ist eine Entwicklung der ZigBee-Allianz, die Ende 2002 gegründet wurde. Die Allianz ist ein Zusammenschluss von derzeit mehr als 230 Unternehmen, welche die weltweite Entwicklung dieser Technologie vorantreiben.

Gerätetypen

Endgerät (ZigBee End Device, ZED)

Geräte, wie zum Beispiel Steuerungs- oder Sensormodule, werden meist mit Batterien betrieben. Diese können als ZigBee-Endgeräte implementiert werden und benötigen nur einen Teil der Funktionen der ZigBee-Spezifikation. Sie nehmen nicht am Routing im Netzwerk teil und können in einen Schlafmodus gehen. Sie melden sich an einem Router ihrer Wahl an und treten so dem ZigBee-Netzwerk bei. Sie können ausschließlich mit dem Router kommunizieren, über den sie dem Netzwerk beigetreten sind. Werden Daten an ein solches Endgerät geschickt, welches sich im Schlafmodus befindet, speichert der Router diese Pakete, bis das Endgerät sie abruft.

Router (ZigBee-Router, ZR)

ZigBee-Router nehmen am Routing der Pakete durch das Netzwerk teil. Sie benötigen einen größeren Funktionsumfang und damit auch etwas mehr Hardwareressourcen. ZigBee-Router treten einem Netzwerk bei, indem sie sich an einem im Netzwerk befindlichen Router anmelden. Das Routing im Netzwerk erfolgt entweder entlang eines sich so bildenden Baumes (Stackprofil ZigBee) oder durch dynamisches Routing als Meshnetzwerk.

Ein ZigBee Router hat so ungefähr die Funktion wie ein WLAN Repeater...

Koordinator (ZigBee coordinator, ZC)

Ein ZigBee-Koordinator startet das Netzwerk mit festgelegten Parametern. Nach dem Start übernimmt er dieselben Aufgaben wie ein ZigBee-Router. Es kann nur einen Koordinator in einem ZigBee Netz geben. In FHEM wird ein solches Gerät Gateway genannt.

Mischen von Komponenten unterschiedlicher Hersteller

Prinzipiell ist es möglich, die Komponenten unterschiedlicher Hersteller zu mischen. Dies kann interessant sein, da jeder Hersteller andere Schwerpunkte in der Modellpalette hat, nicht jeder Hersteller alle Leuchtmittel-Typen vertreibt und sich auch die Eigenschaften und Preise für vergleichbare Leuchtmittel unterscheiden. Auch der in FHEM verfügbare Funktionsumfang unterscheidet sich je nach Bridge.

Leuchtmittel sind in der Regel am unproblematischsten. Taster auch wenn sie direkt die Leuchtmittel steuern. Über die Bridge sind in der Regel aber oft nur die Taster des jeweiligen Herstellers direkt abfragbar bzw. in FHEM einzubinden. Dies gilt auch für Bewegungsmelder und sonstige Sensoren.

Im einzelnen sollte man sich also vor dem Kauf informieren, welche Komponenten tatsächlich problemlos zusammen arbeiten.

Beim Vergleich der Kosten muss aber die jeweilige Bridge des Herstellers zusätzlich mit berücksichtigt werden.

Eine Grundsatzdiskussion über diese Thematik ist im Forum unter dem Titel ... HUE oder OSRAM oder Tradfri oder ...? geführt worden. Kernpunkte aus der Diskussion:

• Es ist sinnvoll oder sogar zwingend nötig, neue Leuchtmittel zumindest einmal bei der Inbetriebnahme auf den aktuellen Firmwarestand zu bringen. Gerade wenn Komponenten herstellerübergreifend verwendet werden sollen, ist sonst oft mit Einschränkungen oder sogar Problemen zu rechnen.
• Hierzu ist aktuell in der Regel die zugehörige original Bridge (und oft auch die App) des jeweiligen Herstellers nötig, d.h., auch wenn man z.B. Osram LIGHTIFY oder IKEA Trådfri Leuchtmittel an einer Hue Bridge betreiben möchte, braucht man zumindest am Anfang einmal auch noch die Osram und IKEA Bridge und muss das Leuchtmittel jeweils an- und ab- und wieder anlernen.
• Aktualisierungen der Hue Bridge und Hue Leuchtmittel lassen sich direkt aus FHEM heraus anstoßen.
• Das HUEBridge Modul erkennt, wenn ein Leuchtmittel zwischen einer Hue und einer deCONZ Bridge (oder umgekehrt) wechselt und verschiebt das zugehörige HUEDevice in FHEM jeweils zum richtigen Bridge-Device. D.h., wenn z.B. zum Firmwareupdate die Bridge gewechselt wird, ist auf FHEM Seite nichts weiter zu tun.

Einbindung in FHEM

Prinzipiell lässt sich hier vorwegschicken, dass die FHEM Hue-Module (ob mit einer Philips Hue Bridge oder mit der Dresden Elektronik Software) den größten Funktionsumfang ermöglichen.

Je nach Art des Gateways und der Art der Einbindung (dediziertes Modul oder generisch über MQTT(2)) sind bei den FHEM Geräten ein unterschiedlicher Funktionsumfang und teils erheblich Unterschiede in den Features, Reaktionen und Readings zu erwarten. Die Entwicklung schreitet stetig voran!

Es existieren derzeit diese detaillierteren Wiki Artikel zur allgemeinen Einbindung:

• Hue, ConBee, TRÅDFRI
• Zigbee2mqtt
• Zigbee2Tasmota-MQTT

Hersteller-Bridges

Wir benötigen also zur Einbindung ein Gateway. Manche Nutzer haben sich gleich ein Starterkit wie Philips Hue oder IKEA Trådfri gekauft. Diese Lösungen haben den Vorteil, dass Alexa-Integration etc. sowie die Smartphone-App gleich mitkommen, und das Einbinden der Endgeräte, vor allem aber Softwareupdates i.d.R. herstellerproprietär gelöst wurden.

Der Nachteil ist, dass die Lösungen bis hin zum gut dokumentierten Hue-System mit API in anderer Hinsicht geschlossene Systeme sind. So ist z.B. über die Hue-Bridge die Abfrage von Hue-Bewegungssensoren oder -Tastern nur per Polling durch FHEM möglich - es gibt keinen Event-Mechanismus, der FHEM notifizieren könnte (siehe #Freie Lösungen). Alle fünf Minuten die Bridge fragen (= Pollen), ob der Bewegungsmelder jemanden gesehen hat und ggf. das Licht ausschalten, ist also per Polling machbar, auf einen ZigBee-Tasterdruck oder Bewegung hin via FHEM die WiFi-Steckdose schalten hingegen eher zu verzögert.

Außerdem ist unser Ziel ja, die Steckerleiste der Steuergeräte kurz zu halten.

Auch die native HomeKit- (Siri) oder Alexa-Integration ist mit kleinen oder größeren Problemen und Einschränkungen behaftet, diese sind unter anderem:

• nur Steuerung der herstellereigenen Leuchtmittel
• Verzögerung der Statusaktualisierung in FHEM, wenn an FHEM vorbei geschaltet wird
• Eventuell 'Cloud-Zwang' des jeweiligen Herstellers
• Eventuell erhöhter Ressourcenverbrauch auf der jeweiligen Bridge durch zusätzliche Verbindungen

Diese Nachteile gibt es bei einer Integration über FHEM nicht.

Hue Bridge von Philips

Siehe Hue. Eine gute Dokumentation kompatibler Geräte findet sich hier. Hue ist wohl die am weitesten verbreitete Bridge und hat auch ein dokumentiertes REST-API. Jedoch ist die Anzahl der Endgeräte (offiziell: 50) und Regeln (ca. 200) stärker als bei anderen Lösungen begrenzt und Events können nicht zu FHEM weitergeleitet werden.

Trådfri von IKEA

Siehe dieses Forenthema und die TRÅDFRI Modulseite.

Lightify von Osram

Siehe dieses Forenthema. Auch hier geht nur Polling von Events, ebenfalls max. 50 Geräte und der Nutzerkreis ist kleiner.

Andere Lösungen

Die Alternative sind Lösungen, die

• spezielle Hardware erfordern, wie den RaspBee (Aufsteckmodul für Raspberry) oder ConBee (USB-Gateway) von Dresden Elektronik
• oder manche Module mit Chips des Herstellers Texas Instruments

und die zusätzlich nötige Software auf dem Raspberry etc. mitlaufen lassen.

Abgesehen von zigbee2tasmota sind dies keine reinen Hardware-Lösungen ohne Zusatzsoftware, in der FHEM die Software-Funktionen des Gateway vollständig abbilden würde. FHEM kommuniziert lediglich mit einer Software, die ebenfalls - ggf. auf dem gleichen Computer - mitläuft.

Dresden Elektronik

Das Dresden Elektronik System ermöglicht aktuell als einziges der 'fertigen' Systeme auch das aktive Senden von Events und somit eine 'fast Echtzeit' Reaktion auf Taster, Bewegungsmelder oder Ähnliches. Realisiert ist das über eine Push Erweiterung im ansonsten weitgehend Hue kompatiblen API. Auch die Integration von Tastern und anderen Sensoren unterschiedlichster Hersteller ist mit der DE Software gut möglich. Die Anbindung an FHEM (inklusive Push) erfolgt über die HUE-Module.

Details dazu und zur Installation sind auf der Seite ConBee zu finden.

Direkt per MQTT

Über die Community-Projekte zigbee2mqtt oder zigbee2tasmota kann ZigBee-Hardware relativ einfach eingebunden werden. Da bei beiden Lösungen der Datenaustausch mittels JSON erfolgt, wird empfohlen, die MQTT2-Modulfamilie zur Einbindung in FHEM zu nutzen. Details sind den Artikeln zigbee2mqtt und zigbee2tasmota zu entnehmen.

Das Modul von Neumann

Siehe das Forenthema "Xiaomi Smart Home ohne Gateway direkt an FHEM" zum Modul XiaomiMQTTDevice.

Funkübertragung

Reichweite erhöhen

Da der gleich Frequenzbereich wie für WLAN genutzt wird, kann es auch zu Interferenzen mit diesem kommen. In diesen Fall kann es sinnvoll sein, für eine der beiden Techniken einen anderen Kanal zu wählen.

• Eine brauchbare WLAN Antenne (2,4GHz) an einen CC2531 "Stick" oder ein anderes Gateway anbauen (eher für Experten)
• ein CC2530 als Gateway oder in der Mitte als Repeater (Achtung verschiedene Firmwares erforderlich; gute Antenne muss meist gesondert gekauft werden, anstatt der beigelegten)
• ZigBee ist ein Mesh-Netz, daher irgendwo auf dem Weg ein ZigBee-Gerät verbauen, welches immer eingeschaltet ist (z.B. ZigBee Funksteckdose)

Sicherheit

Direkte Verbindung von Geräten - Binding

Noch in Arbeit!

Eine direkte Verbindung ( Binding ) zwischen Zigbee Geräten (Schalter, Lampen) erhöht die Betriebssicherheit und ermöglicht Grundfunktionen (z.B. on/off) nicht nur bei Ausfall der Zentrale (FHEM) sondern auch des Zigbee Coordinator (Gateway).

Binding einrichten mit:

1. den Geräten selbst, Beispiel: hue Smart Button + LCA001 Hersteller Anleitung,
2. der Coordinator Software:
   • conbee / deconz - deconz gui notwending, im Handbuch lückenhaft erklärt.
   • zigbee2mqtt - Siehe Dokumentation Kapitel Binding, mqtt publish Befehl bind/unbind.
   • zigbee2tasmota - Dokumentation Zigbee, Befehl ZbBind direkt in der Tasmota Console der ZbBridge.

Sicherheitsrelevante Geräte

Welche Geräte sicherheitsrelevant sind, ist eine sehr schwierige Frage. Beim Türschloss ist das klar. Wenn ein Temperatursensor dafür sorgt, dass ein Raum nicht mehr beheizt und daraufhin wegen geplatztem Heizkörper die Wohnung geflutet wird, so ist dies schon etwas schwerer zu erkennen...

Bekannte Sicherheitslücken

Insecure Rejoin

Insecure Rejoin ist eine der Schwachstellen im Protokoll. ZigBee 3.0 wurde 2015 freigegeben und soll das Problem lösen. Allerdings ist ZigBee 3.0 (Stand Ende 2018) noch immer recht wenig verbreitet.

Ablauf des Insecure Rejoin aus Angreifersicht:

• einen Node aus dem Netz werfen, um nicht auf die Aktivierung neuer Geräte warten zu müssen
• der Node versucht erneut Mitglied im Netz zu werden. Schlüsselaustausch erfolgt mittels dem Key "ZigBeeAlliance09"
• Mitsniffen des neuen Schlüssels

Quelle: Link zu Golem.de über die Forschung von Tobias Zillner

DDOS

• manipulierte Counter (können sogar manche HW zerstören)
• Jamming (einfach die Frequenz belegen mit beliebigem Signal)
• Flutung mit ZigBee Messages

Quelle: https://research.kudelskisecurity.com/2017/11/21/zigbee-security-basics-part-3/

Links

• https://www.golem.de/news/smart-home-sicherheitsluecken-im-zigbee-protokoll-demonstriert-1511-117657-2.html
• Sammlung von OTA-files und Quellen bei koenkk