RFR CUL: Unterschied zwischen den Versionen

Aktuelle Version vom 11. November 2020, 17:46 Uhr

Um die Funkabdeckung von CULs im SlowRF Modus zu erhöhen, ohne lange USB Kabel oder Netzwerke mit CUNs einsetzen zu müssen, lässt sich ein zweites (drittes, viertes, ...) CUL als RFR (Radio Frequency Router) konfigurieren. Die Verbindung erfolgt hierbei über Funk, so dass keine USB Verbindung zum FHEM-Hostrechner erforderlich ist.

Funktion

Das RFR ist kein Repeater im eigentlichen Sinne, sondern eine weiteres CUL, das anstatt per USB per Funk angebunden wird. Nach der Einrichtung empfängt ein RFR CUL zwar sofort und gibt empfangene Commandos auch an FHEM weiter. Das RFR SENDET aber nur, wenn man explizit Geräte mittels IOdev an das RFR koppelt und FHTs zusätzlich auch paired. Dazu muss das RFR auch eine eigene FHT-ID bekommen. Nach erfolgter Konfiguration kann und muss der RFR CUL also wie ein zweiter an den FHEM Host angeschlossener CUL verwendet werden. Die Kommunikation zwischen dem RFR CUL und dem per USB angebundenen CUL erfolgt mit rund 250fach höherem Durchsatz als die SlowRF Kommunikation.

Einrichtung

Es müssen folgende Vorbereitungen getroffen werden:

beiden CULs muss eine sogenannte RFR-ID zugewiesen werden, eine Adresse, mit der die beiden CULs untereinander kommunizieren können.
Zunächst dem direkt angeschlossenem CUL eine RFR-ID geben, dazu fhem Kommando

set MyCUL raw ui0100

absetzen. Dadurch wird dem CUL die ID 01 zugewiesen. Weil die letzten beiden Ziffern "00" sind, sendet dieses CUL seine Kommandos nicht an andere CULs weiter, sondern setzt sie selber ab, bzw kommuniziert per USB mit dem PC.

Dann das als RFR-CUL vorgesehene CUL an den PC anschliessen und seine RFR-ID ebenfalls setzen:

set MyCUL raw ui0201

Dadurch hat das RFR-CUL die RFR-ID 02 und sendet alle seine empfangenen Kommandos an das CUL mit der RFR-ID 01 weiter.

jetzt die CULs erneut tauschen. Das CUL mit der RFR-ID 01 ist wieder am PC angeschlossen.
RFR-CUL mit Strom versorgen (USB Netzteil). Da der zweite Teil der RFR ID nicht "00" ist, weiß das RFR-CUL, dass es ein RFR Gerät ist und versucht nicht über die USB Schnittstelle mit dem PC zu kommunizieren, sondern mit einem anderen CUL mit der RFR-ID 01 über Funk.

Jetzt muss das RFR-CUL für FHEM in der fhem.cfg definiert werden:

define <name> CUL_RFR <own-id> <base-id>

Beispiel:

define MyRFR CUL_RFR 02 01

Die RFR-Übertragung erfolgt im Gegensatz zu den FS20- und FHT-Übertragungen nicht mit 1 kHz, sondern mit 250 kHz und damit einer wesentlich höheren Datenrate.

Die RFR-Übertragung wartet erst auf eine Sendepause, pingt dann den Empfänger (also das jeweils andere CUL) mit wenigen Bits auf 1 kHz an, woraufhin beide auf 250 kHz umschalten und die Daten übertragen. Anschliessend wird auf 1 kHz zurückgeschaltet.

Solange keine Sendepause vorliegt, werden alle empfangenen Daten in einem 64 Byte großen lokalen Puffer geschrieben, dieser ist in den RFR-Rohdaten sichtbar. Obwohl die Übertragung der Daten bei 250 kHz aus Sicht der FHT / FS20 Datenübertragung sehr schnell ist, können sich durch diese Pufferung Probleme bei der Kommunikation zwischen RFR CUL und FHT80 ergeben.

Mehrere RFR CULs

Es ist durchaus möglich mehrere RFR CULs einzusetzen. Diese sind einfach weiter zu Nummerieren:

set MyCUL raw ui0301

und

define MyRFR Noch_ein_CUL_RFR 03 01

Ebenso ist es möglich RFR CULs zu kaskadieren, also ein RFR CUL als Relais zu verwende, anstatt mit dem direkten angeschlossenen CUL zu kommunizieren. Dazu müsste einem CUL bei der Einrichtung

set MyCUL raw ui0302

übermittel werden und die Definiton muss lauten:

define MyRFR Noch_ein_CUL_RFR 03 02

