Debugging von WebUI-Programmen und Skripten

[blackhole]

Variable schreibend eingesetzt führt nicht zu einem Triggern.

Weiterhin wird die Änderung des Inhalts noch nicht einmal geloggt, selbst wenn für die Sysvar das Logging aktiviert wurde.
Und das ist wirklich super, da genau das (das Nicht-Triggern) einen Teufelskreis vermeiden kann.

[Matsch]

Ich wollte nur erklären, wie der Interpreter "lesen" von "schreiben" unterscheidet

Jedenfalls prinzipiell. Nur eben nicht bei einer Nur-Lesen-Anweisung und eben nicht bei .Value()

[Sternthaler]

Woran sollte der Interpreter denn unterscheiden, ob .Value() als Lese- oder Schreibbefehl gemeint ist?

Genau wie bei State() auch.

Leere Klammer .Value() = lesen
Befüllte Klammer .Value(34) = schreibe 34

Verwechselst du das nicht etwa mit dem Beschreiben von SVs, wobei .State(<wert>) eine Protokolltriggerung auslöst, aber .Variable(<wert>) als einzigen Unterschied nicht?

Stimmt, Variable() gibt es ja auch noch.


Ich nutze aber auch grundsätzlich .Value() zum Prüfen, weil ich nicht will, dass jedes Mal die Aktoren (auch nicht die netzbetriebenen) unnütz angefunkt werden.

Hallo in die Runde.
Kurz zu mir: CCU2 und CCU3 seit mehr als 5 Jahren im Betrieb. Viel lesen über HM und extrem viel per Script machen.

Es gibt noch einen weiteren Unterschied:
- Variable("xx") hinterlässt an einer SV keinen Timestamp().
- State("xx") hinterlässt an einer SV sehr wohl einen Timestamp(). (Ich nutze das in 'weiterverarbeitenden' HM-Progs/Scripten)

Gruß
Sternthaler

Editiert am 25.02.2023 19:53 wegen Oberdummheit (und das ausgerechnet beim ersten Beitrag )
Ja klar, ich meinte Variable() und nicht Value()

[Matsch]

Das steht schon 3 Beiträge weiter oben

[[sprotte80]]

Hi

Es gibt noch einen weiteren Unterschied:
- Value("xx") hinterlässt an einer SV keinen Timestamp().

Wie auch?
Das veruracht ja nen ScriptRumetimeError.
Steht schon 3x hier im Fred.
Einfach mal ins Log schauen!

Thomas

[Sternthaler]

Oh nein.

Hallo in die Runde,
da hab ich zu Recht Schelte erhalten.

Aber zum Glück sind wir hier in einem Eintrag zum Thema "Debugging".
Und ja, "Value()" liefert ja auch schon mit dem Button "Fehlerprüfung" einen Syntaxfehler. (Aber wem erzähle ich das.)

Gruß
Sternthaler

P.S.: Ich habe meinen Beitrag oben editiert um nicht noch weiter zu verwirren. Es reicht ja schon, wenn die Scriptsprache hier mit so vielen Möglichkeiten Verwirrung stiftet.

Und zum Testen habe ich das nun so gemacht:

Code: Alles auswählen

var     tmpS0 = "0Test";    !! Name einer SV die zum Testen angelegt sein muss.
var     tmpS1;
var     tmpS2;
var     tmpS31 = "Inhalt 1 / geschrieben mit Variable";
var     tmpS32 = "Inhalt 2 / geschrieben mit State";

WriteLine("START");

tmpS1 = dom.GetObject(tmpS0);
if (! tmpS1) {
  WriteLine(":" # tmpS0 # ": nicht gefunden");
} else {
  WriteLine("Mach mal um :" # system.Date("%F %X") # ":");
  WriteLine("");

  tmpS2 = tmpS1.Variable();
  WriteLine("  Per Variable() gelesen :" # tmpS2 # ":");
  tmpS2 = tmpS1.Value();
  WriteLine("  Per Value()    gelesen :" # tmpS2 # ":");
  tmpS2 = tmpS1.State();
  WriteLine("  Per State()    gelesen :" # tmpS2 # ":");
  WriteLine("    Timestamp :" # tmpS1.Timestamp() # ":");

  WriteLine("");
  WriteLine("Schreibe etwas mit Variable()");
  tmpS1.Variable(tmpS31);
  
  tmpS2 = tmpS1.Variable();
  WriteLine("  Per Variable() gelesen :" # tmpS2 # ":");
  tmpS2 = tmpS1.Value();
  WriteLine("  Per Value()    gelesen :" # tmpS2 # ":");
  tmpS2 = tmpS1.State();
  WriteLine("  Per State()    gelesen :" # tmpS2 # ":");
  WriteLine("    Timestamp :" # tmpS1.Timestamp() # ":");

  WriteLine("");
  WriteLine("Schreibe etwas mit State()");
  tmpS1.State(tmpS32);
  
  tmpS2 = tmpS1.Variable();
  WriteLine("  Per Variable() gelesen :" # tmpS2 # ":");
  tmpS2 = tmpS1.Value();
  WriteLine("  Per Value()    gelesen :" # tmpS2 # ":");
  tmpS2 = tmpS1.State();
  WriteLine("  Per State()    gelesen :" # tmpS2 # ":");
  WriteLine("    Timestamp :" # tmpS1.Timestamp() # ":    Diese Zeit merken");
}

WriteLine("ENDE");

Das Script ausführen.
Oben steht die aktuelle Ausführungszeit.
Die zuletzt angegeben Zeit merken.
Nach ein paar Sekunden nochmals das Script ausführen.
1: Kein Schreiben
Alle 3 Lesevarianten sind ok. Danach zeigt Timestamp() noch die Zeit vom letzten Scriptaufruf (Die von euch gemerkte Zeit).
==> Das wird erwartet.
2: Schreiben mit Variable()
Alle 3 Lesevarianten sind ok. Danach zeigt Timestamp() weiterhin die alte Zeit.
==> HM-Rätsel
3: Schreiben mit State()
Alle 3 Lesevarianten sind ok. Jetzt zeigt Timestamp() die oben ausgegebene Ausführungszeit.
==> Somit hat State() die Ausführungszeit an der SV hinterlassen.

[Xel66]

Jetzt zeigt Timestamp() die oben ausgegebene Ausführungszeit.

Das sind nur optische Auswirkungen. Wichtiger ist, die Auswirkung in der ReGa zu beachten. Ist diese Systemvariable als Trigger in irgendeinem Programm hinterlegt und man möchte NICHT (z.B. für Testzwecke), dass das Programm durch die Änderung der Variable getriggert wird, dann kann man der Variable den Inhalt mit .Variable() unterschieben, ohne dass die ReGa drauf reagiert. Es wird auch kein Zeitstempel gesetzt.

Setzt man aber diese Variable mit .State(), bekommt die ReGa das direkt als Trigger mit und startet somit die Bedinungsprüfungen der Programme, die diese Variable als Trigger enthalten. Ob man das wirklich im laufenden Betrieb benötigt, mag ich nicht bewerten. Für Testzwecke ist das Verhalten aber gut nutzbar.

Gruß Xel66