Ich habe mich seit gestern mal mit dem sFHTs beschäftigt. Prima Sache! Jetzt habe ich nur einige (kleinere) Problem festgestellt.
Wenn ich es laufen lasse, rennt es sich fest, so dass man IPS nur noch im Taskmanager abschießen kann.
Ich habe herausgefunden, dass es mit den Triggern zusammenhängt. Laut Anleitung muss jeder FHT state eingetragen werden.
Dabei bin ich auf einen (scheinbaren) Wiederspruch gestoßen. Du beschreibst, dass jeder FHT eine _soll Var haben muss. Also habe diese unter „target state“ Temp. eingetragen. Jetzt beschreibst Du aber, dass der Trigger über eine _state Var laufen soll. Ist das das Gleiche? Wenn nicht, wie kann ich die state Var zur Abfrage nutzen, ob am Rad gedreht wurde und die soll Var gleichzeitig zur Übertragung (wie es ja das Script erfordert)?
Als zweites habe ich das Problem, dass das Script laut debug die richtige Temp heraus sucht, aber in der _soll Variable und am FHT die falsche erscheint. :eek:
Beispiel: Laut tempsettings.ini in Küche 19 und im Wohnzimmer 21 laut debug ok
Aber in der _soll-Var und am Wohnzimmer FHT nur 19 Grad.
Aber ich vermute, es ist nur irgend ein Denkfehler…
Einige der Probs habe ich gelöst.
Das mit dem Temperaturunterschied lag an einer vollen FHT-Queue als Konsequenz meiner Tests. Hatte vergessen den Softswitch „umzulegen“. :o
Das Triggern durch Vars ist nach dem IPS-Update anders und läuft jetzt prima. Allerdings kommen jetzt andere Probleme zum Tragen:
Der IPS_SENDER beim halbstündigen Aufruf durch den Timer steht jetzt auf „RunScript“. Dadurch interpretiert das sFHTs den Aufruf als manuel execute.
Als zweites ruft sich das Script jetzt mehrfach auf. Durch das Ändern der Var triggert sich das Script ein zweites Mal. Im Log taucht der Trigger über Variable sogar meist vor dem normalen Aufruf auf :eek:
@Fredje:
Hast Du schon das Update gemacht? Die Änderungen (Verbesserungen) sind wirklich gut! Ich habe vorübergehend bei IPS_Sender anstelle von TimerWizzard den RunScript eingetragen. Damit sieht es schon besser aus…
Das kann schon normal sein. Wenn, ganz allgemein, ein Script ein anderes aufruft, und nach dem Durchlauf einen Status über den Erfolg abgibt, so passiert Folgendes:
Das erste Script läuft los und kommt an den Punkt wo ein anderes aufgerufen wird. Es ruft das Zweite Script auf. Dieses läuft durch und schreibt auch einen Log-Eintrag, so wie es soll. Wenn das Zweite Script beendet wird läuft das Erste an der Stelle weiter wo es auf das Zweite gewartet hat. Wenn es selbst dann an seinem Ende angekommen ist, tätigt es natürlich auch seinen Logbucheintrag. Man muss sich das so vorstellen, als würde man Zeile für Zeile durch das Script laufen und sobald man ein externes Script antrifft erstmal das abarbeiten um dan dort weiterzumachen wo man stehengeblieben war. Das Zweite Script ist an dieser Stelle für den Stackpointer (So nennt man den, der Zeile für Zeile durch das Script läuft) wichtiger als das Erste. Wenn es nicht wichtig wäre würde es ja nicht an der Stelle stehen.
Da das manchmal nicht Sinnvoll ist auf ein Zweites Script zu warten kann man das Script in einem Thread starten. Dann hat man aber nicht die gewissheit welches der beiden zuerst fertig ist. Und man hat nur noch begrenzt Zurgiff auf die Daten dort. Wenn du Beispielsweise Daten aus dem Zweiten Script haben willst, musst du schon warten bis diese Daten auch erzeugt wurden.
Das ist jetzt alles sehr allgemein gehalten. Man muss auch nicht zwangsläufig wissen wie sowas funktioniert. Paresy hat solche Dinge alle schon für euch vorausgedacht und er , bzw IPS, macht die Arbeit für euch im Hintergrund.
Das kann schon normal sein. Wenn, ganz allgemein, ein Script ein anderes aufruft, und nach dem Durchlauf einen Status über den Erfolg abgibt,
@Toni
So weit ich das erkennen kann, ruft doch das sFHTs Script kein anderes Script auf. Es scheint mir linear mit Verzweigungen zu sein.
Den Fehler erkenne ich eher so:
Das FHT-Script ermittelt eine neue Temp für einen FHT. Danach wird die erforderliche Variable gesetzt. Es ist im Allgemeinen die Soll-Temp. Genau diese steht aber im Trigger des FHT-Scripts, um manuelle Änderungen durch den Benutzer am FHT zu erfassen (ich glaube aber nur des Loggings wegen).
Während also noch die Schleife für die FHTs läuft, erfolgt ein Aufruf des gleichen Scripts zum zweiten Mal. Und es läuft schneller ab, scheinbar noch bevor das erste fertig ist. Liegt wohl daran, dass beim Var-Trigger nur ein Eintrag ins Log geschrieben wird, ohne Schleifen und anderen Schnick Schnack…
Deine Vermutung kann schon richtig sein. Jedoch ändert das nichts an der Stackpointer-Geschichte. Alle Computer arbeiten so.
Wenn du mal ganz weg gehst von deinem sFHT Script. So wird ein Thread, wie in meinem letzten Beitrag beschrieben, mit einem Script parallel zu dem eigentlichen Aufruf gestartet. Das wird mit der neuen Threading-Verwaltung zusammenhängen die paresy eingebaut hat.
Dass dir das nicht wirklich weiterhilft ist mir schon klar. Aber ich kenne das sFHT-Script nicht gut genug um dir genau zu sagen wo der Fehler liegt.
stimmt … gleicht die ‚soll‘-variable am FHT-instanz
Also habe diese unter „target state“ Temp. eingetragen.
falsch : Der _soll variable soll nicht im FHT-instanz bild erscheinen. Ist eine hilfs-variable.
Jetzt beschreibst Du aber, dass der Trigger über eine _state Var laufen soll. Ist das das Gleiche?
nee
Wenn nicht, wie kann ich die state Var zur Abfrage nutzen, ob am Rad gedreht wurde und die soll Var gleichzeitig zur Übertragung (wie es ja das Script erfordert)?
vielleicht schwierig (naja) zu begreifen aber so lauft es:
wenn am rad des fht’s gedreht wird, wird der ‚state‘ var geupdate. (und nur den state-var) also triggert das script.
wenn ich programatorisch den ‚_soll‘ wert ändere … passiert nichts … bis das script die _soll -temp am FHT ruber schickt FHT_SetTemperature. IPS setzt den ‚state‘ var des FHT auf die _soll wert FHT_SetTemperature. (und dadurch wird das script nochmals getriggert)
im grunde : die state-var kann man nutzen wenn am rad gedreht wird. ist OK; aber durch die eingebakkene IPS funktion FHT_SetTemperature setzt sich der state-var auch. In multi-threading umgebung gibt dies probleme. (Paresy has davor gewarnt.)
hast du mal ins tempSENT.log geschaut, sieht bunt aus…
Für das Prob mit dem Sender auf „RunScript“ statt „TimerEvent“ habe ich folgendes gemacht:
Statt über den TimerWizzard starte ich jetzt das sFHTs direkt über die Event-Settings. Dort habe ich einfach im „TimerInterval“ 1800 (Sekunden) eingetragen. Damit startet das Dingen auch alle halbe Stunde. Muss man halt nur von Hand mal auf halb oder voll „synchronisieren“
Ha, da arbeitet ja schon jemand…
Die Idee war mir auch gekommen. Ich wollte eine extra Var nehmen so was wie sfht_lock
Dann entfällt der Eintrag im Log, das das Script mit inhibit deaktiviert wurde. Denn die Funktion nutze ich im Designer um den Automatik und Local Betrieb anzuzeigen.
vielleicht schwierig (naja) zu begreifen aber so lauft es:
wenn am rad des fht’s gedreht wird, wird der ‚state‘ var geupdate. (und nur den state-var) also triggert das script.
wenn ich programatorisch den ‚_soll‘ wert ändere … passiert nichts … bis das script die _soll -temp am FHT ruber schickt FHT_SetTemperature. IPS setzt den ‚state‘ var des FHT auf die _soll wert FHT_SetTemperature. (und dadurch wird das script nochmals getriggert)
Aha…
das heist also, ich brauche zwei IPS FHT Vars : vwzo_temp_soll und vwzo_temp_state.
Und die _state trage ich in die FHT Instance ein? ?
Getriggert wird dann auch auf die _state???
Ich hoffe, ich habs jetzt nicht vertauscht.
Fabian
PS: Das mit dem Script lock wird uns wohl noch öfter beschäftigen…
In das sFHTs script änderen (per copy & paste)
zeile 149-151
// the serious work start with settin' the inhibit switch
SetValueBoolean("__fht_inhibit",true);
// end modifie
Normalerweise brauchen wir das Lock nur setzen, wenn auch eine Var geändert wird. Ich denke da an den FlankTrigger so ab Zeile 364. Zurücksetzenam Ende des Scriptes sollte funktionieren.
Ich versuche jetzt schon die Var-Änderungen so gering wie möglich zu halten, da das Log schon förmlich „überquillt“ :rolleyes:
kannst Du mal an einem Beispiel erklären, wie man das benutzt?
In der Wiki habe ich zwar schon nachgelesen, aber ich möchte sicher gehen.
Wenn ich das richtig verstanden habe, kann man mit ~Enter ein Semaphore setzen und auch abfragen.?.? Und mit ~Leave gezielt löschen.
Aber wozu brauche ich den Eintrag in ms? Ich will das Script ja nicht verzögern, bis das andere fertig ist, sondern die Abarbeitung abrechen, wenn das erste gerade läuft. Soll ich dazu die Zeit einfach auf „0ms“ setzen?
probiere es mal aus mit 0ms, eventuell auch mit 1. Ich habe in den WIIPS Scripten gewarten (2000ms), da ja die Abarbeitung erforderlich ist. Wenn es bei Dir anders ist, musstest Du es entsprechend anders machen.
im „TimerInterval“ 1800 (Sekunden) eingetragen. Damit startet das Dingen auch alle halbe Stunde. Muss man halt nur von Hand mal auf halb oder voll „synchronisieren“
damit synchronisiert es zwar nur auf die Minute genau, aber wen stört’s…
Das mit dem erneuten Aufruf ist eigendlich auch ganz einfach:
Ich habe die Laufzeit am Ende des Scripts verlängert, bevor ich das Semaphore wieder lösche. Für die, die es interessiert, insgesamt habe ich folgende Änderungen gemacht.
Als erstes den Aufruf:
if ($IPS_SENDER == "Variable"){
.
.
if (!IPS_SemaphoreEnter("sfhtso_run",1))return;