Monatsrückblick Januar/Februar 2026 ist online!

[legro]

Zugegeben: Ich bin alles Andere als ein guter Kenner von JavaScript. Da mir Blockly, das mir den Einstieg in ioBroker überhaupt erst ermöglichte, mir mit der Zeit nicht mehr genügte, habe ich mich auf meine alten Tage doch noch in die Programmierung eingearbeitet.

Was ich schmerzlich vermisse.

Leider gibt es wohl In ioBroker weder eine Art Library noch einen Debugger. Offenbar soll die Implementierung des sog. globalen Ordners wenigstens ein wenig Abhilfe in Sachen Library schaffen. Wenn ich das Ganze richtig verstanden habe, werden die Inhalte aktivierter Skripte aus diesem globalen Ordner an den Anfang aller übrigen Skripte hinein kopiert. Leider bläht mir dieses Konzept mein System gewaltig auf, sodass ich dieses Konzept nicht (mehr) verwende.

Wäre dieser Vorschlag realistisch zu realisieren?

Ich stelle mir vor, dass ich mehrfach verwendete Funktionen in Gruppen aufteile und in separate Skripte packen kann. Anschließend möchte ich in den übrigen Skripten nur diejenige Gruppe zum Einbinden auswählen, die ich gerade für mein Skript benötige.

Vorteil

Es werden nur jene Skripte aus dem globalen Ordner in ein Skript kopiert, die gerade benötigt werden. Dies würde das Aufblähen aller Skripte erheblich verringern.

[OliverIO]

@legro

Aufteilen von Skripte

da gibt e mittlerweile mehrere threads. Eine so richtig gute standardlösung gibt es nicht, da das ablegen von extra Dateien im DAteisystem immer etwas schwierig ist.

Die beste Lösung ist glaube ich die Funktionen auf verschiedene Skripte aufzuteilen und die Funktionen über das Messagingsystem (messageToAsync,onMessage) aufzurufen. Ein Besipiel siehst du hier
https://forum.iobroker.net/topic/84000/skript-aufteilen-möglich/13?_=1775167478022

Debugger

gibt/gab es schon (so ein käferknopf, den ich aber jetzt nicht mehr sehe), aber der ist glaube ich nicht wirklich gut zu bedienen.
Wenn du, allerdings mit kleinen Einschränkungen, debuggen willst, dann verwende dazu vscode. für vscode gibt es auch eine extention die dir die scripte hin und her synchronisiert.
Allerdings stehen dir in vscode die iobroker funktionen nicht zur Verfügung. Also setState ist dort unbekannt.
Ich behelfe mich da immer mit stub-funktionen, die ich am Ende meines Skripts hinzufüge, also sowas wie

//vscode stub functions for iob
function on(/* event, callback */) { }
function setState(/* id, value, ack */) { }
function log(/* msg, level */) { }
function schedule(/* event, callback */) { }

Diese Funktionen machen einfach nichts. Wenn du zum testen dann das doch mal brauchst, kannst du das durch extra code einfach simulieren

Am Beispiel von getState würde das dann so aussehen:
Als erstes holt man sich den Rückgabewert von getState in einem skript im iobroker

log(JSON.stringify(getState("0_userdata.0.val1")));

Das erzeugt dann im log den folgenden Eintrag

{"val":"123","ack":false,"ts":1768518884892,"q":0,"from":"system.adapter.admin.0","user":"system.user.admin","lc":1768518884892}

Den kopiert man
und fügt ihn in eine stubfunktion wie folgt ein

