NEWS
JavaScript 8.3.0 - Log-Trigger, File-Events und Warnungen
-
@ofbeqnpolkkl6mby5e13 sagte: nach der Umstellung auf httpGet, entfernen wollen.
Kein Problem. Es war dort noch nie nötig.
Okay.
-
So kannst du auch sehen, wo das noch überall drin hängt:
echad@chet:/opt/iobroker $ npm ls request iobroker.inst@3.0.0 /opt/iobroker ├─┬ iobroker.backitup@3.0.0 │ └─┬ dropbox-v2-api@2.5.11 │ └── request@2.88.2 deduped ├─┬ iobroker.javascript@8.4.2 │ └── request@2.88.2 ├─┬ iobroker.mihome-vacuum@4.2.0 │ └── request@2.88.2 deduped ├─┬ iobroker.nina@0.0.26 │ └── request@2.88.2 deduped ├─┬ iobroker.nuki-extended@2.7.0 │ ├─┬ nuki-web-api@2.2.1 │ │ └── request@2.88.2 deduped │ ├─┬ request-promise@4.2.6 │ │ ├─┬ request-promise-core@1.1.4 │ │ │ └── request@2.88.2 deduped │ │ └── request@2.88.2 deduped │ └── request@2.88.2 deduped ├─┬ iobroker.samsung@0.6.0 │ └─┬ samsungtv@0.0.0 (git+https://git@github.com/luca-saggese/samsungtv.git#7fc20107455414e2afb94022682e0787e8635550) │ └── request@2.88.2 deduped ├─┬ iobroker.tr-064@4.3.0 │ └─┬ tr-O64@0.2.4 │ └── request@2.88.2 deduped └─┬ iobroker.whatsapp-cmb@0.3.0 └── request@2.88.2 deduped -
So kannst du auch sehen, wo das noch überall drin hängt:
echad@chet:/opt/iobroker $ npm ls request iobroker.inst@3.0.0 /opt/iobroker ├─┬ iobroker.backitup@3.0.0 │ └─┬ dropbox-v2-api@2.5.11 │ └── request@2.88.2 deduped ├─┬ iobroker.javascript@8.4.2 │ └── request@2.88.2 ├─┬ iobroker.mihome-vacuum@4.2.0 │ └── request@2.88.2 deduped ├─┬ iobroker.nina@0.0.26 │ └── request@2.88.2 deduped ├─┬ iobroker.nuki-extended@2.7.0 │ ├─┬ nuki-web-api@2.2.1 │ │ └── request@2.88.2 deduped │ ├─┬ request-promise@4.2.6 │ │ ├─┬ request-promise-core@1.1.4 │ │ │ └── request@2.88.2 deduped │ │ └── request@2.88.2 deduped │ └── request@2.88.2 deduped ├─┬ iobroker.samsung@0.6.0 │ └─┬ samsungtv@0.0.0 (git+https://git@github.com/luca-saggese/samsungtv.git#7fc20107455414e2afb94022682e0787e8635550) │ └── request@2.88.2 deduped ├─┬ iobroker.tr-064@4.3.0 │ └─┬ tr-O64@0.2.4 │ └── request@2.88.2 deduped └─┬ iobroker.whatsapp-cmb@0.3.0 └── request@2.88.2 dedupedSelbst z. B. Backitup 3.0 nutzt das noch...
-
Selbst z. B. Backitup 3.0 nutzt das noch...
@ofbeqnpolkkl6mby5e13 sagte in JavaScript 8.3.0 - Log-Trigger, File-Events und Warnungen:
Selbst z. B. Backitup 3.0 nutzt das noch...
Jein. Nicht direkt, dropbox-v2-api nutzt das noch.
-
@ofbeqnpolkkl6mby5e13 sagte in JavaScript 8.3.0 - Log-Trigger, File-Events und Warnungen:
Selbst z. B. Backitup 3.0 nutzt das noch...
Jein. Nicht direkt, dropbox-v2-api nutzt das noch.
Ah, okay.
-
@haus-automatisierung sagte in JavaScript 8.3.0 - Log-Trigger, File-Events und Warnungen:
Request-Paket is deprecated
Request wird seit Jahren im Adapter genutzt und der Blockly-Baustein "request" nutzt ja genau dieses Paket. Der Block wurde ja bereits in den vorigen Versionen durch "http (GET)" ersetzt. Solltest Du noch die älteren Blöcke nutzen, bekommst Du eine Warnung im Log.
Ich möchte das Paket jetzt langsam aber sicher loswerden. Daher generiert jedes
require('request');im Log jetzt auch eine Warnung. Scheinbar werden die Changelogs ja nicht gelesen, weswegen man am Ende wohl in überraschte Gesichter schauen wird, warum ein Script nicht mehr läuft. Also: Migriert eure Scripts! Und wenn ihr hier im Forum jemanden seht, der Code mitrequire('request');teilt: Bitte entsprechend darauf hinweisen.In der Zukunft wird das Paket dann endlich aus dem Standard entfernt und nicht mehr mitinstalliert. Man kann es zwar in den Instanzeinstellungen dann manuell noch hinzufügen, aber das ist nicht zu empfehlen. request ist seit über 4 Jahren deprecated und wird nicht mehr weiter entwickelt! Einfach nicht mehr nutzen...
javascript.0 2024-05-28 20:29:38.763 error npm warn deprecated request@2.88.2: request has been deprecated...Kann ich das NPM-Modul request, wenn ich alle meine Skripte auf httpGet umgestellt habe, aus der Javascript-Instanz löschen, oder wird das zurzeit intern noch verwendet?
@ofbeqnpolkkl6mby5e13 sagte in JavaScript 8.3.0 - Log-Trigger, File-Events und Warnungen:
Kann ich das NPM-Modul request, wenn ich alle meine Skripte auf httpGet umgestellt habe, aus der Javascript-Instanz löschen
Bitte nie manuell an den npm dependencies von Adaptern rumspielen. Du kannst deine eigenen Pakete dazu installieren per Instanz-Einstellungen. Aber damit kann request nicht entfernt werden.
-
@ofbeqnpolkkl6mby5e13 sagte in JavaScript 8.3.0 - Log-Trigger, File-Events und Warnungen:
Kann ich das NPM-Modul request, wenn ich alle meine Skripte auf httpGet umgestellt habe, aus der Javascript-Instanz löschen
Bitte nie manuell an den npm dependencies von Adaptern rumspielen. Du kannst deine eigenen Pakete dazu installieren per Instanz-Einstellungen. Aber damit kann request nicht entfernt werden.
@haus-automatisierung sagte in JavaScript 8.3.0 - Log-Trigger, File-Events und Warnungen:
...per Instanz-Einstellungen...
Um nichts Anderes ging es.
-
@haus-automatisierung sagte in JavaScript 8.3.0 - Log-Trigger, File-Events und Warnungen:
...per Instanz-Einstellungen...
Um nichts Anderes ging es.
@ofbeqnpolkkl6mby5e13 Ich betone das nur nochmal explizit, weil ich hier schon die verrücktesten Dinge gesehen habe...
-
@ofbeqnpolkkl6mby5e13 Ich betone das nur nochmal explizit, weil ich hier schon die verrücktesten Dinge gesehen habe...
Sowas wäre für Skripte, die viele httpGet oder httpPost Blöcke haben, noch nett:

-
Sowas wäre für Skripte, die viele httpGet oder httpPost Blöcke haben, noch nett:

@ofbeqnpolkkl6mby5e13 Wozu? Das sind doch statische Werte.
-
@ofbeqnpolkkl6mby5e13 Wozu? Das sind doch statische Werte.
@haus-automatisierung
keine Ahnung wann dieser Trigger dazukam.
Ich find den ziemlich genial, jedoch wäre er noch geiler wenn man auch ein Datum setzen könnte.
(für Events die in z.B. einer Woche starten sollen)

-
@haus-automatisierung
keine Ahnung wann dieser Trigger dazukam.
Ich find den ziemlich genial, jedoch wäre er noch geiler wenn man auch ein Datum setzen könnte.
(für Events die in z.B. einer Woche starten sollen)

@stenmic Der ist ja eigentlich für wiederkehrende Ereignisse gedacht. Mit einem Datum wäre es ja einmalig.
-
@stenmic Der ist ja eigentlich für wiederkehrende Ereignisse gedacht. Mit einem Datum wäre es ja einmalig.
@haus-automatisierung
schon verstanden, aber eventuell geht ja beides.Frage… wenn der Datenpunkt leer ist, ist die Funktion deaktiviert?
-
@haus-automatisierung said in JavaScript 8.3.0 - Log-Trigger, File-Events und Warnungen:
@biker1602 sagte in JavaScript 8.3.0 - Log-Trigger, File-Events und Warnungen:
da muss bestimmt bei Antwort Datentyp was rein aber ich habe keinen Plan was
- Warum? Du arbeitest mit dem Response/der Antwort vom Server eh nicht weiter
- Sieht alles richtig aus. Ggf. den Timeout je Block erhöhen. Scheinbar antwortet der HTTP-Server nicht rechtzeitig.
Also ich habe es jetzt schon mit verschiedenen Zeiten versucht alles ohne Erfolg. Die Aktion wird ja ausgeführt aber halt immer mit dem Fehler.

Ich habe schon auf Version v8.5.2 ein update gemacht aber es ändert sich nichts.
-
@haus-automatisierung said in JavaScript 8.3.0 - Log-Trigger, File-Events und Warnungen:
@biker1602 sagte in JavaScript 8.3.0 - Log-Trigger, File-Events und Warnungen:
da muss bestimmt bei Antwort Datentyp was rein aber ich habe keinen Plan was
- Warum? Du arbeitest mit dem Response/der Antwort vom Server eh nicht weiter
- Sieht alles richtig aus. Ggf. den Timeout je Block erhöhen. Scheinbar antwortet der HTTP-Server nicht rechtzeitig.
Also ich habe es jetzt schon mit verschiedenen Zeiten versucht alles ohne Erfolg. Die Aktion wird ja ausgeführt aber halt immer mit dem Fehler.

Ich habe schon auf Version v8.5.2 ein update gemacht aber es ändert sich nichts.
@biker1602 said in JavaScript 8.3.0 - Log-Trigger, File-Events und Warnungen:
@haus-automatisierung said in JavaScript 8.3.0 - Log-Trigger, File-Events und Warnungen:
@biker1602 sagte in JavaScript 8.3.0 - Log-Trigger, File-Events und Warnungen:
da muss bestimmt bei Antwort Datentyp was rein aber ich habe keinen Plan was
- Warum? Du arbeitest mit dem Response/der Antwort vom Server eh nicht weiter
- Sieht alles richtig aus. Ggf. den Timeout je Block erhöhen. Scheinbar antwortet der HTTP-Server nicht rechtzeitig.
Also ich habe es jetzt schon mit verschiedenen Zeiten versucht alles ohne Erfolg. Die Aktion wird ja ausgeführt aber halt immer mit dem Fehler.

Ich glaube jetzt klappt es auch mit dem neuen Baustein denn ich habe mal die Adresse im Browser eingegeben und gewartet bist sie antwortet. das hat fast 2 sek gedauert. Ich habe die Zeit jetzt auf 3 Sek gestellt und jetzt sind die Fehlermeldungen weg.
-
Aktuelle Test Version 8.3.0 Veröffentlichungsdatum 09.05.2024 Github Link https://github.com/ioBroker/ioBroker.javascript/releases/tag/v8.3.0 Auch in dieser Version gibt es wieder viele neue Blöcke, Bugfixes und Features. Das wichtigste zuerst:
Besten Dank an alle Teilnehmer des ioBroker-Master-Kurses. Ihr habt die vielen Stunden Entwicklung und Support (wie immer) finanziert. Natürlich werden die neuen Bausteine und Feature auch im Kurs ausführlich gezeigt und erklärt.
Blockly-Trigger für Logs
Das Thema ist in JavaScript nicht neu. Es gab nur keine Blockly-Bausteine dafür. Also habe ich diese nun nachgereicht.
Damit kann man einen Trigger auf Log-Meldungen registrieren und ein Log-Level vorgeben. Das heißt, dass man z.B. alle Meldungen vom Level
errorbekommen kann und dann z.B. prüfen, welche Instanz (Quelle) die Meldung ausgelöst hat.
Blockly File-Events (Temporärer Dateipfad)
Das Datei-Thema kommt ja hier immer wieder auf - und viele schreiben und lesen direkt aus
/opt/iobroker/iobroker-data/files/. Das man das nicht tun sollte und dafür IMMER die ioBroker-Funktionen nutzen sollte, habe ich ja mittlerweile rauf und runter erklärt.Wenn man als Datenbank nicht
jsonlsondernredisnutzt, dann liegen die Dateien ja nichtmal an dieser Stelle im Dateisystem, sondern in der Redis-Datenbank. Das Problem ist nun: Wenn sich eine Datei ändert, dann kann man damit in Blockly noch nicht viel machen. Bausteine wie Pushover, Mail, Telegram usw. wollen einen Pfad zu einer Datei haben. Das Thema habe ich auf GitHub auch schon platziert.Nun gibt es aber bei einer Redis-Datenbank keinen Pfad im Dateisystem. Also habe ich eine neue Funktion gebaut, welche die Datei aus dem "ioBroker-Speicher" in das Temp-Verzeichnis des Betriebssystems (unter Linux
/tmp) speichert und einen Pfad zurückgibt.Sobald das Script gestoppt wird, wird in diesem Pfad wieder aufgeräumt und die temporären Dateien werden gelöscht!
Jedenfalls kann man auf diesem Weg aktuell weiterhin Bausteine wie Telegram bedienen und jedes Mal wenn sich eine Datei ändert diesen Pfad generieren und an andere Bausteine weiterreichen. Beispiel:

Warnungen
Eigentlich gibt es jetzt an jeder Stelle ein Ausrufezeichen im Block, wenn man etwas zusammenbaut, was so nicht gedacht ist (z.B. Trigger in Trigger). So sollte man eigentlich direkt während der "Programmierung" merken, dass da etwas falsch ist.
Solltet ihr noch Vorschläge für Validierungen haben (wo darf ein Block nicht in einem anderen enthalten sein): Her damit.

Request-Paket is deprecated
Request wird seit Jahren im Adapter genutzt und der Blockly-Baustein "request" nutzt ja genau dieses Paket. Der Block wurde ja bereits in den vorigen Versionen durch "http (GET)" ersetzt. Solltest Du noch die älteren Blöcke nutzen, bekommst Du eine Warnung im Log.
Ich möchte das Paket jetzt langsam aber sicher loswerden. Daher generiert jedes
require('request');im Log jetzt auch eine Warnung. Scheinbar werden die Changelogs ja nicht gelesen, weswegen man am Ende wohl in überraschte Gesichter schauen wird, warum ein Script nicht mehr läuft. Also: Migriert eure Scripts! Und wenn ihr hier im Forum jemanden seht, der Code mitrequire('request');teilt: Bitte entsprechend darauf hinweisen.In der Zukunft wird das Paket dann endlich aus dem Standard entfernt und nicht mehr mitinstalliert. Man kann es zwar in den Instanzeinstellungen dann manuell noch hinzufügen, aber das ist nicht zu empfehlen. request ist seit über 4 Jahren deprecated und wird nicht mehr weiter entwickelt! Einfach nicht mehr nutzen...
System-Variablen
Seit Version v8.0.0 gibt es unter "System" außerdem noch ein neuen Baustein. Über diese kann der Name des Scripts, der Standard-Verzeichnispfad oder der Status des Verbose-Modus des Scripts ausgegeben werden.

Damit könnte man z.B. verbose-Nachrichten schreiben oder Log-Meldungen ändern, wenn der verbose-Modus aktiv ist (hab ich im ioBroker-Master-Kurs auch erklärt, ...):


Vorbereitung auf js-controller 6.x
Das Abhängigkeitsmanagement (für zusätzliche Pakte in den Instanzeinstellungen) bringt in der aktuellen npm-Version ein paar Probleme mit sich. Diese werden im js-controller 6.x adressiert und es gibt auch schon die erste Implementierung der neuen Funktionen. Mehr dazu, sobald der js-controller 6 in einer beta verfügbar ist.
Oberfläche
Die Darstellung des Logs hat sich nun auch leicht geändert und wurde an den Admin angepasst. Die erste Spalte (Quelle) ist neu. Dafür wird in der Meldung selbst die Instanz nicht mehr angezeigt (wie im Admin halt).

Ansonsten habe ich aus den pixeligen Grafiken zum Umschalten von Blockly/JS und Rules/JS mal Vektorgrafiken gemacht die auch skalieren. Auf Retina-Displays sah das vorher ja schlimm aus


Hallo,
folgender Fehler kommt bei mir und JS (8.5.2) stürzt ab:


Plattform: Windows
RAM: 15.9 GB
Node.js: v20.14.0
NPM: 10.7.0
Admin: 6.17.14
JSC: 6.0.4EDIT:
Funktioniert wieder mit v8.6.0
-
Hallo,
folgender Fehler kommt bei mir und JS (8.5.2) stürzt ab:


Plattform: Windows
RAM: 15.9 GB
Node.js: v20.14.0
NPM: 10.7.0
Admin: 6.17.14
JSC: 6.0.4EDIT:
Funktioniert wieder mit v8.6.0
@sigi234 Ist schon auf GitHub erfasst, liegt an einem Core-Paket und ich warte gerade auf einen Fix
-
@sigi234 Ist schon auf GitHub erfasst, liegt an einem Core-Paket und ich warte gerade auf einen Fix
@haus-automatisierung sagte in JavaScript 8.3.0 - Log-Trigger, File-Events und Warnungen:
@sigi234 Ist schon auf GitHub erfasst, liegt an einem Core-Paket und ich warte gerade auf einen Fix
Funktioniert wieder mit v8.6.0
Danke