womit es das 3. CUL (id03) im RFR Verbund wäre, aber mit dem anderen RFR CUL (id02) kommuniziert, das dann die Daten an das direkt per USB Verbundene (id01) weiterreicht.

Es ist aber fraglich, ob dies in der Praxis zuverlässig funktioniert, da zum einen die Reaktionszeiten z.b. bei Schaltungen spürbar länger werden und zum anderen sich Unzuverlässigkeiten in der RFR Funkstrecke potenzieren.

Bekannte Probleme

Mittels set MyRFR raw x09 lässt sich die Sendestärke des RFR CULs einstellen. Gültige Werte sind 00-09. Verwendet werden sollten nur die Werte 05-09, diese entsprechen -10/-5/0/5/10 Sendeleistung in db. Default ist x08 = + 5db. Bitte im Interesse von Nachbarn und der Abhörsicherheit kleinsten problemlos funktionierenden Wert einstellen. Dies ist meistens x07 oder x08. Da speziell die Kommunikation mit den FHTs bidirektional ist, kann die Kommunikation durch höhere Werte oft nicht verbessert werden, da die FHTs selber dadurch nicht stärker senden. Besser versuchen, Lage und Antennenausrichtung des CUL zu verändern.
Werte x00-x04 sind MIT Ramping und führen zum Verlust der Kommunikationsfähigkeit mit anderen CULs. Das bedeutet, das eine RFR CUL, den man z.b. mit set myCUL raw x04 auf maximale Sendeleistung mit Ramping einstellt, hinterher nicht mehr remote angesprochen werden kann.
Beim RFR CUL und FHT80 sind Besonderheiten zu beachten, schon beim pairen: FHT mit RFR CUL pairen.
RFR CULs stehen nur für den SlowRF Mode zur Verfügung, also nicht für CULs im HM oder MAX! Betrieb. Unterstützt werden mindestens die FHT, FS20, EM, HMS und S300 Protokolle
RFR hat keinen ACK oder Resend-Mechanismus, daher ist die Verbindung nicht sehr sicher und sollte ggf nicht für "wichtige" Schaltbefehle verwendet werden. (in der Praxis ist die Anbindung jedoch idR. erstaunlich gut und kann mittels RSSI Readings auch gut überwacht werden. Es sollte angestrebt werden einen RSSI von -80 oder besser zum USB-CUL zu erreichen)
FHEM ermittelt selbständig, wenn Befehle doppelt empfangen werden, also vom CUL und kurz dannach vom RFR CUL (Die RFR CUL Befehle kommen immer als zweite, da sie zunächst etwa zeitgleich mit dem CUL empfangen, dann zwischengespeichert und dann an das CUL übertragen werden). Dies wird über ein Zeitintervall ermittelt. Kommt ein Befehl innerhalb einer bestimmten Zeit zweimal bei FHEM an, so wird er nur einmal ausgeführt. Die Zeitspanne, in der ein doppelter Befehl als der Selbe aufgefasst wird, ist auf 0,5 Sekunden voreingestellt. Da neuere Firmwareversionen des RFR CUL länger auf Funkstille warten (um eine eventuell laufende FHT Kommunikation nicht zu unterbrechen), kann diese Zeitspanne zu kurz sein. Sie kann mit der globalen Variabel dupTimeout verändert werden. Details hierzu hier: dubTimeout verändern
Der State des RFR CULs wird in älteren Versionen von FHEM immer als "???" angegeben, dies ist normal. In neueren Versionen von FHEM ist der State zunächst "defined" und sobald der RFR CUL Daten austauscht "0".
Die Abfrage von ccconf mit get MyRFR cconf führt oft zu einem Timeout, obwohl der RFR_CUL ansonsten klaglos arbeitet und andere Abfragen problemlos beantwortet werden.
Frequenz und Bandbreite müssen beim CUL und RFR-CUL identisch oder zumindest deutlich überlappend sein.

Siehe auch

CUL RFR Abschnitt in der commandref/CUL_RFR
FHT mit RFR CUL pairen
Was ist der Hauscode?

@@ Zeile 1: / Zeile 1: @@
-Um die Funkabdeckung von CULs im [[SlowRF]] Modus zu erhöhen, ohne lange USB Kabel oder Netzwerke mit CUNs einsetzen zu müssen, lässt sich ein zweites CUL als RFR (Radio Frequency Router) konfigurieren. Die Verbindung erfolgt hierbei über Funk, so dass keine USB Verbindung zum FHEM-Hostrechner erforderlich ist.
+Um die Funkabdeckung von CULs im [[SlowRF]] Modus zu erhöhen, ohne lange USB Kabel oder Netzwerke mit CUNs einsetzen zu müssen, lässt sich ein zweites (drittes, viertes, ...) CUL als RFR (Radio Frequency Router) konfigurieren. Die Verbindung erfolgt hierbei über Funk, so dass keine USB Verbindung zum FHEM-Hostrechner erforderlich ist.
 == Funktion ==