function getState(id) {
  if (id === "0_userdata.0.val1") {
    return JSON.parse(
      '{"val":"123","ack":false,"ts":1768518884892,"q":0,"from":"system.adapter.admin.0","user":"system.user.admin","lc":1768518884892}',
    );
  }

und schon hat man seine Stummelfunktion für getState, mit der man dann seine Skripte im iobroker auch debuggen und testen kann.

[ofri2607]

@legro
Sieh‘ dir mal diesen Verlauf an https://forum.iobroker.net/post/1315989
Ich nutze das schon länger ohne Probleme.
Für mich ist der Vorteil darinnen, dass ich damit alles im Javascript-Adapter machen kann und keine externen Files einbinden muss. Und die Sicherung der Module erfolgt ganz normal mit dem ioBroker.

[legro]

@OliverIO

Vorab erst einmal vielen Dank für deine ausführliche Antwort.

Die bisher zu diesen Themen geführten Diskussionen führten leider in meinen Augen nicht zu praktikablen Lösungen. Es blieb letztendlich mehr oder weniger alles beim Alten. Daher habe ich wenig Hoffnung auf tiefgreifende Änderungen.

Meine Einsicht: Es ist wohl auch ein wenig vermessen, von einem System zur Hausautomatisierung eine Entwicklungsumgebung zu erwarten.

Debugger ..

Das dürfte daher ein Wunschtraum bleiben. Hierzu behelfe ich mich ausschließlich mit (Test)Ausgaben in die Console. Hinsichtlich der Verwendung von visual studio code blieb es bei mir leider bloß bei unglücklichen Versuchen.

Library ..

Hier hoffe ich jedoch darauf, dass man eine - doch wohl leicht zu realisierende Art - Include-Technik realisieren könnte: Am Beginn eines Skriptes gibt man an, welche globalen Skripte eingebunden werden sollen.

Hier ist meine derzeitige Notlösung: Ich erstelle in einem Verzeichnis (Library)Skripte mit Funktionen, die ich in mehreren (Anwendungs)Skripten benötige. Dazu kopiere ich das jeweilige (Library)Skript manuell die (Anwendungs)Skripte. Auf diese Weise kann ich sogar Variablen in diesen eingebunden Skripten verwenden.

[legro]

@ofri2607

Danke für den Hinweis.

Wenn ich das richtig verstanden habe, stellt die Option require .. genau das bereit, was ich mir wünsche: eine Library-Funktion.

Nur ist nach einem ersten Durchlesen mein Eindruck, dass das Ganze nicht wirklich problemlos funktioniert - vor allem nicht auf Dauer, da immer wieder Änderungen an diesem System vorgenommen werden. Oder schätze ich dies falsch ein?

[ofri2607]

@legro
Ich nutze das schon seit einiger Zeit ohne jegliche Probleme. Mittlerweile habe ich mehr als 20 Module (als Klassen, Factory-Functions oder Closures) so ausgelagert und es läuft sehr zuverlässig und gibt aus meiner Sicht viel mehr Struktur in den Skripten.
Da es ja eigentlich nur den Spiegelpfad aus dem Javascript-Adapter nutzt, denke ich auch nicht, dass es so einfach nicht mehr funktionieren würde.

Das einzig was etwas lästig ist, ist dass erforderliche Neustarten der Javascript-Instanz nach einer Änderung in einem Modul. Das ist aber bei den globalen Skripten im Wesentlichen ja auch so.
Dies ist auch mit einer der Gründe warum bei mir der Javascript-Adapter mit mittlerweile 5 Instanzen auf einem Raspi 4 (8 GB) als Slave läuft. Damit kann ich das halbwegs gut strukturieren, dass beim jeweiligen Instanzneustart nicht alle Skripte immer neu starten.
Was bei der Aufteilung auch problemlos funktioniert ist, dass das Hauptskript (das Skript das require aufruft) nicht in der selben Instanz sein muss wie das Modul, das funktioniert kreuz und quer.

[ticaki]

@legro sagte:
Nur ist nach einem ersten Durchlesen mein Eindruck, dass das Ganze nicht wirklich problemlos funktioniert - vor allem nicht auf Dauer, da immer wieder Änderungen an diesem System vorgenommen werden. Oder schätze ich dies falsch ein?

Das Problem ist hier einfach die Sinnhaftigkeit.

Globale Skripte z.B. machen weder den Javascript-Adapter langsamer, noch verbrauchen sie viel Speicher. Das ist nur ne Kopfsache.

Ich mal nachgeguckt und da ist bei mir ein 7000 Zeilen lange Map im globalen Ordner die ich nicht mehr brauche (hab nen Adapter dafür geschrieben)

Ohne das globale Skript verbrauchen die beiden Javascript-Adapter-Instanzen zusammen ca. 590 MB, mit aktiviertem globalen Skript ca. 609 MB. Beides ca. 2 Minuten nach Restart.

Ich hab rund 50 laufende Skript - das globale Skript hat 234368 Zeichen: 50 * 234kb =11 700 KB-> 11,7 MB kommt also hin.

Das ich 2 Javascript-Instanzen nutze kostet mich ca. 150MB extra.

Wenn ich viele Standardfunktion hätte, würde ich mir eine globale statische Klasse anlegen und dort den Kram rein machen. Werde ich aber nicht machen, da ich dann die Skripte nicht mehr einfach weitergeben kann.