Fragen zur Ausführung von setState und getState

[mplogas]

@AlCalzone das mache ich tatsächlich in meinem ursprünglichen Batterie-Skript. Meine Clear()-Methode zeigt aber, dass der mit setState() gesetzte Wert nicht zuverlässig mit getState() abgerufen werden kann. Da meine JSONArray-CRUDs Teil eines globalen Scripts sind interessiert mich was ich falsch mache.

[AlCalzone]

@mplogas sagte in Fragen zur Ausführung von setState und getState:

setState() gesetzte Wert nicht zuverlässig mit getState() abgerufen werden kann

Ich vermute dass da noch ein Delay drin ist zwischen "Schreibvorgang erfolgreich" und "wurde im Cache aktualisiert". Bei Triggern kann es auch manchmal sein, dass der Wert in obj.state.val neuer ist als der, der von getState zurückgegeben wird.
Wenn du es irgendwie vermeiden kannst, nutze Datenpunkte nicht wie Variablen, die du sofort wieder benötigst.

[Mic]

@mplogas

@AlCalzone sagte in Fragen zur Ausführung von setState und getState:

Wenn du es irgendwie vermeiden kannst, nutze Datenpunkte nicht wie Variablen, die du sofort wieder benötigst.

Dem kann ich nur zustimmen. Wenn du in einem Script einen Datenpunkt setzt (setState()), dann weißt du ja bereits, was du setzt. Das kannst du dir in einer (globalen) Variable "merken", dann brauchst du danach getState() nicht mehr.
getState() ist "expensive", d.h. es braucht deutlich mehr System-Ressourcen (und Ausführungszeit), als den Wert aus einer (globalen) Variable auszulesen.
Die Seiteneffekte, die du siehst, sollten dann auch weg sein.
Wenn du noch mehr Hilfe brauchst, poste am besten ein komplettes Script, damit wir das schnell nachvollziehen/testen können

[tombox]

Das ganze ist nicht so schön aber um es zu fixen könntest du mit await und den async methoden arbeiten
await getStateAsync
await setStateAsync

[Mic]

Nachtrag:
Falls viele Datenpunkte und Schleifen, dann halte ich mir jeden Datenpunkt-Inhalt für setState und getState in einer globalen Variable, Typ Array, vor. Damit kann ich dann auch schön in Schleifen darauf zugreifen. Es sei denn, man braucht diesen Datenpunktinhalt jeweils nur einmal pro Schleifen-Durchlauf, dann einfach nur eine Variable innerhalb der Schleife.

[Mic]

@tombox sagte in Fragen zur Ausführung von setState und getState:

await getStateAsync
await setStateAsync

Guter Punkt, aber meines Erachtens ist das hier unnötig Mal zur Veranschaulichung:

1. Ich habe einen Text in einem String, z.B. let str = 'das hier ist ein Text.'.
2. Nun speichere ich diesen Text, warum auch immer, auf die Festplatte als txt.-Datei (oder z.B. - wie oben - per setState() in einen Datenpunkt).
3. Danach brauche ich im selben Script wieder den Text, der weiterhin auch im Speicher und in der Variable str vorliegt. Soll ich mir nun tatsächlich die Mühe machen, die txt-Datei wieder auszulesen (oder - wie oben - den State per getState()), obwohl in der Variable str mein Text 'das hier ist ein Text.' bereits vorhanden ist?

[AlCalzone]

@tombox Das hat die gleichen Probleme, da die Async-Methoden nur ein Wrapper um die Callbacks darstellen.

[mplogas]

@Mic said in Fragen zur Ausführung von setState und getState:

Wenn du noch mehr Hilfe brauchst, poste am besten ein komplettes Script, damit wir das schnell nachvollziehen/testen können

Mein Repro-Code im OP zeigt mein Problem. Was ich eigentlich machen will ist einmal am Tag durch alle Sensoren und Switches rennen und alle Sensoren unter einem Schwellwert in einem JSON-Array als string-Datenpunkt speichern. Dieser Teil funktioniert ohne Probleme und ist auch nicht zeitkritisch. Ich möchte allerdings beim Scriptstart sinnvollerweise den Datenpunkt vorher "leeren" (lies: mit einem leeren JSON-Array beschreiben).
Genau dieses Clear() bereitet mir Probleme: wenn ich getValue(id) zeitnah nach setValue(id, value) aufrufe ist bei jedem zweiten Mal (warum jedes Zweite?) nicht der erwartete (und geschriebene) Inhalt im Datenpunkt.

Ich habe meinen Code mal angehangen, aber da passiert auch nicht viel mehr als im Repro. ClearArray und AddToArray sind globale Methoden, die Clear und Add im Repro entsprechen.

schedule("30 5 * * *", CheckBattery);
function CheckBattery() {
    const warning = "javascript.0.x.batterywarning";
    const empty = "javascript.0.x.batteryempty";

    ClearArray(warning);
    ClearArray(empty);    

    let sensors = getObject("enum.sensors.battery").common.members;
    let switches = getObject("enum.switches.battery").common.members;
    let state = sensors.concat(switches);

    for(let i = 0; i < state.length; i++) {
        let battery = getState(state[i]).val;

        if(battery < 30) {
            log("critical: " + state[i] + " " + battery);
            AddToArray(empty, state[i]);
        } else if(battery < 50) {
            log("warning: " + state[i] + " " + battery);
            AddToArray(warning, state[i]);
        }
    }
}

[mplogas]

@AlCalzone Ja, ich kann natürlich drumherum-engineeren indem ich kein Clear nutze sondern ein Overwrite schreibe und somit den Datenpunkt "zeitunkritisch" schreibe. Mich interessierte, ob/was ich falsch gemacht hatte - wenn das by-design ist das auch OK

[AlCalzone]

@mplogas Ich denke das wichtigste ist, Datenpunkte und get/set State nicht als Ersatz für (temporäre) Variablen zu nutzen. Die Analogie von Mic ist ziemlich treffend.

Ich möchte allerdings beim Scriptstart sinnvollerweise den Datenpunkt vorher "leeren" (lies: mit einem leeren JSON-Array beschreiben).

Das kannst du durchaus machen. Allerdings weißt du dann, dass der Inhalt ein leeres Array ist, das brauchst du nicht wieder auslesen.

[mplogas]

@AlCalzone said in Fragen zur Ausführung von setState und getState:

Das kannst du durchaus machen. Allerdings weißt du dann, dass der Inhalt ein leeres Array ist, das brauchst du nicht wieder auslesen.

Das Auslesen geschieht ja nur im Log, weil ich versuchte den Fehler zu finden. Mir ist aufgefallen, dass ich jeden zweiten Tag (bzw. jeden zweiten Lauf) die Werte des vorherigen Laufs noch im Array hatte obwohl ich Clear() aufgerufen hatte. Wie auch immer, ich habe Clear() ersetzt und überschreibe das Array jetzt mit den neuen Werten. Ist leider nicht ganz so modular wie erhofft, aber vermutlich muss ich mich ohnehin gedanklich von den SOLID-Prinzipien lösen und mehr "hacken".