wäre es möglich für die Boolean-Variablen die Event-OnChange-Option so umzubauen dass man auf den „TRUE“ und den „FALSE“ Event getrennt Scripts triggern kann.
Würde z.b. bei den PIRI’s einiges vereinfachen…
Was hält der rest der IPS-Community von dem Gedanken?
habe in meinen Skripts oft nur das TRUE per PHP mit Programmcode hinterlegt, im Skript wird dann sofort wieder auf FALSE gesetzt. Bis jetzt muss ich im Skript immer abfragen, ob gerade TRUE oder FALSE getriggert wurde. Wenn man das unterscheiden könnte, muss ich zwar reichlich umprogrammieren, das wär’s mir aber auf Dauer wert.
hab mich schon immer gefragt wozu es beim PIRI True und False gibt. Wozu benutzt Ihr diese Werte? Mir war es bisher sch… egal was kommt - Hauptsache mein Script wird getriggert. Hab auch schon überlegt den Zustand des Piri nach Auslösen des Scripts wieder auf false zu setzen. Wenn ich aber die Variable, welche das Script getriggert hat in diesem Script setze - wir da nicht dieses Script wieder getriggert und so weiter und so fort…
Man müsste also wie cAtMaX immer beim Aufruf des Scriptes testen
if Variable = false the exit o.s.ä.
der PIRI ist ja ein FS20-Sender und daher eigentlich (von ELV) gedacht einen FS20-Empfänger direkt zu steuern… daher gibts TRUE und FALSE.
Da die Timerfunktion des PIRI nur sehr schlecht bis miserabel funktioniert bietet es sich an diese Aufgabe IPS zu überlassen.
Nur muss man in dem Fall die Variable leider „händisch“ wieder auf FALSE setzten da der PIRI kein FALSE sendet.
Nur damit landet man dann leicht in der Endlosschleifenfalle wie du sie beschrieben hast…
Das ist auch der Grund warum ich gerne die Möglichkeit hätte auf TRUE und FALSE getrennt zu triggern…
Das Prinzip wie es jetzt ist wird auf jedenfall bleiben. Es ist aber geplant Scripte auf Limits bzw bestimmte Werte (wie hier TRUE/FALSE) triggern zu können. Damit könnte man z.B. auch einfacher Alarm bei Grenzwertüberschreitungen triggern. Der Vorteil ist auch, dass man dann auch auf konkrete Flankenwechsel triggern kann. Zur Zeit ist dies ja nur bedingt Möglich. (Der PIRI ist aber nicht so zeitkritisch)
Um kurz die Modi’s zusammenzufassen:
-OnUpdate -> So wie es jetzt ist. Trigger immer beim aktualisieren der Variable
-OnChange -> Trigger nur bei wirklicher Wertänderung (War mal ganz am Anfang in IPS so, wurde aber auf OnUpdate geändert, damit man beim Temperaturloggen gleiche Werte trotzdem erfassen kann)
-OnLimit -> Überschreiten/Unterschreiten von bestimmten Limits
-OnValue -> Trigger, wenn Variable gleich dem zu vergleichenden Wert ist
Dazu kommt, dass dann neue IPS_* Variablen kommen, damit man auch erkennen kann durch welchen Modi das Script nun getriggert wurde.
Fazit:
Ihr könnt eure Scripte erstmal so schreiben wie gehabt, die anderen Features werden euch das Leben nur „leichter“ machen.
Hab mich schon die ganze zeit gewundert warum bei jedem Update getriggert wird obwohl der Wert gleich bleibt…
Is bei den HMS ziemlich lästig da die ja alle 30min ne Statusmeldung abgeben…
Wirds die neuen Features schon in der nächsten Version geben oder erst später?
wie sieht es denn zur Zeit mit euerer Planung aus? Wann kann man den mit den genannten Funktionen rechnen? Ich habe mit der Weile recht regen Verkehr:D in meiner IPS, und für jede verwendete Variable ein Old_Variable anzulegen und auszuwerten ist auch ganz schön stressig:mad:
Das geziehlte Triggern würde die Sache erheblich vereinfachen!
Zum nächsten Update wird es diese Funktionalität geben. + Die Möglichkeit mehrere Scripte parallel laufen zu lassen. Das sollte das Problem mit den Anrufbeantworter Scripten lösen