NEWS
SetState() nach createState() schreibt nichts?
-
Heisst, er reagiert auf das setzen der initialen Werte auch wenn das "on" vom Ablauf her noch gar nicht gesetzt wurde …hm ... ich schau morgen mal nach ...
-
Heisst, er reagiert auf das setzen der initialen Werte auch wenn das "on" vom Ablauf her noch gar nicht gesetzt wurde …hm ... ich schau morgen mal nach ... `
Genau. Ich habe das heute Morgen noch einmal getestet. Mal klappt es, mal klappt es nicht.
Als ob die Subscriptions manchmal noch aktiv wären, obwohl das Skript neu gestartet wurde.
[EDIT] Auszug des erweiterten Logs im Fehlerfall:
06:54:32.661 [info] javascript.1 script.js.Steuerung.Alexa_cURL_Kommandos: 96: alexa_device_command.other_devices.Michael_s_echosim_BETA._info.device_type mit Wert: A3H674413M2EKB (string) angelegt 06:54:32.661 [info] javascript.1 script.js.Steuerung.Alexa_cURL_Kommandos: 97: alexa_device_command.other_devices.Michael_s_echosim_BETA._info.essid mit Wert: null (string) angelegt 06:54:32.661 [info] javascript.1 script.js.Steuerung.Alexa_cURL_Kommandos: 98: alexa_device_command.other_devices.Michael_s_echosim_BETA._info.macAddress mit Wert: null (string) angelegt 06:54:32.661 [info] javascript.1 script.js.Steuerung.Alexa_cURL_Kommandos: --- Alexa Kommandos - Datenpunkte angelegt --- 06:54:32.661 [info] javascript.1 script.js.Steuerung.Alexa_cURL_Kommandos: --- Subscriptions angelegt --- 06:54:32.661 [info] javascript.1 script.js.Steuerung.Alexa_cURL_Kommandos: Kommando für: Arbeitszimmer_Echo_Dot_sw 06:54:32.661 [info] javascript.1 script.js.Steuerung.Alexa_cURL_Kommandos: Kommando: {"type":"tunein","station":"s100198"} 06:54:32.661 [info] javascript.1 script.js.Steuerung.Alexa_cURL_Kommandos: Data to request body: {"type":"tunein","station":"s100198"} 06:54:32.661 [info] javascript.1 script.js.Steuerung.Alexa_cURL_Kommandos: Kommando für: Kueche_Echo_Dot_ws ... usw.
Die Datenpunkte haben alle einzeln zurückgemeldet,dass sie angelegt wurden.
Die Subscriptions werden angelegt.
Die Subscriptions reagieren auf die gerade vorher angelegten Werte.
-
ich hab da nur eine Idee, dass am Ende die "setStates" die beim ANlegen der States passieren ja auch asynchron sind und daher bei der Ausführung durchaus dann nach den "on"s ausgeführt werden könnten.
Um das ggf rauszufinden wäre eine Idee das anlegen der subscriptions um 1-2 Sekunden zu verzögern … also ein "setTimeout(function ..., 2000) einzubauen. Das sollte/könnte den setStates genug Zeit geben um auch abgearbeitet zu sein.
Dann sieht man ob es daran lag ...
Oder Du baust eine "initDone" Variable ein die am Anfang "false" ist und nach Anlegen aller Subscriptions (ggf zeitverzögert) auf "true" geht und in deinem Subscription code prüfst Du ob die true ist und machst nur dann die Logik
-
setState hat auch eine callback-Methode. Man könnte das so handhaben (Pseudocode, => steht für Callback):
createAllStates(): für jeden State: createState => Alle States angelegt? Dann setAllStates() setAllStates(): für jeden State: createState => Alle States gefüllt? Dann init() init(): subscriptions anlegen
@OP: Welche Node-Version verwendest du? Wenn es mindestens 4.X ist kannst du auch auf Promises gehen. Ich poste dir dann gerne Code. Dann würde sich die Initialisierung grob wie folgt gestalten inklusive Ablaufkontrolle:
var createStates = [...]; // Array mit Promises füllen, die States anlegen var fillStates = [...]; // Array mit Promises füllen, die States füllen Promise.all(createStates) .then(function() {return Promise.all(fillStates)}) .then(function() { /* Subscriptions und Skript initialisieren */ }) ;
-
Ich glaube er nutzt hier die Möglichkeit automatisch einen ersten Wert bei createState zu setzen … gerade nachgeschcut. Der clalback sollte dann erst aufgerufen werden wenn auch das setState durch ist ... Also komisch ists
-
@apollon77 und @AlCalzone: erst einmal herzlichenDank für Eure Gedanken und Mühe! :!:
Vorweg der aktuelle Stand, gerade getestet:
-
das Problem ist nicht immer reproduzierbar
-
alle Versuche vorhin waren so, wie sie sein sollten
Ich vermute, dass es ggf. an der Auslastung des Rechners liegt und dass das Setzen des initValue nicht im callback des createState() berücksichtigt ist.
Also immer noch in Teilen asynchrone :?:
ich hab da nur eine Idee, dass am Ende die "setStates" die beim ANlegen der States passieren ja auch asynchron sind und daher bei der Ausführung durchaus dann nach den "on"s ausgeführt werden könnten. `
Du meinst, da ich das initialValue beim ersten Anlegen oder beim Überschreiben (nicht der normale Vorgang, nur wenn ich Änderungen in den Bezeichnungen durchgeführt habe) verwende, ruft der Javascript-Adapter innerhalb der Funktion createState() ein setState() auf und dieses ist im Callback von createState() noch nicht berücksichtigt?
Ich habe mal in den Code vom Javascript-Adapter reingeschaut.
Im createState gibt es u.a. diese Zeile:
if (initValue !== undefined) { adapter.setState(name, initValue, callback);
Ob das dann beim callback vom createState mit berücksichtig ist… da bin ich definitiv raus
Um das ggf rauszufinden wäre eine Idee das anlegen der subscriptions um 1-2 Sekunden zu verzögern … also ein "setTimeout(function ..., 2000) einzubauen. Das sollte/könnte den setStates genug Zeit geben um auch abgearbeitet zu sein.
Dann sieht man ob es daran lag ... `
Hatte ich gemacht, bevor ich oben gepostet hatte. Hilft etwas… aber nicht immer.
Oder Du baust eine "initDone" Variable ein die am Anfang "false" ist und nach Anlegen aller Subscriptions (ggf zeitverzögert) auf "true" geht und in deinem Subscription code prüfst Du ob die true ist und machst nur dann die Logik `
Verstehe ich nicht ganz. Das Problem liegt doch vorher oder?
Es sollten alles States gesetzt sein, bevor die Subscritions angelegt werden.
setState hat auch eine callback-Methode. Man könnte das so handhaben (Pseudocode, => steht für Callback): `
Das wäre die Variante, wenn das createState wirklich die dort enthaltenen setStates asynchrone aufruft?
Also auf initialValue verzichten.
Dann kommt hinzu, dass vorher geprüft werden muss, ob die Werte gesetzt werden müssen (nur beim ersten Start oder bei forcecreation)?
@OP: Welche Node-Version verwendest du? Wenn es mindestens 4.X ist kannst du auch auf Promises gehen. Ich poste dir dann gerne Code. Dann würde sich die Initialisierung grob wie folgt gestalten inklusive Ablaufkontrolle: `
Ich selbst verwende 4.x. Ich überlege, ob es sich lohnt das Skript als Prototype für einen Adapter zu verwenden.
Denke da an die Abwärtskompatibelität…
Da ich das mit den Callbacks() wohl nicht mehr so schnell in den Kopf bekomme, bietet es sich an doch mal Promises anzusehen
Kann das direkt verwendet werden oder muss da noch was geladen werden?
Aber prinzipiell würde ich gerne verstehen, woran es jetzt gerade das Problem ist
-
-
Da ich das mit den Callbacks() wohl nicht mehr so schnell in den Kopf bekomme, bietet es sich an doch mal Promises anzusehen
Kann das direkt verwendet werden oder muss da noch was geladen werden? `
Ab Node 4.x ist das eigentlich nativ unterstützt. Das Skript läuft dann aber nicht unter einer 0.10.x-Umgebung, das muss dir klar sein.Ich sehe zu, dass ich dir heute Abend mal ein bisschen Code bastele zum Testen.
Aber prinzipiell würde ich gerne verstehen, woran es jetzt gerade das Problem ist
`
Dass dein Problem nicht immer reproduzierbar ist, klingt für mich nach Timing-Problemen durch asynchronen Programmablauf. Wenn eine Aktion dann mal länger dauert, hakts woanders. -
Aber warte mal … vllt löst sich dein Problem bald von selbst:
-
Die Funktionen lassen sich vorübergehend sehr leicht "synchron" nachrüsten. Wie gesagt, Code liefere ich später
Den dazu benötigten Nachrüst-Code kann man dann - wenn es soweit ist - wieder entfernen, die Logik funktioniert weiterhin.
–-
Edit: Anscheinend sind die neuen Methoden dann wirklich synchron, und nicht als Promises gekapselt wie angenommen.
Musst du wissen @ruhr70 ob du jetzt was haben willst, oder noch ein bisschen warten kannst.
-
Edit: Anscheinend sind die neuen Methoden dann wirklich synchron, und nicht als Promises gekapselt wie angenommen.
Musst du wissen @ruhr70 ob du jetzt was haben willst, oder noch ein bisschen warten kannst. `
Beim Skript bin ich erst einmal im Reinen. Bei der Funktion. createState() synchron mit Callback und dann setTimeout für die Subscriptions.
Ist der schlimmste Spagetti-Code geworden… aber nun ja.
Ich kann also warten ;-). Das Promises Thema werde ich mir aber trotzdem mal ansehen. Nur die Adapter-Funktionen werden ja dann synchrone. Für das ganze drumherum braucht man dann auch eine Lösung... also Promises!?
-
Ich hatte Code versprochen…
Promise-Kapselung um eine Funktion mit Callback:
// Erwartet eine Funktion, die als letzten Parameter einen Node-JS-Callback annimmt. function promisify(fn, context) { return function (args) { context = context || this; return new Promise(function (resolve, reject) { args.push(function (error, result) { if (error) return reject(error); else return resolve(result); }); fn.apply(context, args); }); }; }
setState und createState mit Promise-Kapselung:
var $setState = promisify(setState), $createState = promisify(createState) ;
–-
Deine Programmlogik ist mir noch nicht 100% klar, aber ausgehend von dem Code http://forum.iobroker.net/viewtopic.php?p=63432#p63432, könntest du es mal so probieren:
// Datenpunkte in ein Array aus Promises umwandeln var createDPs = datenpunkteArr.map(function(dp) { return $createState(dp.name, dp.initialValue, dp.forceCreation, dp.common); }); // Auf Ausführung warten Promise.all(createDPs) .then(function() { // dann mit der Logik weitermachen, z.B. States füllen (geht ähnlich, siehe einer meiner früheren Posts) // oder Subscriptions starten // TODO });
-
Puh… Danke!!!
na, da habe ich ja was zu tun