Quelltext der Seite Kommunikationsprobleme mit FHT

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.


== Symptome ==
Im Einsatz von FHTs kann es zu folgenden Symptomen kommen:

* FHT funktioniert zunächst einwandfrei, dann plötzlich sind keine Temperaturänderungen o.ä. mehr möglich
* 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)
* Temperaturänderungen werden von FHT mit hoher Verzögerung (bis hin zu Stunden) ausgeführt
* FHTs laufen ca. eine Woche problemfrei, dann kommen keinen Daten mehr. Nach einem neuen Pairing ist alles wieder in Ordnung, bis nach ca. einer Woche wieder keine Daten kommen.

== Problemquellen ==
Die FHT-Kommunikation ist recht fragil. Für eine erfolgreiche Kommunikation müssen eine Menge Funktelegramme in einem bestimmten Timing ausgetauscht werden. Selbst wenn keine Kommandos an das [[FHT80b]] übergeben werden, finden alle 15 Minuten Datenübermittlungen statt, da das FHT Temperatur und andere Daten meldet.

Bereits ein fehlendes Datenpaket kann dazu führen, dass die Kommunikation erfolglos war und insgesamt alles wiederholt werden muss.

Störungen des Kanals (z.B. der berühmte Funkkopfhörer aus China) führen daher so gut wie immer zu Problemen in der FHT-Kommunikation. Es reicht, wenn von den 5+n Kommandos (n=Anzahl der übermittelten Werteänderungen) die mindestens hin und her gehen müssen, eines nicht korrekt ankommt und schon muss alles wiederholt werden.

Diese Wiederholung kann aber nur ca. alle 2 Minuten erfolgen. Kommandos, die noch nicht erfolgreich abgearbeitet wurden, verbleiben im FHT Befehlsbuffer des CUL/CUNO (oder sonstiger Funkschnittstellen), obwohl sie seitens FHEM als "abgesetzt" geloggt werden. Dieser FHT Buffer kann mitunter sehr viele Kommandos aufnehmen, die der Reihe nach abgearbeitet werden. Kann z.B. eine Temperaturänderung aufgrund von Funkproblemen erst nach ca. 3 Versuchen erfolgreich zugestellt werden, so dauert es in der Regel etwa 3 x 2 = 6 Minuten, bis die Änderung im FHT sichtbar ankommt. Wird z.B. aus Ungeduld eine erneute Temperaturänderung ausgelöst, so wird diese im FHT Buffer gespeichert und dann nach erfolgter Übertragung des ersten Kommandos übermittelt. Die Abarbeitungszeit der Warteschlange für dieses FHT steigt dann bereits auf ca. 12 Minuten. Es ist leicht möglich, durch Abfrage der Wochenprogramme, Änderung der Day- oder Nighttemperatur, oder Änderung von Wochenschaltpunkten Warteschlangen aufzubauen, die buchstäblich Stunden oder gar Tage zum Abarbeiten benötigen. Temperaturänderungen könnten also mitunter erst Stunden später tatsächlich ausgeführt werden. Jeder Aussendungsversuch führt außerdem zur Belastung des Sendekontos. Ist die [[1% Regel]] überschritten, wird die Warteschlange nicht mehr weiter abgearbeitet.

Solche Störungen des Funkkanals sind nicht selten und können auch ohne äußere Einflüsse stattfinden.
Die FHTs sind mit relativ ungenauen Sendern ausgestattet und können in Sendefrequenz und Flankensteilheit mitunter deutlich von den Sollwerten abweichen, was insbesondere beim Einsatz von CUL / CUNO (weniger beim Einsatz einer FHZ1x00PC) ein Problem sein kann, weil die CUL / CUNO eher trennscharf sind. Dies kann dazu führen, dass die Funkkommunikation oft fehlerhaft ist oder sogar ganz abbricht.

Zusätzlich stellen einige FHTs das Aussenden von Temperatur und weiteren Daten nach 5-10 Tagen ein, wenn nicht zwischendurch von der Zentrale Änderungen übermittelt wurden.

Alle vorstehenden Gründe kombinieren sich für gewöhnlich zu einem komplexen Versagensszenario, das sich gegenseitig selbst verstärkt:

* Schlechte Funklage eines FHT80b erzeugt häufige Retrys.
* Inzwischen stauen sich weitere Kommandos an das FHT auf, z.B. wegen erneuter Temperaturänderungen, automatisiert oder aus Ungeduld, sowie andere Meldungen, etwa Abfrage oder Ändern des Wochenprogramms.
* Die Kommandos sammeln sich im FHT Buffer des Funkadapters an und sorgen dafür, dass die Sendezeit hoch belastet wird.
* Fast Glück hat man noch, wenn der Buffer voll läuft und [[EOB]] Meldungen im Log darauf hinweisen. Es kann aber auch passieren, dass über grössere Zeiträume der Buffer gerade eben nicht voll wird, insbesondere bei CUL / CUN, die im Vergleich zur FHZ1x00PC große Buffer haben, die 30 und mehr Kommandos halten können. Ist zusätzlich das Feature "Softbuffer" eingeschaltet, verschlimmert sich die Situation weiter, da die Warteschlange noch länger werden kann.
* Ist die 1% Marke erreicht, das Funkkontingent also aufgebraucht, verschlimmert sich die Situation dramatisch: Nun bricht auch die Kommunikation mit anderen FHTs zusammen. Da außerdem immer Kommandos im FHT Buffer sind, wird jede freie Sendezeit durch Versuche, die Warteschlange abzuarbeiten, sofort wieder aufgebraucht. Das Timing des Gesamtsystems ist hier leider so, dass sich innerhalb des Retryintervals von ca. 2 Minuten oft gerade zu wenig freie Sendezeiteinheiten aufbauen, um den nächsten Retry komplett abwickeln zu können. D.h. jedes Retry braucht die gerade aufgebauten freien Sendeeinheiten auf, ist aber in sich erfolglos.
* Spätestens ab hier ist vollständiger Stillstand erreicht. Im Log häufen sich die [[LOVF]]- Meldungen, jede Kommunikation mit allen FHTs ist zusammengebrochen. Es kommt eventuell sogar zu Beeinträchtigungen beim Schalten von FS20 Aktoren.

Mit der Anzahl FHTs steigt die Wahrscheinlichkeit für das Auftreten dieser Probleme.

Viele FHEM Nutzer verwenden die Kombination von FHEM und FHT so, dass die FHTs über Manipulation der im FHT gespeicherten Wochenprogramme, Schaltpunkte und Day/Nighttemp gesteuert werden. Dies erhöht die Datenmenge im Vergleich zu einer direkten Temperatursteuerung ("set desired-temp 22") und wird in kritischen Situationen die Fehlerhäufigkeit deutlich anheben. Sehr viel Datenverkehr erzeugt auch die komplette Abfrage des Wochenprogramms mittels Report1=255.

== Diagnose und Lösungsansätze ==
Im Folgenden einige Hinweise wie man das Auftreten von Problemen verringern bzw. diagnostizieren kann.

=== Sparsam mit Funkzeit umgehen ===
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.

