Die FHT’s senden die Sollwerte NUR wenn man am Rad dreht. Der Wert wird (bei mir) nicht Zyklisch übertragen. Ebenso wie der MODE - dieser kommt auch nur wenn man ihn am FHT ändert.
Die zyklischen Daten sind: IST-Temp, Ventil-POS und Fenster-Status
Gruß René
Das ist falsch. Diese Variable wird geupdated, sobald im FHZ Buffer-Fenster die Meldung ‚Sent Message - OK‘ erscheint, unabhängig davon, ob der FHT nun wirklich den Telegramm bekam, oder nicht ! Dabei ist es egal ob nun Mode oder Temperatur !
mfG Franz
So, nun wird die Diskussion losgehen ! 
Gibt es da kein Lokal wo man sich treffen kann ?
mfG Franz
Hier das Ergebnis:
Setzen der Solltemperatur über WIIPS auf OFF:
2007-01-09 11:27:44 ; Arbeiten.Mode.Request ; Integer ; 1
2007-01-09 11:27:44 ; Arbeiten.Temperature.Request ; Float ; 5.50
Die Antwort vom FHT:
2007-01-09 11:28:49 ; Arbeiten.Position ; Float ; 0.00
2007-01-09 11:28:49 ; Arbeiten.Temperature.Set ; Float ; 5.50
2007-01-09 11:30:47 ; Arbeiten.Mode ; Integer ; 1
Setzen der Solltemperatur über WIIPS auf ON:
2007-01-09 11:31:33 ; Arbeiten.Temperature.Request ; Float ; 30.50
2007-01-09 11:31:33 ; Arbeiten.Mode.Request ; Integer ; 1
und die Reaktion:
2007-01-09 11:32:45 ; Arbeiten.Temperature.Set ; Float ; 30.50
2007-01-09 11:32:45 ; Arbeiten.Position ; Float ; 0.00
Mein Limit-Skript schlägt zu und setzt die Temperatur auf 22.0 und den Mode auf AUTO (die 2 Sekunden Verzögerung kommen von diesem Skript):
2007-01-09 11:32:47 ; Arbeiten.Temperature.Request ; Float ; 22.00
2007-01-09 11:32:47 ; Arbeiten.Mode.Request ; Integer ; 0
In der Queue hat sich einiges angesammelt und wird abgearbeitet:
2007-01-09 11:34:42 ; Arbeiten.Mode ; Integer ; 1
2007-01-09 11:36:40 ; Arbeiten.Mode ; Integer ; 0
2007-01-09 11:36:40 ; Arbeiten.Position ; Float ; 0.00
2007-01-09 11:38:37 ; Arbeiten.Temperature.Set ; Float ; 22.00
Nachdem die Queue leer ist kommen nur noch Positions- und Ist-Werte:
2007-01-09 11:40:33 ; Arbeiten.Position ; Float ; 75.00
2007-01-09 11:40:34 ; Arbeiten.Temperature ; Float ; 18.40
2007-01-09 11:42:31 ; Arbeiten.Position ; Float ; 75.00
2007-01-09 11:44:28 ; Arbeiten.Position ; Float ; 75.00
Hier der Skript, mit dem obige Log-Datei erzeugt wurde. Einzige Vorraussetzung: Im IP-SYMCON-Verzeichnis muss ein Unterverzeichnis „data“ vorhanden sein, oder man muss die Variable $path anpassen.
<?
/*
*******************************
IP-SYMCON Event Scripting
*******************************
File : Log_FHT_Special.ips.php
Trigger : OnUpdate of variables to be monitored
Interval :
*/
$debug = FALSE;
$scriptname = $IPS_SELF;
$filedate = date("_Y-m");
$path = IPS_GetKernelDir()."data\\";
$filename = "{$path}{$scriptname}{$filedate}.log";
$filemode = "a+";
if ($debug) IPS_LogMessage($scriptname, $IPS_SENDER);
if ($IPS_SENDER == "Variable") {
$file = fopen($filename,$filemode);
$name = $IPS_VARIABLE;
$lastupdate = date("Y-m-d H:i:s",IPS_GetUpdateTime($name));
$type = IPS_GetVariableType($name);
fprintf($file,"%-20s; %-30s; %-8s; ",$lastupdate,$name,$type);
switch(IPS_GetVariableType($name)) {
case "Float":
$float = GetValueFloat($name);
if ($debug) IPS_LogMessage($scriptname,$lastupdate." ".$name." ".$type." ".(string)$float);
fprintf($file,"%6.2f",$float);
break;
case "Integer":
$integer = GetValueInteger($name);
if ($debug) IPS_LogMessage($scriptname,$lastupdate." ".$name." ".$type." ".(string)$integer);
fprintf($file,"%6d",$integer);
break;
case "Boolean":
$value = GetValueBoolean($name);
$bool = "FALSE";
if ($value) $bool = "TRUE" ;
if ($debug) IPS_LogMessage($scriptname,$lastupdate." ".$name." ".$type." ".(string)$bool);
fprintf($file,"%6s",(string) $bool);
break;
case "String":
$string = GetValueString($name);
if ($debug) IPS_LogMessage($scriptname,$lastupdate." ".$name." ".$type." ".(string)$string);
fprintf($file,"%6s",(string) $string);
break;
}
fprintf($file,"
");
fclose($file);
}
?>
Also, ich bin nun zuhause, und kein einziger FHT hat seit mindestens 7 Tagen auch nur einen Sollwert übermittelt.
Klar wird der Sollwert aktualisiert, aber das wird programintern gesetzt, nachdem der Telegram von der FHZ raus gesendet wurde.
Zur Reihenfolge:
[ol]
[li] Mit einem SetTemp setzt du einen neuen Sollwert.[/li][li] Der wird nun in Target Request reingeschrieben und im gleichen Moment zur FHZ geschickt wo dann die Instanznummer/Uhrzeit/pending steht. [/li][li] Beim nächsten SendeFenster geht der Telegramm dann raus, und sobald in dem FHZ Fenster ‚OK‘ erscheint, wird die Sollwert Variable programm intern auf den neuen Wert gesetzt, was dann auch im Debugger erscheint.[/li][/ol]
Der Punkt 3 ist der Teil, wo du glaubst, der FHT sendet dir den Sollwert, doch es wird, wie gesagt Programmintern gesetzt !
Aber Fakt ist, der FHT sendet dir keine Sollwerte, ausser, du drehst am Stellrad !
Ich denke, Paresy wird das so bestätigen
mfG Franz
Ich bin nicht deiner Meinung. Im Debugger erscheinen unter Instances -> FHT exakt zu dem Zeitpunkt, zu dem die Sollwert-Variable (Target State FHT Response) aktualisiert wird entsprechende Datenbytes vom betroffenen FHT. Das lässt sich eindeutig aus den ersten beiden Bytes, also dem FHT-Code ablesen. Man könnte sich die Mühe machen und sämtliche empfangenen Datenbytes zu decodieren, aber das ist mir im Moment zu viel Arbeit. Aus dem Debugger heraus funktioniert leider kein Cut&Paste, sonst könnte ich das hier leichter darstellen.
Richtig Franz,
ich kann das auch so bestätigen. Es wird lediglich die Variable für die Soll-Temp im Variablenmanager nochmal aktualisiert, sobald die FHZ die Sendung übermittelt hat.
Sollwertvorgabe durch SetTemp:
neue Sollwertvorgabe SetTemp -> Variable wird neu gesetzt -> Daten in Speicher der FHZ -> Warten bis FHT für Empfang bereit -> Daten gehen raus -> Variable wird nochmals neu gesetzt
Sollwertvorgabe durch Drehen am Rad:
neue Sollwertvorgabe am FHT -> FHT sendet an FHZ den neuen Sollwert -> Variable in IPS wird aktualisiert.
Ansonsten ist da Funkstille was den Sollwert angeht - so ist zumindest meine Beobachtung.
Die Datenbyte die man im Debugger sieht sind meiner Meinung nach die Daten die in diesem Moment zum FHT gesendet werden… im Debugger steht irgendwie immer „Received“
So schnell geb ich nicht auf 
. Was würde im Debugger dann passieren, wenn man die Target State FHT Response Variable in der FHT-Instanz löscht?
Das klingt immer gut, hartnäckig dranbleiben ! Ich bitte dich dennoch diesen Thread zu lesen.
Seit du dich ja noch als Newbie bezeichnest, werde ich dir folgende Vorgeschichte erzählen.
In den vorherigen Versionen von IPS ging es anders zu.
Hier ein Beispiel:
Du setzte per FHT_SetMode einen Regler per PHP Skript auf Manual. Dann verlangst du von deinem Skript, sobald der Regler auf manual ist, tu dies tu das !
So, der Befehl FHT_SetMode beeinflusste direkt die Target_Mode Variable, dennoch, der Regler war ja gar nicht auf Manual, sondern lediglich der befehl in der FHZ. Also musste der noch durch die FHz zum FHT gelangen, was aber manchmal erst nach bis zu 30 Minuten geschah, oder eben gar nicht und im Timeout endete. Doch für dein Skript war der Regler schon längst auf Manual !
Also wurden verschiedene Lösung vorgeschlagen, und Paresy hielt dann eine zurück. Der Befehl wurde einfach zuerst in eine Zwischenablage verfrachtet, eben die IPS_Request, dann zum Buffer der FHz, dann zum FHT gesendet. Dann wurde gewartet, bis der FHT die neue Target_Variable bestätigt, und schon hättest (ich sage wohl - hättest) du das gehabt, was du hier so vehement vertrittst.
Nur leider ging das in die Hose ! IPS sendete wohl den Telegramm an den FHT, der jedoch ‚antwortete‘ nicht. GGGss und ich, und auch noch weitere haben das ausgiebig getestet. Doch der Regler wollte partout die Veränderung nicht bestätigen. D.h. der Regler stand wohl auf Manual, jedoch die Variable in IPS ‚wartete‘ noch immer.
Fazit: Manche Skripts wurden eben falsch ausgeführt. Z.b. für diejenigen, die dann im Manual Modus jetzt auf die Zeiten vom Skript verzichten wollten, wurden weiterhin von IPS bedient, da in IPS der FHT noch immer auf Automatik stand.
Also, Modul musste noch mal umgeschrieben werden.
Jetzt klappt das Modul wunderbar, auch wenn ein kleiner Wehmutstropfen bleibt. Es wäre schön gewesen, wenn der FHT die Bestätigung geschickt hätte, anstelle mit dem Trick aus dem Buffer die Target Variable zu ändern.
Du kannst zwar noch weiter auf deiner Position beharren, aber es ist leider nicht so. Doch ich wünsche mir, es wäre so. Doch dafür müsste man mit den leuten von ELV reden, damit die das ändern in Version 3 der FHT’s !
mfG Franz
Was ist den hier los ?
Ich hab jetzt keine zeit - aber später lese ich das noch mal ganz durch?
FHT ist BiDi ? und in auto-betrieb ?
Wenn das war wäre 
:eek: was haben wir hier gemacht das laetzte Jahr? oder 2?
Hilfe !
Es geht nicht darum, dass ich auf einer Position beharren will und ich kenne die Vorgeschichte auch nicht.
Ich geh an das Thema völlig unbefangen und unbelastet heran. Nach allem, was ich bisher gesehen und selbst ausprobiert habe (z.B. mit dem Debugger), sieht es für mich so aus, dass der FHT den Sollwert sendet. Es fällt mir schwer zu glauben, dass dem nicht so ist. Selbst wenn man die Target State Response Variable löscht, sieht man im Debugger unter empfangenen Daten die entsprechenden Datenbytes.
Nana, Fredje, willkommen in der Runde. Nimm dir einen Stuhl !
Wir haben die letzten 2 Jahre verpennt, dass die FHT’s Sollwerte senden?
Wie gesagt, ich wünschte, dem wäre so. Dann hätten wir verschiedene Probleme weniger !
mfG Franz
Ich hab den Thread gelesen und im letzten Posting von Paresy könnte man tatsächlich zu dem Schluss kommen, dass die Response-Variable per SW und nicht durch eine Antwort vom FHT gesetzt wird.
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.
Genau deshalb bin ich nicht zu 100% überzeugt, dass der FHT den Sollwert nicht sendet.
Nachtrag: Selbst auf FTDI-Ebene werden Received Bytes exakt zu dem Zeitpunkt angezeigt zu dem sich die Response-Variable ändert.
WAHNSINN!!!
Da ist man mal den Tag über unterwegs und kann gar nicht genießen, was man hier für eine Diskussion losgetreten hat. :rolleyes:
Also ich vermisse ein Statement von paresy. Solange er sich nicht äußert, können wir uns an den Kopf werfen, was wir wollen.
Allerdings interresiert mich die Ausgabe des debugger auch. Woran erkennt man, dass es sich um den state handelt? Wie muss man die Bytes lesen?
Wie erklärt es sich dann, dass die Quality schwankt? Sind die Trigger daran schuld?
Die im Debug angezeiegten Eingangsdaten sind sehr wahrscheinlich die pos-Meldungen, denn diese kommen exact zum gleichen Zeitpunkt.
Gruß
Fabian
Ich halte mich jetzt auch raus. Nur Paresy kann hier das ganze auflösen !
mfG Franz
Ich habe gerade mal ein paar Versuche mit den FHTs gemacht.
Um mal eine Tatsache zum Nachdenken zu bringen:
Woran erkennt die FHZ, dass Sie einen Request erfolgreich (oder überhaupt) abgesetzt hat?
>> Der state wird genau zu dem Zeitpunkt gesetzt, bei dem die pos-Meldung reinkommt. Wenn der FHT nicht angemeldet ist, kommen aber auch pos-Daten und der request bleibt im Buffer. Genau das passiert auch, wenn mal ein FHT „eingeschlafen“ ist.
Auf Deutsch: woran erkennt die FHZ, dass der FHT den requst empfangen hat - respektive (wenn ohne Rückmeldung) dass er ihn überhaupt haben will?
Paresy hat es softwaremässig gelöst. Sobald die FHZ rückmeldet, dass der Befehl raus ist, wird die Target Variable gesetzt. So einfach ist das.
Ob Empfang oder nicht Empfang des FHT, die Target Variable wird gesetzt werden, sobald die FHZ OK meldet.
mfG Franz
Genau das ist ja meine Frage, woher weiß die FHZ wann es „OK“ ist?
Die FHZ weiss es auch nicht ob der Befehl nun tatsächlich am FHT ankam ! Sie gibt nur OK raus, wenn der Befehl abgesetzt wurde ! Das genügt ihr ! Wenn ein FS20 Befehl rausgeht, erwartet die FHz ja auch keine Bestätigung, sondern schickt in blindlings raus !
mfG Franz