UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Feuersturm]

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?

[apollon77]

@thomas-braun hihi. Surprise. War ein Nebeneffekt mit nem installer/fixer Update

[apollon77]

@feuersturm an sich wüsste ich nicht wie. Wenn wäre auch Admin und so langsamer. Daher auch: was heißt „träger“?

[Feuersturm]

@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.

[eXectiX]

@feuersturm @apollon77

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]

@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.

[amg_666]

@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.

[UweRLP]

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.

[Diginix]

@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 Fehler

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

Und mit Port 80

ERR_EMPTY_RESPONSE

Auch ohne Fix wäre ich über ein Workaround sehr dankbar. Ich fürchte der Fix lässt länger auf sich warten.

[apollon77]

@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

[UweRLP]

@apollon77

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

[UncleSam]

@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?

[foxriver76]

@uwerlp Ausgabe ist so i. O., allerdings ist aufgefallen, dass das auflisten der Instanzen fehlt, daher gut dass du es gepostet hast

[Thomas Braun]

@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.

[ente34]

@kueppert
oder mit Taste "c" in top

[Feuersturm]

@exectix sagte in js-controller 3.2 jetzt im Latest!:

@feuersturm @apollon77

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.

[Diginix]

@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.

[apollon77]

@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.

[Diginix]

@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.

[apollon77]

@diginix Ja das ist blöd, mal schauen ob wir was hinbekommen. Effektiv ists aber so ne Sache. Sauberer wäre eine web Instanz zu haben die du von extern nutzt und eine andere für Lokal