*  [http://www.fhemwiki.de/wiki/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, so wird das Kommando trotz Lazy Mode immer wieder 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.
* Temperatursteuerung der FHTs nicht durch tägliches 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.

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

 <nowiki>define wd_FHT_Wohnzimmer watchdog hzg_wohnzimmer:measured-temp.* 01:00 SAME set hzg_wohnzimmer time</nowiki>
:Alternativ report2=255 1-2x pro Woche nachts absetzen, bei mehreren FHTs eventuell tageweise versetzt:

 <nowiki>define fht_reportZimmer1 at *04:00:00 {if ($wday == 1) { fhem("set hzg_Zimmer1 report2 255")</nowiki>

=== Funklage beobachten ===
* RSSI mitloggen:
 <nowiki>attr CUL addvaltrigger 1</nowiki>
* 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.
* 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.

=== Einstellungen prüfen ===

* Attribut fhtsoftbuffer ausschalten. Beim Einsatz von CUL/CUNO ist die Verwendung von fhtsoftbuffer sowieso überflüssig, da die eigenen FHT Buffer dieser Adapter hinreichend groß sind. Gedacht ist dieses Attribut vor allem für den Einsatz von FHEM mit FHZ1x00PC Zentralen, deren FHT Buffer klein ist und zum Teil nur 8 Befehle halten kann. Das CUL V3 kann demgegenüber 40 FHT Befehle im Buffer halten. D.h. bei einer FHZ1x00PC kann es vorkommen, dass bei 10 zu steuernden FHTs schon ein Kommando der Art "Alle FHTs auf 20 Grad" *nicht* bei allen FHTs ankommt, da nicht alle Befehle zugleich in den Buffer passen. In solchen Fällen ist der Einsatz des Softbuffers hilfreich. (in neueren FHEM Versionen hat das Attribut fhtsoftbuffer daher auf CUL und CUNOs keine Wirkung mehr)

<ul>Das Attribut fhtsoftbuffer erzeugt einen "unendlich" grossen Buffer, was sehr lange Warteschlangen zur Folge haben kann. Das macht die Diagnose sehr schwer und erzeugt seltsamste Effekte, wenn die Kommunikation mit den FHTs nicht einwandfrei ist. In jedem Fall aber "glaubt" FHEM sehr viel länger, dass alles in Ordnung sei, obwohl die Kommunikation gestört ist.

Ganz generell: Wenn eine Installation ohne fhtsoftbuffer nicht zuverlässig läuft, sollte man der Versuchung widerstehen, das Problem durch einen grösseren Buffer lösen zu wollen. Fhtsoftbuffer sollte nur eingesetzt werden, wenn eine FHZ1x00 verwendet wird, die Installation an sich gut läuft und nur gelegentlich EOB Meldungen kommen.
</ul>

* Retrycount auf 1. Wenn fhtsoftbuffer aktiv ist, wird versucht, das Kommando Retrycount-Mal zu wiederholen, wenn es nicht innerhalb von 240 Sekunden abgesetzt werden kann. Das kann die Abarbeitungsgeschwindigkeit der Warteschlange zusätzlich senken, gleichzeitig den Funkzeitverbrauch erhöhen und dadurch Probleme eher noch verschärfen. Sinnvoll ist ein höherer Retrycount womöglich nur, wenn in kleineren Installationen ein FHT gerade am Rande des Funkbereiches liegt, ansonsten aber alles problemfrei abläuft. Ohne  fhtsoftbuffer hat retrycount keine Wirkung, wenn retrycount nicht definiert wird, ist der Defaultwert 1.

* Bei mehreren CUxx in der Installation (auch 1 x CUL und 1x RFR CUL) das Attribut IODev kontrollieren. Ist ein FHT mit einem CUxx gepairt, aber das IODev zeigt auf das andere, ist eine Kommunikation nicht möglich. Da aber Temperatur (und weitere Werte) trotzdem empfangen werden, fällt dies zunächst eventuell nicht sofort auf. Der FHTbuffer des "falschen" CUxx wird dann mit Befehlen an das FHT zugemüllt, die nie erfolgreich abgesetzt werden können. Ist der Buffer schliesslich voll, können auch keine Kommandos an andere mit diesem CUxx gepairte FHTs mehr übermittelt werden, obwohl diese eigentlich nicht betroffen sind.
* Bei mehreren CUxx UNBEDINGT sicherstellen, dass die FHT-ID unterschiedlich ist. Bei gleicher FHT-ID fühlen sich zwei "Zentralen" für die FHT Kommunikation verantwortlich, was immer im Chaos endet: beide Funkadapter antworten bei FHT Kommunikationen und stören sich so gegenseitig. Siehe auch [[Was ist der Hauscode?]].
* Bei mehreren CUxx bitte auch die Erläuterungen zum [[Sendpool]] Attribut berücksichtigen, die Funktion von Sendpool wird oft missverstanden.

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

Dazu:

* Terminalprogramm starten
* Dann mittels <code>telnet (IP des FHEM Servers) 7072 &lt;entertaste&gt;</code> eine Telnetverbindung zu FHEM starten (7072 ist FHEMs Telnetport)
* erneut &lt;entertaste&gt; drücken, nun muss als Prompt "fhem&gt;" erscheinen.

Jetzt können zahlreiche Kommandos zur Diagnose abgegeben werden. 

* info timer &lt;entertaste&gt; 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. 
* 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 =&gt; 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 =&gt; 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).
* 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.
* CUxx Funkadapter können auch resettet werden: "set CUL raw B00" resettet das CUL, und löscht dabei alle Buffer und setzt die freie Funkzeit auf Maximum. Die Wirkung ist die selbe wie den Adapter kurz stromlos zu machen. Will man hingegen nur den FHT Buffer leeren, kann man auch "'''set CUL raw T01xxxx'''" eingeben, wobei xxxx = FHT-ID ist, die aus fhem.cfg aus der CUL-Definition gelesen werden kann. Diese muss natürlich mit der vorherigen übereinstimmen, da sonst alle FHT-Pairings ungültig sind. Nach dem Löschen des Buffers noch kurz mit "get CUL raw T02" überprüfen, dass der Buffer auch wirklich leer ist. Anschliessend irgendeinen Befehl an den FHT senden, z.B. Ändern der desired-temp um 1 Grad. Erfolg beobachten. Daran denken, dass es schon im Idealfall mehr als 2 Minuten dauern kann, bis die Änderung gesendet wird.

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

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

====Neues Pairen ohne Autocreate====
*fhem.cfg unbearbeitet lassen
*FHT80b in Sonderfunktionen "cENT" auf "n/a" stellen, danach sofort in FHEM einen Befehl (egal welchen) an die FHT80b senden. 
*Wenn ca. zwei Minuten später Sonderfunktion cENT auf "ON" steht, war das Pairing erfolgreich.

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

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

== Weiterführende Artikel ==
* [[Was ist der Hauscode?]]
* [[1% Regel]]
* [[Maximal nutzbare Geräte]]

[[Kategorie:FHT Components]]