Kategorie:ZigBee

Allgemeines

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

Die Spezifikation ist eine Entwicklung der ZigBee-Allianz, die Ende 2002 gegründet wurde. Sie 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 und dieses befindet sich im Schlafmodus, 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 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 aktuellsten Firmware stand zu bringen. Gerade wenn Komponenten herstellerübergreifend verwendet werden sollen ist sonst oft mit Einschränkungen oder sogar Problemen zu rechnen.

Hierzu ist aktuell die zugehörige original Bridge (und oft auch die App) des jeweiligen Herstellers nötig. D.h. auch wenn man z.b. Oram LIGHTIFY oder IKEA Trådfri Leuchtmittel an einer HUE Bridge betreiben möchte braucht man zumindest am Anfang ein mal auch noch die Osram und IKEA Bridge.

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 Phillips HUE Bridge oder mit der Dresden Elektronik Software) den größten Funktionsumfang ermöglicht.

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.

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

Siehe Thema.

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 eine gewisse Hardware mitbringen, wie den RaspBee (Aufsteckmodul für Raspberry) oder Conbee (USB-Gateway) von Dresden Elektronik oder (hier mqtt2zigbee-Hardware aufführen), 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" 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 (Zigbee Funksteckdose oder so)

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 wird, und daraufhin wegen geplatzem Heizkörper die Wohnung geflutet wird, so ist dies schon etwas schwerer zu Erkennen...

Bekannte Sicherheitslücken

Insecury Rejoin

Insecure Rejoin ist eine der schwachen Stellen 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 Insecury 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