@fastfoot
Beim Suchen nach Exec und wait bin ich hierher gekommen. Auch wenn das Thema etwas älter ist, es bleibt aktuell. Und danke für die vielen Anregungen!
Für alle, die in BLOCKLY eine execcmd- Funktion möchten, die auf das Ergebnis des Kommandos wartet und das Ergebnis dann auch direkt an eine Variable weitergeben kann: Hier die entsprechende JS-Funktion, die man in den Block "JS-Funktion mit Ergebnis" innerhalb Blockly -> Funktionen einfügt.

return new Promise((resolve, reject) => {
        exec(cmd, function (error, stdout, stderr) {
            resolve(stdout);
        });
    });

Den Unterschied zum klassischen exec-Block sieht man an folgendem Beispiel (Timestamps beachten).
Wer mit asynchroner JS-Programmierung superfit ist, und verschachtelte callbacks mag, braucht das natürlich nicht Vielleicht hilft es ja jemandem, der wie ich danach gesucht hat.

@mcm1957 : done,
https://github.com/iobroker-community-adapters/ioBroker.rpi2/issues/292
Tks für den Hinweis, hätte ich sonst nicht gemacht, weil ich dachte das hier ist das Forum, in dem soetwas reingehört.

Axel21git created this issue in iobroker-community-adapters/ioBroker.rpi2

open misspelling in json-file leads to warning in protokoll solution availlable #292

@smallfeuer Mich hat diese Meldung gestört, weil sie das einzige Warning in meinen iobroker-Protokollen erzeugt.

nodejs: V 20.19.1 rpi2: V 2.4.0

warn: admin.0 (19971) rpi2 has an invalid jsonConfig: [{"instancePath":"/items/_gpios/items/_pullUpWarning/hidden","schemaPath":"#/patternProperties/%5E.%2B/properties/hidden/type","keyword":"type","params":{"type":"string"},"message":"must be string"},{"instancePath":"/items/_gpios","schemaPath":"#/properties/items/patternProperties/%5E.%2B/allOf/9/if","keyword":"if","params":{"failingKeyword":"then"},"message":"must match \"then\" schema"},{"instancePath":"","schemaPath":"#/if","keyword":"if","params":{"failingKeyword":"then"},"message":"must match \"then\" schema"}]

Ich habe diese Warnings wie folgt ausgeschaltet: Auf meinem Raspi 4B gibt es die Datei:

/opt/iobroker/node_modules/iobroker.rpi2/admin/jsonConfig.json

In dieser gibt es ab Zeile 122 die Zeilen:

