FHEM extrem träge mit Chrome 64

Begonnen von fhemfrederik, 26 Januar 2018, 07:02:01

Vorheriges Thema - Nächstes Thema

isy

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.


Ein Weg wird erst zu einem Weg, wenn man ihn geht

fhemfrederik

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

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

Benni

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

@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

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

Gruß
Markus

Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

heikoh81

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

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

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

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.

trs

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




rudolfkoenig


trs


rudolfkoenig

Gerne. Einfach meine Beitraege lesen.

trs

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.