RFR CUL und FHT80

Der Einsatz eines RFR CUL zur Reichweitenverlängerung ist bei FS20 Devices unproblematisch, da leichte Verzögerungen in der Kommunikation keine nachteiligen Folgen haben. Die bidirectionale Kommunikation mit FHT80b Devices kann jedoch zu Problemen führen, da hier das Timing entscheidend ist.

Herausforderungen der FHT Kommunikation an RFR CULs

Die CUL/FHZ <-> FHT Kommunikation ist sehr fragil und braucht für die Übermittlung von N Werten etwa 5+N ungestörte Nachrichtenübermittlungen - abwechselnd von beiden Teilnehmer - mit der langsamen 1kHz Technik. Falls während dieser langen "Diskussion" eine Nachricht nicht klar empfangen wird, dann wird der gesamte Austausch in ca. 2 Minuten wiederholt. Dies schränkt bereits im Normalbetrieb die Anzahl der Maximal nutzbare Geräte (insbesondere FHT80) deutlich ein.

Nur falls ein Austausch komplett abgearbeitet ist, kommt der nächste Austausch aus dem CUL Puffer (T02) dran.

Auf der anderen Seite ist die RFR CUL Übertragung, die erst auf eine Sendepause wartet, bevor auf 250kHz umgeschaltet wird und die Daten zwischen den CULs übertragen werden. Dem RFR Code ist aber nicht bekannt, dass eine FHT-Übertragung unterwegs ist. Er kann daher in kleinen Sendepausen während einer FHT Kommunikation umschalten, um in den Pausen die Kommunikation vom RFR zum CUL abzuwickeln. Dadurch kann es zu Verzögerungen bei der Kommunikation mit dem FHT80 kommen, die zum Abbruch führen. Die Kommunikation wird dann ca. 2 Minuten später wiederholt. Solange keine Sendepause vorliegt, werden alle empfangenen Daten in einem 64 Byte grossen lokalen Puffer geschrieben.

Lösung ab CULfw 1.45

Seit Firmware Version 1.45 (2012-07-11) versucht das RFR jedoch eine laufende FHT Kommunikation zu erkennen und solange einen RFR Kommunikation zu unterbinden.

Im Detail: RFR sendet erst, wenn "rf_isreceiving" 2-mal im Abstand von 24ms Stille meldet.

Seit Version 1.45 wurde die Prüfung erweitert. "rf_isreceiving" prüft nun zusätzlich, ob das FHT Modul auf Daten wartet: (fht80b_timeout != FHT_TIMER_DISABLED) fht80b_timeout wird beim Empfang eines FHT Telegramms mit 41 (== 328ms) initialisiert, auch wenn FHT in CUL deaktiviert ist.

Dadurch sollte erkannt werden, ob eine laufende FHT Communikation stattfindet, die nicht unterbrochen werden sollte.

Diese Methode wurde in späteren CULfw Versionen noch verfeinert.

Lösungsansätze vor CULfw 1.45

Es ist erfahrungsgemäss durchaus möglich, auch mit Firmware vor 1.45 FHTs an einem RFR CUL zu betreiben, es wird jedoch häufiger zu Problemen mit Verbindungsabbrüchen kommen. Problematisch sind insbesondere längere Kommunikationen mit FHTs wie z.b. die Übertragung von Wochenprogrammen. Dies sollte also vermieden werden.

Besonders problematisch sind die diversen Methoden, die FHTs regelmässig zum Senden der Temperaturdaten zu bewegen. Bekanntermassen stellen die FHTs nach 5-10 Tagen das Übermitteln von Daten ein. Zum "Aufrischen" der Kommunikation werden verschiedene Tips gehandelt:

• 1. Methode: Täglich ein

define fht_report at +*06:00:00 set <name> report1 255 report2 255

abzusetzen. (Alternativ "refreshvalues", was die selbe Bedeutung hat). Dies erzeugt jedoch eine nicht unerhebliche Funklast und lange Kommunikationen, ca. 8 Nutznachrichtenübermittlungen (plus 5 Nachrichtenübermittlung bei der Kommunikationsanbahnung) zwischen FHT80 und dem CUL sind notwendig. Bei der Kommunikation mit einem RFR CUL ist die Wahrscheinlichkeit einer Störung hoch.

• 2. Methode: Jede Nacht mit

set ... time

die FHT: Datum und Zeit von fhem setzen lassen Dies kann bei vielen FHTs die als IOdev eine RFR CUL haben problematisch sein.

Eine Reduzierung der Funklast kann erreicht werden, in dem mittels report1/2 nur der tatsächliche Bitwert der benötigten Informationen angefordert werden, insbesondere das Wochenprogramm (report1 = 255) ändert sich idR. selten und wird meist nicht regelmässig benötigt. Ausserdem kann es sinnvoll sein, die Werte nur alle 5 oder 7 Tage anzufordern (bzw die Uhr nur alle 5-7 Tage zu stellen), und für verschiedene FHTs zeitlich versetzt, um die Wahrscheinlickeit sich kreuzender Kommunikation zu reduzieren.

• 3. Methode: Einrichtung eines Watchdog ("Wachundes") mit

define wd_FHT1 watchdog FHT1:measured-temp.* 01:00 SAME set FHT1 time

Der Watchdog überprüft, ob die alle 15 Minute gesendeten Temperaturmeldungen eintreffen. Falls nicht setzt er die Uhrzeit des FHT um ihn so wieder zur Kommunikation anzuregen.