"_pullUpWarning": {
                    "type": "staticText",
                    "text": "pullupwarning",
                    "hidden": false,
                    "style": {

Hier habe ich hinter dem "hidden" das "false" in doppelte Anführungszeichen gesetzt.

"_pullUpWarning": {
                    "type": "staticText",
                    "text": "pullupwarning",
                    "hidden": "false",
                    "style": {

Das gleiche habe ich dann noch in der Datei

/opt/iobroker/iobroker-data/files/rpi2.admin/jsonConfig.json

gemacht.

Seither ist das Warning verschwunden.

Auf die Idee bin ich aufgrund der Fehlermeldung gekommen. Offenbar erwartet die Eigenschaft "hidden" den Typ "string", das sieht man korrekt auch einige Zeilen weiter unten in der json-Datei.

Welche der beiden Dateien wirklich wichtig ist, bleibt mir unklar. Zunächst sieht es so aus, als wäre nur die erste wichtig. Löscht man jedoch die zweite funktioniert es gar nicht.
Da es aber nur ein Workaround ist und dieser einen reboot überstanden hat bin ich soweit zufrieden.

Vielleicht kann der Developper @Garfonso dies ja bitte noch prüfen und ggf. richtig korrigieren.

@Garfonso als developper: Vielen Dank für den deutlichen Hinweis, dass man den Adapter deinstallieren muss und das dann zunächst die library zu installieren hat. Das Upgrade von 1.3 hat daraufhin auf Anhieb funktioniert.

@oliverio
Zu Deinem Trick mit "global". Eben ausprobiert:

function function1 (a,this1) {
    global=this1;
    this1.console.log('innerhalb function1 this1.console.info'); // wird geloggt
    console.log('innerhalb function1 mit global-Trick'); // wird leider ins nirgendwonicht geloggt
return a+1;
}
exports.function1 = function1;

mit Aufruf

foo = require('../../../iobroker-data/modules/modneu.js');
console.log(foo.function1(9, this));

Leider nein: Aber einen solchen Hack hatte ich bei java vor jahren einmal. Mit einigen (internen und problematischen) Funktionen war es meiner Erinnerung nach möglich, den Kontext der aufrufenden Funktion zu ermitteln. War nicht lehrbuchgemäß, hatte aber funktioniert.

Danke dennoch, jetzt wissen wir, dass es so nicht geht.
Und wenn kein Erfahrener hier meint, dass man das an die javascript-Adapter-Leute weitermelden soll, dann ist es auch für mich gut.
Danke nochmals an alle, die bisher mitgedacht haben.

@ticaki
Ok Danke für diesen Tipp.
Der Post läuft gerade in eine andere Richtung als gedacht.

Ich habe drei Lösungen wie ich im require-scope ein log in die iobroker-console loggen kann.
Alle diese Lösungen erfordern das übergeben von "this" über die Funktion.

Für mich ist dieser Teil abgeschlossen.

Offen bleibt für mich und darum geht es mir:
Ist es so richtig im iobroker-javascript-Adapter implementiert?
Ist es so gewollt, dass die Ausgabe eines einfachen console.log im require-scope ohne this-trick - im nirgendwo landet?
Ist es gewollt, dass console.log im main und im require-scope an unterschiedliche Stellen (iobroker-console vs. nirgendwo) hinloggen.
Ist es gewollt, dass die iobroker-javascript-engine sich hier anders verhält als ein andere engine (hier node.js). Hier bekomme ich in beiden scopes das logging an die gleiche Stelle und kann es dort lesen.

Das ist meine Frage. Wenn die erfahrenen Leute hier sagen: "Ist so ok", dann -> closed.

@oliverio
Danke, da haben sich die Posts zeitlich überschnitten.

Nochmal in Kürze:
Es existiert ein Workaround, ich komme also zurecht.
a) Aufrufende Funktion um ", this" ergänzen
b) Aufgerufene Funktion um ", this1" ergänzen.
c) this1.console.log oder this1.log verwenden.

Das finde ich reichlich umständlich für ein console.log() zum debuggen.

Außerdem von der Systematik her:
console.log schreibt im require-scope "irgendwo" hin, nur wohin???
Wäre es dann nicht sinnvoll, die neue iobroker console.log in diesen require scope im Adapter im wrapper mit einzubinden, so dass auch im require-scope in den iobroker geloggt wird?

Dann erst wäre das Verhalten von iobroker-javascript identisch mit dem node.js bezüglich console.log.
In node logt console.log sowohl im main-prg als auch im require-scope an die gleiche Ausgabe (weil statische globale Funktion) .

Soweit zur Erläuterung hope that helps.
Tks!

@ticaki
Vielen Dank für die schnelle Antwort.
Im Hauptprogramm funktioniert log('logtext') mit der Ausgabe auf die iobroker - Console.

Im require-scope funktioniert bei mir weder this.log('logtext') noch log('logtext').
Beides Mal gibt es eine Fehlermeldung "this.log is not a function" bzw. "log is not a function".
Unter node.js gibt es log(' ') nicht. Daher ist das Verhalten für mich nachvollziehbar.

Anders als console.log ist log wohl eine rein iobroker-Funktion, die es im require-scope nicht mehr gibt.
Daher funktionier this1.log('text'), genauso wie this1.console.log('text); im zweiten Beispiel.
Aber dazu muss dann eben wieder this übergeben werden.

Leider ist das keine Lösung. Danke dennoch!

Im iobroker Javascriptadaper habe ich viele Skripts, die Funktionen z.B. "function1" verwenden.
In die "globalen Skripte (global)" sollen sie nicht hinein, da sind dann ja vor jedes Skript eingebunden werden und hier im Forum mehrfach auf die Speicherproblematik hingewiesen wurde.

Die Methoden sind ausgelagert in die Datei modneu.js, darin zwei Consolenmeldungen zum debuggen.

function function1 (a){
          // do some stuff
          console.log('console.log innerhalb function1');
          console.debug('console.debug innerhalb function1');
        return a+1;
    }
exports.function1 = function1;

Aufruf in main.js:

foo = require('../../../iobroker-data/modules/modneu.js');
console.log(foo.function1(9));

Nach dem Neustart des javascripts-Adapters (nach jeder Änderung von modneu.js!) zeigt die javascriptkonsole nur die Ausgabe "10" also 9+1.
Die Consolen-Logs zum debuggen innerhalb der requirefunktion werden nicht angezeigt.

Nun habe ich hier im Forum gelernt, dann man iobroker-Befehle im require-scope nur nutzen kann, in dem man als zusätzlichen Parameter der Funktion this oder globalThis mit übergibt. Dies ist für mich eine gute Lösung, wenn ich iobroker-spezifische Befehle wie setState verwenden möchte.

function function1 (a, this1){
          // do some stuff
          this1.console.log('console.log innerhalb function1');
          this1.console.debug('console.debug innerhalb function1');
        return a+1;
    }
exports.function1 = function1;

Übergabeparameter jetzt (9, this) in main.js:

foo = require('../../../iobroker-data/modules/modneu.js');
console.log(foo.function1(9, this));

Jedoch: console.log ist ein Standard-Befehl von node.js. Dieser Befehl wird vermutlich innerhalb der javascript-adapters so umgelenkt, dass die Ausgabe schön unterhalb des Scriptfensters in iobroker zu sehen ist. Im scope von require gibt es also dieses sinnvolle adapter-spezifische console.log() nicht mehr.

Vermutlich wird ohne this im ersten Fall eine andere console.log verwendet, die aber nicht in das iobroker-Fenster weiterleitet. Nur, wohin gehen die logs, wo kann ich den debug-Ausdruck irgendwo sonst finden?

Bei node.js werden die console.log() Ausgaben standardmäßig auf stdout geschrieben. Daher habe ich mit: systemctl stop iobroker und dann iobroker von hand über node gestartet und die Standardausgabe von node ansehen. Negativ, ebenso keine zusätzlichen logfiles in /opt/iobroker/log. Andere logfiles habe ich nicht gefunden.

Ich bin unsicher, ob das ein Bug ist, weil im wrapper der require-funktion die neue console.debug/info/... -Funktionen noch nicht mit eingebunden wurden und somit kein debuggen mit console.log möglich ist. Oder ist das richtig so und obiges Verhalten einfach die Konsequenz, wenn man require verwenden will, weil man keine globalen Skripte wegen des Speicherplatzes möchte?

Oder gibt es eine einfache Lösung, die ich übersehen habe?
Tks!

@oliverio @ticaki @Asgothian
Ein ganz herzliches Dankeschön! Drei Lösungen, die funktionieren.

@oliverio @ticaki:
Aus Euren Beiträgen habe ich verstanden, warum ich beim Suchen im Netz nicht fündig wurde: Ich habe nach dem Falschen gesucht. Ich wollte die gesuchte Funktion erneut einbinden. Jetzt habe ich verstanden, dass es darum geht, den this Kontext mit zu übergeben. Dann kann ich in der include-Datei auf alles was ich möchte zugreifen - wunderbar!
Mit dieser Lösung kann ich meinen state iobroker-State 0_userdata.0.errstate im Fehlerfall setzten und diesen im Hauptprogramm dann mit einer Fehlerbehandlung weiterverfolgen. Das ist genau das, was ich für mein großes Script brauche, das einen größeren Ablauf steuert und im Fehlerfall dann in den "Error"-Zustand versetzt wird. Prima!

@Asgothian: Auch Deine Lösung, eine Funktion mit zu übergeben, funktioniert.
Durch Deinen Post habe ich nocheinmal über eine callback-Funktion nachgedacht. Denn in einem anderen main Skript möchte ich - ohne states - einfach nur die Variable senderror im main-Prog durch das Include-Prg. setzen.

Das hatte ich zunächst verworfen, denn ich dachte fälschlicherweise, die callback-Funktion wird im context der include-Datei ausgeführt und damit wäre das Setzen meiner senderror-Variable des main-Programmes in diesem context nicht möglich.
Dennoch funktioniert es!
Wenn ich also (in einem anderen Skript) nur einen Schreibbefehl habe, dann kann ich mit

 my = require('../../../iobroker-data/modules/mod1.js');
 result = await my.mywrite(cmd, (h) => {senderror=(h)});

meine Variable errstate im main-Programm setzten und direkt abfragen, wenn ich in der includedatei mod1.js die callbackfunktion aufrufe.

async function mywrite(cmd, callback) { 
// do some stuff
// im Fehlerfall: 
callback("ERROR77");
return myresult; 
}

Dass dies funktioniert, zeigt, dass ich noch einiges zu lernen habe über JS-scopes und JS-this (das anders ist als java-this). Bei der Internetrecherche bin ich dann auf .call und .bind gestoßen und .... Puh, es ist kompliziert.

Dabei will ich ja eigentlich nur ein einfaches #include(mod1.js). Das wäre so einfach, kein scope-Wechsel, kein require, kein this. Aber dass es #include nicht gibt, wurde in einem anderen Beitrag im Forum ja schon mehrfach erläutert.

So damit habe ich jetzt zwei Lösungen. Eine "große" und eine "kleine" und ich sage nochmals

D A N K E

für die passenden und schnellen Lösungen!

Hallo zusammen!
Ich habe eine JS-Funktion, die eine ausgelagerte Funktion aufruft:

// Beschreibe diese Funktion …
async function mywrite(cmd) {
    my = require('../../../iobroker-data/modules/mod1.js');
    result = await my.mywrite(cmd);
// weiteres
    return result;
}

die Datei mod1.js lautet

async function mywrite(cmd) { 
// do some stuff
// hier soll der iobroker-State 0_userdata.0.errstate auf true gesetzt werden, nur wie geht das????
  return myresult; 
}

Wie setzt man in dieser augelagerten Datei einen iobroker-state 0_userdata.0.errstate??
Die Funktionen setState und setStateAsync sind in der ausgelagerten Datei nicht verfügbar!
Ich vermute, man muss am Anfang der ausgelagerten Datei ein require einfügen. Nur welches Module und wie genau mache ich das?
Ich habe im Netz mir einen Wolf gesucht, daher wäre ich dankbar über

1. Eine Lösung
2. Einen Hinweis nach welchen Stichworten ich hätte suchen müssen, um die Lösung selbst herauszufinden.

Danke!

Warum die ausgelagerte Datei? Weil die Funktion dort sehr lange ist und immer mal wieder geändert werden muss und in vielen Skripten Verwendung findet. Mir ist bekannt, dass ich den javascript-Adapter nach jeder Änderung dieser ausgelagerten Datei neu starten muss. Und bisher möchte ich mich nicht in die Adapter-Entwicklung einarbeiten, außer es geht nicht anders.

@fastfoot
Beim Suchen nach Exec und wait bin ich hierher gekommen. Auch wenn das Thema etwas älter ist, es bleibt aktuell. Und danke für die vielen Anregungen!
Für alle, die in BLOCKLY eine execcmd- Funktion möchten, die auf das Ergebnis des Kommandos wartet und das Ergebnis dann auch direkt an eine Variable weitergeben kann: Hier die entsprechende JS-Funktion, die man in den Block "JS-Funktion mit Ergebnis" innerhalb Blockly -> Funktionen einfügt.

return new Promise((resolve, reject) => {
        exec(cmd, function (error, stdout, stderr) {
            resolve(stdout);
        });
    });

Den Unterschied zum klassischen exec-Block sieht man an folgendem Beispiel (Timestamps beachten).
Wer mit asynchroner JS-Programmierung superfit ist, und verschachtelte callbacks mag, braucht das natürlich nicht Vielleicht hilft es ja jemandem, der wie ich danach gesucht hat.

@mcm1957 : done,
https://github.com/iobroker-community-adapters/ioBroker.rpi2/issues/292
Tks für den Hinweis, hätte ich sonst nicht gemacht, weil ich dachte das hier ist das Forum, in dem soetwas reingehört.

Axel21git created this issue in iobroker-community-adapters/ioBroker.rpi2

open misspelling in json-file leads to warning in protokoll solution availlable #292

@smallfeuer Mich hat diese Meldung gestört, weil sie das einzige Warning in meinen iobroker-Protokollen erzeugt.

nodejs: V 20.19.1 rpi2: V 2.4.0

warn: admin.0 (19971) rpi2 has an invalid jsonConfig: [{"instancePath":"/items/_gpios/items/_pullUpWarning/hidden","schemaPath":"#/patternProperties/%5E.%2B/properties/hidden/type","keyword":"type","params":{"type":"string"},"message":"must be string"},{"instancePath":"/items/_gpios","schemaPath":"#/properties/items/patternProperties/%5E.%2B/allOf/9/if","keyword":"if","params":{"failingKeyword":"then"},"message":"must match \"then\" schema"},{"instancePath":"","schemaPath":"#/if","keyword":"if","params":{"failingKeyword":"then"},"message":"must match \"then\" schema"}]

Ich habe diese Warnings wie folgt ausgeschaltet: Auf meinem Raspi 4B gibt es die Datei:

/opt/iobroker/node_modules/iobroker.rpi2/admin/jsonConfig.json

In dieser gibt es ab Zeile 122 die Zeilen:

"_pullUpWarning": {
                    "type": "staticText",
                    "text": "pullupwarning",
                    "hidden": false,
                    "style": {

Hier habe ich hinter dem "hidden" das "false" in doppelte Anführungszeichen gesetzt.

"_pullUpWarning": {
                    "type": "staticText",
                    "text": "pullupwarning",
                    "hidden": "false",
                    "style": {

Das gleiche habe ich dann noch in der Datei

/opt/iobroker/iobroker-data/files/rpi2.admin/jsonConfig.json

gemacht.

Seither ist das Warning verschwunden.

Auf die Idee bin ich aufgrund der Fehlermeldung gekommen. Offenbar erwartet die Eigenschaft "hidden" den Typ "string", das sieht man korrekt auch einige Zeilen weiter unten in der json-Datei.

Welche der beiden Dateien wirklich wichtig ist, bleibt mir unklar. Zunächst sieht es so aus, als wäre nur die erste wichtig. Löscht man jedoch die zweite funktioniert es gar nicht.
Da es aber nur ein Workaround ist und dieser einen reboot überstanden hat bin ich soweit zufrieden.

Vielleicht kann der Developper @Garfonso dies ja bitte noch prüfen und ggf. richtig korrigieren.

@Garfonso als developper: Vielen Dank für den deutlichen Hinweis, dass man den Adapter deinstallieren muss und das dann zunächst die library zu installieren hat. Das Upgrade von 1.3 hat daraufhin auf Anhieb funktioniert.