ZigBee: Unterschied zwischen den Versionen
K (Nur etwas Rechtschreibung und Grammatik) |
K (hauptsächlich Korrektur von Tippfehlern) |
||
(11 dazwischenliegende Versionen von 4 Benutzern werden nicht angezeigt) | |||
Zeile 25: | Zeile 25: | ||
Im einzelnen sollte man sich also vor dem Kauf informieren, welche Komponenten tatsächlich problemlos zusammen arbeiten. | 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 | 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 {{Link2Forum|Topic=93836|LinkText=... HUE oder OSRAM oder Tradfri oder ...?}} geführt worden. Kernpunkte aus der Diskussion: | ||
Hierzu ist aktuell in der Regel | * 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 | * 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 == | == 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. | 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 === | === 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. | 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, | 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 | 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. | Außerdem ist unser Ziel ja, die Steckerleiste der Steuergeräte kurz zu halten. | ||
Zeile 53: | Zeile 60: | ||
==== Hue Bridge von Philips ==== | ==== Hue Bridge von Philips ==== | ||
Siehe [[Hue]]. Eine gute Dokumentation kompatibler Geräte findet sich [https://iconnecthue.com/supported-devices/ hier]. Hue ist wohl die | Siehe [[Hue]]. Eine gute Dokumentation kompatibler Geräte findet sich [https://iconnecthue.com/supported-devices/ 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 ==== | ==== Trådfri von IKEA ==== | ||
Siehe {{Link2Forum|Topic=70653}} und [[TRÅDFRI]]. | Siehe {{Link2Forum|Topic=70653|LinkText=dieses Forenthema}} und die [[TRÅDFRI]] Modulseite. | ||
==== Lightify von Osram ==== | ==== Lightify von Osram ==== | ||
Siehe {{Link2Forum|Topic=28339}}. Auch hier geht nur Polling von Events, ebenfalls max. 50 Geräte | Siehe {{Link2Forum|Topic=28339|LinkText=dieses Forenthema}}. Auch hier geht nur Polling von Events, ebenfalls max. 50 Geräte und der Nutzerkreis ist kleiner. | ||
=== Andere Lösungen === | === Andere Lösungen === | ||
Die Alternative sind Lösungen, die spezielle Hardware erfordern, wie den RaspBee (Aufsteckmodul für Raspberry) oder | 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 [https://github.com/Koenkk/zigbee2mqtt/wiki/Supported-sniffer-devices 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 ==== | ==== 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. | 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 ==== | ==== Direkt per MQTT ==== | ||
Über die Community-Projekte [https://www.zigbee2mqtt.io/ zigbee2mqtt] oder [https://tasmota.github.io/docs/Zigbee/ zigbee2tasmota] kann ZigBee-Hardware relativ einfach eingebunden werden. Da bei beiden Lösungen der Datenaustausch mittels JSON erfolgt, wird empfohlen, die MQTT2-Modulfamilie zur [[MQTT#Installation_in_FHEM|Einbindung in FHEM]] zu nutzen. Details sind den Artikeln [[Zigbee2mqtt|zigbee2mqtt]] und [[Zigbee2Tasmota-MQTT|zigbee2tasmota]] zu entnehmen. | |||
==== Das Modul von Neumann ==== | ==== Das Modul von Neumann ==== | ||
Siehe | Siehe das Forenthema {{Link2Forum|Topic=84790|LinkText="Xiaomi Smart Home ohne Gateway direkt an FHEM"}} zum Modul ''XiaomiMQTTDevice''. | ||
== Funkübertragung == | == Funkübertragung == | ||
=== Reichweite erhöhen === | === Reichweite erhöhen === | ||
{{Randnotiz|RNTyp=g|RNText=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) | * 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 | * 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) | * ZigBee ist ein Mesh-Netz, daher irgendwo auf dem Weg ein ZigBee-Gerät verbauen, welches immer eingeschaltet ist (z.B. ZigBee Funksteckdose) | ||
== Sicherheit == | == 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: | |||
# den Geräten selbst, Beispiel: hue Smart Button + LCA001 Hersteller Anleitung, | |||
# 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 === | === 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... | 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... | ||
Zeile 100: | Zeile 125: | ||
* Jamming (einfach die Frequenz belegen mit beliebigem Signal) | * Jamming (einfach die Frequenz belegen mit beliebigem Signal) | ||
* Flutung mit ZigBee Messages | * Flutung mit ZigBee Messages | ||
Quelle: https://research.kudelskisecurity.com/2017/11/21/zigbee-security-basics-part-3/ | Quelle: https://research.kudelskisecurity.com/2017/11/21/zigbee-security-basics-part-3/ | ||
== Links == | == Links == | ||
* https://www.golem.de/news/smart-home-sicherheitsluecken-im-zigbee-protokoll-demonstriert-1511-117657-2.html | * https://www.golem.de/news/smart-home-sicherheitsluecken-im-zigbee-protokoll-demonstriert-1511-117657-2.html | ||
* Sammlung von OTA-files und Quellen bei [https://github.com/Koenkk/zigbee-OTA koenkk] | |||
[[Kategorie:ZigBee | [[Kategorie:ZigBee]] |
Aktuelle Version vom 6. August 2021, 17:04 Uhr
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:
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
![Info green.png](/w/images/thumb/0/02/Info_green.png/20px-Info_green.png)
- 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:
- den Geräten selbst, Beispiel: hue Smart Button + LCA001 Hersteller Anleitung,
- 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