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

[bahnuhr]

@andersmacher

Das ist m.E. die falsche Entscheidung.
Du wirst schnell feststellen, dass Widgets nicht dargestellt werden (weil die Bibliothek) dazu fehlt.
Auch brauchst du eine 2. web Instanz. Wg. ws Problem.

Aber jeder wie er mag.

[WolfgangFB]

@liv-in-sky sagte in [Umfrage] VIS Ladezeiten:

@wolfgangfb sagte in [Umfrage] VIS Ladezeiten:

Also wenn eine Anwendung 28 Widgets nicht mit einem Gigabyte Ram flüssig darstellen kann ist meiner Meinuing nach sehr resourcenverschwenderisch programmiert worden. Wozu in aller Welt braucht eine Visualisierung derart viel Speicher?

ich dachte, du redest von 27 views ? wo kommen die 28 widgets her - hast du pro view ein widget ? oder habe ich was überlesen

Meine "normale" VIS hat 27 Views, mein Extra Prjekt nur für das schwache Tablet hat eine View mit 28 Widgets.

man kann auch die vis nicht mit einer normalen webseite vergleichen - die widgets machen teilweise viel mehr, als nur mal kurz was anzuzeigen. bei 30 widgets pro view und fast 30 views sind das 900 widgets, die geladen werden und die im hintergrund tüchtig kommunizieren und verwaltet werden müssen - ich finde, das hört sich nach einer menge an, was der browser da zu tun hat

Na ja, wenn ich mir überlege, was vor 30 Jahren mit 400 MHz und 16 MB Ram möglich war empfinde ich 900 Widgets die kommunizieren nicht gerade als viel. Aber so ändern sich die Zeiten...

du solltest auf jeden fall mal mit den entwicklertools von chrome nachsehen, ob da nicht auch noch einige fehler sind

Das Tablet ist ein Firetablet aauf dem Fully Browser läuft.

aber irgendwie sprengt ihr gerade meinen vorstellungshorizont - was macht man mit 27 views oder mehr ? ich habe pro raum eine view in einem project

Pro Raum ein View, das ganze doppelt wegen Mobildarstellung, dann noch Strom, Heizung, Gesamtübersicht, Licht, Multimedia, Temperaturen/Wetter...

[liv-in-sky]

@wolfgangfb sagte in [Umfrage] VIS Ladezeiten:

du solltest auf jeden fall mal mit den entwicklertools von chrome nachsehen, ob da nicht auch noch einige fehler sind

Das Tablet ist ein Firetablet aauf dem Fully Browser läuft.

das macht nix - öffne die view auf dem pc und nutze dort die entwicklertools - vor allem dem tab "konsole" - vielleicht finden sich ladefehler oder timeouts

ich nutze auch ein firetablet 7" mit fully-b. . das lädt jedesmal 5-7 sek, wenn der raum betreten wird, da ich dann erst den bildschirm aktiviere. ansonsten läuft es eigentlich (auch ung. 30 widgets und eine anzeige einer live-cam von der haustür) flüssig.

[WolfgangFB]

@liv-in-sky sagte in [Umfrage] VIS Ladezeiten:

@wolfgangfb sagte in [Umfrage] VIS Ladezeiten:

du solltest auf jeden fall mal mit den entwicklertools von chrome nachsehen, ob da nicht auch noch einige fehler sind

Das Tablet ist ein Firetablet aauf dem Fully Browser läuft.

das macht nix - öffne die view auf dem pc und nutze dort die entwicklertools - vor allem dem tab "konsole" - vielleicht finden sich ladefehler oder timeouts

Da gibt es jede Menge Fehler (Wobei ich erwähnen sollte, dass der PC keinen Internetzugang hat):

