VIS lagged (bis zu 20 sek.) wenn Tablet aufwacht

[krizz2023]

Tach,

ich muss mich leider an die Community wenden, in der Hoffnung auf Schwarmwissen.

Bei mir läuft ein iobroker auf nem Raspi 4+, Im Haus verteilt mehrer Tablets die über eine Vollversion des Kioskbrowsers auf ioroker zugreifen, dort auch alles sauber konfiguriert. Ich habe eine Master-Vis laufen, die mehrere Views hat für jeden Raum eine eigene, somit hat auch jedes Kiosk-Client ne eigene Startseite. Die LAN -Infrastruktur ist, weil altes verbasteltes Haus, nur bedingt gut. Ich arbeite (leider) mit einem lustigen Verbund aus LAN, W-LAN und Power-LAN. Alle Verbrucher wie ein TV, haben aber im Grunde ausreichend Bandbreite um auch Livestreams sauber anzuzeigen; ich gehe also davon aus dass dies nicht der Grund für folgendes Problem ist.

Nun aber das Problem:
Nahezu jedesmal wenn ein Tablet aufwacht, (Trigger durch Bewegungsmelder oder Mikrofon des Tablets oder auch ein Skript dass den Klingeltrigger einer doorbell abfragt) laden die tablets innerhlb der VIS nach und brauchen teilweise bis zu 20 Sek. bis endlich die VIS angeigt. Die Tablets selbst wachen zack auf und auch der Kisokbrowser ist zack da, aber die VIS nicht....
was im Alltag nur nervig ist, fällt mir aber jetzt beim Installieren der doorbird auf die Füße, da die VIS nicht ausreichend schnell wieder da ist um ein -ebenfalls vom doorbird-trigger ausgelöstes, Popup mit dem doorbird-Snapshot auf allen views anzuzeigen. Ist die View auf einem tablet ausreichend schnell wieder da, wird auch das Popup angezeigt, ansonsten nicht.

Da ich nicht weiss woran es liegt, der VIS, der grundsätzlichen Architektur meiner VIS, Konfig des Kioskbrowsers, Bandbreite oder oder oder muss ich es allgemein posten.

Ich liefere gern alles an debug Infos nach, wenn ich denn nur wüßte ich Richtung ich recherchieren muss.

Der Raspi ist frisch aufgesetzt, entschlackt, konfiguiert und gebackupped, alle Bestandteile NPN etc...sind auf dem aktuellsten Stand. Alle Schnittstellen (API) funktionieren wie sie sollen, auch bei der doorbird.

[Homoran]

@krizz2023 sagte in VIS lagged (bis zu 20 sek.) wenn Tablet aufwacht:

Da ich nicht weiss woran es liegt

Da spielen einige Faktoren mit

• nach öffnen des Browsers muss das Frontend (=Tablet) die vis neu aufbauen
  • dazu werden nach Start des Browsers die aktuellen Daten des gesamten Projekts vom Server abgerufen. Dabei hat Einfluss
    • Die Datenmenge (Bilder?)
    • Die Datengeschwindigkeit (WLAN direkt an/in der Wand)
  • anschließend werden vom Browser des Frontends aus den CSS Informationen die Widgets gerendert. Hier ist entscheidend
    • Die CPU Leistung des Tablets
    • das verfügbare RAM

[krizz2023]

@homoran

