@uwe72

Ok, ich antworte mir mal selber

Umstellung auf Datenpunkt "on"

in Verbindung mit dieser Apdaptereinstellung scheint gut zu funktionieren: (Haken an)

Summary:
Beispiel wie man ein Global-Script ins Filesystem auslagert und dann in den Common-Scripten darauf zugreift. Eben nur in den Scripten wo man die Inhalte aus Global auch wirklich benötigt. Ein Beispiel für JavaScript und ein Beispiel für TypeScript.

Zielsetzung:
Da ich wieder an die Grenzen gekommen bin was RAM/CPU angeht, habe ich das Thema nochmals aufgegriffen, die Global-Scripte in externe Module auszulagern. Ich möchte in diesem Post eine (für mich) funktionierende Lösung vorstellen. Ich war früher Java Entwickler, dies ist allerdings bereits 15 Jahre her. JavaScript/TypeScript habe ich nie gelernt, also habe ich nicht den Anspruch professionellen Code zu schreiben. Es existieren viele Posts dazu, wollte aber (auch für mich) zusammenschreiben wie es funktionieren kann, insbesondere wenn ich in 2 Jahren nochmals wissen möchte wie es ging

Hintergrund:
Das Konzept mit den global/common Scripte ist ja leicht fragwürdig, da der Inhalt jedes global-Script in jedes common-Script an den Anfang kopiert wird, obwohl der Inhalt eines global-Scriptes nicht in jedem common-Script benötigt wird. Es wird auch im Forum an diversen Stellen abgeraten überhaupt global-Scripte zu verwenden (vermutlich wegen RAM,CPU, Performance,...). Aber warum verwende ich überhaupt global-Scripte? Da ich eben "ein Stück Softwarecode" nur einmal schreiben möchte und es an vielen Stellen verwenden möchte. Das geht eben nicht ohne die Verwendung von global-Scripte. Ich mag keinerlei Duplizierung von Code.

D.h. ich kann es nicht über global-Script machen, da dieser Code in jedes Script reinkopiert wird, d.h. wenn ich in 3 von 100 common-Scripten was aus global brauche, dann ist es in 97 Scripten unnötigerweise drin. Wenn dies hunderte Zeilen von Code sind ist dies einfach unnötig. Insbesondere wenn es bei TS noch "kompiliert" werden muss.

Weiterer Schwachpunkt: Wenn wenigstens die global-Scripte nur in die common-Scripte reinkopiert werden würden aus der gleichen JavaScript-Instanz wäre auch schon was geholfen. Aber dies geht auch nicht. Die Instanz wird beim Kopieren nicht berücksichtigt

Anforderung:
Mir geht es also einfach darum, dass ich keinen Code doppelt schreiben möchte. In jedem common-Script möchte ich (ausgelagerte) Code-Stellen referenzieren.

Lösungsbeispiel per JavaScript

Externe Datei:
/opt/iobroker/my_scripts/haus.js

function getNumberRooms() : number {
  return 347;
}

module.exports = { getNumberRooms };

ioBroker common-Script:

const { getNumberRooms  } = require('/opt/iobroker/my_scripts/haus.js');
        
log("Anzahl der Räume sind: " + getNumberRooms());

Logausgabe:

javascript.2	20:43:23.456	info	script.js.common._ModuleTest.Haus: Anzahl der Räume sind: 347

Lösungsbeispiel per TypeScript

Externe Datei:
/opt/iobroker/my_scripts/kalender.ts

class Kalender  {
    private adapter: any;
    private myState: string;

    constructor(adapter, myState) {
       this.adapter = adapter;
       this.myState = myState;
    }

    public getCurrentWeekdayAsInteger() : number {
        var now = new Date();
        return now.getDay();
    }

    public updateState() {
        this.adapter.log("Update state within external file");
	   this.adapter.setState(this.myState, this.getCurrentWeekdayAsInteger());
    }

    public sendTelegram() {
        this.adapter.log("Send telegram within external file");        
        this.adapter.sendTo("telegram.0", "Weekday is: " + this.getCurrentWeekdayAsInteger());
    }
}

