Beta Test js-controller 3.0.x auf GitHub
-
@lonsimbt Der Fehler kommt irgendwo "aus dem Adapter". Wüsste nicht wie der controller da was mit zu tun haben könnte
-
@lonsimbt PS: EInzige as sein kann ist das der Fehler schon immer da war aber bisher "nur" eine unhandled Promise rejection war die nicht zum adapter-crash geführt hat ... mit 3.0er controller ist es das aber. Da muss der Entwickler ran
-
@apollon77 gerade installiert vom git, ist aber noch der 3.0.9
-
@deta Mach nochmal, da fehlten noch 2 Files
-
@apollon77 jetzt ok! Beobachte es mal.
-
@apollon77
Kann ich den TR-064 in der gefixten Version einfach wieder für Admin Github laden, oder gibts da ein speziellen Link?
Im Moment läuft alles wie es soll, fehlt eben nur noch der TR-064 in der gefixten Version. -
@Jan1 Ja, Github. muss noch auf npm released werden.
-
@apollon77
Bingo, die 4.0.0 von Github macht nix mehr. Da werden keine Geräte mehr gefunden und vorhandene Geräte aktualisieren nicht mehr.
Edit:
wer lesen kann hat klare Vorteile. Ich geb dann mal das Passwort neu ein
-
@Jan1 sagte in Beta Test js-controller 3.0.x auf GitHub:
wer lesen kann hat klare Vorteile. Ich geb dann mal das Passwort neu ein
Wars das?
-
@apollon77
Ja läuft, was mich aber wundert, dass nirgends ein Fehler gebloggt wurde. -
@apollon77 said in Beta Test js-controller 3.0.x auf GitHub:
@e-i-k-e Achja um hier zusehen ob du ein problem mit den Skripten hast gibts noch einen Weg. Bei den Objekten gibt es system.adapter.javascript.2.eventLoopLag ... schau die den mal an. Der sollte im Idealfall nur seeeehr klein sein (sind Milisekunden). Normal ist alles ich sag mal kleiner 30, was ist der Wert denn bei Dir so? Gff logge den mal per history oder so und dann schau.
Wenn der Wert große Werte hat dann blockiert irgendetwas die Abarbeitung und dann muss Du schauen
Nur mal ganz kurz geschaut, der Wert ist leider sehr hoch.
Ich schaue später mal, ob ich etwas finden kann, was das auslöst.
-
@lonsimbt said in Beta Test js-controller 3.0.x auf GitHub:
Ich habe gerade den js-controller 3.0.9 bei mir getestet. Alle Adapter starten problemlos bis auf den Robonect-Adapter.
Der Fehler ist in v0.1.1 des Robonect Adapters behoben. Die Version ist ab morgen im latest Repository oder kann manuell von GitHub installiert werden: https://github.com/braindead1/ioBroker.robonect
-
@braindead Schaut gut aus. v0.1.1 des robonect-Adapters startet ohne Fehlermeldungen unter dem js-controller 3.0.9.
Danke für die schnelle Korrektur.
Gruß Marco
-
@e-i-k-e Autsch ... 61 Sekunden ... Es kann nur irgendeine Schleife über irgendetwas grosses sein oder etwas anderes was sehr lange dauert und damit alles blockiert und nicht asynchron abläuft.
-
Sentry hat nochmal zugeschlagen und daher habe ich eine 3.0.11 für Euch auf GitHub:
3.0.11 (2020-04-15) Release Elena
- (Apollon77) fix crash when system views are not correctly initalized (Sentry IOBROKER-JS-CONTROLLER-9)
-
-
@sigi234 Ich persönlich finde das als Entwickler sehr toll. Es gab bisher 4 relevante Sentry Crashes und keiner davon wurde hier im Forum gemeldet. Denke die hat einfach keiner gesehn. Von daher muss ich ehrlich sagen: Ja hat sich schon gelohnt
Ich denke wenn wir ins Latest gehen kommen da noch ein paar (einfach weil die Anzahl der User dann stark zunimmt), aber das ist ja ok.
Ob Ihr als User es eingeschaltet lasst oder deaktiviert bleibt jedem selbst überlassen.
-
@apollon77 also ich lasse es aktiviert. hilft ja ungemein für die ganze weiterentwicklung!
-
@apollon77 sagte in Beta Test js-controller 3.0.x auf GitHub:
Ob Ihr als User es eingeschaltet lasst oder deaktiviert bleibt jedem selbst überlassen.
Aha, das kann man deaktivieren? Ich lasse es aber auch so.
-
@sigi234 Jupp. Den State system.host.NAME.plugins.sentry.enabled auf false setzen ... und es ist aus