@@ Zeile 6: / Zeile 6: @@
 Das RFR SENDET aber nur, wenn man explizit Geräte mittels IOdev an das RFR koppelt und [[FHT mit RFR CUL pairen|FHTs zusätzlich auch paired]]. Dazu muss das RFR auch eine eigene FHT-ID bekommen.
 Nach erfolgter Konfiguration kann und muss der RFR CUL also wie ein zweiter an den FHEM Host angeschlossener CUL verwendet werden.
-Die Kommunikation zwischen dem RFR CUL und dem per USB angebundenen CUL erfolgt rund 250fach höherem Durchsatz als die SlowRF Kommunikation.
+Die Kommunikation zwischen dem RFR CUL und dem per USB angebundenen CUL erfolgt mit rund 250fach höherem Durchsatz als die SlowRF Kommunikation.
 == Einrichtung ==
@@ Zeile 36: / Zeile 36: @@
 Solange keine Sendepause vorliegt, werden alle empfangenen Daten in einem 64 Byte großen lokalen Puffer geschrieben, dieser ist in den RFR-Rohdaten sichtbar. Obwohl die Übertragung der Daten bei 250 kHz aus Sicht der FHT / FS20 Datenübertragung sehr schnell ist, können sich durch diese Pufferung Probleme bei der Kommunikation zwischen [[RFR CUL und FHT80]] ergeben.
+== Mehrere RFR CULs ==
+Es ist durchaus möglich mehrere RFR CULs einzusetzen. Diese sind einfach weiter zu Nummerieren:
+ <nowiki>set MyCUL raw ui0301</nowiki>
+und
+ <nowiki>define MyRFR Noch_ein_CUL_RFR 03 01</nowiki>
+Ebenso ist es möglich RFR CULs zu kaskadieren, also ein RFR CUL als Relais zu verwende, anstatt mit dem direkten angeschlossenen CUL zu kommunizieren. Dazu müsste einem CUL bei der Einrichtung
+ <nowiki>set MyCUL raw ui0302</nowiki>
+übermittel werden und die Definiton muss lauten:
+<nowiki>define MyRFR Noch_ein_CUL_RFR 03 02</nowiki>
+womit es das 3. CUL (id03) im RFR Verbund wäre, aber mit dem anderen RFR CUL (id02) kommuniziert, das dann die Daten an das direkt per USB Verbundene (id01) weiterreicht.
+Es ist aber fraglich, ob dies in der Praxis zuverlässig funktioniert, da zum einen die Reaktionszeiten z.b. bei Schaltungen spürbar länger werden und zum anderen sich Unzuverlässigkeiten in der RFR Funkstrecke potenzieren.
 == Bekannte Probleme ==