module.exports = { Kalender};

Transpilieren von TypeScript nach JavaScript
kalender.ts muss zu kalender.js transpiliert werden. Unter Docker muss man im Container drin sein, d.h. z.B. docker exec -it iobroker bash

npx tsc kalender.ts

--> Es entsteht die Datei kalender.js im gleichen Verzeichnis.

ioBroker common-Script:

const { Kalender } = require('/opt/iobroker/my_scripts/kalender.js');
        
var myStateState = "0_userdata.0.html.test_module";
createState(myStateState, -1, {
    name: myStateState,
    desc: myStateState,
    type: 'number', 
    read: true,
    write: true
});
setState(myStateState, -1);


const myCalender = new Kalender(this, myStateState);
log("Heute ist: " + myCalender.getCurrentWeekdayAsInteger());

myCalender.sendTelegram();

log("Wochentag is: " + getState(myStateState).val);
myCalender.updateState();
log("Wochentag is: " + getState(myStateState).val);

Logausgabe:

javascript.2	20:53:14.743	info	script.js.common._ModuleTest.Intern: Heute ist: 5
javascript.2	20:53:14.743	info	script.js.common._ModuleTest.Intern: Send telegram within external file
javascript.2	20:53:14.746	info	script.js.common._ModuleTest.Intern: Wochentag is: -1
javascript.2	20:53:14.746	info	script.js.common._ModuleTest.Intern: Update state within external file
javascript.2	20:53:14.747	info	script.js.common._ModuleTest.Intern: Wochentag is: 5

Zudem wird die Telegram Nachricht versendet:

@Zefau ich traue mich zwar schon gar nichts mehr zu sagen aber nur weil ich es gerade wieder sehe. Bin der Meinung, dass die Reihenfolge (links/rechts) der Gruppen-Buttons vertauscht sein müsste. Analog den Einzelschaltern, sollte rechts der "AN" Button sein und links der "AUS" Button. Kleinigkeit!

Update:
Habe gerade auf Jarvis 2.1 upgedatet. Es ist nun nicht mehr möglich diese Art der Gruppenschalter (aus dem Screenshot) zu verwenden? Fand diese zuvor extrem schön.

@mcu wirklich ganz großes DANKESCHÖN!!!

Funktioniert perfekt.

@uwe72 said in jarvis v3.0.0 - just another remarkable vis:

@mcu

Meine Jarvis-Visualisierungen lassen sich ohne Probleme über den Browser anzeigen.

Über das Handy bekomme ich keinen Zugriff:

ioBroker läuft im docker.

Hat jemand eine Idee?

So weit komme ich noch:

@MCU

Mensch, ich müsste viel mehr deine hervorragende Doku lesen!!!!
https://mcuiobroker.gitbook.io/jarvis-infos/jarvis/besonderheiten-v3/allgemein/verbindungsaufbau

Funktioniert nun!

@apollon77 Funktioniert. Hatte wohl nicht lange genug gewartet gehabt. DANKE!!

@dslraser jetzt hat es geklappt, habe Zugriff auf iobroker über den Browser.

Habe nun als subnet die IP meines NUCs (wo docker läuft) eingegeben.

DANKE!

version: '2.1'

services:
  iobroker:
    restart: always
    image: buanet/iobroker:latest
    container_name: iobroker
    hostname: iobroker
    ports:
      - "8081:8081"
    volumes:
      - ./my-datas/iobroker/iobrokerdata:/opt/iobroker
    networks:
      public:
        ipv4_address: 192.168.178.210

networks:
  public:
    driver: macvlan
    driver_opts:
      parent: eno1
    ipam:
      config:
        - subnet: 192.168.178.109/24

OK, habe eine Lösung gefunden: Filename muss natürlich noch besser gemacht werden.

    exec("c:/clement/ffmpeg -y -i rtsp://admin:todo@192.168.888.999:554/12 -t 5 -f mp4 -vcodec libx264 -pix_fmt yuv420p -an -vf scale=w=640:h=360:force_original_aspect_ratio=decrease -r 15 c:/clement/uwe_out5.mp4");
    setTimeout(function() {
        sendTo('telegram.0', 'c:/clement/uwe_out5.mp4');
    }, 12000);

