Kommunikationsprobleme mit FHT - Versionsgeschichte

AndreasMohr: Typos/Spelling

2019-02-17T19:18:40Z

Typos/Spelling

AndreasMohr: Typos/Spelling

2018-11-18T18:14:08Z

Typos/Spelling

AndreasMohr: Typos/Spelling

2018-02-06T21:17:20Z

Typos/Spelling

Soulman: Hinweis auf abkündigung

2018-01-14T20:38:43Z

Hinweis auf abkündigung

← Nächstältere Version		Version vom 14. Januar 2018, 22:38 Uhr
Zeile 1:		Zeile 1:
	Während FHEM mit reinen Schaltaktoren in der Regel problemarm funktioniert, sind Probleme mit [[FHT80b]] Heizungsteuerungen recht häufig. Dies liegt in der deutlich anspruchsvolleren bidirektionalen Kommunikation, die zur Übermittlung der ggf. durchaus umfangreichen Daten notwendig ist.		{{Randnotiz\|RNTyp=y\|RNText=Das FHT System ist seit 2017 abgekündigt. Vom Hersteller sind keine Neugeräte mehr erhältlich. Es ist daher zu überlegen, fehlerhafte FHTs durch andere von FHEM unterstütze Systeme zu ersetzen, z.b. MAX oder HomeMatic. Parallelbetrieb ist mit zusätzlicher Schnittstelle möglich.}}Während FHEM mit reinen Schaltaktoren in der Regel problemarm funktioniert, sind Probleme mit [[FHT80b]] Heizungsteuerungen recht häufig. Dies liegt in der deutlich anspruchsvolleren bidirektionalen Kommunikation, die zur Übermittlung der ggf. durchaus umfangreichen Daten notwendig ist.

Soulman: /* Repairen */

2018-01-14T20:20:54Z

Repairen

← Nächstältere Version		Version vom 14. Januar 2018, 22:20 Uhr
Zeile 112:		Zeile 112:
	'''Wichtig: vor dem Repairen FHT Buffer des zuständigen CULs löschen, z.b. durch kurz Stromlos machen oder den Befehl "set CUL raw T01 <CUL-ID>" senden.''' Damit werden ggf für dieses FHT bereits aufgestaute Kommandos entfernt.		'''Wichtig: vor dem Repairen FHT Buffer des zuständigen CULs löschen, z.b. durch kurz Stromlos machen oder den Befehl "set CUL raw T01 <CUL-ID>" senden.''' Damit werden ggf für dieses FHT bereits aufgestaute Kommandos entfernt.

	~~====Neues~~ Pairen ~~ohne Autocreate====~~		Zum neuen Pairen wie folgt vorgehen:
	*fhem.cfg unbearbeitet lassen
	*FHT80b in Sonderfunktionen "cENT" auf "n/a" stellen, Sonderfunktionen am FHT80 verlassen, danach sofort in FHEM einen Befehl (egal welchen) an die FHT80b senden.		*FHT80b in Sonderfunktionen "cENT" auf "n/a" stellen, Sonderfunktionen am FHT80 verlassen, danach sofort in FHEM einen Befehl (egal welchen) an die FHT80b senden.
	*Wenn ca. zwei Minuten später Sonderfunktion cENT auf "ON" steht und/oder der Befehl ausgeführt wurde, war das Pairing erfolgreich.		*Wenn ca. zwei Minuten später Sonderfunktion cENT auf "ON" steht und/oder der Befehl ausgeführt wurde, war das Pairing erfolgreich.

	Machmal hilft es, das FHT zusätzlich vorher stromlos zu machen: Batterien raus, 2 Minuten warten (wichtig), Batterien wieder einsetzen.		Machmal hilft es, das FHT zusätzlich vorher stromlos zu machen: Batterien raus, 2 Minuten warten (wichtig), Batterien wieder einsetzen.

	~~====Neues Pairing mit Autocreate====~~
	~~Alternativ hat auch dieser Weg zum Erfolg geführt:~~
	*In der fhem.cfg den define-Eintrag für diesen FHT auskommentieren, autocreate ggf. einschalten, sichern.
	*Am FHT80b in Sonderfunktionen "cENT" auf "n/a" stellen, sodass eine neue Paarung eingeleitet wird
	*Warten bis FHEM nach Empfang eines Datenpaktes vom FHT80 das Geräte anlegt. In der nach dem erfolgten autocreate entstehenden Log-Datei nachsehen, warten, bis der angeblich neu entdeckte FHT das erste Mal seinen Status sendet.
	*Wieder die fhem.cfg editieren, darin den "neu entdeckten" FHT löschen und die oben erfolgte Auskommentierung wieder rückgängig machen, autocrate ggf wieder auschalten, sichern.

	=== provisorische Linderung ===		=== provisorische Linderung ===

Soulman am 14. Januar 2018 um 20:19 Uhr

2018-01-14T20:19:33Z

← Nächstältere Version		Version vom 14. Januar 2018, 22:19 Uhr
Zeile 116:		Zeile 116:
	*FHT80b in Sonderfunktionen "cENT" auf "n/a" stellen, Sonderfunktionen am FHT80 verlassen, danach sofort in FHEM einen Befehl (egal welchen) an die FHT80b senden.		*FHT80b in Sonderfunktionen "cENT" auf "n/a" stellen, Sonderfunktionen am FHT80 verlassen, danach sofort in FHEM einen Befehl (egal welchen) an die FHT80b senden.
	*Wenn ca. zwei Minuten später Sonderfunktion cENT auf "ON" steht und/oder der Befehl ausgeführt wurde, war das Pairing erfolgreich.		*Wenn ca. zwei Minuten später Sonderfunktion cENT auf "ON" steht und/oder der Befehl ausgeführt wurde, war das Pairing erfolgreich.

			Machmal hilft es, das FHT zusätzlich vorher stromlos zu machen: Batterien raus, 2 Minuten warten (wichtig), Batterien wieder einsetzen.

	====Neues Pairing mit Autocreate====		====Neues Pairing mit Autocreate====

Soulman: /* Hardware defekt? */

2018-01-14T20:17:52Z

Hardware defekt?

