Browser Performance mit VIS stark beansprucht
-
Und mal von Hand auf eine andere Webseite gewechselt und dann wieder vis aufgerufen?
Auch da könnte man was automatisches basteln.
Gesendet von meinem SM-G900F mit Tapatalk
-
Nein, noch nicht. Bin zwar kein Anfänger bzgl. SW-Entwicklung, aber ein absoluter Laie bzgl. Javascript. Kannst Du mir eventuell mit einem Sample-Code auf die Sprünge helfen? `
Probiere bitte erstmal mit den Schaltern im Browser , ob das was bringt.Gesendet von meinem SM-G900F mit Tapatalk
-
Die Performance ist bei mir auch jux nach einem der Updates wieder schlecht geworden. Kurz nach meinem letzten Eintrag hier.
Habe beobachtet das vom Tablet Befehle recht zügig gesendet werden. Hingegen aber nicht empfangen werden.
Also iobroker -> Tablet = langsam.
Tablet -> iobroker = okay.
Hat aber nix mit dem wlan zu tun.
-
Jetzt wo Du es sagst fällt mir auf, das ich diese Beobachtung genauso bestätigen kann!
Gibt es mal wieder ein Performanceproblem mit VIS und löse ich dann einen Schaltvorgang aus, dann wird dieser auch umgehend ausgeführt. Die Rückmeldung erfolgt aber extrem verzögert.
Somit kann es eigentlich nicht daran liegen, das das Tablet/Browser generell ausgelastet ist, denn sonst müsste ja auch der "Hinweg" entsprechend verlangsamt sein. Es muss meiner Meinung nach daher an einem Kommunikationsproblem in der Richtung IOBroker => VIS liegen.
@Bluefox: Irgendeine Idee? Wie können wir beim Debuggen helfen? Das muss doch in den Griff zu bekommen sein!
-
Habe beobachtet das vom Tablet Befehle recht zügig gesendet werden. Hingegen aber nicht empfangen werden. `
Genau das habe ich auch beobachtet. Wenn ich einen Knopf auf dem iPad drücke (z.B. ein Bulp on/off Widget), kommt die Aktion direkt im ioBroker bzw. in der CCU an. Aber der dadurch geänderte Status wird nicht aktualisiert! Ich kann auch wieder zurückschalten.Das SVG Uhren Widget zeigt aber korrekt die Zeit!
-
Habe beobachtet das vom Tablet Befehle recht zügig gesendet werden. Hingegen aber nicht empfangen werden. `
Genau das habe ich auch beobachtet. Wenn ich einen Knopf auf dem iPad drücke (z.B. ein Bulp on/off Widget), kommt die Aktion direkt im ioBroker bzw. in der CCU an. Aber der dadurch geänderte Status wird nicht aktualisiert! Ich kann auch wieder zurückschalten.Das SVG Uhren Widget zeigt aber korrekt die Zeit! `
Das gleiche Problem habe ich seit dem letzten Update auch [PERSEVERING FACE] -
Nach den letzten Beschreibungen kann ich jetzt so etwas ähnliches reproduzieren.
Vielleicht meinen wir auch alle das selbe.
Bedienung am Tablet ok:
Lampe schaltet sofort, Zustand wird auch sofort aktualisiert.
Bedienung am lokalen Taster:
Änderung wird jedoch nicht am Tablet angezeigt
Gruß
Rainer
-
Lampe schaltet sofort, Zustand wird auch sofort aktualisiert. `
Nein, bei mir wird der Zustand am Tablet nicht aktualisiert, es wird nur geschaltet.
-
Bei mir ist es wie von flugwelle beschrieben.
-
Bei mir ist es wie von flugwelle beschrieben. `
Dann sind es zumindest schon zwei. (+@fitti)Ich habe mal die Probe aufs Exempel gemacht. PC angeschaltet - vis geöffnet.
Dann habe ich mich mit dem Tablet daneben gestellt und geschaltet.
Auf PC und Tablet sofortige Änderung mit dem Licht zusammen.
Lichtschalter manuell getastet. ca. 3 sec. Verzögerung an Tablet und PC, diese beiden aber synchron.
Tablet über WLAN - allerdings keine 2m vom Repeater und PC sowie RasPi3 mit ioBroker und RasPi3 mit YAHM über LAN.
Auf meinen beiden RasPis läuft nichts anderes.
Wie sehen eure Konfigurationen aus?
Gruß
Rainer
-
Weshalb 2? Wenn ich richtig zähle: mindestens flugwelle+fitti+ich
Meine Konfiguration: Iobroker läuft unter Ubuntu 16.04-Server auf einer VM unter Proxmox, welche auf einem Intelsystem läuft. Auf selbigem Sytem läuft in einer separaten VM (derzeit aber deaktiviert) CCU.IO/DashUI. Für Homematic selbst kommt eine CCU2 zum Einsatz.
Zur Bedienung per VIS kommen 2iPad1, 1Samsung Tab4 8.0 und 1*China-Android Handy zum Einsatz. Alle Geräte natürlich per WLAN angebunden. Manche weiter weg als andere vom Router.
Bei allen treten die Probleme auf. Mal dauert es länger, mal kürzer.
-
mindestens flugwelle+fitti+ich `
@Homoran:schon zwei. (+@fitti) `
sehe ich keinen unterschied
Zur Bedienung per VIS kommen 2iPad1, 1Samsung Tab4 8.0 und 1*China-Android Handy zum Einsatz. Alle Geräte natürlich per WLAN angebunden. `
Dann fangen wir mal hier an:
@mule:Manche weiter weg als andere vom Router.
… Mal dauert es länger, mal kürzer. `
Auch wenn fitti das WLAN ausschliesst - gibt es da eine Korrelation (Weiter =länger)?oder hier
@mule:2iPad1, 1Samsung Tab4 8.0 und 1*China-Android Handy `
gibt es da eine Korrelation (iOS langsam, Android schneller)? oder Android 4 schnell, und 5 langsam?Hier könnte der verd… Stromsparwahn eine Rolle spielen.
Gruß
Rainer
-
Wie sehen eure Konfigurationen aus? `
ioBroker auf raspi3 (LAN).
iPad (WLAN) mit mit vis im Safari (dauerhaft offen). iPad wird über Bewegungsmelder an/aus geschaltet.
Wenn die Seite mit vis neu geöffnet wurde (bzw. über das Javascript neu geladen ist), dann reagiert alles instant: Light Bulp Widget, ein Tap schaltet bzw. setzt ioBroker Objekt, neuer Zustand wird sofort visualisiert.
Nach längerer Zeit funktioniert das nicht mehr. Ein Tap schaltet weiterhin sofort, aber es erfolgt keine Visualisierung des neuen Zustands.
Ich habe den Verdacht, das dies nur passiert, nachdem das iPad länger aus war und beim Einschalten die komplette Ansicht aktualisiert wird.
Gruß,
Rudi
-
Mit dem "länger aus" kann es nicht zusammenhängen, da alle meine aufgezählten Devices permanent laufen und alle Lockscreens und Stromsparmodis deaktiviert sind. Betrieb also 24/7.
Was bei mir aber ab und zu mal auftritt ist ein VIS-Reconnect. Da dies aber nur selten auftritt und es hierüber meiner Kenntnis nach kein Log gibt, kann ich leider keinen direkten Zusammenhang zwischen Reconnect und den Problemen herstellen. Ist nur ein Bauchgefühl.
-
nachdem das iPad länger aus war und beim Einschalten die komplette Ansicht aktualisiert wird. `
Das sind genau meine beiden Verdächtigen.
Apple treibt es mit dem Stromsparen auf die Spitze, und nach längerem Aus wird komplett nachgeladen, sonst evtl. der Cache oder wasauchimmer verwendet.
Neuere Android-Versionen gehen in die gleiche Richtung.
Mit dem "länger aus" kann es nicht zusammenhängen, da alle meine aufgezählten Devices permanent laufen `
eben, nach länger aus ist es wieder ok!Gruß
Rainer
-
Ich hatte flugwelle genau anders herum verstanden, das das Problem bei ihm erst nach längerem Aus auftritt. Eventuell habe ich das aber falsch verstanden.
Falls es an den Stromsparmodi liegt, dann wäre die Frage inwieweit die Kommunikation zwischen CCU.IO und IObroker geändert wurde, denn bei CCU.IO tritt das Problem ja nicht auf?
-
Ich hatte flugwelle genau anders herum verstanden, das das Problem bei ihm erst nach längerem Aus auftritt. `
Genau so habe ich das gemeint. Vielleicht ist es auch Zufall.
Fakt ist, dass ich seit heute morgen so einen Zustand nicht wieder provozieren konnte. Auch wenn das iPad mal so lange aus war, dass die Ansicht insgesamt neu aufgebaut wurde.
-
Apple treibt es mit dem Stromsparen auf die Spitze, und nach längerem Aus wird komplett nachgeladen, sonst evtl. der Cache oder wasauchimmer verwendet. `
Das leuchtet mir nicht wirklich ein. Das iPad hängt permanent am Strom - also kein Grund irgendwas zu sparen.
Und ein komplettes neu laden (so dass "Connecting to server …" erscheint) behebt das Problem auch immer.
-
Bei mir habe ich WLAN ausgeschlossen, da…:
Wenn der Fehler vorliegt, ist ja der Browser extrem unter Last - obwohl sichtbar gar nichts passiert. Und das passiert auch dann auf dem PC. Da hier deutlich mehr Hardwareleistung normalerweise vorliegt, fällt es nur später auf.
Deshalb schließe ich auch die Stromsparfunktion aus.
Ich konnte den Fehler immer mehr provozieren, wenn ich mehr Bindings verwendete. Zur Zeit nehme ich keine mehr und baue mir meine Webseiten auf ioBroker zusammen. Das spart eine Menge performance. (ich habe es jedoch auch nicht mehr heute getestet).
Bei mir läuft ioBroker auf einem Odibroker C2 zur Zeit mit 2GB RAM und eMMC Nand-Speicher. LAN-Verbunden.
Seit 2 Tagen läuft im Moment aber alles super.
Fitti
-
Also ich war nun zwei Tage unterwegs und das iPad war die Zeit über im Ruhezustand (d.h. aus). Als ich heute wieder da war habe ich gleich einen Test gemacht - siehe da: alles funktioniert noch. Allein die länge Zeit ist es also nicht …
Gruß,
Rudi
