ZWCUL: Unterschied zwischen den Versionen
Krikan (Diskussion | Beiträge) (Rohfassung des Artikels / Auslagerung aus Artikel Z-Wave) |
K (Typos/Spelling) |
||
| (2 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
| Zeile 8: | Zeile 8: | ||
|ModOwner=Rudolf König ([http://forum.fhem.de/index.php?action=profile;u=8 Forum]) | |ModOwner=Rudolf König ([http://forum.fhem.de/index.php?action=profile;u=8 Forum]) | ||
}} | }} | ||
Mit dem '''{{PAGENAME}}''' - Modul wird ein [[CUL]] als Gateway zur Ansteuerung von Z-Wave-Geräten in FHEM eingebunden. Die Implementierung der Z-Wave-Controllerfunktionen in der CUL-Firmware culfw (Z-Wave@culfw) befindet sich noch im Beta-Stadium. | |||
== ZWaveCUL (experimentell) == | == ZWaveCUL (experimentell) == | ||
Da Z-Wave eigene Chips zur Funkkommunikation nutzt, ist es prinzipiell erstmal nicht möglich mit einem CC1101 Sendemodul mit ZWave zu kommunizieren. Sicherheitsforscher haben 2013 gezeigt, dass es trotzdem möglich ist. Rudolf König hat auf die vorhandene Arbeit aufgebaut und | Da Z-Wave eigene Chips zur Funkkommunikation nutzt, ist es prinzipiell erstmal nicht möglich, mit einem CC1101 Sendemodul mit ZWave zu kommunizieren. Sicherheitsforscher haben 2013 gezeigt, dass es trotzdem möglich ist. Rudolf König hat auf die vorhandene Arbeit aufgebaut und Z-Wave-Funktionen in culfw 1.66 implementiert. Das Modul 00_ZWCUL.pm bindet den CUL im Z-Wave-Modus in FHEM ein. In Zusammenarbeit mit dem Modul 10_ZWave.pm ist es somit möglich ein Z-Wave Netzwerk mit einem CUL aufzubauen und zu betreiben. | ||
Da ZWCUL niemand produktiv einsetzt, gibt es eventuell noch weitere Probleme als unten aufgeführt. Es wird | Da ZWCUL -soweit bekannt- niemand produktiv einsetzt, gibt es eventuell noch weitere Probleme als unten aufgeführt. Es wird niemandem empfohlen ZWCUL produktiv zur Ansteuerung eines Z-Wave-Netzes einzusetzen, der nicht aktiv mitentwickeln will. Dennoch werden Tester gesucht, da somit ZWCUL ordentlich implementiert werden kann. Für den "Normalanwender" ist die Verwendung eines Z-Wave-Gateways mit einem originalen Z-Wave-Chip, das über 00_ZWDongle.pm angesteuert wird, der empfohlene Weg zur Ansteuerung seines Z-Wave-Netzes. | ||
Im Folgenden werden die Vor- und Nachteile des CULs im Z-Wave-Modus im Vergleich zu einem Stanard-Gateway aufgeführt. | |||
=== Vorteile | === Vorteile === | ||
* da die Hersteller der Controller vom Mesh wissen, legen sie | * da die Hersteller der Controller vom Mesh wissen, legen sie keinen Wert auf gute Antennen, deswegen ist die ''direkte'' Reichweite der "original" Controller (d.h. der erste Hop bei der Übertragung) kleiner als mit CUL/ZWCUL. | ||
* die komplette Konfiguration wird in FHEM gespeichert | * die komplette Konfiguration wird in FHEM gespeichert; man muss kein Firmware Backup machen. | ||
* Routing ist deterministisch und vom Benutzer beeinflussbar. | * Routing ist deterministisch und vom Benutzer beeinflussbar. | ||
* besseres Debugging der Z-Wave-Funkkommunikation | |||
* Firmware ist Open Source | |||
=== (Momentane) Nachteile === | |||
* die "original" Z-Wave Chips können 3 "Datenraten" auf einmal empfangen, und wir können den CC1101 Chip nur mit einer betreiben. Die Zwave Chips schalten bei Kommunikationsproblemen automatisch auf die langsamere Datenrate um, das geht mit ZWCUL nicht. Weiterhin gibt es mindestens ein Gerät (eine Schaltsteckdose), das aus Lizenzgründen das Betätigen des Knopfes am Gerät immer auf der langsamen Datenrate meldet, das würde ZWCUL nicht bekommen, falls es mit der schnellen Datenrate läuft. | |||
* FLiRS (kompatible batteriebetriebene Geräte aufwecken) ist nicht implementiert | |||
* Explorer-Frames (d.h. dynamisches Routing) ist noch nicht entschlüsselt, d.h. Routing muss statisch konfiguriert werden. | |||
* Verschlüsselte Inklusion geht (noch?) nicht (die Nutzdaten sind in diesem Fall mehr als 64 Byte, und culfw mit Z-Wave kann noch kein sliding window), verschlüsselte Kommunikation geht aber. | |||
== | == Links == | ||
* Thread zur Entwicklung: {{Link2Forum|Topic=44905}} | |||
* | * Hinweise zu Vor- und Nachteilen von ZWCUL: {{Link2Forum|Topic=52364|Message=441957}}, {{Link2Forum|Topic=81061|Message=732095}} | ||
[[Kategorie:Z-Wave Components]] | [[Kategorie:Z-Wave Components|CUL]] | ||
Aktuelle Version vom 31. Dezember 2018, 20:02 Uhr
| ZWCUL | |
|---|---|
| Zweck / Funktion | |
| Einbindung CUL im Z-Wave-Modus als Gateway | |
| Allgemein | |
| Typ | Gerätemodul |
| Details | |
| Dokumentation | EN / DE |
| Support (Forum) | ZWave |
| Modulname | 00_ZWCUL.pm |
| Ersteller | Rudolf König (Forum) |
| Wichtig: sofern vorhanden, gilt im Zweifel immer die (englische) Beschreibung in der commandref! | |
Mit dem ZWCUL - Modul wird ein CUL als Gateway zur Ansteuerung von Z-Wave-Geräten in FHEM eingebunden. Die Implementierung der Z-Wave-Controllerfunktionen in der CUL-Firmware culfw (Z-Wave@culfw) befindet sich noch im Beta-Stadium.
ZWaveCUL (experimentell)
Da Z-Wave eigene Chips zur Funkkommunikation nutzt, ist es prinzipiell erstmal nicht möglich, mit einem CC1101 Sendemodul mit ZWave zu kommunizieren. Sicherheitsforscher haben 2013 gezeigt, dass es trotzdem möglich ist. Rudolf König hat auf die vorhandene Arbeit aufgebaut und Z-Wave-Funktionen in culfw 1.66 implementiert. Das Modul 00_ZWCUL.pm bindet den CUL im Z-Wave-Modus in FHEM ein. In Zusammenarbeit mit dem Modul 10_ZWave.pm ist es somit möglich ein Z-Wave Netzwerk mit einem CUL aufzubauen und zu betreiben.
Da ZWCUL -soweit bekannt- niemand produktiv einsetzt, gibt es eventuell noch weitere Probleme als unten aufgeführt. Es wird niemandem empfohlen ZWCUL produktiv zur Ansteuerung eines Z-Wave-Netzes einzusetzen, der nicht aktiv mitentwickeln will. Dennoch werden Tester gesucht, da somit ZWCUL ordentlich implementiert werden kann. Für den "Normalanwender" ist die Verwendung eines Z-Wave-Gateways mit einem originalen Z-Wave-Chip, das über 00_ZWDongle.pm angesteuert wird, der empfohlene Weg zur Ansteuerung seines Z-Wave-Netzes.
Im Folgenden werden die Vor- und Nachteile des CULs im Z-Wave-Modus im Vergleich zu einem Stanard-Gateway aufgeführt.
Vorteile
- da die Hersteller der Controller vom Mesh wissen, legen sie keinen Wert auf gute Antennen, deswegen ist die direkte Reichweite der "original" Controller (d.h. der erste Hop bei der Übertragung) kleiner als mit CUL/ZWCUL.
- die komplette Konfiguration wird in FHEM gespeichert; man muss kein Firmware Backup machen.
- Routing ist deterministisch und vom Benutzer beeinflussbar.
- besseres Debugging der Z-Wave-Funkkommunikation
- Firmware ist Open Source
(Momentane) Nachteile
- die "original" Z-Wave Chips können 3 "Datenraten" auf einmal empfangen, und wir können den CC1101 Chip nur mit einer betreiben. Die Zwave Chips schalten bei Kommunikationsproblemen automatisch auf die langsamere Datenrate um, das geht mit ZWCUL nicht. Weiterhin gibt es mindestens ein Gerät (eine Schaltsteckdose), das aus Lizenzgründen das Betätigen des Knopfes am Gerät immer auf der langsamen Datenrate meldet, das würde ZWCUL nicht bekommen, falls es mit der schnellen Datenrate läuft.
- FLiRS (kompatible batteriebetriebene Geräte aufwecken) ist nicht implementiert
- Explorer-Frames (d.h. dynamisches Routing) ist noch nicht entschlüsselt, d.h. Routing muss statisch konfiguriert werden.
- Verschlüsselte Inklusion geht (noch?) nicht (die Nutzdaten sind in diesem Fall mehr als 64 Byte, und culfw mit Z-Wave kann noch kein sliding window), verschlüsselte Kommunikation geht aber.