germanbluefox / germanbluefox Goto Github PK

Hi GermanBlueFox,

Ingo sagt, Du seiest der richtige Ansprechpartner für meine Fragen.

Hintergrund:

• iObroker läuft in einer VM unter Proxmox auf einem relativ starken Intel NUC.
• Die Clients, alles Apple iPads, greifen ausnahmslos per WLAN auf den iOBroker zu, ob nun Index oder Edit.
• Fünf/sechs+ Clients greifen via Kiosker auf iOBroker-Index zu und dienen zur Visualisierung und Bedienung der
  umfangreichen Views.

Prinzipiell funktionierte das in der Vergangenheit auch gut.

Nun stelle ich fest, dass es Clients gibt, also die Apple Tablets, die entweder schon beim Erstaufruf des Kiosker, der auf eine „Start“-View im Index-iOBroker eingestellt ist, sehr sehr lange brauchen, bis der weiße Hintergrund verschwindet, ein „Connecting to Server – Loading Values“ erscheint und dann aber immer noch viele Sekunden lang nichts aufgeblendet wird.
Im besten Fall ist dann die Start-View da und man kann navigieren, im worst case kommt außer dem weißen Hintergrund fast gar keine Navigation und nichts mehr.

Ich glaube nun, ohne dass ich das empirisch habe testen können, dass es irgendwie am iPad liegt – also entweder RAM-Größe oder Modell und somit Prozessor… denn bspw ein Nicht-Pro-iPad mit 64 GB RAM zeigt das oben geschilderte Mißverhalten, ein Pro-iPad mit bspw 256 GB RAM zeigt dies auffällige Verhalten selten oder gar nicht.

Das impliziert bei mir den Verdacht…

• dass mein iOBroker-Projekt mittlerweile sehr groß / zu groß geworden ist und beim Start von einem Client aus „ALLES“ erstmal geladen wird, also eine große Menge an MB und somit auch Traffic
• dass ein „kleines“ iPad damit dann schnell an die Grenzen kommt und eine Navigations-Funktion entweder ewig lange dauert, bis das Projekt geladen ist oder sogar gar nicht erfolgreich lädt (Gründe: Prozessor und/oder RAM)
• dass das Design des Projekts geändert werden müsste, um optimal übertragen und geladen werden zu können
• dass ein quasi „monolithisches“ Design von sehr großen Views mit Hunderten/Tausenden von Datenpunkten und Links auf andere Views und auch Links auf eCharts usw solange ungeeignet für kleinere Clients ist, bis dies Design nicht optimiert wird
• dass man evtl die Client-Architektur, also wie von dort auf iOBroker-VIS zugegriffen werden soll, radikal ändert (anstatt Kiosker oder Browser-Aufruf irgendetwas anderes wie bspw iOBroker-App oder dergleichen?)

Da ein normaler iOBroker-VIS-Anwender vermutlich keine solchen großen Projekte hat: Wie sind denn die Erfahrungen oder Vorschläge von iOBroker / von Euch, wie man so etwas designen und umsetzen muss?

Platt gesagt: Ich kann ja nicht immer nur leistungsfähigere iPads kaufen müssen (neuere Modelle, immer PRO, immer viel RAM usw usw), um hier mit Client-Zugriff auf iOBroker erfolgreich das Projekt darstellen und steuern zu können. Oder schlimmstenfalls überall ein MacBook and die Wand nageln, nur weil die mit so einem Issue umgehen können, weil sie leistungsfähig genug sind.
Denn 95% des Tages „steht“ der Client ja auf einer View und macht nix (oder zeigt eben nur an), bis man mal einen Button oder mehrere Buttons betätigt und verschiedene andere Views aufruft oder Clicks zur Steuerung des SmartHomes absetzt, bis der Client dann wieder quasi in einen Ruheschlaf versinken kann, bis er erneut via Cam einen interessierten Betrachter/Bediener erkennt, die zuletzt dargestellte View anzeigt und dann auf Navigation oder andere Steuerung wartet.

Gibt es da bei iOBroker entsprechende Ansprechpartner und/oder Tests oder Vorschläge zu Verhaltensweisen für Systemdesigner und Implementatoren?
Oder müsste ich auch ein Ticket aufmachen oder bezahlten Support in Anspruch nehmen?

Danke im Voraus & liebe Grüße
Michael

Michael Schaaf | Telefon +49 (0)7172 – 91 67 56 1 | Mobil +49 172 – 52 33 6 33 | Fax +49 (0)7172 – 93 400 30 | Mail [email protected]