Vermutung: Die FHZ synchronisiert auf die empfangenen Positionsdaten vom FHT (die kommen ziemlich regelmäßig alle 117…118 Sekunden) und weiss dann, wann das Empfangsfenster offen ist und sendet den nächsten Befehl an den FHT.
Protokolle sind urheberrechtlich geschützt, bitte bei Postings beachten!
Gruss Torro
Das meinte ich auch.
Dann steht aber immer noch die Frage:
Auf Deutsch: woran erkennt die FHZ, dass der FHT den requst empfangen hat - respektive (wenn ohne Rückmeldung) dass er ihn überhaupt haben will?
OK, indem ich den FHT anmelde… aber merkt sich die FHZ das? Oder sendet der FHT jedesmal eine besondere Kennung mit, dass er jetzt Daten empfangen will?
Der FHT scheint für ein gewisses Zeitfenster ca. alle 2 Minuten empfangsbereit zu. sein Wenn das Telegramm für ihn bestimmt ist (das erkennt er am Code), dann frisst er das meiner Meinung nach ohne wenn und aber. Auch die FHZ hat einen Code, der sich mit der Comtronic-SW ändern lässt. Ich nehme an, dass der FHT diesen Code während der Anmeldung speichert und dann nur noch auf diese FHZ reagiert.
Ok das erklärt das Verhalten des FHT. Dabei ist aber immer noch nicht klar, wie es um die FHZ steht.
Denn wonach entscheidet die FHZ ob sie einen Befehl als gesendet markiert und IPS sie aus dem Buffer nehmen kann oder ob sie ihn nicht an den FHT losgeworden ist? Eingeschlafene FHTs nehmen ja auch keine Befehle mehr an. Diese bleiben dann doch sicher auch im Buffer hängen… oder liege ich hier falsch? 
Nein, diese Befehle gehen auch raus ! Wenn mal ein FHT keine Daten mehr sendet, auch über einen längeren Zeitrahmen, schickt die FHZ dennoch den Telegramm raus udn kommen auch beim ‚eingeschlafenen‘ FHT an. Das konnte ich gut beobachten.
mfG Franz
…jedemand (weiss nicht mehr wem)
ABER: Dreht man am Rad ODER der FHT schaltet im Auto-Modus die Solltemperatur um, dann erscheinen im Debugger exakt die gleichen Datenbytes wie beim Senden mit FHT_SetTemperature nachdem der Befehl die Queue verlassen hat.
Hierum geht es … nur ! Hat es die gleiche verhaltniss in MANU-betrieb ?
Ich warte es mal ab
Wenn es so sei : wie soll das FHT instanz geändert werden? -> hängt davon ab ob das protokoll auch meldet in was fur ein modus der FHT arbeitet. Sondern kann mann nie wissen ob der neue SOLL-temp (target state IPS request) aus einer FHT_SetTemp oder in AUTO betrieb durch FHT eigenes Programm oder offen turschalter gesetzt wird.
Was sein kann weil : das schliessen von eine offene fenster wird durch dem FHT auch mit das senden der vorherige SOLL-wert bestätigd…
Da soll Paresy mal ran…
Ich nehme heute abend mal die ersten geh-versuche wieder durch die wir damals aufgelisted haben.
Have a nice day
Fredje
Torro hat meine Untersuchungen aus urheberrechtlichen Bedenken gelöscht, aber ich darf wohl folgendes sagen:
Ob man am Rad dreht oder der FHT im Auto-Modus den Sollwert ändert oder per IPS den Sollwert ändert, in allen Fällen empfängt der FTDI die gleichen Rohdaten vom betroffenen FHT. Verifiziert an Hand des FHT-Codes (Hauscode) und dem Temperaturwert.
Was natürlich immer noch nicht ausschließt, dass Paresy die Response-Variable selber setzt.
Also ich misch mich denn auch mal ein 
Alles was Ihr im Debugger seht ist was die FHZ an IPSym geschickt hat. Es sind also Meldungen der FHZ. Was die FHZ meldet ist nicht unbedingt per Funk angekommen, sondern kann auch von der FHZ selbst erstellt sein (z.B. eine Quittung nach senden).
Die FHZ quittiert offensichtlich das Senden eines packets. Ob das aber einfach bedeutet „habs in den Timeslot geschossen“, oder „FHT hats per Funk bestaetigt“ wissen wir nicht.
Soweit ich es beobachte, sind die Timeslots alle 116 Sek offen.
Genauso oft kommen die Stelldaten rein. Die FHZ erkennt anhand der empfangen Stelldaten das der FHT in Reichweite ist und weiss dann wann der naechste Timeslot ist (115 Sek. nach Empfang). Pakete werden dann zu dem Zeitpunkt abgesetzt und als gesendet an den PC quittiert.
Die Frage ist natürlich auch sehr interessant.
Wer kann sagen, ob dieser Telegram von ‚aussen‘ kommt, oder ob die FHZ auch auf diesem Wege mit IPS kommuniziert ?
PARESY !!!
mfG Franz
Genau so ist es. Punkt.
Wer es nicht glaubt, kann ja mal den ips_debug anmachen und gucken, was der FHT wann sendet.
Der FHT sendet nur den SollWert wenn man
a) Am Rad dreht
b) Der Auto Modus den Sollwert verändert hat
Die Vermutung, dass der FHT den Sollwert auch schickt, wenn IPS den gesetzt hat, ist falsch. Das ganze wird Softwaretechnisch, wie guyabano es gesagt hat, emuliert, sobald die FHZ das OK liefert, dass der Befehl an den FHT durchgegangen ist.
paresy
Wer es nicht glaubt, kann ja mal den ips_debug anmachen und gucken, was der FHT wann sendet.
Genau das hab ich gemacht.
Der FHT sendet nur den SollWert wenn man
a) Am Rad dreht
b) Der Auto Modus den Sollwert verändert hat
So weit Zustimmung.
Die Vermutung, dass der FHT den Sollwert auch schickt, wenn IPS den gesetzt hat, ist falsch.
Genau damit hab ich ein Problem. Im Debugger kommen in diesem Fall genau die gleichen Bytefolgen an. Die Frage ist, emuliert das die FHZ oder sind das tatsächlich empfangene Daten?
Das ganze wird Softwaretechnisch, wie guyabano es gesagt hat, emuliert, sobald die FHZ das OK liefert, dass der Befehl an den FHT durchgegangen ist.
Und wie genau sieht dieses OK aus? Unterscheidet sich das von einem Telegramm, das nach Drehen am Rad gesendet wird?
Das stimmt nicht. Guck nochmal genau… Da sind ein paar Byte mehr und verschoben 
Und wie genau sieht dieses OK aus? Unterscheidet sich das von einem Telegramm, das nach Drehen am Rad gesendet wird?
Das siehst du, wenn du das 1. Problem gelöst hast.
paresy
Ich hab genau hingesehen und die Ergebnisse hier gepostet. Ich konnte keinen Unterschied erkennen. Leider hast du das verpasst weil Torro die Debugger-Ergebnisse gelöscht hat.
Das siehst du, wenn du das 1. Problem gelöst hast.
Ich denke nicht, dass ich mir ein zweites Mal die Mühe mache.
Es herrscht wieder ruhe in dieser Thread … pfffieeuw
danke
Ware ganz verunrurht
hehe… soll ich neues öl in’s feuer giessen? wie wäre es mit direkter ansteuerung der stellventile per funk ohne die regeleinheit 
aber das thema lassen wir mal lieber…
@Olli :
Obwohl, ich würde es begrüssen, würde ein FHT eine Empfangsbestätigung von einer Target-Wert-Änderung erfolgen !
mfG Franz
„Now don’t start that again“
Ich habe es angefangen und will es auch zu Ende bringen…
Das oben angesprochene Script liefert tatsächlich (leicht) schwankende Werte bei der Quality.
Durch die Erklärung von paresy (vielen Dank für die Klarheit!) ist ein solches Verhalten aber unmöglich! Denn die Empfangsbestätigung kommt definitiv direkt nach der pos-Meldung - und zwar immer!
Nach genauem Studium der zeitlichen Abfolge der Variablenänderung habe ich das Problem entdeckt:
Da beide laut log-Datei exakt (auf die Hundertstel Sekunde) zum gleichen Zeitpunkt kommen lief das Script durch die Trigger zwei mal parallel. Und wer zuletzt speichert hat gewonnen! 
Jetzt habe ich den Trigger durch den pos-Wert um 100ms verzögert und schon steht niemals etwas anderes als 7 (>> 100%) in der Quality.
Also Schluss mit dem Theater und neuen Ansatz suchen! 
Amen - wir danken Gott
Entschuldigt bitte, aber ich muss dazu nochmal was fragen. Auch mit dem geänderten Script konnte ich in den letzten Tagen einige Sendeausfälle nachvollziehen.
und schon steht niemals etwas anderes als 7 (>> 100%) in der Quality
Da war ich wohl im letzten Statement zu voreilig.
Diese haben definitiv nichts mit dem Script zu tun! Der request wird gesetzt doch der state blieb unverändert. Dies habe ich im Log geprüft! Dort findet sich kein Eintrag des state-Wertes.
Dazu eine Frage:
Wenn der Befehl nicht rausgeht, wie lange bleibt er dann im Buffer?
Hintergrund:
Da ich das Sendeverhalten meines sFHTs gegenüber dem Original von Fredje etwas geändert habe, sende ich nur wenn der state nicht dem soll entspricht. Kann ich gern an anderer Stelle nochmal erklären…
Daher wurde beim nächsten Aufruf (genau eine halbe Stunde später) der request erneut gesendet und ging sofort durch.
Daher interessiert mich, wie lange der request im Buffer bleibt.
Gruß
Fabian
PS: bitte keine Grundsatzdiskussionen mehr, ich versuche nur meine Beobachtungen zu erklären