[Problem] Berechnungen mit Variablen, warum klappt das nicht?

[tempestas]

Was gibt er denn aus?

Nehme an, die 10 ist nur ein Beispiel?

Variable A wird ja nur ienmal gesetzt. Damit läuft die For Schleife imho immer wieder aufs Gleiche raus. Wenn das so sein soll, warum 10x machen?

Im Ergebnis setzt du doch

A = 10

Schleife:

B = 20 (A + 10)

C = 30 (B + 10)

D = 40 (C+10)

Dann wieder Schleife:

B = 20 ( A + 10, wobei A eben einmalig mit 10 fixiert wurde)

C = 30

D = 40

usw

[rantanplan]

Hallo tempestas

Alle Variablen auf 0

Nach dem 1. Programmstart

A=10

B=10

C=10

D=10

Nach dem 2. Programmstart

A=10 (ok)

B=20

C=20

D=20

Und die Schleife läuft jedesmal 10x durch.

[gst666]

> Was gibt er denn aus?
Vermutlich Unfug.

Wahrscheinlich werden die Befehle nicht in der Reihenfolge wie erwartet abgearbeitet. Folgendes Programm mag das verdeutlichen:

setState("javascript.0.varA", 10);
... hier eine Pause in der Programmausführung ...
setState("javascript.0.varA", 20);
console.log(getState("javascript.0.varA").val);

Das Programm kann entweder als Ergebnis 10 oder 20 ausgeben. Das hängt davon ab, ob das zweite setState schon abgeschlossen ist, bevor die Ausgabe kommt. Die Programmausführung wird bei setState fortgesetzt, bevor der eigentliche Schreibvorgang abgeschlossen ist. In dem Beispiel von rantanplan ist das Problem dasselbe, nur durch die Schleife noch verschärft.

[rantanplan]

@gst666:

Das hängt davon ab, ob das zweite setState schon abgeschlossen ist, bevor die Ausgabe kommt. Die Programmausführung wird bei setState fortgesetzt, bevor der eigentliche Schreibvorgang abgeschlossen ist. `
Wie kann man das denn verhindern?

Dieses Beispiel macht die Katastrophe noch deutliche.

for (var count = 0; count < 10; count++) {
  setState("javascript.0.varA"/*varA*/, (getState("javascript.0.varA").val + 10));
  setState("javascript.0.varB"/*varB*/, (getState("javascript.0.varB").val + getState("javascript.0.varA").val + 10));
  setState("javascript.0.varC"/*varC*/, (getState("javascript.0.varC").val + getState("javascript.0.varB").val + 10));
  setState("javascript.0.varD"/*varD*/, (getState("javascript.0.varD").val + getState("javascript.0.varC").val + 10));
}

Grüße

[tempestas]

setStateDelayed mit ansteigendne Intervallen, so dass auf jedenfall der State A geschrieben ist, bevor State B drauf zugreift und ihn für seinen eigenen Wert nutzt

[rantanplan]

@tempestas:

setStateDelayed mit ansteigendne Intervallen, so dass auf jedenfall der State A geschrieben ist, bevor State B drauf zugreift und ihn für seinen eigenen Wert nutzt `
Da hat man mit Blockly aber schlechte Karten

[tempestas]

und wenn du die Schleife nur mit Variablen abarbeiten lässt und erst am Ende die finalen Variablen in die States schreibst?

[AlCalzone]

setState hat einen Callback, der aufgerufen wird, sobald der State tatsächlich geschrieben wurde.

https://github.com/ioBroker/ioBroker.ja … d#setstate

Erst dann kannst du per getState den neuen Wert auslesen.

Ob das aber mit Blockly geht... puuuh. Du kannst höchstens in Skript-internen Variablen rechnen und die Ergebnisse per setState rausschreiben. Dann fällt das getState zum Weiterrechnen weg.

[rantanplan]

@tempestas:

und wenn du die Schleife nur mit Variablen abarbeiten lässt und erst am Ende die finalen Variablen in die States schreibst? `
Habe ich auch schon dran gedacht. Elegant ist aber was anderes.

Und trotzdem ist so etwas eine böse Falle.

Wer kann sagen, wie lange so eine asynchrone Abarbeitung dauert.

Wie soll man so etwas Blockly Anfängern veranschaulichen.

Alles sehr unbefriedigend

Grüße

[tempestas]

@rantanplan:

@tempestas:

und wenn du die Schleife nur mit Variablen abarbeiten lässt und erst am Ende die finalen Variablen in die States schreibst? `
Habe ich auch schon dran gedacht. Elegant ist aber was anderes.

Und trotzdem ist so etwas eine böse Falle.

Wer kann sagen, wie lange so eine asynchrone Abarbeitung dauert.

Wie soll man so etwas Blockly Anfängern veranschaulichen.

Alles sehr unbefriedigend

Grüße `

Ehrlich gesagt verstehe ich dich da nicht ganz.

Warum soll es "eleganter sein", wenn States im Milisekundentakt beschrieben und ausgelesen werden anstatt direkt nur mit Variablen zu Arbeiten? Es gibt doch eh nur ein (bzw vier in deinem Beispiel) Endergebnis(se).

Eleganz liegt ja eh im Auge des Betrachters. Was z.B. paul53 skripted ist für mich elegant.

[inline]

Ist aber schon klar, dass das Ändern von States potentiell den Update von x angeschlossenen vis GUI's, das Ausführen von Skripten und das Senden via mqtt usw triggert?

In so fern sollte man da wirklich etwas vorsichtig mit sein.

LG,

Ralf

[uweklatt]

Hallo,

sinnvoll bzw. hilfreich wäre ein zusätzlicher Parameter für setState() mit der Funktion synchrone/asynchrone Ausführung.

Dann könnte man sich das Rumgehampel mit Callbacks sparen und der Code macht das, was man erwartet.

Tschau

Uwe

[paul53]

@uweklatt:

und der Code macht das, was man erwartet. `
…was Du erwartest.

[uweklatt]

Hallo Paul,@paul53:

…was Du erwartest. ` Ja, und was die Mehrheit der "Laienprogrammierer" auch erwartet

Tschau

Uwe

[apollon77]

Es ist korrekt das der JavaScript-Adapter an sich alles versucht synchron zu machen.

Welche JS-Version ist im Einsatz?

Wenn aktuell (mind 3.4.x) dann bitte GitHub Issue aufmachen dafür, sonst bitte updaten und neu versuchen

[gst666]

States sind keine Variablen. Falls man wie rataplan rechnen will, so sollte man die States in eine Variable einlesen und dann wenn die Berechnungen abgeschlossen sind, kann man den Wert in einen State wieder zurückschreiben.

Auch wenn es sich platt anhört. States sind keine Variablen.

Wer sich mal gewundert hat, warum man beim auslesen der States am Ende .val angibt, mag folgendes ausprobieren:

console.log(JSON.stringify(getState("obj")));

obj durch einen gültigen State ersetzen.

Wie man sieht, werden eine Reihe von Daten gespeichert und nicht nur der Wert des eigentlichen States. Bei zu häufiger Verwendung wird das System stark belastet.

[rantanplan]

@tempestas:

Ehrlich gesagt verstehe ich dich da nicht ganz.

….. Es gibt doch eh nur ein (bzw vier in deinem Beispiel) Endergebnis(se). `
Das Beispiel ist auch nur zur Verdeutlichung und sonst ziemlich sinnlos.

Das Problem tauchte bei einem "Hilfsprojekt" hier im Forum auf.

Zudem lief es bei mir und bei dem User nicht.

Da scheinen auch die Leistungsstärke des verwendeten System eine Rolle zu spielen.

Erst ein "Stresstest" brachte mich auf die Fährte.
@tempestas:

…Warum soll es "eleganter sein", wenn States im Milisekundentakt beschrieben und ausgelesen werden anstatt direkt nur mit Variablen zu Arbeiten?... `
Versetzt Dich mal bitte in einen Blockly-Anfänger.

Grüße

[rantanplan]

@apollon77:

Welche JS-Version ist im Einsatz?

Wenn aktuell (mind 3.4.x) dann bitte GitHub Issue aufmachen dafür, sonst bitte updaten und neu versuchen `
3.4.5 ist bei mir im Einsatz.

GitHub ist für mich leider immer noch eine Blackbox :oops:

Werde es mal bei Trello versuchen.

Grüße

[apollon77]

Github issues anlegen ist simpel.

Github.com , Account anlegen mit E-Mail. Dann im entsprechenden github Projekt (Adapter rechts beim Fragezeichen),dort auf issues und create issue. Text eingeben. Done

[tempestas]

Hi Rantanplan,

Ich verstehe nicht, warum du der möglichen Lösung so ablehnend gegenüber stehst? Zumal die Probleme mit den States ja schon beschrieben wurden?

@rantanplan:

Versetzt Dich mal bitte in einen Blockly-Anfänger. `

Kann ich nicht; Blockly war mir zu schwierig, habe ich nie verstanden (ehrlich, ich verstehe es nicht und finde es erstaunlich, wie du damit zauberst) und daher gleich versucht, JS zu lernen. Da bin ich noch immer dabei. Jeden Tag ein Stückchen mehr dank geduldiger Leute wie Pix, paul53 und vielen mehr.

Aber ganz grundsätzlich:

Nach meiner Erkenntnis hier im Forum ist es eher so, dass jeder, der sich minimal mit "programmieren" beschäftigt, sei es Blockly oder direkt JS, so etwas wie Variablen kennt. Denn Variablen gibt es in jeder Sprache seit jeher. Dagegen sind die states für Viele etwas Neues.

Warum sollte es für einen Anfänger leichter sein, States zu verstehen als Variablen, die mit Werten gefüllt werden und diese ganz am Ende dann zurückspielen? Das erschließt sich mir nicht; völlig losgelöst von der Frage, womit programmiert wird.