Empfehlungen für zuverlässige Darstellung auf Tablets?

[pd_mueller]

@homoran Ja, ich verwende sowohl den Fully (mit Lizenz) im Wohnzimmer wie auch Wallpanel im Bad. Wallpanel verhält sich insgesamt ähnlich. Ein Nachteil ist bei Wallpanel jedoch, dass keine Sprachausgaben über sayit ausgegeben werden.

[ukl]

@pd_mueller ich habe 3 Systeme mit Display's ( 7") angeschlossen an Raspi3+ und LAN in unserem Haus zu laufen, ioBroker läuft auf einer Synology.
Die VIS im ioBroker und die Kiosk Browser auf den Raspi's laufen seit Ewigkeiten stabil und Deine in-stabile und un-zuverlässige Anzeige kann ich nicht bestätigen. Es gibt auch keinerlei performance Probleme bezüglich Echtzeit.

Ob die Tablets und Android das Problem sind???

BTW: die Raspi's langweilen sich, weil der Browser braucht dort eigentlich für die reine Darstellung keine große Performance, so ich kann die anderen Komemntare nicht nachvollziehen

[UncleSam]

@ukl Zu den wichtigsten Faktoren gehören:

• Version von WebView/Chromium, wo die Vis dargestellt wird
• Komplexität der Views (und wohl auch deren Anzahl)
• Art der Visualisierung, die eingesetzt wird
• Anbindung (WLAN vs LAN)

Kaum eine Rolle spielen:

• Performance des ioBroker "Servers" (Raspi, NUC, NAS, ...)

[BananaJoe]

@pd_mueller Also ich hab hier ein Lenovo Tablet mit Android 10, der aktuellen Chromium Engine und dem Fully Kiosk Browser.

So wie du verwende ich fast nur die Inventwo-Widgets.

Im Normalfall läuft alles Super bei mir. Die View wird 24x7 auf dem Tablet angezeigt, die Daten/Werte sind immer aktuell.
Aber ich hatte auch zwischendurch schon mal das Problem das nichts aktualisiert wurde - und hatte das mit ähnlichen Versuchen wie du zu lösen versucht.

Ich meine gefunden zu haben woran es lag - an den Iventwo-Widgets. Ich nehme an auch du machst regelmäßig Updates des Adapters, eventuell bist du wie ich sogar auf der Beta-Schiene unterwegs.

Geh mal in den VIS-Editor und klicke nacheinander jedes Inventwo-Widget einmal an. Bei vielen wird er danach was speichern nehme ich an. Damit wird - ich drücke es mal so aus - das Widget selbst auch aktualisiert und der/das VIS weis wieder wie er es richtig darstellen muss. Das hatte ich z.B. als die Popup-Funktion in die MultiButtons eingebaut wurde.

Danach noch mal auf den Tablet frisch geladen und gut ist.

[Georgius]

Ich hatte die Probleme auch. Daher suche ich eine Lösung für die neue Wohnung.
Inzwischen läuft der Iobroker auf einem leistungsstarken Nas im Docker. Meine Idee wäre dort auch etwas laufen zu lassen was ein Browser ist in Verbindung mit einer Remote Lösung. Kennt wer so etwas?

[pd_mueller]

@bananajoe Vielen Dank für den Tipp!
Es ist tatsächlich so, dass ich fast nur die inventwo-Widgets verwende.
Ich klicker die jetzt mal durch und schau, ob es dann besser wird.

[febea]

@pd_mueller Kann dich verstehen.

Ich nutze den IOBroker jetzt auch schon Ewigkeiten und bin von einer Visualisierung zur nächsten. Aktuell nutze ich wieder die "normale" VIS. Aber auch ich habe das Problem, dass die VIS immer wieder bei der Aktivierung einem Reload unterzogen werden muss, da sich sonst die dargestellten Werte nicht regelmäßig aktualisieren.

Als Beispiel: Ich zeige z.B. Spritpreise auf einer Seite an und diese sind nicht aktuell, obwohl sie sich geändert haben. Im IOBroker direkt in den Objekten sind die Werte perfekt, aber sie werden einfach nicht direkt von der VIS nach einer Änderung übernommen.

