hehe
Wenn der Befehl nicht rausgeht, wie lange bleibt er dann im Buffer?
Ich denke endloss… wenn’s ne FHT gibt die nicht mehr angemeldet ist bleiben die befehle stehen bis … der IPS-absturz oder neu start.
Nach 30 minuten neu senden … ist gut möglich das dan deine 2 werten durchgehen ohne probleme. Hängt ab vom funksalat.
Schönen Sonntag
Wie ist die genaue Funktionsweise der Queue?
Ich denke mir das so:
Mit dem FHT_Set… wird die Temperatur als request in den Buffer der FHZ geschoben. Ist die Nachricht an den FHT raus, wird der Eintrag gelöscht.
Bleibt die Message im Buffer hängen, müsste sie irgendwann (~1h ???) wieder gelöscht werden. Denn wie bei jeder Queue werden die Befehle (zumindest für ein und dieselbe Instanz) nacheinander abgearbeitet.
Wenn also nach einer halben Stunde der nächste request an den gleichen FHT durchgeht, muss der vorhergehende (hängengebliebene) gelöscht worden sein. Denn ich kann genau nachvollziehen, dass der nächste durchgehende request erst genau durch den nächsten Scriptaufruf entstand und nicht „irgendwann zufällig“ durchging.
@paresy:
Kannst Du diesen Vorgang bitte mal genauer beschreiben?
Ich hoffe, das verstößt nicht wieder gegen irgendwelche Urheberrechte… 
Gruß und schönen Sonntag
Fabian
Hallo Fabian,
die Telegramme bleiben für etwas länger als 60 Minuten im Buffer.
Danach werden sie für ein paar weitere Minuten mit „Timeout“ gekennzeichnet.
Dann werden sie gelöscht.
Der Buffer, den man in den Instances ansehen kann, ist ein sekundärer Buffer, der von Paresy in der beschriebenen Weise verwaltet wird.
Die FHZ enthält einen eigenen (primären) Buffer, den sie selbst verwaltet.
Wie das Timing dort gehandhabt wird, ist mir nicht bekannt.
Ich weiss aber mit Sicherheit, dass auch Telegramme, die mit Timeout gelöscht wurden, durchaus noch sehr viel später aus dem internen Buffer versendet werden können.
Ein Timeout beweist also nicht, dass das Telegramm verloren gegangen ist.
Gruß
HJH
Das bringt mich wieder zu der Frage:
Auf Deutsch: woran erkennt die FHZ, dass der FHT den request empfangen hat - respektive (wenn ohne Rückmeldung) dass er ihn überhaupt haben will?
und wie teilt die FHZ das IPS mit???
Hallo liebes Forum,
wollen wir noch ein Tänzchen wagen? 
Da die Antwort auf meine letzte Frage noch offen steht, habe ich selbst noch ein wenig gegraben.
Also ich habe mich nochmal ein wenig mit der Kommunikation des FHT beschäftigt. Über einen Link zur FHZ-Linux Gemeinde, welcher hier bereits irgendwo gepostet wurde, habe ich mir mal den dort beschriebenen Datentransfer der FHZ (über USB) angesehen.
Dort steht am unteren Ende des Bereiches für den FHT etwas von „Übernahmequittung“. Nun habe ich mal mit einer RegisterVariable „mitgelauscht“ und ein paar Bytes dekodiert. Da findet sich tatsächlich eine „Quittung“ zur Übernahme der Solltemperatur vom FHT. Und siehe da, der FHT-Code und die gesetzte Temperatur stimmen überein…
Das gibt mir doch schwer zu denken. :rolleyes:
Ich darf die Protokolle zwar hier nicht veröffentlichen, aber wenn jemand Hilfe braucht… 
Gruß
Fabian
Hmmm, ja, es mag sein, dass 'ne Quittung aus der FHZ rausgeht zu IPS. Nur hast du immer noch nicht die Bestätigung, wer nun diese Quittung rausgibt, ob der FHT die zur FHZ sendet, und die sie weiter gibt an IPS, oder ob die FHZ nur diese Quittung selbst generiert und an IPS…
Ich konnte aus Paresy’s Wörter klar entnehmen, dass die FHZ das tut, und nicht etwa ein FHT.
So wie ich das ganze sehe ist es einfach: Die FHZ wartet auf sein Zeitfenster. Und das kommt genau dann, wenn die Ventilposition reinkommt (soweit sind wir schon). Dann sendet die FHZ ein Telegramm, falls einer in der Queue steht. Nach absetzen dieses Telegramms wartet die FHZ nicht darauf, dass sie eine Bestätigung bekommt von dem FHT, sondern generiert direkt einen Telegramm für IPS: ‚Der Telegramm ist raus‘ !
mfG Franz
Ja so habe ich mir das auch gedacht.
Aber warum bleiben dann immer mal Befehle in der Queue stehen obwohl der FHT fleißig weiter seine Daten (pos usw.) sendet, anscheinend aber nichts mehr empfängt?
Erst gestern Abend hatte ich den umgekehrten Fall:
Ein Befehl blieb als ungesendet in der Queue stehen, obwohl der State gesetzt wurde (Temp ging raus) und das konnte ich in meinem Log auch nachvollziehen.
Dies scheint jedoch ein Kommunikationsproblem mit IPS zu sein. Denn den kompletten Ablauf habe ich mitgeloggt und die Daten sind eindeutig korrekt.
Dabei stellt sich eine neue Frage: warum wird der State auf den angeforderten Wert gesetzt, wenn der Befehl noch als ungesendet im Buffer steht?
Es gibt nur eine Quittung anhand derer IPS entscheiden könnte, das der Befehl raus ist. Und dieser sollte den Befehl in der Queue löschen und den State setzen.
Gruß
Fabian
@paresy:
Nutzt Du die Funktion 7E 00 oder die eigentliche Quittung?
Hallo Fabian,
die selbe Beobachtung habe ich auch gemacht.
Ich bin der Meinung, dass die Kommunikation (Handshake) zwischen IPS und FHZ noch nicht wasserdicht ist.
Paresy sollte sich das noch einmal ansehen.
Gruß
HJH
Aus was in die linux genmeinschafft bekannt ist, ist 7E der ‚ende block‘ oder ende data-telegramm ./… also nee:
Nutzt Du die Funktion 7E 00 oder die eigentliche Quittung?
Aus was in die linux genmeinschafft bekannt ist, ist 7E der ‚ende block‘ oder ende data-telegramm
Interessant… woher hast Du das ?
Ich habe mir die Funktion mal genauer angesehen (ich hoffe, es gibt jetzt nicht wieder das Problem mit dem Urheberrecht):
Wenn ich an den FHT einen SetTemp schicke, steht diese Temp nach der Quittung für einen Zyklus im Parameterfeld des 7E. Wenn der Befehl raus ist und der State gesetzt wurde, wird der Parameter im 7E im nächsten Zyklus (immer ca. 15min) wieder 00.
Mal sehen, was passiert, wenn ich den Mode setze…
Gruß
Fabian
Mal eine bescheidene Frage.
Über welche Version der FHT geht es hier?
Es gibt nur eine Version des FHT, der bidi ist , das ist der FHT80b.
mfG Franz
Wenn denn alles stimmt, habe ich eine Version 2 ?
Soweit mir dieses bekannt ist, gibt es wohl verschiedene Versionen:confused: