UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[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 :cry:

[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 :cry:

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 :cry:

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.

[Homoran]

Jetzt möchte ich mich als Hüter und Beschützer der Einsteiger doch noch in diese Diskussion einmischen!

@paul53:

@uweklatt:

und der Code macht das, was man erwartet. …was Du erwartest.
und genau das ist der Knackpunkt.

Paul erwartet etwas anderes, weil er das Verhalten kennt und WEISS, dass die "übliche Laienerwartung" nicht erfüllt wird.

Daher kann ich rantanplans Aussage:
@rantanplan:

Versetz Dich mal bitte in einen Blockly-Anfänger. `
nur voll unterstreichen.

Selbst ich komme nicht mit js-klar. Ich kann es lesen, ggf. analysieren und durch try and error anpassen, aber das ist nichts für Einsteiger.

Die ohne jegliche Programmiererfahrung einfach etwas zusammenklicken wollen.

Dies geht mit Blockly sehr einfach, wenn man etwas strukturiertes Denken einsetzt.

@tempestas:

Blockly war mir zu schwierig, habe ich nie verstanden `
Das wiederum kann ich nicht verstehen, will dieses aber bitte nicht in diesem Thread diskutieren!

Die einzige Vermutung ist, dass du bereits so "programmierverseucht" (im positiven Sinne) bist, dass du Probleme hast das Programmierdenken absoluter Noobs nachzuvollziehen (auch das ist NICHT negativ gemeint, sondern meine Erfahrung in ähnlichen Fällen).

Blockly ist ein tolles Werkzeug um Einsteigern eine einfache Möglichkeit zu bieten visuelles coding auszuführen.

und genau deswegen hat Blockly natürlich auch Einschränkungen.

Und ein Einsteiger erwartet natürlich, dass Arbeitsschritte nacheinander abgearbeitet werden und man im dritten Schritt auf das Ergebnis vom ersten Schritt zugreifen kann.

Gruß

Rainer

[tempestas]

Hallo Rainer,

ich sage ja auch gar nicht, dass ich das Grundproblem nicht nachvollziehen kann.

Ich sage lediglich, dass wenn man Variablen einsetzt, es gehen sollte. Und mein Unverständnis bezieht sich dann darauf, dass das als "nicht schön" abgelehnt wird.

Warum sind Variablen weniger schön als States?

Kann man in Blockly keine Variablen setzen? Habe ich keine Ahnung.

Warum ist einem Blockly Anfänger vermeintlich ein State sofort zugänglich intellektuell, aber eine Variable nicht?

Letztlich ist der State wie er hier genutzt wird, ja nichts anderes als etwas dass ich unter Reiter Objects mir visuell ansehen kann.

Genutzt wird er aber zu 90% (nämlich bei 9 von 10 Durchläufen) wie eine Variable. Und diese 9x sehe ich noch nichtmal, da es ja, trotz aller Asynchronität, trotzdem alles sehr schnell geht nach menschlichem Ermessen.

Meine JS Kenntnisse lagen übrigens exakt bei 0 im März diesen Jahres. Sieht man auch an meinen ersten Postings, in denen ich verzweifelt versuche, einen Code zu verstehen :oops: :lol:

Und es gibt hier genug elegant programmierte Sachen, die ich noch immer nicht verstehe.

Aber das ist ja nicht das Thema

[AlCalzone]

@Homoran:

Und ein Einsteiger erwartet natürlich, dass Arbeitsschritte nacheinander abgearbeitet werden und man im dritten Schritt auf das Ergebnis vom ersten Schritt zugreifen kann. `
Die Erwartung kann ich nachvollziehen. Dennoch (und das sollte Einsteigern verständlich gemacht werden) sollten States nicht als Variablenersatz gesehen werden, da der Rattenschwanz dahinter zu groß ist (DB-Aktualisierung, mögliche UI-Aktualisierung, Skript-Trigger, etc…).

Das erwartete Verhalten, das du beschreibst, ist mit Skript-Variablen gegeben. Dafür sind sie da und dafür sollten sie benutzt werden. Das hat nichts mit "nicht schön" zu tun. Zwischenergebnisse von Rechnungen sollten in Variablen landen, nicht in States. States sind gedacht für etwas langlebigere Werte mit Bedeutung.

Jedes System hat Grenzen innerhalb derer man arbeiten soll/muss. Klare Regeln wie

• States sind für Eingabewerte (wie Sensordaten) und Endergebnisse von Berechnungen

• Variablen sind für Zwischenwerte
  verstehen auch Anfänger, wenn man es entsprechend kommuniziert.

Das ursprüngliche Problem vom TE ist für mit von der Kategorie

"Bist du dir sicher, dass du das wirklich machen willst? Ich glaube nicht!"