Failed to fetch https://spocs.getpocket.com/spocs: NetworkError when attempting to fetch resource. DiscoveryStreamFeed.jsm:284
No response for spocs_endpoint prop DiscoveryStreamFeed.jsm:884
Failed to fetch https://getpocket.cdn.mozilla.net/v3/firefox/global-recs?version=3&consumer_key=40249-e88c401e1b1f2242d9e441c4&locale_lang=de&region=DE&count=30: NetworkError when attempting to fetch resource. DiscoveryStreamFeed.jsm:284
No response for feed DiscoveryStreamFeed.jsm:1221
TypeError: NetworkError when attempting to fetch resource.
browser.engagement.session_time_including_suspend - Attempted to set the scalar to an incompatible value.
Failed to fetch https://spocs.getpocket.com/spocs: NetworkError when attempting to fetch resource. DiscoveryStreamFeed.jsm:284
No response for spocs_endpoint prop DiscoveryStreamFeed.jsm:884
Failed to fetch https://getpocket.cdn.mozilla.net/v3/firefox/global-recs?version=3&consumer_key=40249-e88c401e1b1f2242d9e441c4&locale_lang=de&region=DE&count=30: NetworkError when attempting to fetch resource. DiscoveryStreamFeed.jsm:284
No response for feed DiscoveryStreamFeed.jsm:1221
TypeError: NetworkError when attempting to fetch resource.
browser.engagement.session_time_including_suspend - Attempted to set the scalar to an incompatible value.
Die Webkonsolen-Logging-API (console.log, console.info, console.warn, console.error) wurde von einem Skript auf dieser Seite deaktiviert
TopSitesFeed: Failed to fetch data from Contile server: NetworkError when attempting to fetch resource. TopSitesFeed.jsm:207
Failed to fetch https://spocs.getpocket.com/spocs: NetworkError when attempting to fetch resource. DiscoveryStreamFeed.jsm:284
No response for spocs_endpoint prop DiscoveryStreamFeed.jsm:884
Failed to fetch https://getpocket.cdn.mozilla.net/v3/firefox/global-recs?version=3&consumer_key=40249-e88c401e1b1f2242d9e441c4&locale_lang=de&region=DE&count=30: NetworkError when attempting to fetch resource. DiscoveryStreamFeed.jsm:284
No response for feed DiscoveryStreamFeed.jsm:1221
TypeError: NetworkError when attempting to fetch resource.
browser.engagement.session_time_including_suspend - Attempted to set the scalar to an incompatible value.
XHRGEThttp://192.168.1.203:8082/vis/tplLcarsButtonToggle.ejs

mit Internetzugang sehe ich nichts besonderes im Zusammenhang mit der VIS.

LoginManagerPrompter: Couldn't process supplied URIString: http://192.168.1.119 8 LoginManagerPrompter.jsm:994:16
TopSitesFeed: Failed to fetch data from Contile server: NetworkError when attempting to fetch resource. 11 TopSitesFeed.jsm:208
Der ServiceWorker für den Gültigkeitsbereich 'https://community.home-assistant.io/' wurde wegen Ablauf der Timeout-Frist abgebrochen, obwohl waitUntil/respondWith-Promises ausständige waren. 2
BroadcastService: receivedBroadcastMessage: handler for remote-settings/monitor_changes threw error: Error: Polling for changes failed: NetworkError: Network request failed.
    pollChanges resource://services-settings/remote-settings.js:334
PushBroadcastService.jsm:267
LoginManagerPrompter: Couldn't process supplied URIString: http://192.168.1.119 LoginManagerPrompter.jsm:994:16
Der ServiceWorker für den Gültigkeitsbereich 'https://web.whatsapp.com/' wurde wegen Ablauf der Timeout-Frist abgebrochen, obwohl waitUntil/respondWith-Promises ausständige waren. 2
Structured Ingestion ping failure with error: error 10 PingCentre.jsm:136
    sendStructuredIngestionPing resource:///modules/PingCentre.jsm:136

[liv-in-sky]

@wolfgangfb

sagt mir leider nix - kein einziger eintrag bezügl, VIS

[Homoran]

@wolfgangfb sagte in [Umfrage] VIS Ladezeiten:

900 Widgets die kommunizieren

das ist wahrscheinlich dein Fehler im Denkansatz.
Die Kommunikation ist nicht das Thema. Sondern das ständige Rendern beim Neuaufbau.

[Andersmacher]

@bahnuhr Ich wollte/will nicht "beratungsresistent" erscheinen, daher nur vorsorglich noch einmal mich zum Verständnis:
Die alte VIS gibt es, so wie es verstanden habe, seit einigen Jahren und sie wurde vermutlich pö a pö verbessert. Vor gut 2 Jahren habe ich angefangen, sie zu benutzen und bisher haben mich die von Dir genannten Punkte nicht für mich erkennbar behindert. Bezüglich der Widgets vermute ich, daß es sich um "neuere/anspruchsvollere/schickere" handelt, die nicht dargestellt werden? Offenbar welche, die ich bisher noch nie benutzt habe.

Du wirst schnell feststellen, dass Widgets nicht dargestellt werden (weil die Bibliothek) dazu fehlt.
Auch brauchst du eine 2. web Instanz. Wg. ws Problem.

Natürlich verstehe ich, daß man Dinge immer weiterentwickeln und verbessern kann und das ist auch gut so, daß das geschieht.
Aber wenn diese beiden Punkte tatsächlich ein Problem wären, das "jeden zum sofortigen Umstieg" bewegen sollte/müßte, wie haben dann die (vermutlich vielen 100, 1000 oder wieviele auch immer) Nutzer bis vor wenigen Wochen ioBroker/VIS sinnvoll nutzen können, denn länger gibt es doch die neue App noch gar nicht.

