Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[liv-in-sky]

hat jemand von euch feststellen können, dass auf tablets mit fully-browser und raspi 4 mit chromium (kiosk) eine seltsame "weiße" seite kommt. zuerserst kommt das übliche "...daten werden geladen..." , dann wird die seite weiß, dann dauert es gefühlt ewig, bis die vis-seite geladen ist

leider weiß ich nicht mehr, welchen adapter ich upgedatet habe, als das zum vorschein kam - evtl der web adapter ?

das selbe ist schon jmd aufgefallen: https://forum.iobroker.net/post/665379

[haselchen]

@liv-in-sky

Exakt das gleiche Phänomen habe ich ebenfalls mit der VIS App und einer Synology.
Scheint vielleicht nicht Geräte- oder Browserabhängig zu sein.
Das Gute ist, da ich nicht gleich die neuesten Version aufspiele, kann ich niedrigere Versionen der Adapter abdecken :) und vielleicht so zur Lösung beitragen.

Simple Api 2.6.1
Socket.IO 3.1.4
VIS 1.3.4
Webserver 3.2.3

[Chaot]

@liv-in-sky
Ich habe einen ähnlichen Effekt auf meinem Raspi mit Chromium.
Der Raspi ist komplett abgespeckt und macht nur den Touchscreen. Trotzdem kommt es zu einer weißen Seite die ca. 10 Sekunden steht.
Bei den Tablets mit Fully ist das genauso. Wobei ich das auf Fully geschoben hatte.
Bei den Tablets mit Wallpanel ist das seltsamerweise nicht so. Aber da vermute ich das die den Cache nicht löschen bei einem Reload.

[liv-in-sky]

@haselchen

ich vermute mal, dass der web-adapter evtl das thema ist - es könnte aber auch ein vis- ode socket-adapter thema sein

[fuso]

@liv-in-sky

ja, da läuft nur chromium im Kiosk mode.
ich habe da ein Raspberry pi OS (Buster) mit desktop. Mit Desktop deswegen, weil es einfacher einzurichten war. Bin damals umgestiegen von Raspi 3 auf den 4er. Dachte einfach der Neue hat dafür auch ausreichend Leistung.
Mir ist da noch so ein Gedanke gekommen. Was wäre, wenn ich auf den Raspi noch einen iobroker im Multihost installiere und nur die VIS als Adapter laufen lassen. denkst Du das könnte besser laufen? Oder total daneben gedacht?

[Chaot]

@liv-in-sky
Ich sehe zu haselchen nur eine Gemeinsamkeit:

Simple Api n.a.
Socket.IO 3.1.4
VIS 1.4.3
Webserver 3.4.9

[liv-in-sky]

@fuso etwas vorbei gedacht - ich habe auch das selbe setting - buster mit kiosk autostart - ist schon ok

multihost und vis drauf und dann noch der desktop mit kiosk ist ja nur mehr performance gebrauch - bring also nichts

den desktop brauchst du ja für chrome im kiosk mode - das geht nicht anders - hast du eine ssd oder sd karte ? bin nicht sicher, ob das was bringt - ich nutze nur ssd für raspis

das einzige, was man probieren könnte: es gibt mittlerweile andere system für raspi 4 - z.b ubuntu (glaube ich) - da gibt es einiges auf youtube - evtl ist da der chrome-browser besser und schneller integriert ! bei mir ist der chromium dienst bei einer dauerlast von 45% - das ist ganz schön viel - aber geht nicht besser mit buster

[liv-in-sky]

@chaot
ich habe

socket 3.1.4
vis 1.4.3
web: 3.4.9

wenn aber bei der vis 1.3.4 von @haselchen auch das problem liegt - kann es vis nicht sein

also socket oder web

[liv-in-sky]

@Bluefox
@apollon77

hat von euch beiden evtl eine idee - ich habe keine ahnung, wie ich den fehler finden könnte bzw wie ich einen fehler dokumentieren könnte

[apollon77]

Na dann macht doch mal ein GitHub issue .. vllt mit nem video?

[liv-in-sky]

@apollon77

kann ich versuchen - aber es tritt sporadisch auf

ein refresh in chrome auf raspi oder ein fully browser kill auf dem tablet helfen immer

@Chaot @haselchen @fuso

vielleicht denkt ihr auch mal dran und macht ein handy-video, wenn es vorkommt und postet es - dann kann ich gerne ein github-issue öffnen

[haselchen]

@liv-in-sky

Habs mal gefilmt.
1min 36 dauert es von App Start bis die Home View erscheint.

[liv-in-sky]

@haselchen kannst du es bitte posten

[apollon77]

passiert es eigentlich auch im normalen Browser?

[Homoran]

Nur mal so ins unreine gedacht:

Auch wenn die komplett vis im Frontend gerendert wird und die Geschwindigkeit daher von der Leistungsfähigkeit des Frontends abhängt, wird für jeden Flot (oder eCharts) Chart teilweise massive Rechenarbeit auf dem Server benötigt, da alle Daten aus der zuständigen Datenbank (History, SQL, Influx) gelesen, gemäß der im Chart eingestellten Aggregation berechnet werden müssen und dann an das Frontend geschickt werden.
Je nach Leistungsfähigkeit des Servers und der Datenleitung kann das schon einige Zeit dauern.

Kann sein, dass in der Zeit zwar alle Frames im Frontend geladen sind, aber noch nicht wirklich alles angekommen ist.

Daher muss man bei vielen Charts höllisch aufpassen diese nicht mit Daten zu überladen, sondern nur so viele Datenpunkte pro Linie zu definieren, wie es sowieso von der Auflösung nur machbar ist.
Bei einer 24h Anzeige muss nicht jede Minute ein Datenpunkt enthalten sein (=1440 Datenpunkte), wenn die grafische Darstellung nur 240pixel breit ist

[haselchen]

@liv-in-sky

Die max . Grösse ist 5mb hier.
Das Teil ist 152mb gross

Und nu?

[liv-in-sky]

@haselchen

kannst du da reinladen ?

https://drive.google.com/drive/folders/1-BYdy7kGJkx8FGcsRKEN5LCt3aFvqFaA?usp=sharing

[liv-in-sky]

@apollon77 nein - nicht auf dem pc mit chrome - da habe ich das noch nicht gehabt

[liv-in-sky]

@homoran

könnte sein - aber bei einem refresh der seite oder ein neuer start des fully browsers funktioniert es - da muss ja auch alles geladen werden - evtl ein cache problem

tritt bei mir meist am anfang/tagesbeginn auf- wenn also die seite verlassen wird und am nächsten tag wird das geladen

[Homoran]

@liv-in-sky sagte in ladezeit der vis bei raspi und tablet:

aber bei einem refresh der seite oder ein neuer start des fully browsers funktioniert es

Mit dem Fully kenne ich mich nicht aus (ich hatte testweise mal mit Wallpanel gearbeitet), kann aber sein, dass diese beiden ein ganz anderes caching-Verhalten haben wie die auf Tempo und Datensparsamkeit getrimmten aktuellen Browser.