js-controller 3.2 jetzt im Latest!
-
@apollon77
Hey, ihr baut da vollständige TabCompletion ein und sagt nix?
Oder hab ich das nur überlesen?Auf jedenfall ein dickes Danke schön! Ich bin ja eigentlich tippfaul, und das auf der Konsole...
-
Ich hab in den letzten Tagen das Gefühl, dass mit js-controller 3.2.x mit meinen Adapter ("beta" Repository) meine VIS auf meinem Tablet unter Fully Kiosk Brower deutlich träger ist als vor der Aktualisierung.
Ich habe jetzt erstmal mein "Produktivsystem" wieder aktiviert und werde nochmal gezielter auf die Reaktion von meiner VIS achten.
Hat jemand schon ähnliches beobachten können?
@apollon77 Können die Änderungen vom js-controller 3.2.x Einfluss auf das Verhalten der VIS haben? -
@thomas-braun hihi. Surprise. War ein Nebeneffekt mit nem installer/fixer Update
-
@feuersturm an sich wüsste ich nicht wie. Wenn wäre auch Admin und so langsamer. Daher auch: was heißt „träger“?
-
@apollon77 sagte in js-controller 3.2 jetzt im Latest!:
@feuersturm an sich wüsste ich nicht wie. Wenn wäre auch Admin und so langsamer. Daher auch: was heißt „träger“?
Auch beim Zugriff auf den Admin kommt es mir so vor, dass er länger lädt bis alles komplett aufgebaut ist.
Träge bei der VIS bedeutet in dem Fall, dass ich auf eine Schaltfläche drücke und das Umschalten + Aufbau der neuen View teilweise mehrere Sekunden dauert.Beide Container mit ioBroker liegen auf der selben internen Festplatte vom Nuc und haben die gleichen zugewiesenen Ressourcen. Ich werd jetzt erstmal wieder mein Produktivsystem 1-2 Tage laufen lassen und schauen ob es genau so "flott" ist wie damals. Nicht das es am Ende am Fully Browser liegt, da ich spontan nicht weiß, wann er das letzte Mal auf dem Tablet aktualisiert wurde.
-
Auch beim Zugriff auf den Admin kommt es mir so vor, dass er länger lädt bis alles komplett aufgebaut ist.
Das Gefühl habe ich auch seit der 3.2!
-
@feuersturm also bei Vis ist das umschalten der views komplett Browser seitig soweit Ich weiß. Da werden ja nur die Daten einmalig Anfang geladen und danach nur alle Updates übertragen.
-
@exectix Kann ich nicht bestätigen, läuft gefühlt genauso gut wie die Vorgänger. Admin hat bei mir auch rumgezickt und war extrem langsam, Browser-Cache löschen hat da - warum auch immer - was gebracht, scheint also kein js-controller Problem zu sein.
-
Hallo kann das jemand nachvollziehen?
C:\Program Files\iobroker\iobroker003>iobroker status all iobroker is running on this host. SYSTEM/memoryLimitMB: 0 SYSTEM/hostname: HP-ED800(iobroker003) NETWORK/IPv4: true NETWORK/IPv6: true NETWORK/useSystemNpm: true OBJECTS/type: file OBJECTS/host: 127.0.0.1 OBJECTS/port: 9001 OBJECTS/user: OBJECTS/pass: OBJECTS/noFileCache: false OBJECTS/connectTimeout: 2000 OBJECTS/OPTIONS/retryStrategy: reconnectCount => { if (!ready && initError && ignoreErrors) { return new Error('No more tries'); } if (this.stop) { return new Error('Client has stopped ... no retries anymore'); } if (ready && reconnectCount >= retry_max_count) { return new Error('Stop trying to reconnect'); } // A function that receives an options object as parameter including the retry attempt, // the total_retry_time indicating how much time passed since the last time connected, // the error why the connection was lost and the number of times_connected in total. // If you return a number from this function, the retry will happen exactly after that // time in milliseconds. If you return a non-number, no further retry will happen and // all offline commands are flushed with errors. Return an error to return that // specific error to all offline commands. if (!ready) { return 300; } else { return retry_max_delay; } /*if (options.error.code === 'ECONNREFUSED') { // End reconnecting on a specific error and flush all commands with a individual error return new Error('The server refused the connection'); } if (options.total_retry_time > 1000 * 60 * 60) { // End reconnecting after a specific timeout and flush all commands with a individual error return new Error('Retry time exhausted'); } if (options.times_connected > 10) { // End reconnecting with built in error return undefined; } // reconnect after return Math.max(options.attempt * 100, 3000);*/ } OBJECTS/OPTIONS/enableReadyCheck: true OBJECTS/OPTIONS/host: 127.0.0.1 OBJECTS/OPTIONS/port: 9001 OBJECTS/OPTIONS/db: 0 OBJECTS/OPTIONS/family: 0 OBJECTS/OPTIONS/autoResubscribe: false OBJECTS/OPTIONS/connectionName: OBJECTS/maxQueue: 1000 STATES/type: file STATES/host: 127.0.0.1 STATES/port: 9000 STATES/maxQueue: 1000 STATES/OPTIONS/retryStrategy: reconnectCount => { if (!ready && initError) { return new Error('No more tries'); } if (this.stop) { return new Error('Client has stopped ... no retries anymore'); } if (ready && reconnectCount >= retry_max_count) { return new Error('Stop trying to reconnect'); } // A function that receives an options object as parameter including the retry attempt, // the total_retry_time indicating how much time passed since the last time connected, // the error why the connection was lost and the number of times_connected in total. // If you return a number from this function, the retry will happen exactly after that // time in milliseconds. If you return a non-number, no further retry will happen and // all offline commands are flushed with errors. Return an error to return that // specific error to all offline commands. if (!ready) { return 300; } return retry_max_delay; /*if (options.error.code === 'ECONNREFUSED') { // End reconnecting on a specific error and flush all commands with a individual error return new Error('The server refused the connection'); } if (options.total_retry_time > 1000 * 60 * 60) { // End reconnecting after a specific timeout and flush all commands with a individual error return new Error('Retry time exhausted'); } if (options.times_connected > 10) { // End reconnecting with built in error return undefined; } // reconnect after return Math.max(options.attempt * 100, 3000);*/ } STATES/OPTIONS/enableReadyCheck: true STATES/OPTIONS/host: 127.0.0.1 STATES/OPTIONS/port: 9000 STATES/OPTIONS/db: 0 STATES/OPTIONS/family: 0 STATES/OPTIONS/autoResubscribe: false STATES/OPTIONS/connectionName: LOG/level: info LOG/maxDays: 7 LOG/noStdout: true LOG/TRANSPORT/FILE1/type: file LOG/TRANSPORT/FILE1/enabled: true LOG/TRANSPORT/FILE1/filename: log/iobroker LOG/TRANSPORT/FILE1/fileext: .log LOG/TRANSPORT/SYSLOG1/type: syslog LOG/TRANSPORT/SYSLOG1/enabled: false LOG/TRANSPORT/SYSLOG1/host: localhost LOG/TRANSPORT/SYSLOG1/protocol: udp4 LOG/TRANSPORT/SYSLOG1/localhost: iobroker dataDir: ../../iobroker-data/ C:\Program Files\iobroker\iobroker003>Ausser obige Auffälligkeit läuft die 3.2.11 unter Windows problemfrei.
-
@unclesam sagte in js-controller 3.2 jetzt im Latest!:
@diginix Zu LE: das ist bekannt und lässt sich (ohne Fix in Greenlock) nicht beheben. Einzige Möglichkeit ist, auch lokal auf Port 443 zu wechseln.
Wo soll ich denn den Port 443 noch einstellen bzw auf ihn wechseln?
In der web.0 Instanz ist er ja schon eingetragen wegen LE.
Admin nutzt https aber eben mit 8081 und den default Zertifikaten.Bis JS-Controller 3.1 waren die lokalen URLs für flot, materialui usw. auch mit https Protokoll:
https://192.168.2.47/flot/preset.html
Da kommt aber nun als FehlerERR_SSL_VERSION_OR_CIPHER_MISMATCHUnd mit Port 80
ERR_EMPTY_RESPONSEAuch ohne Fix wäre ich über ein Workaround sehr dankbar. Ich fürchte der Fix lässt länger auf sich warten.
-
@uwerlp sagte in js-controller 3.2 jetzt im Latest!:
Ausser obige Auffälligkeit
Was ist die Auffälligkeit?
status "all" liefert genau diese Ausgabe .. es fehlen glaube ich nur die Instanzen noch dazu
-
Diese Ausgabe
OBJECTS/OPTIONS/retryStrategy: reconnectCount => { if (!ready && initError && ignoreErrors) { return new Error('No more tries'); } if (this.stop) { return new Error('Client has stopped ... no retries anymore'); } if (ready && reconnectCount >= retry_max_count) { return new Error('Stop trying to reconnect'); } // A function that receives an options object as parameter including the retry attempt, // the total_retry_time indicating how much time passed since the last time connected, // the error why the connection was lost and the number of times_connected in total. // If you return a number from this function, the retry will happen exactly after that // time in milliseconds. If you return a non-number, no further retry will happen and // all offline commands are flushed with errors. Return an error to return that // specific error to all offline commands. if (!ready) { return 300; } else { return retry_max_delay; } /*if (options.error.code === 'ECONNREFUSED') { // End reconnecting on a specific error and flush all commands with a individual error return new Error('The server refused the connection'); } if (options.total_retry_time > 1000 * 60 * 60) { // End reconnecting after a specific timeout and flush all commands with a individual error return new Error('Retry time exhausted'); } if (options.times_connected > 10) { // End reconnecting with built in error return undefined; } // reconnect after return Math.max(options.attempt * 100, 3000);*/ }und das
STATES/OPTIONS/retryStrategy: reconnectCount => { if (!ready && initError) { return new Error('No more tries'); } if (this.stop) { return new Error('Client has stopped ... no retries anymore'); } if (ready && reconnectCount >= retry_max_count) { return new Error('Stop trying to reconnect'); } // A function that receives an options object as parameter including the retry attempt, // the total_retry_time indicating how much time passed since the last time connected, // the error why the connection was lost and the number of times_connected in total. // If you return a number from this function, the retry will happen exactly after that // time in milliseconds. If you return a non-number, no further retry will happen and // all offline commands are flushed with errors. Return an error to return that // specific error to all offline commands. if (!ready) { return 300; } return retry_max_delay; /*if (options.error.code === 'ECONNREFUSED') { // End reconnecting on a specific error and flush all commands with a individual error return new Error('The server refused the connection'); } if (options.total_retry_time > 1000 * 60 * 60) { // End reconnecting after a specific timeout and flush all commands with a individual error return new Error('Retry time exhausted'); } if (options.times_connected > 10) { // End reconnecting with built in error return undefined; } // reconnect after return Math.max(options.attempt * 100, 3000);*/ }habe ich als Fehlermeldung interpretiert.
Wenn die Ausgabe so in Ordnung ist dann mein Fehler
-
@diginix Was ich nicht verstehe: wieso benutzt du LE für interne Server? LE ist ja eigentlich für externe Server gedacht und da gibt es nur einen Port 443. Oder wie löst du das? Split-Horizon-DNS?
-
@uwerlp Ausgabe ist so i. O., allerdings ist aufgefallen, dass das auflisten der Instanzen fehlt, daher gut dass du es gepostet hast
-
@uwerlp
Nicht alles wo das Wort 'Error' drin vorkommt ist auch eine Error-Meldung.
Das was du da gefunden hast ist doch nur die retryStrategy für den Fall, das die aufgeführten Errors im System auftauchen. -
@kueppert
oder mit Taste "c" in top -
@exectix sagte in js-controller 3.2 jetzt im Latest!:
Auch beim Zugriff auf den Admin kommt es mir so vor, dass er länger lädt bis alles komplett aufgebaut ist.
Das Gefühl habe ich auch seit der 3.2!
@apollon77 @eXectiX Vermutlich hängt es mit dem Fully Browser zusammen. Heute Nachmittag lief meine eigentliche Produktivinstanz auch deutlich träger als sonst. Nachdem ich den Fully Browser dann zu und wieder auf gemacht habe war es wieder flotter. Hat also erstmal nichts mit dem js-controller zu tun, werde vermutlich ein neue Diskussion dazu aufmachen.
-
@unclesam sagte in js-controller 3.2 jetzt im Latest!:
@diginix Was ich nicht verstehe: wieso benutzt du LE für interne Server? LE ist ja eigentlich für externe Server gedacht und da gibt es nur einen Port 443. Oder wie löst du das? Split-Horizon-DNS?
Ich habe eine myfritz Domain mit der ich von außen auf MaterialUI zugreife und für die ist auch das LE Cert.
Aber wenn ich im Heimnetz bin habe ich bisher dann logischerweise lokale IPs genutzt.
Wozu gibt es LE denn, wenn nicht genau für das was ich damit mache?
Es klang so, als ob man weiterhin parallel auch lokale IPs nutzen könne, auch ohne, dass greenlock ein Fix erhält. -
@diginix mal ne blöde Frage: wenn du lokal zugreifst per ip kam Dann bisher immer eine ssl Warnung oder?! Weil der Domain Name hat ja nicht gepasst oder?!
Aber ja die Änderung ist scheinbar das jetzt nur noch der fqdn Zugriff von Greenlock verarbeitet wird und nicht einfach die certs so genutzt werden.
-
@apollon77 Ja, genau der Browser hat das nat. bemerkt und als unsicher markiert, aber der Webserver hat ja geliefert. Was er eben nun nicht mehr macht.