Basis der Lösung habe ich hier gefunden:
https://forum.iobroker.net/topic/9508/frage-blockly-klingel-bild-per-telegram-versenden-snapshot-von-cam-per-telegram-versenden/51

Erst einmal Danke an @Zefau für die wirklich exzellente Arbeit mit diesem Adapter. Die Visualisierung ist prinzipiell komplett ohne große Kenntnisse zu erstellen, bietet aber insbesondere durch das CustomHTMLWidget viele Möglichkeiten, individuelle Visualisierungen zu erstellen.

Das einzige was mich stört ist, dass die Topbar, d.h. die Menüleiste in vertikaler Richtung so viel Platz in Anspruch nimmt. Eigentlich besteht doch bei den meisten Visualisierungen Platzmangel. Ich brauche den Platz um noch mehr auf die "erste Seite" zu packen, siehe Screenshot.

Weiß nicht, ob die Community, d.h. die Anwender dies nicht noch öfters stört? Falls doch, würde ich mir wünschen, dass ihr für den dafür vorgesehenen FeatureRequest "votet", d.h. unterstützt:
https://github.com/Zefau/ioBroker.jarvis/issues/124

Danke Euch!

Zefau created this issue in Zefau/ioBroker.jarvis

closed add option to hide TopBar #124

@dslraser @fastfoot Danke Euch!

ioBroker funktioniert nun auf alle Fälle. Richtig klasse, nun auch wieder mit Shelly/Coap und Alexa2 Adapter.

Freue mich riesig

@denjo hat auch anhieb geklappt. Perfekt, danke dir!

@denjo noch besserer Tipp. Danke dir!!

NFC/Fingerprint: Ich würde mir wünschen, dass ich in ioBroker mitbekomme, wenn der "Fingerprint-Sensor" einen registrierten "User" (Finger) erkannt hat. Müsste nicht mal wissen, "welcher Finger", nur eben einer der angelernten. Dann könnte ich über ioBroker die Tür öffnen. Der Tür öffnet ist bei mir über Homematic realisiert bzw. kann über ein HM-Relais die Tür öffnen.

@jackdaniel Danke dir für den Tipp.

Protect-Integration ist mir auch sehr wichtig. Nutze bis jetzt den Umweg für HomeAssistant und den ioBroker HASS-Adapter. In HomeAssistant wird das Fingerprint Doorbell 4 Pro Feature nicht unterstützt bis jetzt. Und würde dies so gerne nutzen!

Ich schau mir das mal mit der Homebridge an! Kannte das System gar nicht. Vielen lieben Dank!

@mcm1957 Danke dir!

Ich habe 10-15 Jahre professionell in Java entwickelt. Seit über 10 Jahre allerdings nicht mehr. JavaScript/TypeScipt habe ich nie gelernt, komme aber einigermaßen für meine Anwendungszwecke klar.

"Machs doch selber, statt zu meckern" - ist natürlich immer ein Totschlagargument

Ich traue mir nicht zu den Protect-Adapter aktuell zu fixen, traue mir - mit anfänglicher Unterstützung - aber zu einen kleinen Adapter selber zu schreiben und damit zu beginnen. Ich wäre auch dazu bereit. Wer weiß was sich daraus dann ergeben kann. Gibt es irgendwo ein Liste von Adapterwünschen? Ggf. wäre da was dabei womit ich starten könnte?

Ich möchte auf niemanden rumhacken, schon gar noch auf Matthias Kleine. Ich weiß wie extrem gut, engagiert und zuverlässig er ist! Ein Bekannter von mir hat auch enorme Probleme mit diesem Thema:
https://github.com/iobroker-community-adapters/ioBroker.shelly/issues/931

Ticket für JS-Thema habe ich angelegt:
https://github.com/ioBroker/ioBroker.javascript/issues/1779

dike1982 created this issue in iobroker-community-adapters/ioBroker.shelly

