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 (siehe #Firmware updates).
Firmware updates
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[1] 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 auch aus FHEM heraus anstoßen.
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.
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, aber 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 5 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 meist 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
Lightify von Osram
Siehe Thema. 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. Eine reine Hardware-Lösung ohne Zusatzsoftware, in der FHEM die Software-Funktionen des Gateway vollständig abbildet, gibt es nicht - FHEM kommuniziert lediglich mit einer Software, die ebenfalls auf dem - ggf. 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.
Direkt per MQTT
Siehe MQTT2-Module - Praxisbeispiele#zigbee2mqtt
Das Modul von Neumann
Siehe diesen Forenbeitrag: Thema
Funkübertragung
Reichweite erhöhen
- 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
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
- ↑ Der Diskussionsstand 11/2018 hierzu ist diesem Forenthread zu entnehmen.