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

[Codierknecht]

Meine erste Frage wäre:
Die anonyme Methode beim exec wird mit 3 Parametern aufgerufen.
Kann man den 3. Parameter stderr einfach weglassen?

Zweite Frage (auch zum "exec"):
Wie würde man hier grundsätzlich ein Error-Handling einbauen?

[paul53]

@codierknecht sagte: createState nur 1x beim Start des Script, dann aber unterhalb von 0_userdata und mit Namen und Einheiten

Sehr gut, aber es fehlt type: 'number'

[OliverIO]

@codierknecht sagte in Learning JS - ein erster Versuch:

execCall

würde ich liebe execPython nennen

[Codierknecht]

Gute Idee, ich ziehe das im Eingangspost nach.

[Ahnungsbefreit]

@oliverio @Codierknecht Gute Idee von @OliverIO aber ich würde auch erst einmal prüfen, wie groß das Array ist und ob an den Stellen auch wirklich eine Zahl steht. Sonst steigt das Script aus oder Du schreibst Müll in den Datenpunkt

[paul53]

@codierknecht sagte: Kann man den 3. Parameter stderr einfach weglassen?

Ja.

@codierknecht sagte: Wie würde man hier grundsätzlich ein Error-Handling einbauen?

Einfachste Version:

if(!error) {
    // Auswertung von stdout / result
}

[OliverIO]

@codierknecht sagte in Learning JS - ein erster Versuch:

Die anonyme Methode beim exec wird mit 3 Parametern aufgerufen.
Kann man den 3. Parameter stderr einfach weglassen?

ja, kann man weglassen.
Notfalls kann man die möglichen Paramter auch diese auch über das Parameter-Array arguments entnehmen.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/arguments?retiredLocale=de

Kommt aber darauf an, wie die 'Fehlerbehandlung genau läuft.
Bin da jetzt kein Spezialist, da ich mit exec noch nicht so oft gearbeitet habe.

1. Fall 1: Programm gibt keinen Rückgabe Status, dann wurde es für node ohne Fehler ausgeführt. Wenn Programm den Fehler nur in stderr schreibt, dann muss da geparst werden
2. Fall 2: Programm gibt Rückgabe code für Fehler zurück, der müsste dann in error drin stehen. Die Fehlerbearbeitung müsste dann so aussehen

if (error) {
}

[Codierknecht]

@ahnungsbefreit
Das Array sollte dabei ja fix sein. Ein

if (array.length != 99) throw "Result does not match expected length";

sollte funktionieren, oder?

OK, die tatsächliche Größe des Array kenne ich aktuell nicht, da ich das Result aus dem Original-Post nie gesehen habe (oder zu faul bin das abzutippen).

Ich werde die Ergänzungen im im Eingangspost nachziehen, damit das hier nicht zu unübersichtlich wird.

[Codierknecht]

@ahnungsbefreit sagte in Learning JS - ein erster Versuch:

ob an den Stellen auch wirklich eine Zahl

Wirft parseInt() einen Fehler, wenn keine Zahl drin steht?

[paul53]

@codierknecht sagte: Wirft parseInt() einen Fehler, wenn keine Zahl drin steht?

Nein, es liefert NaN (Not a Number).

[Codierknecht]

@paul53 sagte in Learning JS - ein erster Versuch:

Nein, es liefert NaN (Not a Number).

Wie prüft man dann möglichst elegant?

if (isNaN(parseInt(valueArray[position.watt]) || isNaN(parseInt(valueArray[position.today]) ... 

sieht irgendwie reichlich sperrig aus.
OK, man könnte das auch noch in eine Prüfmethode auslagern.

Ihr seit mir schon fast zu schnell. Ich komme ja kaum noch nach

[paul53]

@codierknecht sagte: Wie prüft man dann möglichst elegant?

Ich würde es so machen:

  if(!isNaN(watts)) setState(dpPrefix + 'Watt', watts, true);
// usw.

[Codierknecht]

@paul53 sagte in Learning JS - ein erster Versuch:

@codierknecht sagte: Wie prüft man dann möglichst elegant?

Ich würde es so machen:

  if(!isNaN(watts)) setState(dpPrefix + 'Watt', watts, true);
// usw.

Ist oben eingebaut.
Das Problem das ich da sehe: Wenn da mal "NaN" drinsteht, wird lediglich nix in den DP geschrieben.
Eleganter wäre ja, wenn das iwie auch zu 'nem Fehler führen würde, der geloggt werden kann.
Ich bau oben mal eine Variante dafür ein. Mal sehen, was ihr davon haltet.

[paul53]

@codierknecht
Übrigens: Bei den Werten, die im ursprünglichen Thema zu sehen sind, darf man nicht mit parseInt() wandeln, sondern mit parseFloat().
Außerdem stehen die Werte laut Log immer hinter einem "):". Damit würde ich splitten.

[Codierknecht]

@paul53 sagte in Learning JS - ein erster Versuch:

@codierknecht
Übrigens: Bei den Werten, die im ursprünglichen Thema zu sehen sind, darf man nicht mit parseInt() wandeln, sondern mit parseFloat().
Außerdem stehen die Werte laut Log immer hinter einem "):". Damit würde ich splitten.

Natürlich … werde ich oben ändern.

@paul53 sagte in Learning JS - ein erster Versuch:

@codierknecht
Übrigens: Bei den Werten, die im ursprünglichen Thema zu sehen sind, darf man nicht mit parseInt() wandeln, sondern mit parseFloat().
Außerdem stehen die Werte laut Log immer hinter einem "):". Damit würde ich splitten.

Klingt auch etwas handlicher als mit Leerzeichen zu splitten.

[Codierknecht]

@paul53 sagte in Learning JS - ein erster Versuch:

Außerdem stehen die Werte laut Log immer hinter einem "):". Damit würde ich splitten.

Auch das habe ich oben geändert.
Damit ist das mit den Array-Indizes 1,2 und 3 schon fast so einfach, dass man das enum auch wieder weglassen könnte.
Ich lasse es aber wegen Wart- und Erweiterbarkeit mal drin.

[Codierknecht]

@codierknecht
Aktueller Stand für heute im Eingangspost.
Das Konvertieren und Prüfen der Werte habe ich in eine eigene Funktion ausgelagert.

Für heute lasse ich das erstmal so stehen. Morgen ist auch noch ein Tag.

Letzte Erkenntnis für heute:
Für mehr als 2-3 Zeilen JS lohnt sich auf jeden Fall die Installation von VSCode.

[Codierknecht]

@codierknecht
Warum meckert VSCode hier?

[OliverIO]

@codierknecht
Es ist zwar ein separater Block aber evtl kollidiert diese error Deklaration mit der aus dem exec callback. Dort Ishtar man auch so ein kleines strichlein mit einem Hinweis.
Was passiert wenn du das error aus dem catch Block bspw nach err umbenennst?

[Codierknecht]

@oliverio
Den Verdacht hatte ich auch schon - hilft nix
Hab's dann wieder zu "error" zurück geändert, weil das so in fast allen Dokus verwendet wird.
Der Scope ist ja auch ein völlig anderer als das "error" in der Callback.
Es wird ja auch gemeckert, dass die gar nicht deklariert wäre. Dann müsste ich aber try-catch völlig falsch verstanden haben.

Die 3 Punkte im Callback meckern nur an, dass hier keine Typdeklaration vorhanden ist.
Da wir hier JS und kein TS haben, habe ich das mal geflissentlich ignoriert

P.S.: Es meckert auch nur VSCode - im Editor im ioB sieht's OK aus