Hallo zusammen,
seit ich Chrome 64 nutze ist das Web Frontend extrem träge bzw. lässt sich nicht mehr benutzen. Im Edge Browser ist alles OK.
(Versehentlich unter Homematik veröffentlicht. Kann ich leider nicht mehr ändern. Sorry.)
Viele Grüße
Frederik
Zitat von: fhemfrederik am 26 Januar 2018, 07:02:01
(Versehentlich unter Homematik veröffentlicht. Kann ich leider nicht mehr ändern. Sorry.)
Doch, den Verschieben-Button findest du ganz unten links.
Zitat von: KernSani am 26 Januar 2018, 07:20:07
Doch, den Verschieben-Button findest du ganz unten links.
Danke :)
Problem ist auch behoben. Es war ein simples Update.
(War schon kurz davor die VM zurückzusetzen)
Was hast du denn aktualisiert? Chrome? Fhem? Windows? Bei mir wird FHEM mit der Zeit nämlich unter Chrome und Ubuntu 17.10 nach etwas rumklicken im GUI immer langsamer bis zu dem Punkt das das GUI gar nicht reagiert. Am Anfang ist es noch schnell. Chrome beendet und wieder gestartet löst das Problem nur kurzfristig. Firefox funktioniert gleichzeitig ohne Probleme. Das ist mir erst die letzten 2 oder 3 Tage aufgefallen, dass das passiert.
Wenn ich für FHEMWEB longpoll ausschalte, verschwindet das Problem bei mir mit Chrome. Lösche ich das Attribut wieder, also stelle die Standard-Einstellung wieder her, hängt Chrome wieder nach ein paar Klicks.
Habe das selbe Problem. FHEM Update hat leider auch nicht geholfen.
Hatte gestern auf Android einen ähnlichen Effekt nach Chrome Update.
Über Port 8083 gestartet gab es nach 2 oder 3 Aufrufen keine Ausgabe mehr, Chrome hängt.
Neues Fenster mit Port 8084 läuft wieder kurz, nach ein paar Aufrufen wieder Stillstand.
Nächster Port mit dem gleichen Ergebnis.
Fhem läuft und ist über Telnet erreichbar.
Ebenso im Web über Linux oder PC.
Tablet neu gestartet und Verlauf gelöscht, dann lief alles wieder.
Kann ich leider bei meinen Installationen auch bestätigen.
Andere Browser funktionieren.
Was kann man für Infos liefern um auf Fehlersuche zu gehen?
Zitat von: michaelw am 27 Januar 2018, 14:24:46
Was hast du denn aktualisiert? Chrome? Fhem? Windows?
Ich hatte FHEM aktualisiert. Die Besserung war aber nur von kurzer Dauer. Mit Edge habe ich weiterhin keinerlei Probleme.
Wie schaut es nach "attr global longpoll websocket" aus?
Zitat von: rudolfkoenig am 29 Januar 2018, 16:30:17
Wie schaut es nach "attr global longpoll websocket" aus?
Du meinst
attr WEB longpoll websocket, oder?
Ja, sorry.
Sollte keine Kritik sein. Ich wollte nur darauf hinweisen, dass nicht falsch gesucht wird. :-)
Am Rande:
Es wird bei diesem Thema nicht helfen, aber ich nutze auch Chrome 64 und FHEM über einen ReverseProxy (hier: Nginx) und habe das longpoll-Attribut nicht modifiziert. Ich konnte keine Probleme feststellen.
Hallo zusammen,
bei mir tritt ein ähnliches Problem auf, wo mit dem Chrome 64 das Arbeiten in FHEM schnell erlahmt. Hintergrund ist, dass dem Chrome offenbar die freien Sockets ausgehen. Nach einiger Zeit Arbeiten in FHEM werden offenbar Sockets im Chrome nicht sauber freigegeben und bei einem Reload kommt links unten nur noch "Warten auf verfügbaren Socket".
Ob das jetzt ein Problem in Chrome oder FHEM ist, kann ich nicht sagen. Laut Web-Konsole wird nur ein Socket für Longpoll geöffnet und das wars. Es bleiben mMn keine Sockets hängen. Ich tippe daher auf ein Problem in Chrome selbst.
Gruß
Markus
Zitat von: FunkOdyssey am 29 Januar 2018, 17:08:46
Sollte keine Kritik sein. Ich wollte nur darauf hinweisen, dass nicht falsch gesucht wird. :-)
Am Rande:
Es wird bei diesem Thema nicht helfen, aber ich nutze auch Chrome 64 und FHEM über einen ReverseProxy (hier: Nginx) und habe das longpoll-Attribut nicht modifiziert. Ich konnte keine Probleme feststellen.
Seltsamerweise konnte ich heute so etwas ähnliches beobachten.
Durch einen SSH Tunnel zu einer Linux VM und von dort dann zu meiner FHEM VM auf meiner NAS und mit Chrome 64 konnte ich auch keine Probleme feststellen.
Bei meinem Android Tablet ist das beschriebene Verhalten mit Chrome 64.0.3282.123 heute wieder da.
Beim Update wird übrigens nichts angezeigt. attr global updateInBackground 1 ist gesetzt
Mit attr WEB longpoll websocket beides gefixt.
Ich hatte longpoll auf 1. Mit websocket habe ich keine Probleme mehr.
Hatte das mal wegen Tablet UI umgestellt. Wird zwar das Problem nicht lösen, aber was ist der Unterschied?
Siehst du in FHEM die dazugehoerigen Verbindungen (list TYPE=FHEMWEB)?
Wenn ja, kannst du bitte jeweils ein list von ihnen machen?
Ich bin inzwischen auch davon betroffen (Chrome 64.0.3282.119 (Offizieller Build) (64-Bit)).
Nach einer Umstellung von longpoll auf websocket scheint das Problem erst einmal behoben.
Befindet das websocket-Feature eigentlich immer noch im proof-of-conept Status (https://forum.fhem.de/index.php?topic=59713.0)?
Es ist zumindest aktuell noch nicht in der Commandref (http://commandref.fhem.de/#longpoll) dokumentiert.
gb#
@haus-automatisierung.com: Danke, es reicht.
Offensichtlich macht Chrome64 die longpoll Verbindungen nicht mehr zu, mAn ein Chrome Bug.
Ich habe default fuer Chrome auf websocket umgestellt, war etwas Umbau dafuer notwendig.
@Benni: websocket ist nicht mehr poc (eher default demnaechst), und ich habe es gerade dokumentiert.
Bei mir sieht die Socket-Statistik so aus, wenn Chrome auf verfügbare Sockets für FHEM wartet,
Gruß
Markus
Ich habe gestern seit langem mal wieder ein FHEM-update gemacht.
Jetzt beobachte ich auch so ein träges Verhalten - aber im Gegensatz zu euch verwende ich ein Chromium auf einem Raspberry, der seit schon seit >1 Jahr kein Update mehr bekommen hat. Ich hatte bislang kein "attr. longpoll", aber auch wenn ich es auf "1! setze, zeigt sich keine Veränderung.
Ich schreibe dies, weil es aus meiner Sicht doch auch mit einer Veränderung in fhem zu tun haben könnte. Das Problem tritt sowohl hinter einem Apache Reverse Proxy als auch bei direktem Zugriff auf den :8083 auf.
Was mir auch noch aufgefallen ist:
- es dauert deutlich länger, den Java-Webeditor zu zu laden, und insbesondere deutlich länger, die Änderungen durch Klick auf den Button wieder an FHEM zu senden
- die Buttons zeigen in Chrome kein "Klick-Verhalten" mehr, d.h. sie sind statisch wie Grafiken
- copy- oder rename-Befehle, die ich über die Befehlszeile in fhemweb absetze, dauern deutlich länger als vorher. top auf dem fhem-system zeigt keine sonderliche CPU-Auslastung des Raspi3
Viele Grüße,
Heiko
Hallo,
bei mir ist FHEMWEB jetzt auch und nur mit aktuellem Chrome 64 auf Windows 10 langsam und bleibt manchmal für ein paar Minuten hängen. Das liegt offenbar nicht an FHEM, da das noch auf dem Stand von September 2016 ist und bislang keine Probleme hatte. Das Einschalten von longpoll ändert daran nichts und websocket gab es ja noch nicht. Habe jetzt die Backup SD-Karte in den Raspberry eingesetzt, keine Änderung obwohl damit ja auch alles auf dem Uraltstand ist.
Tschüs,
Jörg
Ich vermute, dass es sich um ein Chrome-Bug handelt, was nur die alte "attr WEB longpoll 1" Variante (das war auch die Voreinstellung) betraf. Ich habe mit meinem Patch die Voreinstellung auf "attr WEB longpoll websocket" gestellt, wenn ich meine Chrome erkannt zu haben. Falls jemand aehnliche Probleme hat, bitte vor einem neuen Beitrag hier im Thread Folgendes pruefen:
- FHEM ist aktuell, und wurde nach dem update neu gestartet
- "attr WEB longpoll" ist entweder nicht gesetzt oder es steht auf websocket.
Im Beitrag bitte die Ausgabe von navigator.userAgent aus der JavaScript-Konsole erwaehnen.
Setze ich
attr WEB longpoll
habe ich aber das Problem hinter einem Apache Reverse Proxy, daß ich wieder die "Connection Lost"-Warnings oben haben.
Auch mit Firefox.
Somit ist das aus meiner Sicht leider auch keine Lösung.
Ich habe jetzt das gleiche Problem Gibt es schon eine Lösung?
Meines Wissens ja.
Ok,
darf ich erfahren, welche?
Gerne. Einfach meine Beitraege lesen.
Das habe ich. Aber leider nicht erkannt, ob es mit "attr WEB longpoll" geht. Oder ob dann wieder Verbindungsfehler gibt:
Setze ich
Code: [Auswählen]
attr WEB longpoll
habe ich aber das Problem hinter einem Apache Reverse Proxy, daß ich wieder die "Connection Lost"-Warnings oben haben.
Auch mit Firefox.
ZitatDas habe ich.
Das war aus der Frage nicht ersichtlich.
- Chrome 64 hat Probleme mit "attr WEB longpoll 1" (die bisherige Voreinstellung), deswegen habe ich bei erkannten Chrome die Voreinstellung auf "attr WEB longpoll websocket" gestellt.
- damit Apache websocket weiterleitet, muss man es explizit konfigurieren, Anleitungen findet man, wenn man nach "apache proxy websocket" sucht.