Für die Entwicklung meiner Views benutze ich die neue App auf Grund Deiner Empfehlung ja schon, denn durch den entfallenden Resync spart man dabei viel Zeit.
Und wenn die anderen beiden Probleme (WS und/oder Bibliothek) bei mir irgendwann doch noch auftreten, kann ich ja noch immer komplett auf die neue App umstellen.
Oder vielleicht auch, wenn ich neuere Hardware habe.

Noch´mal Danke für Deine Tipps und Hinweise!

Und genau, wie Du schreibst...jeder wie er mag.:relaxed:

[SHL59]

Moin aus Hamburg,

auch wenn dieser Beitrag schon älter ist, möchte ich hier noch einmal einhaken.
Etwas unklar ist allerdings, ob es um VIS(1) oder VIS-2 geht.

Zu VIS(1) kann ich nur sagen, dass ich mit den Ladezeiten vollkommen zufrieden bin.
Ich nutze die aktuelle ioBrocker-Visu-App auf Mobiltelefon und Tablet mit 17 bzw. 11 Views und einer Vielzahl Daten und Buttons.
Die Werte sind sofort nach dem Öffnen der App in allen Views vorhanden.

Ich schreibe hier, weil ich jetzt das 3. oder 4. Mal den Versuch unternommen habe auf die neue VIS-2 umzusteigen.
Dazu habe ich jeweils meine Projekte aus VIS in die VIS-2 importiert, aber in der VIS-2 noch keine weiteren Anpassungen vorgenommen.

Jede View die nach Start der Visu-App aufgerufen wird, benötigt zwischen 3 und 10 Sekunden (je nach Anzahl der Widgets) bis alle Werte und Bildchen in der Ansicht erscheinen.
Wurden alle Views einmal aufgerufen, und alle Werte sind geladen, kann man zwischen den Views wechseln und die Daten laden dann recht prompt.
Wird die App aber geschlossen und neu gestartet, wartet man wieder genauso lange bis die Anzeigen vollständig sind. Und das nervt gewaltig.
Meine anfängliche Hoffnung, dass das Problem der langen Ladezeiten im Laufe der Weiterentwicklung der VIS-2 behoben sein würde, haben sich also nicht erfüllt.

Mein IoBroker läuft im Container auf QNAP TS 251+ mit 16GB RAM,
Alle Adapter im stable sind aktuell.
Mobile Geräte: IPhone 13 Pro Max und iPad 11. Gen. Von 2025.

Da ich zu Ladezeiten explizit der VIS-2 keine ‚Beschwerden‘ gefunden habe, hoffe ich hier auf Hilfe. Vielleicht hat ja jemand eine Idee.
Vielleicht ist auch das Importieren der Projekte aus der VIS(1) das Problem (?)…
Aber alternativ alles in VIS-2 neu machen???:disappointed:

VG
Stefan

[stenmic]

@shl59
Moin aus Jever :)
mir geht es genauso. VIS1 ist unschlagbar schnell. VIS2 ist das schlimmste was ich je gesehen habe. Eine Schande für ioBroker! Leider, will bloß keiner hören. Und ich hab die Views neu erstellt, am import kann es nicht liegen. Mir tun die Leute leid die auch noch für den Jäger Adapter Euros gezahlt haben.

[MartinP]

@stenmic Seit dem letzten Smartphone - Austausch gegen ein neues Modell ist es etwas besser geworden...

Aber die Bedienung des recht einfachen Garagentoröffner Views ist trotzdem in der Gemengelage von schlechtem WLAN-Empfang draußen, kalten Fingern usw. noch so lahm, dass ich manchmal doch zum Fahrrad hineinstellen erstmal die Tasche reinbringe und drinnen auf den Taster an der Wand drücke ....

[stenmic]

@martinp daran liegt es auch nicht. Der Broker läuft bei mir auf nem fetten NUC und als Devices hab ich iPhones 16 Pro und iPads Pro. Allgemein leidet die Performance bei ioBroker immer mehr bei jedem Update!

[sigi234]

@shl59 sagte in [Umfrage] VIS Ladezeiten:

Aber alternativ alles in VIS-2 neu machen???

Ja :relaxed:

[SHL59]

@sigi234 sagte in [Umfrage] VIS Ladezeiten:

@shl59 sagte in [Umfrage] VIS Ladezeiten:

Aber alternativ alles in VIS-2 neu machen???

Ja :relaxed:

@stenmic sagte in [Umfrage] VIS Ladezeiten:

@shl59
Und ich hab die Views neu erstellt, am import kann es nicht liegen. Mir tun die Leute leid die auch noch für den Jäger Adapter Euros gezahlt haben.

Das nutzt ja wohl auch nichts :confused:

[OliverIO]

@stenmic

react kann schon schnell sein, sofern javascript auf dem client schnell verarbeitet wird und das gerät ausreichend Hauptspeicher hat.

Was nicht gut funktioniert ist, in vis2 alte vis1 widgets weiter zu verwenden, insbesondere dann, wenn man viel mit binding macht.
die vis1 widgets werden unter der haube mit der gleichen vis1 logik ausgeführt, da ist react einfach nur eine weitere zusätzliche verarbeitungsschicht.
wenn man allerdings alles neu mit rein vis2 nativen widgets macht, dürfte es geschwindigkeitsmäßig sogar von vorteil sein.

[sigi234]

@shl59 sagte in [Umfrage] VIS Ladezeiten:

Das nutzt ja wohl auch nichts

Na ja, soweit ich informiert bin werden die Widgets auf vite umgestellt und dadurch wird es schneller.
Abgesehen davon müssen noch viele Issues abgearbeitet werden.

[SHL59]

Also für mich erst einmal gut zu wissen, dass ich nicht allein bin mit dem Problem.
Mit meinen aktuellen Visualisierungen werde ich definitiv bis auf Weiteres bei VIS(1) bleiben.

Wenn ich mal Langeweile habe:upside_down_face: werde ich mal ein paar Views komplett neu in VIS-2 anlegen und schauen, ob sich der Aufwand lohnt.

[MartinP]

@shl59 Ich habe mal einen Versuch gemacht, im Haus bei gutem WLAN ...

Iobroker Vis APP, mein "Türen und Tore" Vis2-View ist der Start-View meines View-Baumes ... Sehr langsamer Celeron N3000... Mittelklasse Samsung A36 5G Smartphone...

Vom Aufruf der Vis App bis zur Darstellung des Start-Views 6 Sekunden.

Wechseln in einen anderen View 3 Sekunden.

Zurückwechseln in den Türen und Tore View 3 Sekunden ...

[SHL59]

@martinp
Ja, ernüchternd.
Wenn man nicht wüsste, dass es auch schneller geht mit VIS(1), müsste man wohl damit leben.
Wie gesagt: bei der VIS(1) gibt es in meinem Fall keinerlei Verzögerung beim Laden der Views. Bilder und Daten werden sofort angezeigt. Bei Neustart der VISU-App beträgt die Wartezeit ca. 1 Sekunde und die View ist mit allen Daten da.

Vielleicht gibt es ja jemanden, der erklären kann, weshalb die Ladezeiten bei der VIS-2 so ungleich viel länger sind.

[OliverIO]

@shl59

folgender Test, jeweils gleicher Client und gleicher Server und mit geleertem cache geladen (in chrome mit STRG + F5)
Die Werte konnten in den Chrome Web Developer Tools im Netzwerk Tab abgelesen werden.

Szenario 1:

Leeres Projekt ohne widgets
vis1:
537kb übers Netz transferiert, 2,2MB entpackt in 1,2 Sekunden
vis2:
4,8MB übers Netz transferiert, 20,4MB entpackt in 2,4 Sekunden

Szenario 2:

3 basic widgets (html,image,string)
vis1:
537kb übers Netz transferiert, 2,2MB entpackt in 1,6 Sekunden
vis2:
4,8MB übers Netz transferiert, 20,4MB entpackt in 2,4 Sekunden

Szenario 3:

3 basic widgets (html,image,string) + zusätzlicher Adapter (rssfeed ohne verknüpften feed
vis1: widget RSS Feed 2
558kb übers Netz transferiert, 2,3MB entpackt in 1,2 Sekunden
vis2: widget RSSFeed Widget
5MB übers Netz transferiert, 21,3MB entpackt in 2,8 Sekunden

Szenario 4:

Wie Szenario 3. Der View wurde gedoppelt und jeweils ein Navigation Button zum anderen View hinzugefügt

Initiales laden
vis1: widget RSS Feed 2
559kb übers Netz transferiert, 2,3MB entpackt in 1,3 Sekunden
vis2: widget RSSFeed Widget
5MB übers Netz transferiert, 21,3MB entpackt in 4,1 Sekunden

View-Wechsel
vis1: widget RSS Feed 2
keine veränderung
vis2: widget RSSFeed Widget
keine veränderung

Wie gesagt, das sind nur die Lade- und Renderzeiten für das erste laden. Wenn die Oberfläche mal läuft, dürften die Zeiten für das aktualisieren von States oder ein view Wechsel viel geringer sein, da ja alles bereits beim ersten mal schon geladen wurde,