← Nächstältere Version		Version vom 14. Januar 2018, 22:17 Uhr
Zeile 129:		Zeile 129:
	== Hardware defekt? ==		== Hardware defekt? ==
	Es gibt auch defekte FHT80b, aber oft hilft eine geringe Aufweitung der Bandbreite (siehe oben) oder schlicht eine neuer Satz Batterien. Manchmal führt auch ein "matchen" der FHTs mit der Funklage zum Ziel: Rausfinden, welche FHTs am problemlosesten arbeiten und diese an den Stellen unterbringen, die funktechnisch die ungünstigsten sind, während weniger zuverlässige FHTs näher an der Zentrale eingesetzt werden. Aufgrund der recht primitiven Sender/Empfänger (Pendelempfänger) der FHTs sind hier durchaus deutliche Streuungen möglich.		Es gibt auch defekte FHT80b, aber oft hilft eine geringe Aufweitung der Bandbreite (siehe oben) oder schlicht eine neuer Satz Batterien. Manchmal führt auch ein "matchen" der FHTs mit der Funklage zum Ziel: Rausfinden, welche FHTs am problemlosesten arbeiten und diese an den Stellen unterbringen, die funktechnisch die ungünstigsten sind, während weniger zuverlässige FHTs näher an der Zentrale eingesetzt werden. Aufgrund der recht primitiven Sender/Empfänger (Pendelempfänger) der FHTs sind hier durchaus deutliche Streuungen möglich.
			Mitunter können Probleme auch gelöst werden, in dem das FHT Stromlos gemacht wird: Batterien raus, 2 Minuten warten (wichtig), Batterien wieder einsetzen.

	== Weiterführende Artikel ==		== Weiterführende Artikel ==

Soulman: /* provisorische Lösung */

2017-09-24T13:28:02Z

provisorische Lösung

← Nächstältere Version		Version vom 24. September 2017, 15:28 Uhr
Zeile 124:		Zeile 124:
	*Wieder die fhem.cfg editieren, darin den "neu entdeckten" FHT löschen und die oben erfolgte Auskommentierung wieder rückgängig machen, autocrate ggf wieder auschalten, sichern.		*Wieder die fhem.cfg editieren, darin den "neu entdeckten" FHT löschen und die oben erfolgte Auskommentierung wieder rückgängig machen, autocrate ggf wieder auschalten, sichern.

	=== provisorische ~~Lösung~~ ===		=== provisorische Linderung ===
	Als schnelle Notlösung kann es auch helfen, den FHT Buffer der Funkschnittstelle regelmäßig zu leeren. Beim CUL lässt sich das durch den Befehl "'''set CUL raw T01 <CUL-ID>'''" (löscht nur den FHT Buffer) oder "'''set CUL raw B00'''" (resettet das CUL komplett, auch Funkkontingent wird neu gestartet) bewerkstelligen, den man z.b. jede Nacht absetzen kann. Dies hilft nicht bei FHTs mit denen es Kommunikationsprobleme gibt, lindert aber die daraus resultierenden Probleme anderer FHTs oder gar die Kommunikation mit anderen Protokollen wie FS20, falls aufgestaute Befehlswarteschlangen das Funkkontingent verbrauchen. Grundsätzlich verdeckt diese Notlösung das Problem aber nur und kann eine echte Analyse und Lösung nicht ersetzen.		Als schnelle Notlösung kann es auch helfen, den FHT Buffer der Funkschnittstelle regelmäßig zu leeren. Beim CUL lässt sich das durch den Befehl "'''set CUL raw T01 <CUL-ID>'''" (löscht nur den FHT Buffer) oder "'''set CUL raw B00'''" (resettet das CUL komplett, auch Funkkontingent wird neu gestartet) bewerkstelligen, den man z.b. jede Nacht absetzen kann. Dies hilft nicht bei FHTs mit denen es Kommunikationsprobleme gibt, lindert aber die daraus resultierenden Probleme anderer FHTs oder gar die Kommunikation mit anderen Protokollen wie FS20, falls aufgestaute Befehlswarteschlangen das Funkkontingent verbrauchen. Grundsätzlich verdeckt diese Notlösung das Problem aber nur und kann eine echte Analyse und Lösung nicht ersetzen.

Soulman: /* Diagnose und Lösungsansätze */

2017-09-24T13:27:32Z

Diagnose und Lösungsansätze

← Nächstältere Version		Version vom 24. September 2017, 15:27 Uhr
Zeile 123:		Zeile 123:
	*Warten bis FHEM nach Empfang eines Datenpaktes vom FHT80 das Geräte anlegt. In der nach dem erfolgten autocreate entstehenden Log-Datei nachsehen, warten, bis der angeblich neu entdeckte FHT das erste Mal seinen Status sendet.		*Warten bis FHEM nach Empfang eines Datenpaktes vom FHT80 das Geräte anlegt. In der nach dem erfolgten autocreate entstehenden Log-Datei nachsehen, warten, bis der angeblich neu entdeckte FHT das erste Mal seinen Status sendet.
	*Wieder die fhem.cfg editieren, darin den "neu entdeckten" FHT löschen und die oben erfolgte Auskommentierung wieder rückgängig machen, autocrate ggf wieder auschalten, sichern.		*Wieder die fhem.cfg editieren, darin den "neu entdeckten" FHT löschen und die oben erfolgte Auskommentierung wieder rückgängig machen, autocrate ggf wieder auschalten, sichern.

			=== provisorische Lösung ===
			Als schnelle Notlösung kann es auch helfen, den FHT Buffer der Funkschnittstelle regelmäßig zu leeren. Beim CUL lässt sich das durch den Befehl "'''set CUL raw T01 <CUL-ID>'''" (löscht nur den FHT Buffer) oder "'''set CUL raw B00'''" (resettet das CUL komplett, auch Funkkontingent wird neu gestartet) bewerkstelligen, den man z.b. jede Nacht absetzen kann. Dies hilft nicht bei FHTs mit denen es Kommunikationsprobleme gibt, lindert aber die daraus resultierenden Probleme anderer FHTs oder gar die Kommunikation mit anderen Protokollen wie FS20, falls aufgestaute Befehlswarteschlangen das Funkkontingent verbrauchen. Grundsätzlich verdeckt diese Notlösung das Problem aber nur und kann eine echte Analyse und Lösung nicht ersetzen.

	== Hardware defekt? ==		== Hardware defekt? ==

Soulman: /* Repairen */

2017-09-24T13:15:53Z

Repairen