open [Bug]: [MQTT] Unable to get mqttprefix of client with id "shellyplus2pm-e #931

uwe72 created this issue in ioBroker/ioBroker.javascript

open Refactoring common/global Scripte #1779

@apollon77

ich überspitze mal: "es ist halt open source" da kann man nichts machen.

Ob "matter" sinnvoll ist oder nicht kann ich nicht beurteilen. Hilft iobroker aber auch nichts wenn dann noch mehr zu HA abgewandert sind.

Mag sein, dass protect nun nicht der Mainstream-Adapter ist, aber wie sieht es mit Shelly aus? Habe ich zwar selber auch nicht (aber ein Bekannter). Da gibt es Fehlermeldungen/Bugs, welche Januar 2024 gemeldet wurden und sich bis heute nichts geändert hat.

Wenn man diese Dinge anspricht, dann ist es in meinen Augen konstruktiv. Konstruktiv angesprochen hatte ich auch vor ein paar Monaten beispielsweise, dass die Architektur des JS-Adapters verbesserungswürdig ist. Kann nicht sein, dass alle global-Scripte in die common-scripte reinkopiert werden (ob man den Code dort benötigt oder auch nicht) und zudem beim reinkopieren nicht mal die JS-Instanz berücksichtigt wird. Da wurde dann rumgeritten warum ich überhaupt so viel in "global" habe. (Vermutlich gibt es wenige die mehr den JS-Adapter nutzen als ich). Diese Antwort ist gleichermaßen nicht konstruktiv. Man bräuchte dort auch den gleichen require/import-Mechanismus, wie ich es mir erarbeitet habe (https://forum.iobroker.net/topic/78632/info-auslagerung-von-global-scripten-ins-filesystem/1). Aber halt idealerweise nicht nach ganz extern (Filesystem), sondern innerhalb des JS-Adapters.

Es kommt alles immer ein wenig "von oben herab", keinerlei kritisches scheint erwünscht zu sein. Auch wenn es kein "MAN" gibt, muss es doch was geben, dass ein wenig mehr als "ALLE" ist, denn irgendjemand muss doch auch festlegen, welche Adapter nun "offiziell" sind und welche nicht?

Denke was ich kundtun wollte habe ich nun gemacht. Gerne noch ein "böser" Post zurück, den halte ich aus Schöne Weihnachten!

@thomas-braun ok, vergiss meine Kommentare

Mache mir halt einfach nur Sorgen. Und da bin ich glaub nicht alleine

@thomas-braun gutes Stichwort produktmanagement. Bin zu weit weg. Aber man müsste da hinkommen, dass die "Hauptadapter", wie unify, protect, shelly, alexa, homematic, hue,... einfach funktionieren, wenn es sein muss auch gegen Bezahlung. Ich liebe iobroker, schätze insbesondere auch die Möglichkeit der Nutzung von JavaScript. Mache mir halt einfach sorgen, dass es noch weiter abwärts geht. Verstehe einfach auch viele Adapter Entwickler nicht. Wenn iich so ein Projekt beginne, hunderte user meinen Adapter nutzen, dann lasse ich diese doch nicht im stich?! Vielleicht bin ich zu alt um dies zu verstehen

@mcm1957 gibt so viel Adapter die nicht mehr gepflegt werden. So kann man ein tolles Produkt wie den iobroker auch kaputt machen. Du investiert man in ein matter Integration, statt zu schauen, dass die vorhandenen Adapter gewartet sind und nützliche neue dazu kommen. Komplett unverständlich für mich diese Strategie

@meikel

Mich würde grundsätzlich interessiert was der Status dieses Adapters ist? Gibt es noch einen Entwickler der sich dafür zuständig fühlt? Mein Eindruck wäre es, dass der Adapter tot ist. Deswegen verwende ich ihn auch nicht mehr.

Habe für mich mal eine funktionierende Lösung in einem neuen Post aufgeschrieben:
https://forum.iobroker.net/topic/78632/info-auslagerung-von-scripte-aus-global-aufs-filesystem