RFR CUL und FHT80 - Versionsgeschichte

Soulman: /* Lösung ab CULfw 1.45 */

2017-09-16T01:18:02Z

Lösung ab CULfw 1.45

← Nächstältere Version		Version vom 16. September 2017, 03:18 Uhr
Zeile 25:		Zeile 25:
	Dadurch sollte erkannt werden, ob eine laufende FHT Communikation stattfindet, die nicht unterbrochen werden sollte.		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 ==		== Lösungsansätze vor CULfw 1.45 ==

Soulman: /* Lösungsansätze vor CULfw 1.45 */

2014-01-02T23:37:36Z

Lösungsansätze vor CULfw 1.45

← Nächstältere Version		Version vom 3. Januar 2014, 01:37 Uhr
Zeile 28:		Zeile 28:

	== Lösungsansätze vor CULfw 1.45 ==		== 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.		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:		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:

Soulman: /* Lösungsansätze vor CULfw 1.45 */

2014-01-02T23:36:56Z

Lösungsansätze vor CULfw 1.45

← Nächstältere Version		Version vom 3. Januar 2014, 01:36 Uhr
Zeile 28:		Zeile 28:

	== Lösungsansätze vor CULfw 1.45 ==		== 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.		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.

	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:		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:

Soulman: /* Herausforderungen der FHT Kommunikation an RFR CULs */

2013-05-28T12:23:43Z

Herausforderungen der FHT Kommunikation an RFR CULs

← Nächstältere Version		Version vom 28. Mai 2013, 14:23 Uhr
Zeile 3:		Zeile 3:

	== Herausforderungen der FHT Kommunikation an RFR CULs ==		== Herausforderungen der FHT Kommunikation an RFR CULs ==
	Die CUL/FHZ ~~<~~-~~>~~ FHT [[~~Maximal nutzbare Geräte~~]] 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.		Die CUL/FHZ <-> FHT [[Maximal_nutzbare_SlowRF_Geräte#detailierte_Betrachtung\|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.		Dies schränkt bereits im Normalbetrieb die Anzahl der [[Maximal nutzbare Geräte]] (insbesondere FHT80) deutlich ein.

Soulman am 28. Mai 2013 um 12:21 Uhr

2013-05-28T12:21:01Z

← Nächstältere Version		Version vom 28. Mai 2013, 14:21 Uhr
Zeile 1:		Zeile 1:
	Der Einsatz eines [[FHT80b]] Devices kann jedoch zu Problemen führen, da hier das Timing entscheidend ist.		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 ==		== Herausforderungen der FHT Kommunikation an RFR CULs ==

Soulman am 11. Mai 2013 um 19:01 Uhr

2013-05-11T19:01:38Z

← Nächstältere Version		Version vom 11. Mai 2013, 21:01 Uhr
Zeile 45:		Zeile 45:
	<nowiki>define wd_FHT1 watchdog FHT1:measured-temp.* 01:00 SAME set FHT1 time</nowiki>		<nowiki>define wd_FHT1 watchdog FHT1:measured-temp.* 01:00 SAME set FHT1 time</nowiki>
	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.		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.


			[[Kategorie:CUL]]

Generix: Die Seite wurde neu angelegt: „Der Einsatz eines FHT80b Devices kann jedoch zu Problemen führen, da hier das Timing entscheidend ist. == Herausforderungen der FHT Kommunikation an RFR …“

2013-05-10T20:51:36Z

Die Seite wurde neu angelegt: „Der Einsatz eines FHT80b Devices kann jedoch zu Problemen führen, da hier das Timing entscheidend ist. == Herausforderungen der FHT Kommunikation an RFR …“

Neue Seite

Der Einsatz eines [[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 [[Maximal nutzbare Geräte]] 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.

== 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.

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
<nowiki>define fht_report at +*06:00:00 set <name> report1 255 report2 255</nowiki>
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
<nowiki>set ... time</nowiki>
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
<nowiki>define wd_FHT1 watchdog FHT1:measured-temp.* 01:00 SAME set FHT1 time</nowiki>
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.