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

[Armilar]

@homoran sagte in TypeScript, viele common/global Scripte --> CPU am Anschlag:

Aber die Scripte machen doch in der Regel nichts beim Neustart

doch! sie weden kompiliert

Aber nur wenn es Änderungen gibt...

Ansonsten wird die Version aus dem Cache genutzt.

[paul53]

@armilar sagte: Ansonsten wird die Version aus dem Cache genutzt.

Das betrifft anscheinend den Precompiler TypeScript --> Javascript.
Skripte werden bei jedem Neustart kompiliert, da beim Stoppen der RAM freigegeben wurde.

[uwe72]

Ich habe aus ca. 40 (kleineren) Common-Scripte ca. 25 (größere) gemacht und von 8 global Scripten auf 5 reduziert.

Ich laufe nun zumindest nicht mehr in das CPU-Problem rein. Das Speichern nach dem Ändern eines Global-Script dauert nun ca. 5 Minuten.

Übrigens, das Ändern von Common-Scripten ist nie ein Problem, auch vor der "Optimierung" nicht.

[uwe72]

Generell mache ich sehr viel mit Scripten und stoße aktuell an Grenzen mit den Rahmenbedingungen:

• TypeScript
• ca. 40 common-Scripte
• ca. 5-8 global-Scripte (mit teilweise bis zu 3000 Zeilen Code)

Ich spiele in einer anderen ioBroker-Umgebung mit dem Thema "messageTo" herum mit dem Ziel ganz auf global-Scripte verzichten zu können.

Ist ein wenig ein konstruiertes Beispiel, aber ganze Klassen(-inhalte) bekommt man nicht verschickt, oder? Sondern vermutlich nur "primitive" Datentypen oder vermutlich json?

export class TestPosition {
    private threeQuarter:   number;
    private half:         number;
    private oneQuarter:     number;

    constructor(threeQuarter: number, half: number, oneQuarter: number) {
        this.threeQuarter = threeQuarter;
        this.half = half;
        this.oneQuarter = oneQuarter;
    }

    public getThreeQuarter() : number {
        return this.threeQuarter;
    }
    public getHalf() : number {
        return this.half;
    }
    public getOneQuarter() : number {
        return this.oneQuarter;
    }
}

//var data = "uwe";
var data = new TestPosition(10,20,30);

messageTo({ instance: 'javascript.0', script: 'script.js.common.Test2', message: 'message1' }, data, {timeout: 1000}, result =>
    console.log(JSON.stringify(result)));

//@ts-expect-error
onMessage('message1', (data, callback) => {
    console.log(`UWE !!! Received data: ${data}`); callback({ result: Date.now() });
    var my = data.getThreeQuarter();
    log("YIPIEEEEEEEEEEEEEEEEEE: " + my);
});

Error in callback: TypeError: data.getThreeQuarter is not a function

[paul53]

@uwe72 sagte: ca. 5-8 global-Scripte (mit teilweise bis zu 3000 Zeilen Code)

Das ist eindeutig viel zu viel. Dafür sind "globale" Skripte nicht vorgesehen.
So viele häufig verwendete eigene Funktionen?

[uwe72]

Bitte löschen.

[paul53]

@uwe72
Ist die Struktur der ioBroker-Objekte inkl. Aufzählungen so schlecht, dass man eigene globale Datenstrukturen benötigt?

[ticaki]

@uwe72
Hab das da zwar noch nicht probiert, aber als ich das mit Funktionen ausprobiert habe, hat es nicht funktioniert. Dann wird es IMHO wohl auch nicht mit Klassen gehen.

[uwe72]

@paul53 Hab das Beispiel noch ausgetauscht. Es ist nicht nur Datenstruktur, sondern auch viel Logik für generische Anwendungszwecke. Z.B. generische Alexasteuerung über IOT-Adapter, d.h. man gibt nur Alexanamen an und alles andere funktioniert automatisch (Registrierung der Datenpunkte im iot-Adapter, Lampen ein/aus,...).

Kann dennoch drüber nachdenken wie ich es schaffe, das aus dem global-Bereich rauszubekommen, zumindest große Teile davon nach common zu verschieben.

Ob, man mein Beispiel nun gut oder schlecht findet, wollte ich nur darauf hinweisen, dass ich eben mit den Rahmenbedingungen an Grenzen stoße.

Vielleicht stoßen andere mit "sinnvollen" Anwendungszwecken eben auch mal an diese Grenzen.

[Homoran]

@uwe72 sagte in TypeScript, viele common/global Scripte --> CPU am Anschlag:

gut oder schlecht findet

ist jetzt nicht die Frage.

Aber im Prinzip scheinst du ganze Programmteile von ioBroker mit eigenen Funktionen überstülpen zu wollen.

[uwe72]

@homoran Alles gut ;-)

[uwe72]

@oliverio habe deinen Hinweis mal ein wenig verfolgt. Habe es prinzipiell auch hinbekommen ein eigenes Modul auf https://www.npmjs.com/ anzulegen. Dieses Modul habe ich dann in ioBroker der Instanz hinzugefügt und konnte auch auf die Inhalte des Moduls innerhalb der ioBroker Scripte zugreifen. War allerdings alles mit JavaScript.