Vielleicht ist das auch dein Problem.

mfg Christian

[Architect0711]

@unclesam

Hi UncleSam,

Ich würde gerne selbst eine UI mit Angular erstellen, kannst du dazu bitte ein paar infos sharen zb. wie man sich mit iobroker verbindet über socketio oder hast du evtl sogar GitHub links, wo man ein bischen spickeln kann, damit ich nicht ganz von null anfangen muss?

LG Robert

[UncleSam]

@architect0711 Inzwischen gibt es eine Library, die dir die ganze Sache abnimmt: https://github.com/ioBroker/socket-client

Die solltest du relativ problemlos in deinem Angular Projekt verwenden können. Dafür würde ich einen Service erstellen, der die Library kapselt.

Meine ältere Lösung findest du in diesem Beitrag: https://forum.iobroker.net/post/566570

[Architect0711]

@unclesam Yeah cool vielen Dank!

[Architect0711]

@unclesam Hey ich habe mir einen Service gebastelt, der so ein "Connection" objekt erstellt, kriege aber immer die Meldung:

"Socket connection could not be initialized: Error: Socket library could not be loaded!"

Kennst du eine Lösung für das Problem? Muss ich da noch irgend ein npm paket installieren? Die README.md enthält leider wenig hilfreiche infos. In der Connection.ts sucht er irgendwie nach einem object namens window.io und wirft dann den fehler, wenn er es nicht findet, aber was es damit auf sich hat, weiß ich leider nicht:

	private waitForSocketLib(): Promise<void> {
		// Only wait once
		if (this._waitForSocketPromise) return this._waitForSocketPromise;

		this._waitForSocketPromise = new Promise(async (resolve, reject) => {
			// If socket io is not yet loaded, we need to wait for it
			if (typeof window.io === "undefined") {
				// If the registerSocketOnLoad function is defined in index.html,
				// we can use it to know when the socket library was loaded
				if (typeof window.registerSocketOnLoad === "function") {
					window.registerSocketOnLoad(() => resolve());
				} else {
					// otherwise we need to poll
					for (let i = 1; i <= 30; i++) {
						if (window.io) return resolve();
						await wait(100);
					}

					reject(new Error("Socket library could not be loaded!"));
				}
			} else {
				resolve();
			}
		});
		return this._waitForSocketPromise;
	}

Hier ist meine config, wobei ich nicht glaube, dass es daran liegen kann. (ip und port habe ich mal abgeändert)

  private connectionProps: ConnectionProps  = {
    /** The socket name. */
    name: "angularUiConnectionSocket",
    /** State IDs to always automatically subscribe to. */
    autoSubscribes: [],
    /** Automatically subscribe to logging. */
    autoSubscribeLog: true,
    /** The protocol to use for the socket.io connection. */
    protocol: "https",
    /** The host name to use for the socket.io connection. */
    host: "123.45.67.890",
    /** The port to use for the socket.io connection. */
    port: 12345,
    /** The socket.io connection timeout. */
    ioTimeout: 20000,
    /** The socket.io command timeout. */
    cmdTimeout: 5000,
    /** Flag to indicate if all objects should be loaded or not. Default true (not loaded) */
    doNotLoadAllObjects: true,
    /** Flag to indicate if AccessControlList for current user will be loaded or not. Default true (not loaded) */
    doNotLoadACL: true,
    /** Progress callback. */
    onProgress: this.onProgress,
    /** Ready callback. */
    onReady: this.onReady,
    /** Log callback. */
    onLog: this.onLog,
    /** Error callback. */
    onError: this.onError,
    /** Object change callback. */
    onObjectChange: this.onObjectChange,
    /** Gets called when the system language is determined */
    onLanguage: this.onLanguage,
    /** Forces the use of the Compact Methods, wich only exists in admin 5 UI. */
    admin5only: false
  };

[Scrounger]

@pd_mueller

@unclesam sagte in Empfehlungen für zuverlässige Darstellung auf Tablets?:

@pd_mueller Auch wenn ich mich hier jetzt wohl unbeliebt mache: das ist leider so bei vis.

Machst du nicht, bin da aber absolut anderer Meinung
VIS kann super performant sein und ist meiner Meinung nach (hab viel getestet, z.B. Lovelace, Jarvis, etc.) am stabilsten und hat definitiv die größte flexibilität.
Ich schreibe bewusst kann, weil man bei einer performanten VIS und den Tablets auf ein paar Dinge achten sollte.

@unclesam sagte in Empfehlungen für zuverlässige Darstellung auf Tablets?:

Da sehr viel im Browser gemacht wird, ist der (gerade auf schwächeren Systemen) etwas überfordert.

Stimm ich voll zu, die performance von VIS hängt voll vom verwendeten Endgerät ab. Grundsätzlich zeigt meine Erfahrung dass man bei den Tablets mind. 3GB RAM haben sollte, um so mehr, um so besser.

@pd_mueller sagte in Empfehlungen für zuverlässige Darstellung auf Tablets?:

• Bei Aktivierung der Anzeige des Tablets im Wohnzimmer (mit Fully) über den Bewegungsmelder dauert es einige Sekunden (weisses Bild, drehender Symbol, dann "Daten werden geholt...", bis die Visualisierung angezeigt wird

Ursache hierfür ist meistens das im Standby des Tablets das WLAN ausgeschaltet wird, was dann zu diesem Effekt führt. Bei Android gibt es aber Möglichkeiten das zu verhindern. Zusätzlich bietet z.B. der Fully Browser die wakelock Funktionen, die hierbei auch helfen können. Leider kann das bei manchen Tablet sehr tricky sein, speziell ab Android 11.
Grundsätzlich kann ich hier nur empfehlen schließt das Tablet ans LAN an, sofern das bei Euch möglich ist. Entweder gleich ein Tablet mit LAN Anschluss kaufen (z.B. Xoro Pads, Allnet, etc.) oder einen USB to Ethernet Adapter verwenden. Damit umgeht man das Problem mit dem WLAN Standby.

@pd_mueller sagte in Empfehlungen für zuverlässige Darstellung auf Tablets?:

• Anzeige der Zustände ist nicht aktuell, erst nach manuellem Refresh
  (runterziehen der Anzeige, so dass ein Refresh angestossen wird)
• Eingaben (per Touch auf den Tablets) werden nicht angenommen (erst nach Refresh)
• Eingaben werden angenommen (z.B. Licht wird eingeschaltet), der Ein-Zustand aber nicht visualisiert.

Diese Effekte treten meiner Erfarhung auf, wenn etwas grundlegendes mit der VIS nicht stimmt. Das kann z.B. der Einsatz von zuvielen Bindings sein (siehe unten meine Anmerkung zu Bindings) und das Fehler auftreten, z.B. Verursacht von Widgets. Um das näher zu analysieren, kann ich jedem nur empfehlen sich mit dem Thema Remote Debugging zu beschäftigen und zu schauen was in der Console steht. Hier gibts ne gute Anleitung. Per ADB kann das auch übers Netzwerk erfolgen ohne Anschluss per USB -> einfach mal googlen.

Eine weitere Ursache kann bei Verwendung von Fully z.B. die Android System WebView sein - diese wird von Fully verwendet. Hier sollte man Testweise mal alle updates deinstallieren und schauen ob es dann besser läuft - hat bei mir schon oft geholfen. Evtl. muss man auch mal die Versionen durchprobieren - am besten Changelog anschauen und aktuelle Issues ansehen.

So und jetzt noch zum eigentlichen Thema - paar Regeln zum Aufbau der VIS:

• Verzichtet möglichst auf Bindings:
  Beim Einsatz von zuvielen Bindings leidet die Performance meiner Erfahrung nach. Dazu muss man den Mechanismus von Bindings verstehen. Wenn sich der verwendet Datenpunkt des Binding ändert, dann wird das Widget komplett neu gerendert. D.h z.B. wenn man in einem Widget mehere Bindings mit mehreren verschiedenen Datenpunkten verwendet wird bei jeder Änderung das ganze Widget neu gerendert, dass kann zu einem Speicherüberlauf führen. Vor allem wenn man z.B. Datenpunkte verwendet die sich im Sekundentakt ändern.
  Ich persönlich verwende Bindings nur die beim Laden der View gesetzt werden oder nur ganz ganz selten die Datenpunkte aktualisiert werden.
  Das war meiner Erfahrung nach in 95% der Fälle die Lösung für die schlechte Performance.
• Verlagert die Last auf den Server. D.h. es gibt Möglichkeiten Datenpunkte im Vorfeld für die VIS entsprechend aufzubereiten, so dass die Endgeräte diese Arbeit nicht übernehmen müssen. Meine MDW Widgets bieten hier sehr viele Möglichkeiten - Schleichwerbung
• Packt nicht zuviel in eine View, macht lieber zwei oder drei daraus. Verwendet hier "View in Widget", "View in Widget 8", "Grid Views" oder "Masonry Views". Mit diesen Widget werden die Views nur dann geladen, wenn Sie wirklich gebraucht werden. Wenn die View nicht aktiv ist, schmeißt Sie VIS nach einer gewissen Zeit aus dem Speicher
• Setup -> Einstellungen -> Lösche nicht aktive Views: Diesen Wert - vor allem bei Performance schwachen Tablets - möglichst gering einstellen.

Ich hab schon einige Visu für verschiedene Tablets erstellst, die sowohl per WLAN angebunden sind und per BM ein / ausgeschaltet werden - alle laufen 24/7 und sind super performant ohne das irgendwann ein Refresh durchgeführt werden muss.

Meine eigenen Visu's laufen auf einem Allnet 15" Tablet mit 4GB RAM und auf einem Raspi 4 4GB mit Touchscreen (nur Chormium im Kiosk Modus) - beide per LAN angebunden. Es werden rund 1.500 Datenpunkte verwendet und die Visu ist super performant - bin super zufrieden

Fazit: Ich finde VIS top. Kann aber kniffelig sein die richtigen Einstellungen zu finden bzw. die Probleme zu indentifizieren. Wenn das aber alles klappt ist die Performance und useability meiner Meinung nach die beste Option für ioBroker.

[UncleSam]

@architect0711 sagte in Empfehlungen für zuverlässige Darstellung auf Tablets?:

wobei ich nicht glaube, dass es daran liegen kann. (ip und port habe ich mal abgeändert)

Und genau der Port wäre super interessant gewesen. Kannst du uns den verraten?

Ich nehme mal @AlCalzone auch noch in den Thread, da er sehr viel an der Socket Library gearbeitet hat.

[Architect0711]

@unclesam hatte den Port 8084 genommen. Sorry für die späte Antwort, ich war eine Weile nicht zuhause.

Also, um ein paar mehr Informationen zu providen:

Ich kriege eine Verbindung, wenn ich aus dem example Ordner in dem ioBroker.socketio Github repo die conn.js in mein Projekt nehme und die <script> Tags aus der index.html in meine index.html einfüge. Dann verbindet sich die conn.js mit dem Server und loggt fröhlich irgendwelche States in die Konsole.

Aber das will ich doch gar nicht. Ich will einen Service in einer TypeScript Klasse haben (z.b. IoBrokerService), der sich mit dem Server verbindet und den ich dann als Singleton Service in meine ganzen Komponenten injecten kann und mich auf gewisse Topics subscriben kann. Dafür ist die Library doch da, oder nicht? Wie benutzt du die Bibliothek denn in deiner Angular Anwendung?

Ich habe das gerade mal geprüft und das conn.js Skript stellt die Verbindung zum iobroker auch her, wenn ich gar kein Connection objekt instanziere.

Die Parameter für das Connection objekt sind auch etwas anders als die, die in der conn.js für das servConn objekt übergeben werden. In allen Beispielen wird immer direkt die conn.js in vanilla javascript verwendet. Wofür die TypeScript library überhaupt da ist, habe ich bis jetzt nicht verstanden.

Ich bleibe auf jeden Fall dran, bin mal gespannt, was dabei raus kommt