← Nächstältere Version		Version vom 24. September 2017, 15:15 Uhr
Zeile 110:		Zeile 110:
	Wiederkehrende Actuator-Meldung "'''unknown_69'''" lassen sich z.b. meist mit einem neuen Pairing lösen.		Wiederkehrende Actuator-Meldung "'''unknown_69'''" lassen sich z.b. meist mit einem neuen Pairing lösen.

	'''Wichtig: vor dem Repairen FHT Buffer des zuständigen CULs löschen, z.b. durch kurz Stromlos machen oder den Befehl "set CUL raw T01 <CUL-ID>" senden.'''Damit werden ggf für dieses FHT bereits aufgestaute Kommandos entfernt.		'''Wichtig: vor dem Repairen FHT Buffer des zuständigen CULs löschen, z.b. durch kurz Stromlos machen oder den Befehl "set CUL raw T01 <CUL-ID>" senden.''' Damit werden ggf für dieses FHT bereits aufgestaute Kommandos entfernt.

	====Neues Pairen ohne Autocreate====		====Neues Pairen ohne Autocreate====

← Nächstältere Version		Version vom 18. November 2018, 20:14 Uhr
Zeile 1:		Zeile 1:
	{{Randnotiz\|RNTyp=y\|RNText=Das FHT System ist seit 2017 abgekündigt. Vom Hersteller sind keine Neugeräte mehr erhältlich. Es ist daher zu überlegen, fehlerhafte FHTs durch andere von FHEM unterstützte Systeme zu ersetzen, z.b. MAX oder HomeMatic. Parallelbetrieb ist mit zusätzlicher Schnittstelle möglich.}}Während FHEM mit reinen Schaltaktoren in der Regel problemarm funktioniert, sind Probleme mit [[FHT80b]] Heizungssteuerungen recht häufig. Dies liegt in der deutlich anspruchsvolleren bidirektionalen Kommunikation, die zur Übermittlung der ggf. durchaus umfangreichen Daten notwendig ist.		{{Randnotiz\|RNTyp=y\|RNText=Das FHT System ist seit 2017 abgekündigt. Vom Hersteller sind keine Neugeräte mehr erhältlich. Es ist daher zu überlegen, fehlerhafte FHTs durch andere von FHEM unterstützte Systeme zu ersetzen, z.B. MAX oder HomeMatic. Parallelbetrieb ist mit zusätzlicher Schnittstelle möglich.}}Während FHEM mit reinen Schaltaktoren in der Regel problemarm funktioniert, sind Probleme mit [[FHT80b]] Heizungssteuerungen recht häufig. Dies liegt in der deutlich anspruchsvolleren bidirektionalen Kommunikation, die zur Übermittlung der ggf. durchaus umfangreichen Daten notwendig ist.