-* Mittels <code>set MyRFR raw x09</code> lässt sich die Sendestärke des RFR CULs einstellen. Gültige Werte sind 00-09. Verwendet werden sollten nur die Werte 05-09, diese entsprechen -10/-5/0/5/10 Sendeleistung in db. Default ist x08 = + 5db. Bitte im Interesse von Nachbarn und der Abhörsicherheit kleinsten problemlos funktionierenden Wert einstellen. Dies ist meistens x07 oder x08. Da speziell die Kommunikation mit den FHTs bidirektional ist, kann die Kommunikation durch höhere Werte oft nicht verbessert werden, da die FHTs selber dadurch nicht stärker senden. Besser versuchen, Lage und Antennenausrichtung des CUL zu verändern. Siehe auch Diskussion unter [https://groups.google.com/group/cul-fans/browse_thread/thread/683ca5c892eae1c3/c682a640f1ba863c?lnk=gst&amp;q=bWidth+freq#c682a640f1ba863c GoogleGroups-CUL-Fans]
+* Mittels <code>set MyRFR raw x09</code> lässt sich die Sendestärke des RFR CULs einstellen. Gültige Werte sind 00-09. Verwendet werden sollten nur die Werte 05-09, diese entsprechen -10/-5/0/5/10 Sendeleistung in db. Default ist x08 = + 5db. Bitte im Interesse von Nachbarn und der Abhörsicherheit kleinsten problemlos funktionierenden Wert einstellen. Dies ist meistens x07 oder x08. Da speziell die Kommunikation mit den FHTs bidirektional ist, kann die Kommunikation durch höhere Werte oft nicht verbessert werden, da die FHTs selber dadurch nicht stärker senden. Besser versuchen, Lage und Antennenausrichtung des CUL zu verändern.
 * Werte x00-x04 sind MIT Ramping und führen zum Verlust der Kommunikationsfähigkeit mit anderen CULs. Das bedeutet, das eine RFR CUL, den man z.b. mit <code>set myCUL raw x04</code> auf maximale Sendeleistung mit Ramping einstellt, hinterher nicht mehr remote angesprochen werden kann.
 * Beim [[RFR CUL und FHT80]] sind Besonderheiten zu beachten, schon beim pairen: [[FHT mit RFR CUL pairen]].
-* RFR CULs stehen nur für den SlowRF Mode zur Verfügung, also nicht für CULs im HM oder MAX! Betrieb.
+* RFR CULs stehen nur für den SlowRF Mode zur Verfügung, also nicht für CULs im HM oder MAX! Betrieb. Unterstützt werden mindestens die FHT, FS20, EM, HMS und S300 Protokolle
-* FHEM ermittelt selbständig, wenn Befehle doppelt empfangen werden, also vom CUL und kurz dannach vom RFR CUL (Die RFR CUL Befehle kommen immer als zweite, da sie zunächst etwa zeitgleich mit dem CUL empfangen, dann zwischengespeichert und dann an das CUL übertragen werden). Dies wird über ein Zeitintervall ermittelt. Kommt ein Befehl innerhalb einer bestimmten Zeit zweimal bei FHEM an, so wird er nur einmal ausgeführt. Die Zeitspanne, in der ein doppelter Befehl als der Selbe aufgefasst wird, ist auf 0,5 Sekunden voreingestellt. Da neuere Firmwareversionen des RFR CUL länger auf Funkstille warten (um eine eventuell laufende FHT Kommunikation nicht zu unterbrechen), kann diese Zeitspanne zu kurz sein. Sie kann mit der globalen Variabel dupTimeout verändert werden. Details hierzu hier: [http://fhem.de/commandref.html#dupTimeout dubTimeout verändern]
+* RFR hat keinen ACK oder Resend-Mechanismus, daher ist die Verbindung nicht sehr sicher und sollte ggf nicht für "wichtige" Schaltbefehle verwendet werden. (in der Praxis ist die Anbindung jedoch idR. erstaunlich gut und kann mittels RSSI Readings auch gut überwacht werden. Es sollte angestrebt werden einen RSSI von -80 oder besser zum USB-CUL zu erreichen)
-* Der State des RFR CULs wird in älteren Versionen von FHEM immer als "???" angegeben, dies ist normal. In neueren Versionen von FHEM ist der State "defined".
+* FHEM ermittelt selbständig, wenn Befehle doppelt empfangen werden, also vom CUL und kurz dannach vom RFR CUL (Die RFR CUL Befehle kommen immer als zweite, da sie zunächst etwa zeitgleich mit dem CUL empfangen, dann zwischengespeichert und dann an das CUL übertragen werden). Dies wird über ein Zeitintervall ermittelt. Kommt ein Befehl innerhalb einer bestimmten Zeit zweimal bei FHEM an, so wird er nur einmal ausgeführt. Die Zeitspanne, in der ein doppelter Befehl als der Selbe aufgefasst wird, ist auf 0,5 Sekunden voreingestellt. Da neuere Firmwareversionen des RFR CUL länger auf Funkstille warten (um eine eventuell laufende FHT Kommunikation nicht zu unterbrechen), kann diese Zeitspanne zu kurz sein. Sie kann mit der globalen Variabel dupTimeout verändert werden. Details hierzu hier: {{Link2CmdRef|Anker=dupTimeout|Label=dubTimeout verändern}}
-* Die Abfrage von ccconf mit <code>get MyRFR cconf</code> führt meistens zu einem Timeout, obwohl der RFR_CUL ansonsten klaglos arbeitet und andere Abfragen problemlos arbeiten.
+* Der State des RFR CULs wird in älteren Versionen von FHEM immer als "???" angegeben, dies ist normal. In neueren Versionen von FHEM ist der State zunächst "defined" und sobald der RFR CUL Daten austauscht "0".
+* Die Abfrage von ccconf mit <code>get MyRFR cconf</code> führt oft zu einem Timeout, obwohl der RFR_CUL ansonsten klaglos arbeitet und andere Abfragen problemlos beantwortet werden.
+* Frequenz und Bandbreite müssen beim CUL und RFR-CUL identisch oder zumindest deutlich überlappend sein.
 == Siehe auch ==
-* CUL RFR Abschnitt in der Commandref [http://fhem.de/commandref.html#CUL_RFR]
+* CUL RFR Abschnitt in der {{Link2CmdRef|Anker=CUL_RFR}}
 * [[FHT mit RFR CUL pairen]]
 * [[Was ist der Hauscode?]]