@ tommi:
Danke für deine Tipps.
Ich habe mich inzwischen weiter eingelesen, deshalb:
[ul]
[li]habe ich die statischen Methoden (außer einer Selbstinstanzierung) entfernt,
[/li][li]und da es grundsätzlich auch 2 Bricks sind -> eine Klassenvererbung hinzugefügt (sollte auch nur bei einer Ableitung bleiben),
[/li][li]und die statischen Variablen als private gesetzt, dafür eigene Methoden hinzugefügt.
[/li] [/ul] @ alle php Junkies:
Eine reine Verständnisfrage:
Wenn man z.B. globale Variablen als statisch definiert (in IPS grundsätzlich nicht zweckmäßig, ist mir klar) wird ein Speicherbereich für diese Variable definiert.
Ist dann der Zugriff auf diese Variable schneller, oder ist es eigentlich egal ob „statisch global“ oder nur „global“ ?
Die statische Variante ist eine Verschwendung von Speicher, falls man die Variable nicht immer benötigt, das ist mir auch klar.
@ alle:
Ein Update der Bricks erfolgt zu einem späteren Zeitpunkt. Ich muss erst noch ein paar Testläufe durchführen.
@ bmwm3:
Kann ich dir so nicht sagen, aber es ist ein Fehler. Es wird alles nur eventmäßig getriggert und nicht zeitmäßig (alle 50 Sek. ??) getriggert. Weiters betrifft es ein FHT oder mehrere?
Tipp: Versuche einmal das eFHZ-Brick aus dem Skripteditor zu löschen.
Es kann vorkommen, dass das Brick durch Variablen getriggert wird obwohl es keine Variablen (sondern nur Konstanten) enthält.
Wenn es dir recht ist, kannst du per PN eine/ein paar Logs schicken wo auch der Fehler aufgetreten ist, deine Settings.xml.
@ bmwm3:
Kann ich dir so nicht sagen, aber es ist ein Fehler. Es wird alles nur eventmäßig getriggert und nicht zeitmäßig (alle 50 Sek. ??) getriggert. Weiters betrifft es ein FHT oder mehrere?
Tipp: Versuche einmal das eFHZ-Brick aus dem Skripteditor zu löschen.
Es kann vorkommen, dass das Brick durch Variablen getriggert wird obwohl es keine Variablen (sondern nur Konstanten) enthält.
Wenn es dir recht ist, kannst du per PN eine/ein paar Logs schicken wo auch der Fehler aufgetreten ist, deine Settings.xml.
Gruß
Günter.
hy, habe den fehler gefunden. hatte in dem skript bei include ein \ statt /.
kleiner fehler grosse ursache. DANKE
Jetzt hätte ich mal eine Frage an die FHTs-Profis bzw. Protokoll-Profis des FHT.
Kann man per Skript oder eFHT-Befehl z.b. eFHT::bFHT_SetWindowStatus(true); den FHT in den FensterOffen-Modus setzen.
Hintergrund: Wenn ich dann doch mal meine Hoppe-Fenstergriffe bekomme (Lieferzeit ???) würde ich gerne wenn ich ein Fenster öffne den FHT in den FensterOffen-Status setzen damit dieser automatisch auf die WindowTemp geht.
Gibt es da eine Möglichkeit oder kann man den Modus nur mit einem FS20-TFK anstossen?
Hallo Werner,
das habe ich mir auch schon überlegt. Das Setzen des FensterModus ist über die FHTs leider nicht möglich. Der Grund liegt wahrscheinlich darin dass mehrere TFK Aktoren angemeldet werden können (Vermutung). Ich selbst habe leider keine TFK im Einsatz um das zu analysieren. Vielleicht lege ich mir noch einen zu um das zu probieren.
Wenn der FS20 TFK ein ganz normales FS20 Signal sendet (also per FS20 RX empfangbar ist), dann müsstest ihr den TFK mit einer FS20 TX Instanz emulieren können.
Bin mir aber grad nicht sicher, ob das funktioniert.
hy @spawn,
wenn ich es richtig verstanden habe, stehen die target bricks dafür, um mir anzuzeigen was in der fht gespeichert ist oder?
bei mir steht in jeder target eine 0.
was mache ich da schon wieder falsch.
Hi paresy, das wäre eine Möglichkeit. Es gibt eventuell noch eine Hürde. Die FHTs haben diese Zwangspause von 116 Sek. Mit einer TX Instanz kann ich den richtigen Zeitpunkt noch nicht bestimmen dass die FHTs das Protokoll aufnehmen können. Wie gesagt ich habe noch keine TFK zum Probieren, und nach meiner Meinung wäre es gleich am Besten über den Puffer einer FHZ1000/1300 PC zu senden.
Hi bmwm3, ich nehme mal an: mit target bricks meinst du die FHT Responce Statusvariablen laut IPS FHT Modul und die FHT Responce Statusvariablen im eFHT - Brick.
In diesem Falle: Ja.
Falls die Statusvariablen nicht richtig gesetzt werden, überprüfe das Berechnungsskript. (=eFHT_calc.ips.php lt. meiner beigelegten Anleitung). Hier noch einmal ein Beispiel dafür.
<?
/*
*******************************
IP-SYMCON Event Scripting
*******************************
*/
include(IPS_GetKernelDir()."bricks\\eFHT\\recv.eFHZ.php");
/*
********************************************************************
* ANSCHLIESSEND DIE ZU VERWENDETEN eFHT BRICKS EINBAUEN
* z.B:
* include("ROOM1_eFHT.ips.php");
* Check($IPS_VALUE);
* include("ROOM2_eFHT.ips.php");
* Check($IPS_VALUE);
* etc..
* [Die INCLUDES NICHT in Schleifen verbauen -> Timingprobleme]
********************************************************************
*/
include("FHT_Büro.ips.php"); // das erste FHT
Check($IPS_VALUE);
include("FHT_Bad.ips.php"); // das zweite FHT
Check($IPS_VALUE);
?>
Erklärung:[ul]
[li]das erste include bindet die Empfangs/Zuweisungsfunktionen ein
[/li][li]das zweite include bindet die Namen der Statusvariablen ein. Muss für jedes FHT erneut hinzugefügt werden
[/li][/ul]
Günter.
da gäbe es ein Problem, mit dem wir leider alle zu kämpfen haben.
Beim TFK, der direkt an der FHT angeknüpft ist, geht es relativ schnell bis der FHT merkt, ein Fenster ist offen. Dieser Kontakt ist auf direktem Weg. Doch den anderen Weg , mit FS20TFK, muss er über die FHZ gehen, dann IPS, zurück zur FHZ und dann erst FHT. Dazwischen könnten in einem sehr ungünstigen Fall meherere Stunden liegen. Ich habe keine Zweifel dass das FS20TFK Signal an IPS zügig geliefert wird, doch der Rückweg…naja. Wir alle wissen dass das manchmal sehr lange dauern kann, wenn mal ein FHT wieder eingeschlafen ist.
Und das würde bedeuten, dass viel Heizenergie flöten gehen würde. Nicht Zweck und Sinn der Sache!
Meine Meinung: Ich würde es hier bei der Original-Idee vom FHT-typischen Kontakt bleiben. An den kann man ja auch kleine Magnet-Kontakte extern anschliessen.
zum TFK habe ich leider keine Infos, mit relativ schnell nehme ich an: Empfang in diesem Zeitfenster. Theoretísch gesehen müsste es auch funktionieren.
zum Punkt Einschlafen:
Also laut meinen Beobachtungen -> Einschlafen ist eigentlich der falsche Name, wenn ein FHT einschläft ist meistens folgendes passiert:
Durch irgendeine Funkkollision oder anderen Grund, hat der betreffende FHT nicht das „vollständige“ Protokoll mitbekommen. Aus diesem Grund fehlt dem FHT das Acknowledge des FHZ1000. Ein FHZ1000 (nicht PC Version) bekommt das mit und sendet das ganze nochmal.
Im eFHT-Brick ist eine Methode enthalten die das FHT neu initialisiert -> sFHT::Init(). Damit kann das FHT „aufgeweckt“ werden und es sendet dann alle Register einmal neu aus und ist anschließend wieder ON AIR.
Natürlich sollte man das aucht nicht gleich wieder verallgemeinern.
Aber eben nur ‚Theoretisch‘. Praktisch gesehen wird es nicht gehen, zumindest nicht immer. Ich habe 11 FHT’s auf 3 FHZ’s (auf jedem Stockwerk eine) verteilt. Und dennoch, es kommt des öfteren vor, dass ein FHT keine Ventilpositionen oder Temperaturen sendet. Und das liegt nicht an der Empfangsqualität da ich auf den 3 FHZ’s lausche (jeder FHT-Telegramm kommt also maximal 3x bei IPS an). Gerade noch gestern hatte der FHT im Schlafzimmer wieder einen Aussetzer für mindestens 1 Stunde. Warum, weiss keiner.
Ich finde jedenfalls die FS20TFK Variante als sehr riskant.
Ich sehe schon das das nicht so einfach ist, aber das mit den Laufzeitproblemen bei den FHTs kennen wir ja zu genüge.
Glücklicherweise muss ich sagen das keiner meiner 4 FHTs bis zum heutigen Tage einmal eingschlafen wäre.
Falls spawn das mit dem direkten setzen des FHTs in den FensterOffen-Modus nicht hinbekommen sollte (wird nur der Fall sein wenn sich der FHT protokolltechnisch nicht setzen lässt) werde ich es mit folgendem Skript versuchen, auch mit dem Wissen das es ein paar Minuten dauert.
$debug = true;
eFHT::Begin("eFHT_Keller");
$KellerWindTemp = GetValueFloat("Keller_FHT_Target_Fenster");
$KellerSunTemp = GetValueFloat("Keller_FHT_Target_Tag");
if ($debug) echo $KellerWindTemp."
"; // debug Ausgabe
if ($debug) echo $KellerSunTemp."
"; // debug Ausgabe
$KellerFenster = false; //Wird später durch Hoppe getriggert.
if ($KellerFenster) {
eFHT::bFHT_SetTemperature($KellerWindTemp);
} else {
eFHT::bFHT_SetTemperature($KellerSunTemp);
}
eFHT::bFHT_SendTo();
Habe das Skript jetzt ein paar mal mit Fenster auf - Fenster zu getriggert und folgenden Laufzeit beobachtet.
Franz, nachdem ich mich weiter eingelesen habe - ich muss dir grundsätzlich recht geben.
Das Hauptproblem wird sein dass die Fensterkontakte (FHT80TF) am FHT angelernt werden müssen, dadurch:[ul]
[li]FHT stellt den Modus von sich aus um, keine direkte Kontrolle durch FHZ (Vortäuschung = vielleicht möglich ? aber derzeit mehr als theoretisch)
[/li][li]FHT sendet seinen Hauscode an TF: mit einer TX Instanz sehe auch hier wieder Schwierigkeiten (der FS20 Hauscode unterscheidet sich ja gegenüber dem FHT Hauscode)
[/li][li]FHT synchronisiert sich mit dem FHT80TF und stellt seine Zwangspausen um auf eine Minute (die 2 Minuten-Pause für die Stellantriebe scheint aber aufrecht zu bleiben)
[/li][/ul]
:mad: …, aber:
es existiert ein noch mir UNBEKANNTES Register im FHT. Vielleicht ist dieses ja für die Fenstermelder.
Und ob sich das FHT mit diesem kontrollieren lässt … ?
Diese FS20TFK Variante geht auch. Jedoch ist sie sehr unzuverlässig. Du sagst, du hast probiert und es ging. ja prima, doch hast du mal so 20 Versuche gemacht, und dann mal einen Reaktionsmittelwert berechnet?
Ich kann dir jetzt schon sagen, der liegt bedeutend höher. Das mit dem FHT TFK ist meiner Meinung nach die einzige funktionnierende Lösung
Hy @spawn, also es steht genauso bei mir drin, wenn ich dan mal auf execute drücke, kommt die fehlermeldung: <br />
<b>Notice</b>: Undefined variable: IPS_VALUE in <b>C:\Program Files\IP-SYMCON\scripts.currentscript</b> on line <b>13</b><br />
hi bmwm3, ja is klar, weil bei Execute während des Ablaufes die Variable $IPS_VALUE nicht gesetzt wird. Das geschieht nur wenn das Skript mit dem zugehörigen Variable getriggert wird.
Was nun wahrscheinlich bei dir noch fehlt, ist dieser EventTrigger.
Setze über „EVENTS“ im Fenster „Script Events“ die Variable eFHZ_calc (oder die Berechnungsvariable deiner Wahl) auf „OnChange“.
