ich muss nochmal ein Thema bezüglich des umstrittenen Befehls FHT_Request_Data aufleben lassen.
Wird der Befehl ausgeführt, so verstummen ja bekanntlich alle FHT’s.
Bzw. senden nur einmal ihren Datensatz (direkt nacht dem Request) und verstummen dann. Ist das so?
Was passiert beim nächsten FHT_Request?? Senden die Systeme dann wieder Daten?
Hat das mal jemand ausprobiert?
Das Problem was ich habe:
Die FHT’s senden hin und wieder ihre Daten aus. Dies dauert „sehr lange“ (1 bit im Mittel so etwa 1ms). Bei mir kommt es wohl öfter zu Paketkollisionen (habe „nur“ 3 FHT’s) und das nervt etwas.
Würden die FHT’S nur noch auf den RequestBefehl hin senden und sonst schweigen, dann könnte man den Datenfluss ein wenig besser kontrollieren.
Wer hat mal genauer getestet??
Ansonsten würd eich das halt mal tun :o
hab’ zwarnur einmal den Befehl gesendet und damit meine FHTs „abgeschossen“ (musste die Teile 30 Minuten ohne Strom liegen lassen, alle Kontakte brücken um die Elkos leer zu ziehen und im IPS komplett löschen und neu anlegen und anmelden) - hat mich alles in allem ca. 20 Minuten pro FHT gekostet - hab 4 davon im Einsatz
Wenn du dir das unbedingt antun willst, teste doch mal bitte, ob ein request in 10 Minutenabstand funktioniert - und ob die FHTs dann trotzdem noch auf FHT_SetMode etc. reagieren.
Zum Testergebnis könntest du mir noch ne Info dazuschreiben, welche fhz du hast - bei der 1300er soll doch die fht-Kommunikation deutlich besser funktionieren als bei der 1000er.
Ich wurde ABSOLUT abraten FHT_RequestData zu nutzen.
Habe nichts wie probleme gehabt damit.
FHT_Request bringt dir in die timing auch niks, weil die daten die aus dem request_data befehl rausfliessen auch zb das wochenprogramm und so geben, und diese menge daten werden uber mehrere send-blocks rausgeschickt.
Damit bekommst du absoluter funk-salat, wenn der kommando jede 10 minuten abgeschossen wird.
Mein rat:
in eine FHZ1000 umgebung ‚nur‘ jede 12minuten*{anzahl FHT’s in einsatz}etwas senden (wie soll-temp oder sonstiges.)
in eine 1300’er umgebung liegt der max. wert (UNBESTÄTIGT) denke ich bei (6minuten*anzahl FHT’s) (ohne buffer probleme angeschaut zu haben).
Habe noch welche FHT’s in bestellung - komme bestimmt darauf zuruck.
Was möchtest du senden zu die FHT’s wo du nicht warten kannst? Jede 10-e minute eine neue soll-wert? Macht doch kein sinn !
Mann muss in eine 1000-er umgebung unbedingt die sende blocks frei lassen (also keine kommando’s ruber senden die nicht unbedingt nötig sind - selber nicht im debug oder so) um der empfang der daten offen zu lassen.
Meine Erfrahrung ist so das unter oberige konditionen bis zu 3 FHT’s laufen können; mehr gibt timing probleme (hatte damals 5 im einsatz und der laetzte hat sich nur 1x / tag gemeldet).
Also, ich habe jetzt 11 FHT’s im Einsatz und es läuft super.
Es ist ein wenig Schweiss geflossen und hat auch am Nervenkostüm gezerrt aber es geht.
Auf jedenfall diesen Request_Data Befehl vergessen. Bringt wirklich nichts!
Die FHT’s sollten schön einer nachdem dem anderen bearbeitet werden. Es ist ja so, dass du nicht die ganze Zeit am Befehle senden bist. Es kommt gelegentlich zu kleinen „Rush-hours“, wenn alle langsam auf Nacht Program schalten sollen (und umgekehrt) aber wenn du hier alle Zeiten nur um ein paar Minuten verlegst, das wird das auch klappen.
Am besten verfährst du, wenn du ein Script schreibst (ich nenne es FHT_LOOP) was im Minutentakt einen Zähler inkrementiert. Dei jedem Zählerstand bearbeitest du dann einen anderen FHT. Meine Schleife läuft eben bis 11. D.h. jeder FHT Script wird jede 11 Minuten durchlaufen.
Wenn genügend Abstand ist, werden die FHT’s eigentlich sehr gesprächig.
Ausserdem, seit ich die USB Verlängerungskabel angeschloosen habe, und meine FHZ mittig im Haus plazieren konnte kommen die Werte auch fliessend rein.
$fht_loop = GetValueInteger("FHT_LOOP_COUNTER");
if ($fht_loop < 11) $fht_loop = $fht_loop + 1;
else ($fht_loop = 0);
SetValueInteger("FHT_LOOP_COUNTER", $fht_loop);
switch ($fht_loop)
{
case 1 : IPS_RunScript("FLOOR_FHT");
break;
case 2 : IPS_RunScript("KITCH_FHT");
break;
case 3 : IPS_RunScript("SALA_FHT");
break;
case 4 : IPS_RunScript("WC_FHT");
break;
case 5 : IPS_RunScript("BATH1_FHT");
break;
case 6 : IPS_RunScript("BATH2_FHT");
break;
case 7 : IPS_RunScript("KID1_FHT");
break;
case 8 : IPS_RunScript("KID2_FHT");
break;
case 9 : IPS_RunScript("MASBED_FHT");
break;
case 10 : IPS_RunScript("KID3_FHT");
break;
case 11 : IPS_RunScript("COMP_FHT");
break;
}
und dann ein FHT „Modul“ hier in diesem Fall BATH1 was soviel wie Badezimmer 1 bedeutet:
$FHT_mode = GetValueInteger("BATH1_FHT_TARGET_MODE");
$WINDOW_status = GetValueBoolean("BATH1_FHT_ACTUAL_WINDOW");
$house_status = GetValueBoolean("HOUSE_STATUS");
// --- Execute Automatic only when Window closed and Mode = Automatic ----------
if (($WINDOW_status == False) AND ($FHT_mode == 0) AND ($house_status = True))
{
$hour=date("H");
$minute=date("i");
$time = $hour.":".$minute;
$heute = array("Sunday","Monday","Tuesday","Wednesday","Thursday","Friday","Saturday","");
$tag = date("w");
// Read last Target Value
$newtemp=GetValueFloat("BATH1_FHT_MEMO_TEMP");
// Choose Normal or Holiday Parameter-File
if (GetValueBoolean("BATH1_ROOM_STATUS") == False)
$handle = fopen("C:/Program Files/IP-Symcon/DATA/BATH1_FHT.par","r");
else
$handle = fopen("C:/Program Files/IP-SYMCON/DATA/BATH1_FHT_HOL.par","r");
// Find the right parameter to adjust the target if necessary
while ($line = fgets($handle, 1000))
{
$parameter = explode(";", $line); //[0]-Day, [1]-Start Time, [2]-Temperature
$day=$parameter[0];
$switchtime=$parameter[1];
$temp=$parameter[2];
if (($day == $heute[$tag]) AND ($time > $switchtime))
$newtemp = substr($temp, 0, 4); // extract the "
" from the file
}
fclose($handle);
// When Value changes -> Send the new Value to the Unit
if (GetValueFloat("BATH1_FHT_MEMO_TEMP") != $newtemp)
{
FHT_SetTemperature(64288, (float)$newtemp);
SetValueFloat("BATH1_FHT_MEMO_TEMP", (float)$newtemp);
SetValueString("BATH1_HMI_LAST_MESSAGE", "PARAMETER, Temperature in Bedroom now set on ".$newtemp." °C");
}
// If Actual and Target Values don´t match
else
if ((GetValueFloat("BATH1_FHT_TARGET_TEMP")) != (GetValueFloat("BATH1_FHT_MEMO_TEMP")))
{
SetValueString("BATH1_HMI_LAST_MESSAGE", "PARAMETER, Setpoint has been modified manually. Target has been adjusted!");
FHT_SetTemperature(64288, (float)$newtemp);
}
SetValueString("BATH1_HMI_FHT_SCRIPT_RUN", "EXECUTED");
// Compare actual and target temperature after 1 hour, and send
// target again if temperature didn't change
$last_target_update = date("H:i", IPS_GetUpdateTime("BATH1_FHT_TARGET_TEMP"));
$actual_temp = GetValueFloat("BATH1_FHT_ACTUAL_TEMP");
$target_temp = GetValueFloat("BATH1_FHT_TARGET_TEMP");
$time_diff = (strtotime($time) - strtotime($last_target_update));
if (($time_diff > 3600) AND (abs($actual_temp - $target_temp) > 2))
{
FHT_SetTemperature(64288, (float)$target_temp);
SetValueString("BATH1_HMI_LAST_MESSAGE", "!! Target was not recieved by FHT. I sent it again !!");
}
}
else SetValueString("BATH1_HMI_FHT_SCRIPT_RUN", "STOPPED");
Inhalt:
Kann zwischen 2 Dateien switchen, je nach Schulferien
Script wird nicht durchlaufen, fall ein Fenster geöffnet wird, auf Manuel setzt wird und in meinem Fall noch, falls keiner mehr im Haus ist und House_Stauts == False wird (Kleiner Push Button)
Läuft auf dem Prinzip von der Parameter Steuerung (Dank an Retarius für diese gute Idee)
Hat auch das Feature, dass wenn das Script merkt, dass die Temperatur nicht wirklich fällt, wenn ein neues Target geschickt wurde, es das Target nochmals sendet. Der Wert 3600 ist hier eine Stunde, kann aber bei Bedarf angepasst werden sowie auch der Differenzwert innerhalb diese Zeitfenster
ich denke ich habe mich etwas falsch ausgedrückt, bezüglich dem was ich als Problem sehen, bzw. habe.
Ich habe nicht das Problem, dass ich von meinem System her zu viele Pakete zu den FHT’s aussende, sondern die FHT’s senden ja willkürlich ihre Informationen aus.
Ich habe (vom Gefühl her) sehr oft Paketkollisionen (z.B. Rollo fähr tnicht runter, Flur-Licht geht nicht aus). Die meisten (z.B. das Flurlicht) kann man einfach abfangen, aber gerade beim Rollo wirds schon schwieriger, da ich keine Info habe, ob der Befehl angekommen ist.
Bsp. Fahre Rollo auf 80% - Pos-Variable wird in IPS auf 80% gesetzt- Befehl wird ausgesendet, kommt aber nicht an. Dann denkt IPS der Rollo ist bei 80%, dabei steht der aber noch bei 100%. Sage ich nun Rollo auf 0% müsste der Rollo volle 100% fahren um auf zu sein - IPS sagt aber 80% nochfahren reicht. D.h. (wenn dieser Befehl dann durchkommt) steht der Rollo nicht ganz oben…
Das ist eigentlich das größte Problem was mir mit den FS20MS bevorsteht. Ich hab zwar einige Lösungsansätze, aber der Komfort der genauen Positionieren leidet hat sehr darunter.
Nun meine Idee, da ich dieses Problem auf Paketkollisionen von IPS-Senden und FHT-Senden schiebe, ich bringe die FHT’s mit dem FHT_Request Befehl „zum schweigen“ und bekomme dann nur die Daten wenn ich den FHT_Request sende. Den darf ich dann natürlich nur senden, wenn keiner der Rollos bewegt werden soll. Aber hiermit hätte man dann die Kontrolle darüber wann die FHT’s ihre Daten ausspucken.
Aber da der FHT_Request-Befehl so „verwüstlich“ wirkt - hab das selber ja mal kurz damals schon ausprobiert. Ich denke ich werde das aber dennoch nochmals testen.
Meine eigentliche Frage war: kommen denn tatsächlich nach dem FHT_Request die Daten aus dem FHT? Und das auch immer (nur) dann, wenn man den Befehl sendet, oder geht da snur ein mal und dann sind die FHT’s „gecrashed“ ??
Wer hat Vorrang, FHT oder FS20, das weis nur EL. Ich hatte schon mal ein Thread zu diesem Thema geöffnet guckst du hier.
Fest steht, die Markisensteuerung z.B. blockiert den PHP Parser während der Ausführung. (Deshalb begnüge ich mich, meine Rollos mit True und False zu bedienen.) Also spätestens hier (wenn du grosse Markisen hast) dürfte schon einiges verloren gehen. Dazu ein reger Betrieb auf FS20 kann auch mal Schwierigkeiten machen.
Nur, das alleine auf das zu schieben, ist flasch.
Wie schon gesagt, eine wichtige Erfahrung die ich gemacht habe mit den FHT’s ist: Sie zum „sprechen“ zu bringen mit Request_Data bringt überhaupt nichts, dann werden sie nur noch mehr stur. Das beste ist, man lässt sie in Ruhe für eine Weile. Und eine Weile nenne ich 1 bis 2 Tage ! Dann (so hat man das Gefühl) sprechen die sich ab, und es stellt sich eine „rangordnung“ ein, und die FHT werte kommen bei mir fliessend und im Paar-Minutentakt. Und das bei 11 FHT’s!
Natürlich, Kollisionen bei regem FS20 Verkehr kann schon mal Probleme bringen. Bei mir war jedoch nicht das Problem das Empfangen, sondern das Senden von Target-Werten. Nun, mit meiner integrierten „Sende-Werte-nochmal-falls-nicht-geklappt-Funktion“ läuft alles fabelhaft. Und das seit nun 2 Wochen. Ich kann nun sagen, mein FHT Projekt ist fertig!
