FHEM extrem träge mit Chrome 64

fhemfrederik · 26 Januar 2018, 07:02:01

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

KernSani · 26 Januar 2018, 07:20:07

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.

fhemfrederik · 26 Januar 2018, 08:20:14

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)

michaelw · 27 Januar 2018, 14:24:46

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.

michaelw · 28 Januar 2018, 11:24:37

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.

b4r7 · 28 Januar 2018, 22:22:08

Habe das selbe Problem. FHEM Update hat leider auch nicht geholfen.

isy · 28 Januar 2018, 23:18:31

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.

fischit · 28 Januar 2018, 23:26:35

Kann ich leider bei meinen Installationen auch bestätigen.
Andere Browser funktionieren.

Was kann man für Infos liefern um auf Fehlersuche zu gehen?

fhemfrederik · 29 Januar 2018, 07:08:52

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.

rudolfkoenig · 29 Januar 2018, 16:30:17

Wie schaut es nach "attr global longpoll websocket" aus?

FunkOdyssey · 29 Januar 2018, 17:02:34

Zitat von: rudolfkoenig am 29 Januar 2018, 16:30:17
Wie schaut es nach "attr global longpoll websocket" aus?

Du meinst

Code Auswählen

attr WEB longpoll websocket
, oder?

rudolfkoenig · 29 Januar 2018, 17:04:10

Ja, sorry.

FunkOdyssey · 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.

Markus Bloch · 29 Januar 2018, 18:20:54

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

b4r7 · 29 Januar 2018, 19:37:21

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.

isy · 29 Januar 2018, 23:38:24

Bei meinem Android Tablet ist das beschriebene Verhalten mit Chrome 64.0.3282.123 heute wieder da.
Beim Update wird übrigens nichts angezeigt.

Code Auswählen

attr global updateInBackground 1 ist gesetzt

Mit

Code Auswählen

attr WEB longpoll websocket beides gefixt.

fhemfrederik · 30 Januar 2018, 06:55:00

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?

rudolfkoenig · 30 Januar 2018, 22:22:24

Siehst du in FHEM die dazugehoerigen Verbindungen (list TYPE=FHEMWEB)?
Wenn ja, kannst du bitte jeweils ein list von ihnen machen?

Benni · 31 Januar 2018, 05:26:11

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?

Es ist zumindest aktuell noch nicht in der Commandref dokumentiert.

gb#

rudolfkoenig · 31 Januar 2018, 10:28:53

@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.

Markus Bloch · 31 Januar 2018, 10:44:48

Bei mir sieht die Socket-Statistik so aus, wenn Chrome auf verfügbare Sockets für FHEM wartet,

Gruß
Markus

heikoh81 · 09 Februar 2018, 18:17:08

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

Jörg71 · 10 Februar 2018, 12:11:15

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

rudolfkoenig · 10 Februar 2018, 12:38:26

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.

heikoh81 · 12 Februar 2018, 21:30:58

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.

Somit ist das aus meiner Sicht leider auch keine Lösung.

trs · 29 März 2018, 07:07:54

Ich habe jetzt das gleiche Problem Gibt es schon eine Lösung?

rudolfkoenig · 29 März 2018, 07:36:40

Meines Wissens ja.

trs · 29 März 2018, 07:43:05

Ok,

darf ich erfahren, welche?

rudolfkoenig · 29 März 2018, 08:04:55

Gerne. Einfach meine Beitraege lesen.

trs · 29 März 2018, 08:13:40

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.

rudolfkoenig · 29 März 2018, 09:30:58

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.