Ok. Klingt soweit erstmal plausibel.
Mein VIS ist so groß nicht. Sind beim Backup 1,5 MB.
Es gibt keinerlei opulente Hintergrundgrafiken oder gar Bewegtbild zu laden.
Die Tablets (gerootete Amazon fire 7 + sind ansonsten völlig nackt, es laufen keinerlei Hintergrundanwendung.
Wenn Videostreams im selben Netzwerk sauber laufen und deutlich höhere Bandbreiten benötigen ist das denke ich auch auszuschließen.
Ich hatte dieses Phänomen bereits mit einer alten durch Entwicklung sehr verbastelten Installation auf meinem raspi, hatte darin die Ursache gesehen und alles frisch und neu aufgebaut, aber das Problem besteht weiterhin.
Auf dem raspi läuft auch ansonsten nichts und ich meine es ist ein. 4b+. Also bis vor kurzem der "Bolide" der das locker leisten müsste. Möchte ich auch eigentlich ausschließen als Ursache.

Und ich habe noch von keinem anderen so ein Problem geschildert bekommen, oder geht das allen so?

[krizz2023]

@homoran

Somit stinkt es nach Tablets die zu schwach auf der Brust sind beim rendern?
Lasse ich mir das Vis aufm Laptop anzeigen habe ich diese Probleme tatsächlich nicht.
Aber warum sollte das ein Tablet auf dem z.b. auch Spiele gerendert werden müssen an seine Grenzen bringen?

[Homoran]

@krizz2023 sagte in VIS lagged (bis zu 20 sek.) wenn Tablet aufwacht:

ich möchte jetzt nicht auf jede deiner Aussagen ei gehen.
Ich fürchte nur, dass diese Vergleiche keine Vergleiche sind.
es ist etwas anderes ein Bild darzustellen, als eine Grafik aus CSS Anweisungen zu erstellen, wo jede geometrische Teilfigur gerechnet werden muss.

und wie gesagt ist das Backend dabei kompkett außen vor, weil dieses ausschließlich kleine Textdateuen zur Verfügung strllt, was auch die geringe Größe deiner vis erklärt.

[krizz2023]

@homoran
Ok. Also wenn ich Deine Aussage richtig interpretiere, ist eine weitere Fehlersuche am Raspi oder der VIS eher unnötig, da das Problem wohl eher am Endgerät zu suchen ist.

Ich werde mal versuchen, in meinem Skript, dass bei Betätigen der Klingel nicht nur nen Screen on an alle Tablets zu schicken sondern auch nen Browser refresh.
Vllt. Hilft das.

Dennoch die Frage wie suche/grenze ich denn jetzt idealerweise sinnvoll das Problem ein?

[wendy2702]

@krizz2023 leihe/besorge dir ein Potentes Tablet und teste damit. Ist das Problem, genau wie bei deinem PC, nicht vorhanden ist es relativ eindeutig.

[krizz2023]

@wendy2702

Und wie viele verschiedene Endgeräte sollte ich dann Deiner Meinung nach ausprobieren, damit es eindeutig ist? Ist mir ehrlich gesagt als Lösungsansatz etwas zu random und damit halt auch nicht wirklich zielführend.

[Samson71]

@krizz2023
Was haben Deine Tablets an Leistungsdaten (Prozessor/RAM)?

[wendy2702]

@krizz2023 sagte in VIS lagged (bis zu 20 sek.) wenn Tablet aufwacht:

@wendy2702

Und wie viele verschiedene Endgeräte sollte ich dann Deiner Meinung nach ausprobieren, damit es eindeutig ist? Ist mir ehrlich gesagt als Lösungsansatz etwas zu random und damit halt auch nicht wirklich zielführend.

Wieso wieviele?

Laut deinem Eingangs Post hast du bisher nur Fire TV tablets.

Da wäre der Test doch z.B. mal mit zumindest einem weiteren doch nicht Zuviel, oder?

Andere Möglichlichkeit um z.B. die WLAN Verbindung auszuschließen wäre wenn die Tablets das unterstützen mal ein LAN Adapter anzuschließen. Dafür kenne ich das Amazon Zeugs aber zu wenig.

Zum Troubleshooting ob das Tablet die Daten zeitnah vom Server bekommt kannst du ja auch mal den Netzwerkverkehr mitschneiden und zusammen mit dem iobroker log auswerten.

[OliverIO]

@krizz2023
Eine Lösung wäre es die tablets nicht einschlafen lassen sondern wenn überhaupt nur den Bildschirm abzudunkeln.
So viel Strom verbrauchen die nicht.

Das rerendering beim aufwachen wirst du immer haben.
Durch potentere Hardware kannst du es nur minimieren.

[gluecksmann]

@wendy2702

Also ich habe 3 identische FireTablets ... theoretisch alle gleich... aber einer hat auch diese genannten Probleme...

[A Former User]

This post is deleted!

[wendy2702]

@gluecksmann was bedeutet denn „theoretisch“?

Wenn es bei dir nur eins ist von 3 und die hoffentlich auch praktisch identisch sind, würde ich auf ein Netzwerk Problem tippen.

Aber sind die wirklich komplett identisch?

[krizz2023]

@wendy2702

Ich für meinen Fall habe 3 Fire HD8 mit 2GB RAM und nem 2GHz HexaCore und ein Fire HD7 auf dem aber ein deutlich kleineres, separates VIS für meine Alarmanlage läuft. Alles komplett identisch konfiguriert, bis auf die IP's natürlich, alle per MQTT mit iobroker verbunden um Ladezyklen steuern zu können. Darüber bekommen die auch per Skript ihren Screen on von der doorbird, sowie nen browserrefresh.

Die Tablets, bzw. Kiosk geht nie in einem kompletten Standby bzw. Sleep, auch W-Lan ist immer "geforced".
Ich habe auch mit Browser-refrehs beim "Aufwachen" herumgespielt, was aber auch nichts bringt, denn:

Das Problem lässt sich auf den internen Aufbau vom VIS eingrenzen. Der Browser-refresh ist instant da, d.h. ich kann im Einzelfall auch kurzzeitig das VIS sehen und bedienen, bis sich das VIS neu aufbaut und das dauert.
Das ist auch insofern eindeutig, weil die VIS interne Rücklaufuhr fürs Laden zu sehen ist.
Auch den BrowserCache nicht zu leeren in der Hoffnung dass das Frontend nicht soviel nachladen muss bringt nichts.
Versuche mit LAN ist leider nicht möglich, da die Tablets leider nur drahtlos können.

Ich befürchte mittlerweile dass es am W-LAN Datendurchsatz an den Stellen der Tablets liegt.
Allerdings betrifft das auch ein Tablet, welches in unmittelbarer Nähe zum Router sitzt (keine 4m entfernt) und auch baulich nichts dazwischen, sprich voller W-LAN Empfang. Allerdings ist dort die Nachladezeit gefühlt etwas kürzer, aber dennoch so lang dass meine Skripte für ein Pop-up bei Betätigung der doorbird ins
Leere läuft.
Und ich baue mein WLAN mit nem Archer AX55 auf der WiFi6 macht. Das reicht eigentlich für deutlich mehr.

[hansmeier]

Ich vermute deine Tablets gehen zwischenzeitlich in den Fully Browser Modus "screenOff" und werden dann per "screenOn" wieder aktiviert ?
Wenn du statt dessen "stopScreensaver" / "startScreensaver" nutzt, sollte der Spuk vorbei sein.
Allerdings ist trotz "screensaver Brightness = 0" das Tablett noch ganz leicht beleuchtet. Sieht man aber nur nachts.
Zumindest ist es bei meinen Tabletts so.

[wendy2702]

@krizz2023 dieses Nachladen/Neuladen hatte ich auf einem Ipad Air als ich dort in der VIS 4 Live Kamera Streams mit hoher Auflösung hatte. Da kam tatsächlich nach Untersuchung das Wifi nicht mehr mit (alles von Unify). Habe dann die Streams auf kleinere Auflösung umgestellt wodurch weniger Daten übermittelt werden und seitdem läuft es.

Zu Wifi 6, können die Fire Tablets den Standart denn überhaupt?

[krizz2023]

@wendy2702 Nee, leider nicht, was mich, sollte es sich Erhärten dass es mitunter an der Performance des tablets liegt, welche wählen lässt die auch 5G können.

[wendy2702]

@krizz2023 Kenne je deine Baulichen Möglichkeiten nicht aber vielleicht ist diese Lösung auch für dich interessant:

https://forum.iobroker.net/topic/72273/projekt-touchscreen-auf-raspi?page=1

[krizz2023]

@wendy2702 Nicht wirklich, auch wenn mir das natürlich auch kurz in den SInn kam. MAch ich zum steuern meines Soundcraft UI24 auch so. Das wäre auch oversized.