sFHTs Super FHT Script

@GGGss:

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)? :confused:

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…

MfG
Fabian

Moin Moin!

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…

MfG
Fabian

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.

Toni

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… :smiley:

Fabian

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.

@Toni:

Danke für die Erklärung. Eigendlich kenne ich dieses Verhalten, programmiere selbst hin und wieder nach Bedarf…

Mir war nur nicht bewusst, dass IPS das auch so handhabt. Irgendwo hatte ich mal gelesen, dass ein Script nur einmal aufgerufen werden kann.

Im Update erfolgte also eine Änderung mit der Handhabung der Threads :cool:

Dann erklärt sich auch das Verhalten des Scripts. Muss ich mal sehen, woran es liegt >> Jetzt wo ich weiß, wonach ich suchen muss.

Eventuell kann man ja die Zeit des letzten Aufrufes vergleich… mal sehen.

Also Danke nochmal für die kleine „Nachhilfestunde“! :cool:

Fabian

Hey Leute,

War ne woche verreist … habe die gleiche probleme seit ich den (multi-threading) live-update auf meine machine laufen habe… also

das script wird tatsachlich mehrmals angerufen durch setzen von var’s durch das eigene script.

das heisst das ich ne ‚inhibit‘ (lese: verboten aus zu fuhren) variable einbauen muss um die selbst-triggering aus zu schliessen.

weiss bloss nicht wo und wie ich die variable wieder resetten muss.

wird schon einige zeit brauchen bis ich das klar bekomme.

Vielleicht hilft einer von euch ?

Grusse,
Fredje

lösung (ohne zu testen):

eine IPS variable anlegen : ‚__fht_inhibit‘ type ‚Boolean‘

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

zeile 386 - 388 (nach eintrag zeile 149-151)


// 2006/05/30 modifie due to multi-threads
SetValueBoolean("__fht_inhibit",false);
// 2006/05/30 end modifie

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.)

Oberige inhibit lösung solls schaffen. (hoffe ich)

Hi Fredje,

hast du mal ins tempSENT.log geschaut, sieht bunt aus… :confused:

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“ :cool:

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.

Fabian

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? :confused: ?

Getriggert wird dann auch auf die _state???

Ich hoffe, ich habs jetzt nicht vertauscht. :confused:

Fabian

PS: Das mit dem Script lock wird uns wohl noch öfter beschäftigen…

aj jaj jaj !!!
hombres ! das lauft ganz falsch!

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:

Also für heute Gute Nacht!
Fabian

Hallo Fredtje,

machs nicht so kompliziert, Du kannst die IPS Semaphore Steuerung nehmen

IPS_SemaphoreEnter

und

IPS_SemaphoreLeave

Gruss Torro

Guten Morgen Torro,

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?

Fabian

Hallo Fabian,

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.

Einfach mal testen…

Gruss Torro

Also getestet ist es:
Mit 1ms läufts perfekt. Ist die Zeitspanne zu hoch, wird das Script nochmal ausgeführt…

Danke nochmal für die Hilfe!

Fabian

Moin!

Ich war wohl etwas zu voreilig! Leider ist es wie beim Lottospiel, mal klappts, mal nicht.

Anscheinend hat das Script unterschiedliche Laufzeiten. :confused:
Ich teste jetzt noch ein paar andere Werte… :mad:

Also jetzt müsste es prima laufen:

als erstes habe ich wegen:

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“

eine automatische Timersynchronisation eingefügt:

$minutes = (integer)date("i");
if(bcmod($minutes,30) != 0) {
   IPS_SetScriptTimer("sfhtso",1800 - $minutes * 60);
} else {
   IPS_SetScriptTimer("sfhtso",1800);
}

damit synchronisiert es zwar nur auf die Minute genau, aber wen stört’s… :cool:

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;

und am Ende des Scripts:

IPS_Sleep(1000);
IPS_SemaphoreLeave("sfhtso_run");

Also ich hoffe, das hilft denjenigen, die es benutzen. :smiley:

Sicher geht einiges noch besser, aber ich beschäftige mich mit PHP erst seit der letzten Woche.

Gruß Fabian

@Fabian,

Danke dir fuer die Suche :wink:
Wegen Zeitmängel bin ich noch nicht dran gekommen.
Wenns freigegeben werden kann, werde ich wiki und doku änderen.

Grusse,
Fredje