Neues und, wie ich finde Interessantes von der FHT-Front:
Bei mir war es heute morgen ziemlich kalt im Haus.
Grund:
FHZ-Buffer voll. über 40 Einträge. Ja ich weiß, muss ich noch programmtechnisch abfangen… :o
Eine Prüfung der Variablen ergab, dass gestern abend um 20 Uhr herum die letzten Pos-Daten aller FHTs eingegangen sind. Natürlich arbeitet das Script weiter und stellt die neuen States an die FHTs. Da ich immer auf den state prüfe, waren das jede halbe Stunde 7 Reqeusts.
Aber nun zum Interessanten:
Nur IPS war der Meinung. dass keine Daten mehr reinkommen. Meine parallel aufgezeichneten FHT-Eingangsdaten über RegisterVariable liefern ganz normale Kommunikation.
So kommt es auch, dass die letzten States bis etwa 23:00 gestern abend noch rausgegangen sind. Nur heute morgen war halt der Buffer voll…
Ich und noch welche im forum sind der meinung das es noch ein ‚haken‘ gibt im FHT-queue, aber nur wen es zu schwierigkeiten kommt und deshalb nicht nachvollziehbar.
Wenn es nur eine möglichkeit gäbe das zu simulieren könnten wie Paresy die richtung angeben die gefolgt werden soll.
Ich kann auch gesagt nichts dazu sagen. Ich gebe Fredje schon recht, dass es noch einen Haken gibt, nur wo soll Paresy anfangen zu suchen? Ich geh dem Problem halt aus dem Weg, da ich mit 3 FHZ’s 11 FHT’s ansteuere, und ich muss ehrlich gesagt, sagen, dass ich seither überhaupt keine probleme mit meiner Heizungssteuerung habe.
Da sich der Fehler eindeutig auf das FHT-Modul festmachen lässt, wäre es gut, wenn man Module zur Laufzeit dynamisch laden und entladen könnte. Das wurde ja hier auch schon angesprochen, wenn auch ein einem anderen Kontext.
Ich habe heute morgen schnell noch einen „watchdog“ programmiert, welcher IPS neustartet, wenn ein Fehler erkannt wird, wie z.B. keine Daten mehr von den FHTs usw…
Nur es würde in diesem Fall eigentlich das FHT Modul reichen. :rolleyes:
BTW:
Es war seit letztem Sommer das zweite Mal und das bei Uptimes von bis zu 6 Wochen.
Falls es nochmal auftreten sollte, wäre es Interessant zu wissen, ob du mit dem ips_debug Tool, Daten für die jeweiligen FHT Instanzen bekommst bzw am FHZ Splitter.
Ich vermute du hast dein Register Variable direkt hinter dem FTDI?
Wertest du auch die Daten richtig aus, oder woraus schließt du, dass FHT Daten gekommen sind. (Es hätten ja auch FS20/HMS Daten sein können)
Kleines Update zum Thema:
Heute morgen gab’s wieder Probleme mit den FHTs. Aber diesmal sind die Daten ganz normal rein und raus gegangen. Nur in der Queue standen noch drei Befehle drin.
Und das, obwohl die FHTs die Temp empfangen haben und auch die state-Variable korrekt gesetzt wurde.
@paresy:
Hat sich seit dem letzten Update was am FHT-Modul geändert? Denn vorher hatte ich nie derartige Ausfälle.
Interessant wäre es auch mal zu wissen, ob es verschiedene Hardware- bzw. Firmware Versionen gibt des gleichen Typs von FHZ.
Somit könnte man auch mal verschiedenes ausklammern.
Dann stellt sich auch die Frage, warum hat der eine Probleme, der andere nicht?
Ich würde mal ganz vorsichtig behaupten, dass verschiedene Probleme einfach hausgemacht (ELV) sind, oder einfach auch nur an der 1% Hürde scheitern u.a. das kuze Zeitfenster.
[Klammer auf]
Sicherlich werde ich einige hier wieder langweilen mit diesen Aussagen, doch seit ich mit mehr als nur einer FHZ fahre, habe ich keine Ausfälle mehr, weder Probleme in irgendeiner Form. Ich will hiermit nicht sagen ‚Kauft mehr FHZ’s‘ (Ich stehe nicht auf der Gehaltsliste von ELV). Ich will lediglich sagen, dass solche Fehler einfach nur systembedingt sind, und meiner Meinung nach das ganze eine Fehlkonzeption war, nicht genug getestet worden ist, oder gekonntes Marketing ist nach dem Motto ‚Die FHZ kann quasi bis zu 9999 FHT’s verwalten, doch kauft euch besser mehrere davon, is‘ besser’
[/Klammer zu]
ich habe weiterhin auch das Problem, dass die MODE-Befehle einfach nicht sauber rausgehen. Die „verhungern“ bei mir meist im Zwischenspeicher.
Sauber gehen die nur raus, wenn wenig im FHT Speicher abzuarbeiten ist (also der Speicher vorher leer ist). Wenn noch ein paar Sachen 2-10 drinstehen kann man sicher davon ausgehen, dass ein Mode-Befehl hängenbleibt und nur über das Timeout gekickt wird. Das war „früher“ auch nicht so.
Ich hab heute mal wieder etwas intensiver die Kommunikation des FHT aufgezeichnet. Unter anderem komplette Neuinitialisierungen.
Dabei ist mir was sehr Interessantes aufgefallen:
Normalerweise erkennt man an der LED der FHZ, dass Daten reinkommen. Heute habe ich einen Ventilantrieb neu synchronisiert. Hierbei wird jede Sekunde ein Sync-Telegramm gesendet. Dies wird auch brav von der FHZ empfangen (steht im Log) aber die LED zeigt diese nicht an.
Und jetzt kommen mir wieder Zweifel zu der (mir ansich einleuchtenden) Unabhängigkeit des Datentransfers zwischen FHT<>FHZ und FHT<>Ventilantrieb. Denn wozu sollte der Raumregler zum Synchronisieren des Ventilantriebes Daten mit dem Protokoll der FHZ raus schicken??? :eek:
Irgendwie kann ich die Entwickler von diesen Dingern nicht ganz verstehen.
Sicherlich werde ich einige hier wieder langweilen mit diesen Aussagen, doch seit ich mit mehr als nur einer FHZ fahre, habe ich keine Ausfälle mehr, weder Probleme in irgendeiner Form.
Dies sind die ersten „echten“ Probleme seit einem Jahr. Die Tatsache, dass die Daten nachweislich bei den FHTs ankommen und sogar im state bestätigt wurden aber dennoch in der Q stehen, entlässt die FHZs aus der Schuldfrage. :rolleyes:
