RFR CUL

Aus FHEMWiki

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.

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 250kBaud, also mit einem 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.

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. Siehe auch Diskussion unter GoogleGroups-CUL-Fans
  • 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.
  • 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 "defined".
  • Die Abfrage von ccconf mit get MyRFR cconf führt meistens zu einem Timeout, obwohl der RFR_CUL ansonsten klaglos arbeitet und andere Abfragen problemlos arbeiten.

Siehe auch

Abgerufen von „http://wiki.fhem.de/w/index.php?title=RFR_CUL&oldid=10817“