Was ich gerade gar nicht hinkriege ist, das Ganze noch mit Typescript zu machen. Müsste dies grundsätzlich funktionieren?

[OliverIO]

@uwe72
Ah ok, sogar auf NPM publiziert

NPM hat auch die Möglichkeit, Pakete einfach auf der Festplatte über Dateipfad zu referenzieren. Das meinte ich eigentlich.

Klar geht das auch mit Typescript.
Aber du weißt, dass Typescript nativ nicht ausgeführt wird, sondern vorher erst nach Javascript transpiliert werden muss.
Dazu werden im Paket entsprechende Tools installiert, die das dann voll automatisch machen.

Es gibt ja einige Adapter, die in Typescript erstellt worden sind. Da kannst du mal schauen.

[uwe72]

@oliverio Über NPM Publizierung und per JS habe ich es mal hinbekommen:
https://forum.iobroker.net/topic/70069/einfügen-von-js-klassen-aus-eigenem-npm-modul/13

Werde es aber noch versuchen ohne Publizierung und mit TS. Ja ich weiß, dass zur Laufzeit nur JS verwendet wird. Ich weiß auch, dass Du es so meintest, dass man die Module lokal ablegt, ohne Publizierung.

[uwe72]

@oliverio Mittlerweile funktioniert es ohne über NPM zu publizieren und auch mit TypeScript.

Ein externes .ts (liegt in einem Verzeichnis innerhalb iobroker) wird zu .js "kompiliert" (fehlt gerade der Fachbegriff) und im iobroker-TS-Script über require eingebunden.

Was noch nicht funktioniert ist, wenn im externen Script "Dinge" wir sendTo() verwendet werden. Dieses wird dann in iobroker angemeckert, da unbekannt.

Hast Du dazu noch eine Idee?

Gerne im Thread, ganz unten:
https://forum.iobroker.net/topic/70069/einfügen-von-js-klassen-aus-eigenem-npm-modul/47

[OliverIO]

@uwe72 sagte in (ERLEDIGT!) TypeScript, viele common/global Scripte --> CPU:

sendTo

ja das externe script hat ersteinmal keinen bezug zum aktuellen context in dem die funktionen verfügbar sind.

wenn du testweise in einem separaten script von iobroker das folgende ausführst,
dann siehst du alles was im script context verfügbar ist.
wenn du an dein externes script this mit übergibst, dann kannst du dann unter der empfangenden variable dort, alle befehle erreichen.

console.log(Object.keys(this).join(",\n"));

Beipsiel

iobroker script

const xx=require("externesSkript");
xx.externeFunktion(this)

externes Skript

export Function externeFunktion(iob) {
  iob.log("Logausgabe im iobroker log");
}

Hab das jetzt nicht direkt getestet, aber so müsste es grob laufen.

Wenn du im externen script mit vscode arbeitest, dann erwarte da ersteinmal keine syntax überprüfung, da müsste man sciherlich noch eine type definition hinzufügen. aber da weiß ich auch nix

[uwe72]

@oliverio Danke dir! Werde ich mir anschauen. VG

[ticaki]

@oliverio
Danke geht:

const { Person } = require('/home/iobroker/library/lib.js');
const joe = new Person("Joe", "Müller", 31, this);
log(joe.information());
joe.log();

lib.ts

class Person {
    private nachname: string;
    private vorname: string;
    private alter: string;
    private adapter: any;
    constructor(vorname, nachname, alter, adapter) {
      this.vorname = vorname;
      this.nachname = nachname;
      this.alter = alter;
      this.adapter = adapter;
    }
  
    information(): string {
      return (`Mein Name ist ${this.vorname} ${this.nachname} und ich bin ${this.alter} Jahre alt!!!!1`);
    }
    log(): void {
        this.adapter.log(this.information());
    }
  }
 
module.exports = { Person};

muss nur noch raus bekommen welchen Type adapter haben sollte.

[OliverIO]

@ticaki sagte in (ERLEDIGT!) TypeScript, viele common/global Scripte --> CPU:

this.adapter.log(this.information());

hm, geht wahrscheinlich nix kauptt, aber ich würde dann lieber this.log nehmen.
this.adapter.log ist die funktion des javascript adapters.
damit umgehst du wahrscheinlich eigene log verarbeitung des javascript-adapters.
ich würde alles was bei this.adapter verfügbar ist in ruhe lassen und nicht verwenden.

wäre glaube ich ein hinsweis darauf, das die sandbox des javascript-adapters ein loch hat

lustig ist das adapter in der auflistung, des kleinen testscripts nicht mit aufgeführt wird

[ticaki]

@oliverio
Lese den Code nochmal this ist Person this.adapter ist this im javascript adapter :)

Heißt

---lib ------------------ Javascript Adapter
this.adapter.log('bla') == this.log('bla')

Hab das extra in adapter umbenannt, weils auch so im adapter gemacht wird (zumindest von mir)