RFR CUL - Versionsgeschichte

Soulman: /* Mehrere RFR CULs */

2020-11-11T16:46:44Z

Mehrere RFR CULs

← Nächstältere Version		Version vom 11. November 2020, 18:46 Uhr
Zeile 43:		Zeile 43:
	<nowiki>define MyRFR Noch_ein_CUL_RFR 03 01</nowiki>		<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 ~~z verwednen~~, anstatt mit dem direkten angeschlossenen CUL zu kommunizieren. ~~dazu~~ müsste em CUL bei der Einrichtung
			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>		<nowiki>set MyCUL raw ui0302</nowiki>

	und die ~~Feiniton msste~~ lauten		übermittel werden und die Definiton muss lauten:

	<nowiki>define MyRFR Noch_ein_CUL_RFR 03 02</nowiki>		<nowiki>define MyRFR Noch_ein_CUL_RFR 03 02</nowiki>

	~~übermittelt werden,~~ 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.		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.		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 ==		== Bekannte Probleme ==

Soulman: Ergänzung

2020-11-11T16:45:33Z

Ergänzung

@@ Zeile 42: / Zeile 42: @@
 und
   <nowiki>define MyRFR Noch_ein_CUL_RFR 03 01</nowiki>
 == Bekannte Probleme ==

Soulman: ergänzunen

2018-03-29T20:53:11Z

ergänzunen

← Nächstältere Version		Version vom 29. März 2018, 22:53 Uhr
Zeile 47:		Zeile 47:
	* 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.		* 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]].		* 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
			* 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: {{Link2CmdRef\|Anker=dupTimeout\|Label=dubTimeout verändern}}		* 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}}
	* 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".		* 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 ~~meistens~~ zu einem Timeout, obwohl der RFR_CUL ansonsten klaglos arbeitet und andere Abfragen problemlos beantwortet werden.		* 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 ==		== Siehe auch ==

Soulman: /* Einrichtung */ Ergänzung

2018-03-29T20:30:08Z

Einrichtung: Ergänzung

← Nächstältere Version		Version vom 29. März 2018, 22:30 Uhr
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.		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>

	== Bekannte Probleme ==		== Bekannte Probleme ==

Soulman: /* Funktion */

2018-03-29T20:26:45Z

Funktion

← Nächstältere Version		Version vom 29. März 2018, 22:26 Uhr
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.		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.		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 ==		== Einrichtung ==

Soulman am 29. März 2018 um 20:26 Uhr

2018-03-29T20:26:03Z

← Nächstältere Version		Version vom 29. März 2018, 22:26 Uhr
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 ==		== Funktion ==

Baumbuwe: typo

2018-01-31T12:33:14Z

typo

← Nächstältere Version		Version vom 31. Januar 2018, 14:33 Uhr
Zeile 47:		Zeile 47:

	== Siehe auch ==		== Siehe auch ==
	* CUL RFR Abschnitt in der {{~~Link2Cmdref~~\|Anker=CUL_RFR}}		* CUL RFR Abschnitt in der {{Link2CmdRef\|Anker=CUL_RFR}}
	* [[FHT mit RFR CUL pairen]]		* [[FHT mit RFR CUL pairen]]
	* [[Was ist der Hauscode?]]		* [[Was ist der Hauscode?]]

Baumbuwe: Vorlage Link2Cmdref

2018-01-31T12:08:16Z

Vorlage Link2Cmdref

← Nächstältere Version		Version vom 31. Januar 2018, 14:08 Uhr
Zeile 42:		Zeile 42:
	* Beim [[RFR CUL und FHT80]] sind Besonderheiten zu beachten, schon beim pairen: [[FHT mit RFR CUL pairen]].		* 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.
	* 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]		* 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}}
	* 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".		* 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 meistens zu einem Timeout, obwohl der RFR_CUL ansonsten klaglos arbeitet und andere Abfragen problemlos beantwortet werden.		* 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 beantwortet werden.

	== Siehe auch ==		== 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]]		* [[FHT mit RFR CUL pairen]]
	* [[Was ist der Hauscode?]]		* [[Was ist der Hauscode?]]

Soulman: /* Bekannte Probleme */ Link auf nur noch teilweise erreichbar 8 Jahre alte Diskussion entfernt

2017-09-16T01:16:07Z

Bekannte Probleme: Link auf nur noch teilweise erreichbar 8 Jahre alte Diskussion entfernt

← Nächstältere Version		Version vom 16. September 2017, 03:16 Uhr
Zeile 38:		Zeile 38:

	== Bekannte Probleme ==		== 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&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.		* 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]].		* Beim [[RFR CUL und FHT80]] sind Besonderheiten zu beachten, schon beim pairen: [[FHT mit RFR CUL pairen]].

Soulman: /* Bekannte Probleme */

2017-09-16T01:12:40Z

Bekannte Probleme

← Nächstältere Version		Version vom 16. September 2017, 03:12 Uhr
Zeile 43:		Zeile 43:
	* 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.
	* 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]		* 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]
	* 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".		* 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 meistens zu einem Timeout, obwohl der RFR_CUL ansonsten klaglos arbeitet und andere Abfragen problemlos ~~arbeiten~~.		* 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 beantwortet werden.

	== Siehe auch ==		== Siehe auch ==