Adapterzustand, welcher Datenpunkt?

Roelli

@mcm1957 sagte in Adapterzustand, welcher Datenpunkt?:

Ev erklär das mal genauer.

Wenn ich ein Blockly mache mit einem 1-Minuten-cronjob als Trigger und damit dann z.B. per Alexa Sprachausgabe etwas sagen lasse und dann das Skript stoppe, dann stoppt es nicht. Es läuft unendlich weiter.
Und scheinbar läuft es teilweise auch mehrmals parallel. Habe gerade das hier gefunden wo jemand das gleiche Problem beschreibt:
https://github.com/ioBroker/ioBroker.javascript/issues/1756

Ich habe nun ein altes VM Backup mit 10GB wieder aktiviert. Da geht noch alles. Ich weis allerdings nicht genau was das Problem ausgelöst hatte. Ich glaube es hat mit dem update des JS-Controllers angefangen. Ich hatte 7.0.3 und hab dann auf 7.0.6 ge-updated und dann auch den admin adapter geupdated. Danach... Probleme.

Roelli

Und... seit ein paar Monaten ist es bei mir so, dass bei einem iobroker neustart der javascript-adapter niemals automatisch auf grün geht.
Man muss ihn immer zuerst neustartet oder stoppt und starten.

mcm1957

@roelli said in Adapterzustand, welcher Datenpunkt?:

Wenn ich ein Blockly mache mit einem 1-Minuten-cronjob als Trigger und damit dann z.B. per Alexa Sprachausgabe etwas sagen lasse und dann das Skript stoppe, dann stoppt es nicht. Es läuft unendlich weiter.

Nun wenn du ein Blockly alle Minnuten starten lässt dann musst du natürlich sicherstellen, dass das Blockly nie länger als eine Minute laufen kann.

Wie stoppst du das Blockly?

Roelli

@mcm1957 sagte in Adapterzustand, welcher Datenpunkt?:

Wie stoppst du das Blockly?

Ich drücke einfach bei den Blockly-Skripten auf "Pause".

ticaki

@roelli

Backupit machen und neu aufsetzen. Ich kann keinen der genannten Fehler nachvollziehen, hab aber keine 200 Skripte - dafür aber locker 60000 Zeilen an Skriptcode in den vorhandenen.

schedule hab ich gerade noch ausversucht, die werden beendet, aber sicherlich gibt es eine Konstellation in denen die endlos weiter laufen. Spiegelverzeichnisse können auch ein Grund sein wieso da was amok läuft. Daher hab ich das deaktiviert.

Was mir bzw. einem Tester beim tagesschau adapter aufgefallen ist (recht schnelles System bei dem), das der javascript adapter auf rot geht (für ne halbe/ganze Sekunde) wenn der Adapter startet. Daher hab ich die Korrektur aller Objektdaten beim Start des Adapters um den Faktor 3 verlangsamt. Das können je nach Nutzerauswahl ein paar tausend Objekte sein, die beim Start alle in Ordnung gebracht werden.

Da über das Benachrichtigen der Admin und jede Javascriptinstanz über solche Aktualisierungen benachrichtigt wird. Ist es nachvollziehbar. Aber wieso das Probleme bei den heutigen Geschwindigkeiten macht, keine Ahnung. Andererseits wird heute auch viel mehr überprüft ob der Adapter-Entwickler da nciht irgendeinen Quark rein schreibt :)

mcm1957

@roelli said in Adapterzustand, welcher Datenpunkt?:

@mcm1957 sagte in Adapterzustand, welcher Datenpunkt?:

Wie stoppst du das Blockly?

Ich drücke einfach bei den Blockly-Skripten auf "Pause".

Wie wird das Script "Cronjob Trigger Test" gestartet? Was hast du da eingestellt?
Und wie beendet sich das Script "Cronjob Trigger Test" wenn du NICHT auf Pause drückst?
Wenn du schreibst dass das Script "Cronjob Trigger Test" alle Minuten gestartet wird, muss es sich ja auch mal selbst (binnen einer Minute) beenden !?!?
Wie sieht das Script "Cronjon Trigger Test" aus? Was tut es?

Roelli

@mcm1957 sagte in Adapterzustand, welcher Datenpunkt?:

Wie sieht das Script "Cronjon Trigger Test" aus? Was tut es?

Ich habe einfach den "Zeitplan" Block genommen und steuere damit eine Sprachausgabe an.
Und bin die letzten Jahre davon ausgegenangen, dass der Zeitplan dann auch automatisch gestoppt wird wenn man das komplette Skript stoppt. War aber noch nie so? (mir fällt auch gerade garnicht ein wie mann es im Blockly dann richtig macht, dass der Zeitplan dann auch gestoppt wird?)

Roelli

@mcm1957

Ich habe gerade eine alte VM hergestellt bevor ich JS-Controller und Admin-Adapter geupdated habe und wenn ich da dieses Cronjob-Skript stoppe, dann stoppt auch der Cronjob! (und läuft nicht einfach weiter)

Liegt gefühlt also am JS-Controller oder Admin-Adapter.

ticaki

@roelli
Hast du Spiegelverzeichnis im js-adapter aktiviert?

mcm1957

@roelli
Nun ja - ich würde hier auch erwarten dass das Blockly sich nach der Sprachausgabe beendet.

Roelli

@ticaki sagte in Adapterzustand, welcher Datenpunkt?:

@roelli
Hast du Spiegelverzeichnis im js-adapter aktiviert?

Wenn in der Zeile "Spiegeln von Skripten in den Dateipfad" nichts steht, dann ist das Spiegelverzeichnis NICHT aktiviert? Bei mir steht jedenfalls nix.

Ich wollte noch erwähnen das ich eine zweite JavaScript Instanz aktiviert habe. Darin habe ich versucht mit einem Blockly den die erste Instanz zu überwachen und mir eine Telegram-nachricht zu schicken wenn der erste adapter (Javascript.0) nicht mehr funktioniert.

ticaki

@roelli

Setzte mal in das telegram blockly einen debug(info) logausgabe stein rein.

Da beiden instanzen auf 100% gehen und es sich anhört als wenn in der 2. kaum skripte sind, kann man da ja mal nachgucken.

EDIT: Wie oben geschriebne ist mir 1 Fall bekannt in dem der Javascript-Adapter alive state kurz ausgeht. Könnte ja sein das der flackert - dann kann man im Code gucken wann der flackern könnte :)

Roelli

Aha! Das der Javascript adapter abschmiert schein ein globales Problem zu sein. Fängt scheinbar nun bei mehreren Nutzern an.

mcm1957

@roelli said in Adapterzustand, welcher Datenpunkt?:

Aha! Das der Javascript adapter abschmiert schein ein globales Problem zu sein. Fängt scheinbar nun bei mehreren Nutzern an.

Warum postest du diese Meldung in mehreren Topics? Beschäftigungsthereapie für Helfer?
Aber hier ist die Anmerkung wenigstesn mal nicht ganz offtopic.

Und zur Sache:
Bitte liefere genauere Infos zu deiner Behauptung. Wenn auf FB wer schreibt dass sein Javascript Adapter ein problem hat ist das noch lange kein globales Problem und nicht unbedingt mit deinem Blocklies in ZUsammenhang zu sehen. Da gibt es viel zu veile potenzielle Benutzerfehler.

Ergo um da irgendeinen Kontext herzustellen:
Genaue Fehlerbeschreibung liefern.
Genaue Versionsangaben des betroffenen System liefern.
Ggf Logs im DEBUG Mode
Ggf beteiligte Scripts posten