Zeile 44:		Zeile 44:
	Da die Ausnutzung der freien Funkzeit jede Situation schnell deutlich verschlimmert, sollte man immer bemüht sein, seine Ziele mit wenig Datenverkehr zu erreichen. Dies gilt insbesondere, wenn man sich der Anzahl [[Maximal nutzbare Geräte]] nähert.		Da die Ausnutzung der freien Funkzeit jede Situation schnell deutlich verschlimmert, sollte man immer bemüht sein, seine Ziele mit wenig Datenverkehr zu erreichen. Dies gilt insbesondere, wenn man sich der Anzahl [[Maximal nutzbare Geräte]] nähert.

	* [[Heizung_mit_Bewegungsmelder_steuern#FHT80b\|FHT Lazy Mode]] nutzen (Temperaturänderungen werden nur übertragen, wenn sie von der momentan eingestellten Temperatur abweichen.) Dies ist besonders hilfreich, wenn die Temperatursteuerung automatisiert durch Bewegungsmelder oder "Zuhausestatus"-Automatismen gesteuert wird, da hier in relativ kurzer Folge die selbe Temperatureinstellung übermittelt wird. Lazy Mode schützt aber nicht immer davor, dass die Warteschlange schnell anschwillt. Steht ein FHT80b z.b. auf 18 Grad, und soll auf 20 Grad angehoben werden, wenn ein Bewegungsmelder auslöst, so wird das Kommando trotz Lazy Mode immer wieder bei Bewegungsmelderauslösung in die Warteschlange eingetragen, solange das erste Kommando nicht erfolgreich abgesetzt und die neue Temperatur vom FHT rückgemeldet wurde. Das kann dazu führen, dass die FHT-Warteschlange dutzende Male das selbe "desired-temp" Kommando enthält. Wenn die Kommandos in der Warteschlange sind, gibt es keine Instanz mehr, die bemerken könnte, dass die nachfolgenden Kommandos überflüssig sind: Es wird gnadenlos versucht, alles zu senden. Lazy Mode wirkt auch bei set date oder set time (Stunde).		* [[Heizung_mit_Bewegungsmelder_steuern#FHT80b\|FHT Lazy Mode]] nutzen (Temperaturänderungen werden nur übertragen, wenn sie von der momentan eingestellten Temperatur abweichen.) Dies ist besonders hilfreich, wenn die Temperatursteuerung automatisiert durch Bewegungsmelder oder "Zuhausestatus"-Automatismen gesteuert wird, da hier in relativ kurzer Folge die selbe Temperatureinstellung übermittelt wird. Lazy Mode schützt aber nicht immer davor, dass die Warteschlange schnell anschwillt. Steht ein FHT80b z.B. auf 18 Grad, und soll auf 20 Grad angehoben werden, wenn ein Bewegungsmelder auslöst, so wird das Kommando trotz Lazy Mode immer wieder bei Bewegungsmelderauslösung in die Warteschlange eingetragen, solange das erste Kommando nicht erfolgreich abgesetzt und die neue Temperatur vom FHT rückgemeldet wurde. Das kann dazu führen, dass die FHT-Warteschlange dutzende Male das selbe "desired-temp" Kommando enthält. Wenn die Kommandos in der Warteschlange sind, gibt es keine Instanz mehr, die bemerken könnte, dass die nachfolgenden Kommandos überflüssig sind: Es wird gnadenlos versucht, alles zu senden. Lazy Mode wirkt auch bei set date oder set time (Stunde).

	* Temperatursteuerung der FHTs nicht durch tägliche Änderung der Wochenprogramme im FHT durchführen. Obwohl diese Methode den Vorteil hat, dass sie eine höhere Ausfallsicherheit bietet (weil die FHTs auch ohne FHEM ihr zuletzt eingegebenes Wochenprogamm weiter verwenden können), so steigt der auszutauschende Datenverkehr stark an.		* Temperatursteuerung der FHTs nicht durch tägliche Änderung der Wochenprogramme im FHT durchführen. Obwohl diese Methode den Vorteil hat, dass sie eine höhere Ausfallsicherheit bietet (weil die FHTs auch ohne FHEM ihr zuletzt eingegebenes Wochenprogamm weiter verwenden können), so steigt der auszutauschende Datenverkehr stark an.
Zeile 53:		Zeile 53:
	:Diese werden schneller abgearbeitet als entsprechende Einzelkommandos.		:Diese werden schneller abgearbeitet als entsprechende Einzelkommandos.

	* Zeitlich unkritische Kommandos (z.b. Setzen des Datums) spät nachts durchführen, wo das Sendekontingent unbelastet ist.		* Zeitlich unkritische Kommandos (z.B. Setzen des Datums) spät nachts durchführen, wo das Sendekontingent unbelastet ist.

	* Keine regelmässigen Reports abfragen, insbesondere NICHT report1=255 (also komplettes Wochenprogramm abfragen)		* Keine regelmässigen Reports abfragen, insbesondere NICHT report1=255 (also komplettes Wochenprogramm abfragen)
Zeile 64:		Zeile 64:
	* RSSI mitloggen:		* RSSI mitloggen:
	:<code>attr CUL addvaltrigger 1</code>		:<code>attr CUL addvaltrigger 1</code>
	* RSSI der FHTs beobachten. Unter -85 (also z.b. -89) ist ungünstig. Unbedingt versuchen, ein besseres RSSI als -85 hinzubekommen, zu ALLEN FHTs.		* RSSI der FHTs beobachten. Unter -85 (also z.B. -89) ist ungünstig. Unbedingt versuchen, ein besseres RSSI als -85 hinzubekommen, zu ALLEN FHTs.
	* Antennnenlage des CUL/CUN korrigieren (z.b. Antenne um 45 Grad kippen), eventuell Lage des FHTs ändern, ein halber Meter kann schon viel bringen. Dabei kommt es nicht zwingend nur auf die absolute Entfernung zum Funkadapter an, auch die Lage im Gebäude kann viel ausmachen.		* Antennnenlage des CUL/CUN korrigieren (z.B. Antenne um 45 Grad kippen), eventuell Lage des FHTs ändern, ein halber Meter kann schon viel bringen. Dabei kommt es nicht zwingend nur auf die absolute Entfernung zum Funkadapter an, auch die Lage im Gebäude kann viel ausmachen.
	* Wenn CUL / CUN eingesetzt werden, gegebenenfalls die Parameter freq, bandwidth und sens ändern. Als Startpunkt z.B. bandwidth auf 464 kHz und sens auf 8 dB anstelle 4dB ändern. Kombinationen ausprobieren, aber nicht mehrere Parameter gleichzeitig ändern. RSSI-Auswirkung jeder Änderung beobachten.		* Wenn CUL / CUN eingesetzt werden, gegebenenfalls die Parameter freq, bandwidth und sens ändern. Als Startpunkt z.B. bandwidth auf 464 kHz und sens auf 8 dB anstelle 4dB ändern. Kombinationen ausprobieren, aber nicht mehrere Parameter gleichzeitig ändern. RSSI-Auswirkung jeder Änderung beobachten.

	Wenn das keinen Erfolg bringt, zweiten CUL / CUNO einsetzen, z.b. auch als RFR CUL. Dabei [[RFR CUL und FHT80]] Besonderheiten berücksichtigen: Nicht zu viele FHTs ans RFR CUL anbinden, nur so viele wie gerade nötig. FS20 Repeater helfen nicht.		Wenn das keinen Erfolg bringt, zweiten CUL / CUNO einsetzen, z.B. auch als RFR CUL. Dabei [[RFR CUL und FHT80]] Besonderheiten berücksichtigen: Nicht zu viele FHTs ans RFR CUL anbinden, nur so viele wie gerade nötig. FS20 Repeater helfen nicht.

	=== Einstellungen prüfen ===		=== Einstellungen prüfen ===
Zeile 86:		Zeile 86:

	=== Diagnosemöglichkeiten im Fehlerfall ===		=== Diagnosemöglichkeiten im Fehlerfall ===
	Eine Möglichkeit, sich dem Problem zu nähern ist, das Logfile mit verbose5 anzeigen zu lassen. Die Meldungen sind dann recht detailliert und lassen einige Rückschlüsse zu. Erfahrungsgemäß ist es jedoch besser, sich die Kommunikation mit einer Telnetsitzung anzusehen. Ein Nachteil des Logfiles liegt z.B. darin, dass eine Temperaturänderung als "ausgeführt" angezeigt wird, wenn sie erfolgreich an z.b. das CUL übermittelt wurde, auch wenn sie dort nur in einen schon übervollen Buffer geschrieben wird. In einer Telnetsitzung kann man hingegen den Zustand des Buffers prüfen und die Kommunikation mit dem FHT beobachten.		Eine Möglichkeit, sich dem Problem zu nähern ist, das Logfile mit verbose5 anzeigen zu lassen. Die Meldungen sind dann recht detailliert und lassen einige Rückschlüsse zu. Erfahrungsgemäß ist es jedoch besser, sich die Kommunikation mit einer Telnetsitzung anzusehen. Ein Nachteil des Logfiles liegt z.B. darin, dass eine Temperaturänderung als "ausgeführt" angezeigt wird, wenn sie erfolgreich an z.B. das CUL übermittelt wurde, auch wenn sie dort nur in einen schon übervollen Buffer geschrieben wird. In einer Telnetsitzung kann man hingegen den Zustand des Buffers prüfen und die Kommunikation mit dem FHT beobachten.

	Dazu:		Dazu:
Zeile 98:		Zeile 98:
	* info timer <entertaste> zeigt einem alle Events, die FHEM empfängt und sendet. Hier kann man die Kommunikation live verfolgen und so z.B. sehen, ob noch Kommunikation mit dem FHT versucht wird. Einfach eine Weile mitlaufen lassen und sich ansehen, was alles passiert.		* info timer <entertaste> zeigt einem alle Events, die FHEM empfängt und sendet. Hier kann man die Kommunikation live verfolgen und so z.B. sehen, ob noch Kommunikation mit dem FHT versucht wird. Einfach eine Weile mitlaufen lassen und sich ansehen, was alles passiert.
	* Wenn man einen CUxx im Einsatz hat, dann kann man sich mittels "set CUL raw X61" ("CUL" durch Namen der eigenen Schnittstelle wie in fhemconfig definiert ersetzen) auch Details der Kommunikation anzeigen lassen. So kann man vergleichen, ob die Kommunikation mit dem Beispiel [[FHT80b#Log-Auszug]] übereinstimmt, also planmäßig abläuft. "set CUL raw X21" setzt das CUL wieder auf den Standard-Loglevel zurück. Achtung, Groß- und Kleinschreibung beachten: Das X61/X21 hat ein großes X.		* Wenn man einen CUxx im Einsatz hat, dann kann man sich mittels "set CUL raw X61" ("CUL" durch Namen der eigenen Schnittstelle wie in fhemconfig definiert ersetzen) auch Details der Kommunikation anzeigen lassen. So kann man vergleichen, ob die Kommunikation mit dem Beispiel [[FHT80b#Log-Auszug]] übereinstimmt, also planmäßig abläuft. "set CUL raw X21" setzt das CUL wieder auf den Standard-Loglevel zurück. Achtung, Groß- und Kleinschreibung beachten: Das X61/X21 hat ein großes X.
	* Auch sollte man prüfen, ob ~~der~~ der CUxx so konfiguriert ist, wie man glaubt. Mit "get CUL ccconf" kann man die wichtigsten Werte ansehen.		* Auch sollte man prüfen, ob der CUxx so konfiguriert ist, wie man glaubt. Mit "get CUL ccconf" kann man die wichtigsten Werte ansehen.
	* Ist der FHT Buffer leer oder was hat sich da ggf. aufgestaut? "'''get CUL raw T02'''" ergibt den Inhalt des Buffers. Da sollte möglichst nichts drin stehen ("CUL raw => N/A") oder nicht viel. Mit der Zeit erkennt man die Codes gleich, daraus ergibt sich, welches FHT Probleme macht (Adresse) und welche Kommandos noch auf Aussendung warten. Folgender Beispieloutput: "CUL raw => 060D:4118 060D:65FF 060D:66FF 060D:4120" ist bereits verdächtig. FHT 060D hat noch 4 Kommandos in der Warteschlange, die Abarbeitung hier dauert schon im besten Fall ~~mindestensW~~ noch 8 Minuten. Sieht bereits nach "Rückstau" aus. (4118 = desired temp auf Wert 18, 65ff= report1=255 66ff= report2=255).		* Ist der FHT Buffer leer oder was hat sich da ggf. aufgestaut? "'''get CUL raw T02'''" ergibt den Inhalt des Buffers. Da sollte möglichst nichts drin stehen ("CUL raw => N/A") oder nicht viel. Mit der Zeit erkennt man die Codes gleich, daraus ergibt sich, welches FHT Probleme macht (Adresse) und welche Kommandos noch auf Aussendung warten. Folgender Beispieloutput: "CUL raw => 060D:4118 060D:65FF 060D:66FF 060D:4120" ist bereits verdächtig. FHT 060D hat noch 4 Kommandos in der Warteschlange, die Abarbeitung hier dauert schon im besten Fall mindestens noch 8 Minuten. Sieht bereits nach "Rückstau" aus. (4118 = desired temp auf Wert 18, 65ff= report1=255 66ff= report2=255).
	* Mehrfaches Eingeben von "get CUL raw T02" im Abstand von ca 2 Minuten (dem Intervall, in dem Kommunikation mit dem FHTs stattfinden kann) zeigt einem, ob die Schlange sich abarbeitet oder welche Kommandos klemmen.		* Mehrfaches Eingeben von "get CUL raw T02" im Abstand von ca 2 Minuten (dem Intervall, in dem Kommunikation mit dem FHTs stattfinden kann) zeigt einem, ob die Schlange sich abarbeitet oder welche Kommandos klemmen.
	* Wenn man CUxx im Einsatz hat kann man auch die freie Sendezeit prüfen: "get CUL raw X" Der zweite Zahlenwert ist die Sendezeit in 10ms Slots. Während ein FS20 Schalter im Idealfall mit 21 Einheiten (=210 ms) erledigt werden kann, braucht schon die simpelste Übertragung nur eines Wertes an ein FHT ca. 3x mehr Zeiteinheiten. Wenn also nicht mindestens 65 Zeiteinheiten frei sind, kann keine FHT Übertragung erfolgreich sein.		* Wenn man CUxx im Einsatz hat kann man auch die freie Sendezeit prüfen: "get CUL raw X" Der zweite Zahlenwert ist die Sendezeit in 10ms Slots. Während ein FS20 Schalter im Idealfall mit 21 Einheiten (=210 ms) erledigt werden kann, braucht schon die simpelste Übertragung nur eines Wertes an ein FHT ca. 3x mehr Zeiteinheiten. Wenn also nicht mindestens 65 Zeiteinheiten frei sind, kann keine FHT Übertragung erfolgreich sein.
Zeile 108:		Zeile 108:
	simples neu Pairen eines nicht kommunizierenden FHTs.		simples neu Pairen eines nicht kommunizierenden FHTs.

	Wiederkehrende Actuator-Meldung "'''unknown_69'''" lassen sich z.b. meist mit einem neuen Pairing lösen.		Wiederkehrende Actuator-Meldung "'''unknown_69'''" lassen sich z.B. meist mit einem neuen Pairing lösen.

	'''Wichtig: vor dem Repairen FHT Buffer des zuständigen CULs löschen, z.b. durch kurz Stromlos machen oder den Befehl "set CUL raw T01 <CUL-ID>" senden.''' Damit werden ggf für dieses FHT bereits aufgestaute Kommandos entfernt.		'''Wichtig: vor dem Repairen FHT Buffer des zuständigen CULs löschen, z.B. durch kurz Stromlos machen oder den Befehl "set CUL raw T01 <CUL-ID>" senden.''' Damit werden ggf für dieses FHT bereits aufgestaute Kommandos entfernt.

	Zum neuen Pairen wie folgt vorgehen:		Zum neuen Pairen wie folgt vorgehen:
Zeile 119:		Zeile 119:

	=== provisorische Linderung ===		=== provisorische Linderung ===
	Als schnelle Notlösung kann es auch helfen, den FHT Buffer der Funkschnittstelle regelmäßig zu leeren. Beim CUL lässt sich das durch den Befehl "'''set CUL raw T01 <CUL-ID>'''" (löscht nur den FHT Buffer) oder "'''set CUL raw B00'''" (resettet das CUL komplett, auch Funkkontingent wird neu gestartet) bewerkstelligen, den man z.b. jede Nacht absetzen kann. Dies hilft nicht bei FHTs mit denen es Kommunikationsprobleme gibt, lindert aber die daraus resultierenden Probleme anderer FHTs oder gar die Kommunikation mit anderen Protokollen wie FS20, falls aufgestaute Befehlswarteschlangen das Funkkontingent verbrauchen. Grundsätzlich verdeckt diese Notlösung das Problem aber nur und kann eine echte Analyse und Lösung nicht ersetzen.		Als schnelle Notlösung kann es auch helfen, den FHT Buffer der Funkschnittstelle regelmäßig zu leeren. Beim CUL lässt sich das durch den Befehl "'''set CUL raw T01 <CUL-ID>'''" (löscht nur den FHT Buffer) oder "'''set CUL raw B00'''" (resettet das CUL komplett, auch Funkkontingent wird neu gestartet) bewerkstelligen, den man z.B. jede Nacht absetzen kann. Dies hilft nicht bei FHTs mit denen es Kommunikationsprobleme gibt, lindert aber die daraus resultierenden Probleme anderer FHTs oder gar die Kommunikation mit anderen Protokollen wie FS20, falls aufgestaute Befehlswarteschlangen das Funkkontingent verbrauchen. Grundsätzlich verdeckt diese Notlösung das Problem aber nur und kann eine echte Analyse und Lösung nicht ersetzen.

	== Hardware defekt? ==		== Hardware defekt? ==
	Es gibt auch defekte FHT80b, aber oft hilft eine geringe Aufweitung der Bandbreite (siehe oben) oder schlicht ein neuer Satz Batterien. Manchmal führt auch ein "matchen" der FHTs mit der Funklage zum Ziel: Rausfinden, welche FHTs am problemlosesten arbeiten und diese an den Stellen unterbringen, die funktechnisch die ungünstigsten sind, während weniger zuverlässige FHTs näher an der Zentrale eingesetzt werden. Aufgrund der recht primitiven Sender/Empfänger (Pendelempfänger) der FHTs sind hier durchaus deutliche Streuungen möglich.		Es gibt auch defekte FHT80b, aber oft hilft eine geringe Aufweitung der Bandbreite (siehe oben) oder schlicht ein neuer Satz Batterien. Manchmal führt auch ein "matchen" der FHTs mit der Funklage zum Ziel: Rausfinden, welche FHTs am problemlosesten arbeiten und diese an den Stellen unterbringen, die funktechnisch die ungünstigsten sind, während weniger zuverlässige FHTs näher an der Zentrale eingesetzt werden. Aufgrund der recht primitiven Sender/Empfänger (Pendelempfänger) der FHTs sind hier durchaus deutliche Streuungen möglich.
	Mitunter können Probleme auch gelöst werden, ~~in dem~~ das FHT Stromlos gemacht wird: Batterien raus, 2 Minuten warten (wichtig), Batterien wieder einsetzen.		Mitunter können Probleme auch gelöst werden, indem das FHT Stromlos gemacht wird: Batterien raus, 2 Minuten warten (wichtig), Batterien wieder einsetzen.

	== Weiterführende Artikel ==		== Weiterführende Artikel ==

← Nächstältere Version		Version vom 6. Februar 2018, 23:17 Uhr
Zeile 1:		Zeile 1:
	{{Randnotiz\|RNTyp=y\|RNText=Das FHT System ist seit 2017 abgekündigt. Vom Hersteller sind keine Neugeräte mehr erhältlich. Es ist daher zu überlegen, fehlerhafte FHTs durch andere von FHEM ~~unterstütze~~ Systeme zu ersetzen, z.b. MAX oder HomeMatic. Parallelbetrieb ist mit zusätzlicher Schnittstelle möglich.}}Während FHEM mit reinen Schaltaktoren in der Regel problemarm funktioniert, sind Probleme mit [[FHT80b]] ~~Heizungsteuerungen~~ recht häufig. Dies liegt in der deutlich anspruchsvolleren bidirektionalen Kommunikation, die zur Übermittlung der ggf. durchaus umfangreichen Daten notwendig ist.		{{Randnotiz\|RNTyp=y\|RNText=Das FHT System ist seit 2017 abgekündigt. Vom Hersteller sind keine Neugeräte mehr erhältlich. Es ist daher zu überlegen, fehlerhafte FHTs durch andere von FHEM unterstützte Systeme zu ersetzen, z.b. MAX oder HomeMatic. Parallelbetrieb ist mit zusätzlicher Schnittstelle möglich.}}Während FHEM mit reinen Schaltaktoren in der Regel problemarm funktioniert, sind Probleme mit [[FHT80b]] Heizungssteuerungen recht häufig. Dies liegt in der deutlich anspruchsvolleren bidirektionalen Kommunikation, die zur Übermittlung der ggf. durchaus umfangreichen Daten notwendig ist.


Zeile 6:		Zeile 6:

	* FHT funktioniert zunächst einwandfrei, dann plötzlich sind keine Temperaturänderungen o.ä. mehr möglich		* FHT funktioniert zunächst einwandfrei, dann plötzlich sind keine Temperaturänderungen o.ä. mehr möglich
	* FHTs funktionieren einwandfrei, jedoch ~~seit dem~~ ein weiteres dazu gekommen ist, wird die Datenübertragung langsam oder fällt ganz aus, auch zu FHTs, die vorher ohne Probleme liefen.		* FHTs funktionieren einwandfrei, jedoch seitdem ein weiteres dazu gekommen ist, wird die Datenübertragung langsam oder fällt ganz aus, auch zu FHTs, die vorher ohne Probleme liefen.
	* FHT funktioniert manchmal für Stunden gut, übermittelt aktuelle Werte und lässt sich ansprechen, dann für mehrere Stunden wieder nicht, schliesslich "erholt" sich das FHT wieder (oft über Nacht)		* FHT funktioniert manchmal für Stunden gut, übermittelt aktuelle Werte und lässt sich ansprechen, dann für mehrere Stunden wieder nicht, schliesslich "erholt" sich das FHT wieder (oft über Nacht)
	* Temperaturänderungen werden von FHT mit hoher Verzögerung (bis hin zu Stunden) ausgeführt		* Temperaturänderungen werden von FHT mit hoher Verzögerung (bis hin zu Stunden) ausgeführt
Zeile 47:		Zeile 47:

	* Temperatursteuerung der FHTs nicht durch tägliche Änderung der Wochenprogramme im FHT durchführen. Obwohl diese Methode den Vorteil hat, dass sie eine höhere Ausfallsicherheit bietet (weil die FHTs auch ohne FHEM ihr zuletzt eingegebenes Wochenprogamm weiter verwenden können), so steigt der auszutauschende Datenverkehr stark an.		* Temperatursteuerung der FHTs nicht durch tägliche Änderung der Wochenprogramme im FHT durchführen. Obwohl diese Methode den Vorteil hat, dass sie eine höhere Ausfallsicherheit bietet (weil die FHTs auch ohne FHEM ihr zuletzt eingegebenes Wochenprogamm weiter verwenden können), so steigt der auszutauschende Datenverkehr stark an.
	:Mitunter verwendete Implementationen, die Anhand von Tabellen, Kalendern oder der Auswertung von Excelsheets mehrere FHTs regelmässig mit geänderten Wochenprogrammen und/oder Änderungen der Day/Night Temperaturen steuern, sind in schwierigen ~~Funksituation~~ deutlich anfälliger.		:Mitunter verwendete Implementationen, die Anhand von Tabellen, Kalendern oder der Auswertung von Excelsheets mehrere FHTs regelmässig mit geänderten Wochenprogrammen und/oder Änderungen der Day/Night Temperaturen steuern, sind in schwierigen FunksituationenKo deutlich anfälliger.

	* Soweit möglich, in FHEM versuchen, Kommandos zusammenzufassen. Bis zu acht Kommandos können in einem SET Befehl abgesetzt werden, z.B.:		* Soweit möglich, in FHEM versuchen, Kommandos zusammenzufassen. Bis zu acht Kommandos können in einem SET Befehl abgesetzt werden, z.B.:
Zeile 53:		Zeile 53:
	:Diese werden schneller abgearbeitet als entsprechende Einzelkommandos.		:Diese werden schneller abgearbeitet als entsprechende Einzelkommandos.

	* Zeitlich unkritische ~~Komandos~~ (z.b. Setzen des Datums) spät nachts durchführen, wo das Sendekontingent unbelastet ist.		* Zeitlich unkritische Kommandos (z.b. Setzen des Datums) spät nachts durchführen, wo das Sendekontingent unbelastet ist.

	* Keine regelmässigen Reports abfragen, insbesondere NICHT report1=255 (also komplettes Wochenprogramm abfragen)		* Keine regelmässigen Reports abfragen, insbesondere NICHT report1=255 (also komplettes Wochenprogramm abfragen)
	:Da einige FHTs nach einiger Zeit keine Temperaturdaten mehr senden, fragen viele Nutzer diese über tägliches Absetzen von report2=255 ab. Besser ist es jedoch, das FHT mit einem ~~Wachdog~~ zu überwachen und nur bei Bedarf zu "wecken", z.B. so:		:Da einige FHTs nach einiger Zeit keine Temperaturdaten mehr senden, fragen viele Nutzer diese über tägliches Absetzen von report2=255 ab. Besser ist es jedoch, das FHT mit einem Watchdog zu überwachen und nur bei Bedarf zu "wecken", z.B. so:
	::<code>define wd_FHT_Wohnzimmer watchdog hzg_wohnzimmer:measured-temp.* 01:00 SAME set hzg_wohnzimmer time</code>		::<code>define wd_FHT_Wohnzimmer watchdog hzg_wohnzimmer:measured-temp.* 01:00 SAME set hzg_wohnzimmer time</code>
	:Alternativ report2=255 1-2x pro Woche nachts absetzen, bei mehreren FHTs eventuell tageweise versetzt:		:Alternativ report2=255 1-2x pro Woche nachts absetzen, bei mehreren FHTs eventuell tageweise versetzt:
Zeile 66:		Zeile 66:
	* RSSI der FHTs beobachten. Unter -85 (also z.b. -89) ist ungünstig. Unbedingt versuchen, ein besseres RSSI als -85 hinzubekommen, zu ALLEN FHTs.		* RSSI der FHTs beobachten. Unter -85 (also z.b. -89) ist ungünstig. Unbedingt versuchen, ein besseres RSSI als -85 hinzubekommen, zu ALLEN FHTs.
	* Antennnenlage des CUL/CUN korrigieren (z.b. Antenne um 45 Grad kippen), eventuell Lage des FHTs ändern, ein halber Meter kann schon viel bringen. Dabei kommt es nicht zwingend nur auf die absolute Entfernung zum Funkadapter an, auch die Lage im Gebäude kann viel ausmachen.		* Antennnenlage des CUL/CUN korrigieren (z.b. Antenne um 45 Grad kippen), eventuell Lage des FHTs ändern, ein halber Meter kann schon viel bringen. Dabei kommt es nicht zwingend nur auf die absolute Entfernung zum Funkadapter an, auch die Lage im Gebäude kann viel ausmachen.
	* Wenn CUL / CUN eingesetzt werden, gegebenenfalls die Parameter freq, bandwidth und sens ändern. Als Startpunkt z.B. bandwidth auf 464 ~~khz~~ und sens auf 8 db anstelle ~~4db~~ ändern. Kombinationen ausprobieren, aber nicht mehrere Parameter gleichzeitig ändern. RSSI-Auswirkung jeder Änderung beobachten.		* Wenn CUL / CUN eingesetzt werden, gegebenenfalls die Parameter freq, bandwidth und sens ändern. Als Startpunkt z.B. bandwidth auf 464 kHz und sens auf 8 dB anstelle 4dB ändern. Kombinationen ausprobieren, aber nicht mehrere Parameter gleichzeitig ändern. RSSI-Auswirkung jeder Änderung beobachten.

	Wenn das keinen Erfolg bringt, zweiten CUL / CUNO einsetzen, z.b. auch als RFR CUL. Dabei [[RFR CUL und FHT80]] Besonderheiten berücksichtigen: Nicht zu viele FHTs ans RFR CUL anbinden, nur so viele wie gerade nötig. FS20 Repeater helfen nicht.		Wenn das keinen Erfolg bringt, zweiten CUL / CUNO einsetzen, z.b. auch als RFR CUL. Dabei [[RFR CUL und FHT80]] Besonderheiten berücksichtigen: Nicht zu viele FHTs ans RFR CUL anbinden, nur so viele wie gerade nötig. FS20 Repeater helfen nicht.
Zeile 99:		Zeile 99:
	* Wenn man einen CUxx im Einsatz hat, dann kann man sich mittels "set CUL raw X61" ("CUL" durch Namen der eigenen Schnittstelle wie in fhemconfig definiert ersetzen) auch Details der Kommunikation anzeigen lassen. So kann man vergleichen, ob die Kommunikation mit dem Beispiel [[FHT80b#Log-Auszug]] übereinstimmt, also planmäßig abläuft. "set CUL raw X21" setzt das CUL wieder auf den Standard-Loglevel zurück. Achtung, Groß- und Kleinschreibung beachten: Das X61/X21 hat ein großes X.		* Wenn man einen CUxx im Einsatz hat, dann kann man sich mittels "set CUL raw X61" ("CUL" durch Namen der eigenen Schnittstelle wie in fhemconfig definiert ersetzen) auch Details der Kommunikation anzeigen lassen. So kann man vergleichen, ob die Kommunikation mit dem Beispiel [[FHT80b#Log-Auszug]] übereinstimmt, also planmäßig abläuft. "set CUL raw X21" setzt das CUL wieder auf den Standard-Loglevel zurück. Achtung, Groß- und Kleinschreibung beachten: Das X61/X21 hat ein großes X.
	* Auch sollte man prüfen, ob der der CUxx so konfiguriert ist, wie man glaubt. Mit "get CUL ccconf" kann man die wichtigsten Werte ansehen.		* Auch sollte man prüfen, ob der der CUxx so konfiguriert ist, wie man glaubt. Mit "get CUL ccconf" kann man die wichtigsten Werte ansehen.
	* Ist der FHT Buffer leer oder was hat sich da ggf. aufgestaut? "'''get CUL raw T02'''" ergibt den Inhalt des Buffers. Da sollte möglichst nichts drin stehen ("CUL raw => N/A") oder nicht viel. Mit der Zeit erkennt man die Codes gleich, daraus ergibt sich, welches FHT Probleme macht (Adresse) und welche Kommandos noch auf Aussendung warten. Folgender Beispieloutput: "CUL raw => 060D:4118 060D:65FF 060D:66FF 060D:4120" ist bereits verdächtig. FHT 060D hat noch 4 Kommandos in der Warteschlange, die Abarbeitung hier dauert schon im besten Fall ~~mindesten~~ noch 8 Minuten. Sieht bereits nach "Rückstau" aus. (4118 = desired temp auf Wert 18, 65ff= report1=255 66ff= report2=255).		* Ist der FHT Buffer leer oder was hat sich da ggf. aufgestaut? "'''get CUL raw T02'''" ergibt den Inhalt des Buffers. Da sollte möglichst nichts drin stehen ("CUL raw => N/A") oder nicht viel. Mit der Zeit erkennt man die Codes gleich, daraus ergibt sich, welches FHT Probleme macht (Adresse) und welche Kommandos noch auf Aussendung warten. Folgender Beispieloutput: "CUL raw => 060D:4118 060D:65FF 060D:66FF 060D:4120" ist bereits verdächtig. FHT 060D hat noch 4 Kommandos in der Warteschlange, die Abarbeitung hier dauert schon im besten Fall mindestensW noch 8 Minuten. Sieht bereits nach "Rückstau" aus. (4118 = desired temp auf Wert 18, 65ff= report1=255 66ff= report2=255).
	* Mehrfaches Eingeben von "get CUL raw T02" im Abstand von ca 2 Minuten (dem Intervall, in dem Kommunikation mit dem FHTs stattfinden kann) zeigt einem, ob die Schlange sich abarbeitet oder welche Kommandos klemmen.		* Mehrfaches Eingeben von "get CUL raw T02" im Abstand von ca 2 Minuten (dem Intervall, in dem Kommunikation mit dem FHTs stattfinden kann) zeigt einem, ob die Schlange sich abarbeitet oder welche Kommandos klemmen.
	* Wenn man CUxx im Einsatz hat kann man auch die freie Sendezeit prüfen: "get CUL raw X" Der zweite Zahlenwert ist die Sendezeit in 10ms Slots. Während ein FS20 Schalter im Idealfall mit 21 Einheiten (=210 ms) erledigt werden kann, braucht schon die simpelste Übertragung nur eines Wertes an ein FHT ca. 3x mehr Zeiteinheiten. Wenn also nicht mindestens 65 Zeiteinheiten frei sind, kann keine FHT Übertragung erfolgreich sein.		* Wenn man CUxx im Einsatz hat kann man auch die freie Sendezeit prüfen: "get CUL raw X" Der zweite Zahlenwert ist die Sendezeit in 10ms Slots. Während ein FS20 Schalter im Idealfall mit 21 Einheiten (=210 ms) erledigt werden kann, braucht schon die simpelste Übertragung nur eines Wertes an ein FHT ca. 3x mehr Zeiteinheiten. Wenn also nicht mindestens 65 Zeiteinheiten frei sind, kann keine FHT Übertragung erfolgreich sein.
Zeile 105:		Zeile 105:

	=== Repairen ===		=== Repairen ===
	Lassen sich durch die obigen Massnahmen keine ~~nahliegenden Problem~~ entdecken, hilft gelegentlich auch ein		Lassen sich durch die obigen Massnahmen keine naheliegenden Probleme entdecken, hilft gelegentlich auch ein
	simples neu Pairen eines nicht ~~komunizierenden~~ FHTs.		simples neu Pairen eines nicht kommunizierenden FHTs.

	Wiederkehrende Actuator-Meldung "'''unknown_69'''" lassen sich z.b. meist mit einem neuen Pairing lösen.		Wiederkehrende Actuator-Meldung "'''unknown_69'''" lassen sich z.b. meist mit einem neuen Pairing lösen.
Zeile 122:		Zeile 122:

	== Hardware defekt? ==		== Hardware defekt? ==
	Es gibt auch defekte FHT80b, aber oft hilft eine geringe Aufweitung der Bandbreite (siehe oben) oder schlicht ~~eine~~ neuer Satz Batterien. Manchmal führt auch ein "matchen" der FHTs mit der Funklage zum Ziel: Rausfinden, welche FHTs am problemlosesten arbeiten und diese an den Stellen unterbringen, die funktechnisch die ungünstigsten sind, während weniger zuverlässige FHTs näher an der Zentrale eingesetzt werden. Aufgrund der recht primitiven Sender/Empfänger (Pendelempfänger) der FHTs sind hier durchaus deutliche Streuungen möglich.		Es gibt auch defekte FHT80b, aber oft hilft eine geringe Aufweitung der Bandbreite (siehe oben) oder schlicht ein neuer Satz Batterien. Manchmal führt auch ein "matchen" der FHTs mit der Funklage zum Ziel: Rausfinden, welche FHTs am problemlosesten arbeiten und diese an den Stellen unterbringen, die funktechnisch die ungünstigsten sind, während weniger zuverlässige FHTs näher an der Zentrale eingesetzt werden. Aufgrund der recht primitiven Sender/Empfänger (Pendelempfänger) der FHTs sind hier durchaus deutliche Streuungen möglich.
	Mitunter können Probleme auch gelöst werden, in dem das FHT Stromlos gemacht wird: Batterien raus, 2 Minuten warten (wichtig), Batterien wieder einsetzen.		Mitunter können Probleme auch gelöst werden, in dem das FHT Stromlos gemacht wird: Batterien raus, 2 Minuten warten (wichtig), Batterien wieder einsetzen.