FHEMWEB und Modul 74_Unifi "Connection lost, trying a reconnect every 5 seconds"

[hoppel118]

Hallo Leute,

ich nutze seit mittlerweile fast 3 Jahren FHEM, bin super zufrieden und werde langsam süchtig.

Ich nutze folgendes Netzwerk-Equipment von Ubiquiti Unifi

• Unifi Controller im Docker Container v5.6.40LTS
• 1x Unifi Security Gateway
• 2x Unifi Switch US 8 150W
• 3x Unifi UAP AC Pro

Ich behaupte, dass mein Server die Performance bringt, die FHEM benötigt, um vernünftig betrieben werden zu können, siehe Signatur. Bitte nicht falsch verstehen, ich bin eigentlich das Gegenteil von eingebildet.

Problematik

Kürzlich habe ich nun also das Modul "74_Unifi" in Betrieb genommen. Allerdings erhalte ich immer zum Interval (bei mir 30 Sekunden) der Device-Definition im FHEM WebInterface die folgende Meldung:

"Connection lost, trying a reconnect every 5 seconds".

Ich habe meine Problematik dann im Unifi Thread beschrieben. Dirk (alias Wuehler, der Modul Entwickler) hat mit mir ein paar Sachen analysiert. Am Ende habe ich dann eher zufällig herausgefunden, dass die Meldung ausschließlich auftritt, wenn ich mich in dem room "Netzwerk" befinde, in dem auch die Unifi-Devices definiert sind. Gehe ich in irgendeinen anderen room, bspw. "Schlafzimmer", erscheint die Meldung nicht.

Ansonsten habe ich das Modul seit gestern Abend in Betrieb, die Readings werden aktualisiert. Es gab auch sonst keine Performance-Probleme mit anderem Equipment. Meine CPU dümpelt meistens im einstelligen Bereich vor sich hin. Auch das Unifi-Modul lastet meinen Server nicht aus.

Weitere Vorgehensweise

Dirk bat mich hier in diesem Forenbereich einen eigenen Thread für dieses Thema zu öffnen, da er davon ausgeht, dass die Problematik mit FHEMWEB zusammenhängt. Zitat:

Ich habe als Vermutung, dass es daran liegt, dass das Unifi-Modul viele http-requests absetzt und daher FhemWeb keine Ressourcen für sein Polling hat.
Da auch das Modul freezemon Unifi als mögliche Quelle für freezes anzeigt wäre das ein weiterer Hinweis das Design des Unifi-Moduls zu überdenken.
Wäre schön, wenn wir das mit FhemWeb klären könnten.

Hier der entsprechende Unifi-Modul-Thread: https://forum.fhem.de/index.php/topic,40287.msg878200.html#msg878200


Was braucht ihr nun, um dem Thema auf die Schliche zu kommen?

Ich bin für alle Schandtaten bereit.

Danke und Gruß Hoppel

[Wuehler]

Moin,

Danke Hoppel, klinke mich hier ein, um am Ball zu bleiben und mitzubekommen, ob/was am Unifi-Modul ggf. geändert werden muss.

Laut Hoppel kommt die Meldung in FhemWeb immer dann, wenn das Unifi-Modul die Informationen aus dem Unifi-Controller ausliest. In diesem "Moment" werden 7 Non-Blocking-Http-Request abgesetzt.
Seltsam finde ich, dass es nur in diesem einen Raum auftritt. Das passt irgendwie nicht zu meiner Vermutung.

VG,
Dirk

[hoppel118]

Moinsen,

welche Logs soll ich bereitstellen, FHEMWEB und Unifi gleichzeitig oder einzeln auf verbose 5 oder sogar global verbose 5?

Gruß Hoppel

[hoppel118]

*** Doppelpost, bitte löschen ***

[rudolfkoenig]

welche Logs soll ich bereitstellen

Fuer die letzten 5 Sekunden vor der Reconnect Meldung:
- Daten aus der JavaScript-Konsole des Browsers
- ein "attr global verbose 5" Mitschnitt von FHEM.
Sonst: Definition der FHEMWEB Instanz, und Name des Browsers.

[hoppel118]

Hallo,

danke erstmal für die Unterstützung!

und Name des Browsers.

Das hat mich gerade auf eine Idee gebracht. Hauptsächlich betrachte ich mein FHEMWEB an meinem PC (Windows 10) über Chrome. Irgendwann war Firefox einfach nur noch langsam und ich habe mich von Firefox abgewendet. Internet Explorer und/oder Edge habe ich nie wirklich genutzt. Ansonsten bediene ich FHEM über eine Homebridge per App oder Sprache.

Ich habe nun alle möglichen anderen OS und Browser mit folgendem Ergebnis getestet:

1. PC

• OS: Windows 10 64 Bit (up-to-date)
• Java: Version 8 Update 191 (Build 1.8.0_191-b12)
• Browser: Microsoft Edge 42.17134.1.0 --> Problem besteht
• Browser: Firefox Quantum (64Bit) 64.0 --> LÄUFT!!!
• Browser: Google Chrome 71.0.3578.98 (Offizieller Build) (64-Bit) --> Problem besteht

2. MacBook Pro

• OS: macOS Mojave (up-to-date)
• Browser: Safari 12.0.2 (14606.3.4) --> LÄUFT!!!
• Browser: Firefox Quantum (64Bit) 64.0 --> LÄUFT!!!

3. iPhone 8

• OS: iOS (up-to-date)
• Browser: Safari up-to-date --> LÄUFT!!!
• Browser: Firefox Quantum up-to-date --> LÄUFT!!!
• Browser: Google Chrome up-to-date --> LÄUFT!!!

Sorry, ich bin leider vorher nicht auf die Idee gekommen, es einfach mal einem anderen Gerät/Browser zu testen.

Mit Firefox hätte ich nun also einen Browser für alle meine Rechner bzw. Smartphones, bei dem es dieses Problem nicht gibt. Anscheinend hat sich beim Firefox in letzter Zeit einiges geändert. Die Resonanz im Internet zum neuen Firefox ist gar nicht so schlecht. Gibt es für FHEM so etwas wie einen empfohlenen oder nicht empfohlenen Browser?


Dennoch möchte ich gern dabei unterstützen, das Problem auch für Chrome und evtl. Edge zu lösen bzw. zumindest herauszufinden, wo das Problem liegt. Hier also alle Informationen, die ich liefern kann:

Fuer die letzten 5 Sekunden vor der Reconnect Meldung:
- Daten aus der JavaScript-Konsole des Browsers

Wie mache ich das?

- ein "attr global verbose 5" Mitschnitt von FHEM.

Um 16:51:02 wurden die Readings im Unifi Modul aktualisiert. Hier das Logfile:

https://pastebin.com/dSLF1LS1

Sonst: Definition der FHEMWEB Instanz

Code Auswählen Erweitern

define WEB FHEMWEB 8083 global
attr WEB HTTPS 1
attr WEB csrfToken none
attr WEB defaultRoom Thermostate
attr WEB editConfig 1
attr WEB group Beleuchtung,Lampen,Lichter,Strom,Sensoren,Thermostate
attr WEB iconPath fhemSVG:openautomation:default
attr WEB roomIcons Save.config:message_attention Aussen:temp_outside Badezimmer:scene_shower Büro:it_pc Flur:scene_stairs Küche:scene_cooking Schlafzimmer:scene_making_love_clean Wohnzimmer:scene_livingroom Dachboden:it_server Lampen:li$
attr WEB sortRooms Aussen Badezimmer Büro Flur Küche Schlafzimmer Wohnzimmer Dachboden
attr WEB sslVersion TLSv12:!SSLv2
attr WEB stylesheetPrefix dark
#attr WEB verbose 5
define allowed_WEB allowed
attr allowed_WEB basicAuth SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
attr allowed_WEB validFor WEB

Wenn ihr mir nun sagt, vergiss das Problem und verwende Firefox, dann kann das für mich eine Lösung sein. Bin gerade am Überlegen mal wieder einen Browserschwenk zu machen. Ob, das auf meinen Apple Devices Sinn macht, weiß ich noch nicht.

Danke für eure Unterstützung und viele Grüße Hoppel

[Wuehler]

Zitat von: rudolfkoenig am Heute um 10:43:42
Fuer die letzten 5 Sekunden vor der Reconnect Meldung:
- Daten aus der JavaScript-Konsole des Browsers

Wie mache ich das?

Die Entwicklertools des Browsers öffnen und dort dann die console. In Chrome müsste Ctrl+Shift+J funktionieren.

[hoppel118]

OK, mit global verbose 3 sehe ich dort schon Fehler:

22:29:45.572 FW_queryValue:{ReadingsVal("UnifiController","blockClient","")}
fhemweb.js:492 22:29:45.576 FW_queryValue:{AttrVal("UnifiController","room","")}
fhemweb.js:492 22:29:45.668 Inform-channel opened (websocket) with filter UnifiController
fhemweb.js:492 22:29:45.702 Rcvd:
fhemweb.js:1183 WebSocket connection to 'wss://10.11.11.11:8083/fhem?XHR=1&inform=type=status;filter=UnifiController;since=1546205382;fmt=JSON&fw_id=399&timestamp=1546205385667' failed: Invalid frame header
FW_longpoll @ fhemweb.js:1183
fhemweb.js:492 22:30:04.412 ERRMSG:Connection lost, trying a reconnect every 5 seconds.<
fhemweb.js:492 22:30:09.314 ERRMSG:<
fhemweb.js:492 22:30:09.416 Inform-channel opened (websocket) with filter UnifiController
fhemweb.js:492 22:30:09.455 Rcvd: ["UnifiController","connected","<div id=\u0022UnifiController\u0022  title=\u0022connected\u0022 class=\u0022col2\u0022>connected</d...(137)
fhemweb.js:1183 WebSocket connection to 'wss://10.11.11.11:8083/fhem?XHR=1&inform=type=status;filter=UnifiController;since=1546205382.1769998;fmt=JSON&fw_id=399&timestamp=1546205409415' failed: Invalid frame header
FW_longpoll @ fhemweb.js:1183
fhemweb.js:492 22:30:34.701 ERRMSG:Connection lost, trying a reconnect every 5 seconds.<
fhemweb.js:492 22:30:39.603 ERRMSG:<
fhemweb.js:492 22:30:39.705 Inform-channel opened (websocket) with filter UnifiController
fhemweb.js:492 22:30:39.746 Rcvd: ["UnifiController","connected","<div id=\u0022UnifiController\u0022  title=\u0022connected\u0022 class=\u0022col2\u0022>connected</d...(137)
fhemweb.js:1183 WebSocket connection to 'wss://10.11.11.11:8083/fhem?XHR=1&inform=type=status;filter=UnifiController;since=1546205405.9299998;fmt=JSON&fw_id=399&timestamp=1546205439704' failed: Invalid frame header
FW_longpoll @ fhemweb.js:1183
fhemweb.js:492 22:31:04.988 ERRMSG:Connection lost, trying a reconnect every 5 seconds.<
fhemweb.js:492 22:31:09.890 ERRMSG:<
fhemweb.js:492 22:31:09.991 Inform-channel opened (websocket) with filter UnifiController
fhemweb.js:492 22:31:10.023 Rcvd: ["UnifiController","connected","<div id=\u0022UnifiController\u0022  title=\u0022connected\u0022 class=\u0022col2\u0022>connected</d...(137)

Ich mach das Ganze dann gleich nochmal mit einem global verbose 5.

Gruß

[rudolfkoenig]

Ich tippe auf dem Virenscanner als Verursacher, die sind fuer sowas bekannt.

fhemweb.js:1183 WebSocket connection to '...' failed: Invalid frame header

Hier waeren die Websocket-frame-header Details insteressant, siehe https://kaazing.com/inspecting-websocket-traffic-with-chrome-developer-tools/
Kannst du bitte "attr WEB longpoll 1" auch testen? Verwendet die alte HTTP-longpoll Methode statt websocket.

Gibt es für FHEM so etwas wie einen empfohlenen oder nicht empfohlenen Browser?

Ich versuche alle zu unterstuetzen, es sei denn Dinosaurier wie IE machen extra viel Arbeit.

- Daten aus der JavaScript-Konsole des Browsers

Linux/Windows: Shift-Ctrl-i, OSX: Alt-Cmd-i, IE/Edge:F12 (wenn ich mich recht erinnere)
Es gibt dafuer ueberall auch einen Menueeintrag, Sinngemaess: Entwicklertools, Javascript-Console.

[hoppel118]

Ob verbose 3 oder 5 ist egal, es sind dieselben Meldungen. Somit brauche ich auch das Log nicht nochmal neu machen.

Im Firefox sieht das Ganze viel besser aus. Hier gibt es diesen "Websocket connection Fehler" nicht:

22:43:32.167 FW_queryValue:{ReadingsVal("UnifiController","blockClient","")} fhemweb.js:492:5
22:43:32.174 FW_queryValue:{AttrVal("UnifiController","room","")} fhemweb.js:492:5
22:43:32.257 Inform-channel opened (HTTP) with filter UnifiController fhemweb.js:492:5
22:43:32.263 Rcvd: fhemweb.js:492:5
22:43:50.637 Rcvd: ["UnifiController","connected","<div id=\u0022UnifiController\u0022  title=\u0022connected\u0022 class=\u0022col2\u0022>connected</d...(137) fhemweb.js:492:5
22:43:50.642 Rcvd: ["UnifiController--UC_speed_ping","0","0"] fhemweb.js:492:5
...
...

Braucht ihr noch irgendwas?

Danke und Gruß Hoppel

[hoppel118]

Ich tippe auf dem Virenscanner als Verursacher, die sind fuer sowas bekannt.

Ich habe keine speziellen Virenscanner im Einsatz. Auf meinem Windows PC ist es der Default "Viren- und Bedrohungsschutz".

Hier waeren die Websocket-frame-header Details insteressant, siehe https://kaazing.com/inspecting-websocket-traffic-with-chrome-developer-tools/

Damit muss ich mich beschäftigen. Das sieht erstmal komplex aus, wenn man keine Ahnung hat, was das ist.

Kannst du bitte "attr WEB longpoll 1" auch testen? Verwendet die alte HTTP-longpoll Methode statt websocket.

Jo, das funktioniert. Sobald ich das gesetzt habe, sehen die Meldungen im Chrome genauso ausführlich und fehlerfrei aus, wie im Firefox.

Ich versuche alle zu unterstuetzen, es sei denn Dinosaurier wie IE machen extra viel Arbeit.

Linux/Windows: Shift-Ctrl-i, OSX: Alt-Cmd-i, IE/Edge:F12 (wenn ich mich recht erinnere)
Es gibt dafuer ueberall auch einen Menueeintrag, Sinngemaess: Entwicklertools, Javascript-Console.

Aha, gut zu wissen. Danke!

Wie gehen wir jetzt weiter vor? Soll ich das mit den "Websocket-frame-header Details" noch machen? Oder ist das "attr WEB longpoll 1" nun die Lösung?

Wenn euch das weiter bringt, mache ich das aber gerne noch.

Gruß Hoppel

[rudolfkoenig]

Wie gehen wir jetzt weiter vor? Soll ich das mit den "Websocket-frame-header Details" noch machen? Oder ist das "attr WEB longpoll 1" nun die Lösung?

Websocket debuggen wird auch fuer mich Arbeit sein, und bis dato hat sich keiner sonst beschwert. Allerdings koennten wir das fuer die Zukunft vermeiden.
Wie du willst, entscheide Du.

[hoppel118]

Hier waeren die Websocket-frame-header Details insteressant, siehe https://kaazing.com/inspecting-websocket-traffic-with-chrome-developer-tools/

OK, war doch nicht so komplex. Ich habe das "attr WEB longpoll 1" für diesen Test nochmal deaktiviert.

Hier das Ergebnis im "Headers"-Tab:

General
  Request URL: wss://10.11.11.11:8083/fhem?XHR=1&inform=type=status;filter=UnifiController;since=1546208354.684;fmt=JSON&fw_id=326&timestamp=1546208389334
  Request Method: GET
  Status Code: 101 Switching Protocols
Response Headers
  Connection: Upgrade
  Sec-WebSocket-Accept: PMX8zKY2++4+ml53+J5udG9Dumg=
  Upgrade: websocket
Request Headers
  Accept-Encoding: gzip, deflate, br
  Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7
  Authorization: Basic YWRtaW46TWlob2F1Zzgy
  Cache-Control: no-cache
  Connection: Upgrade
  Cookie: X-OPENMEDIAVAULT-LOGIN-%242y%2410%242loOZ2p.snzH94EJKc6PreQfM2cbhbay2Kf30n2uZaS1AcC3W48xW=The+beginning+of+knowledge+is+the+discovery+of+something+we+do+not+understand.; X-OPENMEDIAVAULT-LOCALE=de_DE; X-OPENMEDIAVAULT-LOGIN-%242y%2410%24zDasAVz5Vorsx9rEmEyMoOhUvnTpSaWaR8HSFxnwT5Jht7DODh3xm=Fear+is+the+mind-killer.; XSRF-TOKEN=eyJpdiI6ImMyVmVwK0R5ZUR1SWY2UXZaY3hVZGc9PSIsInZhbHVlIjoiV2FXcjJVSndvcytoOVBVNlh1aDhETGxCcVU0NWwwOCswdWpQZkFtbkU3OTh5S3E3ZVVOSlpwakRIU2NkeGNzeCIsIm1hYyI6IjZlN2JjNjU5NzUwMTc1MzJlMDdlM2ZiNTBhYWE3NTYzMWY2NmU4MzY4ZmZjYmE0MjVmMDc5YTI3MjM3N2Q3ODcifQ%3D%3D; heimdall_session=eyJpdiI6IndYOVwvTGRaenJBRWtSTTVSZUVNbEtnPT0iLCJ2YWx1ZSI6IkxrcnppK1dJdDdQWDE3dTFUXC9cL1pyZGV0c1VlNW9OenVGVysra3VYVkxFa2tyemxyNDRlV0l4NlpCdWhGVjlQdSIsIm1hYyI6IjQxYWQ5ZDA0ZGExYWI2ZDAxMjdkMGU0ZDY0Yzg3N2JhMzhmMDhjMmY3MTM3YTRhMzRiY2JjYzcwMmQzOWQwNDYifQ%3D%3D
  Host: 10.11.11.11:8083
  Origin: https://10.11.11.11:8083
  Pragma: no-cache
  Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
  Sec-WebSocket-Key: ha7Lr0ngLY/Ipeg/E2tH5Q==
  Sec-WebSocket-Version: 13
  Upgrade: websocket
  User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Query Strin Parameters
  XHR: 1
  inform: type=status;filter=UnifiController;since=1546208354.684;fmt=JSON
  fw_id: 326
  timestamp: 1546208389334

Hier das Ergebnis im "Frames"-Tab:

["UnifiController","connected","<div id=\u0022UnifiController\u0022 title=\u0022connected\u0022 class=\u0022col2\u0022>connected</div>"]   138   23:19:49.368
(Opcode -1)   20   23:20:14.612

Ist das das, was ihr braucht? Was braucht ihr noch?

Gruß Hoppel

[hoppel118]

Websocket debuggen wird auch fuer mich Arbeit sein, und bis dato hat sich keiner sonst beschwert. Allerdings koennten wir das fuer die Zukunft vermeiden.
Wie du willst, entscheide Du.

OK, meinetwegen gern. Wenn man damit in der Zukunft Fehler bei anderen vermeiden kann, spart das auch bei euch Entwicklern etwas Zeit und ihr könnt euch um andere evtl. spannendere Themen kümmern. Ich bin gerade in der Thematik drin, nicht ganz auf den Kopf gefallen und habe mittlerweile einiges an Erfahrung in FHEM gesammelt. Wahrscheinlich bin ich nicht der schlechteste Tester.  

Dirk sprach eigentlich mal davon, das Unifi Modul ggf. zu aktualisieren. Siehst du hier keine Notwendigkeit mehr?

Gruß Hoppel

[rudolfkoenig]

Ist das das, was ihr braucht? Was braucht ihr noch?

Einen dicken roten Pfeil auf die Zeile, die laut Chrome falsch sein soll, mit Beschreibung, wie es richtig ist.

Kannst du mir bitte bei der funktionierenden Version aus der JavaScript-Konsole alle Daten, die nach dem Aufruf der Problemseite protokolliert werden, hier anhaengen?
Evtl. sind in den Daten Sonderzeichen, die FHEMWEB in der Websocket Version escapen sollte.

[hoppel118]

Einen dicken roten Pfeil auf die Zeile, die laut Chrome falsch sein soll, mit Beschreibung, wie es richtig ist.

OK, wenn es weiter nichts ist... Sag das doch gleich. Ich will eigentlich nur testen, ob ihr den Fehler findet.

Kannst du mir bitte bei der funktionierenden Version aus der JavaScript-Konsole alle Daten, die nach dem Aufruf der Problemseite protokolliert werden, hier anhaengen?

Gern! Wo ich das gerade sehe, wenn ich die Entwicklerkonsole in Firefox auf der Startseite meines FHEMWEBs aktiviere, sehe ich bereits folgenden Fehler:

Code Auswählen Erweitern

InvalidStateError: A mutation operation was attempted on a database that did not allow mutations.
  transaction resource://gre/modules/IndexedDB.jsm:349:39
  objectStore resource://gre/modules/IndexedDB.jsm:377:23
  getStore resource://normandy/lib/AddonStudies.jsm:82:10
  getAll resource://normandy/lib/AddonStudies.jsm:204:12
  InterpretGeneratorResume self-hosted:1255:8
  next self-hosted:1210:9

Sollten wir das deiner Ansicht nach auch noch analysieren?

1. FHEMWEB room "Netzwerk" über Firefox ohne "attr WEB longpoll 1"

https://pastebin.com/FPjkWiSK

2. FHEMWEB room "Netzwerk" über Chrome ohne "attr WEB longpoll 1"

...der Vollständigkeit halber, auch wenn du das eigentlich nicht haben wolltest.

https://pastebin.com/qtKx1Snn

3. FHEMWEB room "Netzwerk" über Chrome mit "attr WEB longpoll 1"

https://pastebin.com/nLzZHung

Evtl. sind in den Daten Sonderzeichen, die FHEMWEB in der Websocket Version escapen sollte.

Hm..., evtl. ist das Fehler. Ich habe 3 Netzwerke (VLANs) mit entsprechenden WLANs (SSIDs) eingerichtet bzw. in Betrieb.

• Gallien
• Gallien-IoT
• Gallien-Gäste

Immer wenn es in den Logs oben um das Gäste-WLAN geht, steht dort "Gallien-G_ste" statt "Gallien-Gäste".

EDIT: Evtl. schaffe ich es morgen, testweise das Gäste-WLAN und -VLAN umzubenennen, so dass keine Sonderzeichen mehr enthalten sind. Eine wirkliche Lösung ist das aber auch nicht, da ich sicher nicht der einzige bin, der sein Gaeste-WLAN, Gäste-WLAN nennt.

Wenn du noch irgendwas brauchst, gib mir einfach Bescheid.

Wie dem auch sei... Das war mein letzter Post für dieses Jahr! Ich wünsche dir/euch einen guten Rutsch ins neue Jahr! Feiert schön und bis bald!


Danke für die tatkräftige Unterstützung das Problem zu lösen.

Viele Grüße Hoppel

[hoppel118]

Musste den Beitrag gerade nochmal editieren. So viele Zeichen hat der Post nicht zu gelassen bzw. einfach abgeschnitten. Habe die entsprechenden Logs nun bei Pastebin hochgeladen und hier verlinkt.

Viele Grüße Hoppel

[rudolfkoenig]

Ich habe die Daten durchgelesen, und mir ist nichts aufgefallen.
Dann habe ich aus den Daten defines/setreadings gebaut und auf einem aktuellen Chrome nachgestellt: kein Fehler.
Auch mit Umlauten in Readings gibt es keine Probleme, sofern alles brav utf8 kodiert wird.
=> Keine Idee.

Habe die entsprechenden Logs nun bei Pastebin hochgeladen und hier verlinkt.

Bitte demnaechst hier direkt anhaengen, siehe beim Beitrag Verfassen den Punkt Erweiterte Optionen, Datei anhaengen.

[hoppel118]

Hm... spannend...

Danke für die investierte Zeit. Kannst du mir nochmal bestätigen, dass du genau diese Version des Browsers im Einsatz hast: "Google Chrome 71.0.3578.98 (Offizieller Build) (64-Bit)"?

Eigenartig ist, dass ich dieses Problem nur mit Chrome und Edge ohne "attr WEB longpoll 1" auf dem Windows Rechner habe.

- Kann es sein, dass utf8 mein Problem auslöst ("Gallien-G_ste" statt "Gallien-Gäste" in der Entwicklerkonsole)?
- Wie kann ich prüfen, ob bei mir alles utf8 kodiert wird?

Ich werde mein Gäste-WLAN auf jeden Fall nochmal umbenennen und prüfen, ob es dann in den beiden Browsern funktioniert.

- Fällt dir noch irgendwas ein, was ich noch testen könnte, um das Problem in Chrome/Edge auf meinem Windows Rechner zu lösen?

Genügend funktionierende Alternativen habe ich ja nun.


@Dirk: Siehst du noch etwas, was ich/wir unbedingt noch testen sollten?

Vielen Dank und einen guten Start ins neue Jahr!

Gruß Hoppel

[Wuehler]

Frohes neues Jahr,

Mir geben die Logs leider auch keine Hinweise.
Ganz am Anfang hatte Rudi nochmal was zum Virenscanner geschrieben. Hast du den mal deaktiviert?

VG,
Dirk

[weihnachtsmann]

Happy New Beer und tolles Modul @WUEHLER !

Ich hatte das Modul einige Zeit super am Laufen und gestern noch mal neu nutzen/einrichten wollen. Dabei stellte ich fest, dass die connect/disconnect events im Sekundentakt erfolgen. Logpoll oder Browser sind dabei egal. Das Modul verbindet zu Controller 192.168.1.205:8443 und disconnected dann wieder. Man sieht es auch in der Admin Console des Unifiy Event Logs. Habe auch mal ein einfaches Passwort für den user erfolglos benutzt, um Escaping von Sonderzeichen als Fehler zu isolieren. Im Moment tippe ich auf Versionsänderung des Unifi Controller Web Frontends. Vielleicht im TLS Handshake? Gruss!

[Wuehler]

Lieber guter Weihnachtsmann 

das sieht mir dann nach einem anderen Problem aus, als in diesem Thread diskutiert. Hier ging es um FHemWeb. Bitte poste daher im Unifi-Thread die folgenden Infos:
- kurze Beschreibung des Problems
- Version des Unifi-Moduls
- Version des Unifi-Controllers
- Logauszug mit verbose=5 wenn der Fehler passiert
- Die Definition deines Unifi-Moduls (list Unifi)

[weihnachtsmann]

Uups. Bin wohl etwas überarbeitet nach den Feiertagen. Mach ich!
Schönes 2019!

[hoppel118]

Moinsen,

nachdem ich nun mein Problem mit meiner Homebridge einigermaßen im Griff habe, beschäftige ich mich jetzt hiermit nochmal.

OK, bevor es losgeht, erstmal "attr FHEMWEB longoll" deaktivieren.

Ganz am Anfang hatte Rudi nochmal was zum Virenscanner geschrieben. Hast du den mal deaktiviert?

Wie bereits erwähnt, nutze ich keine spezielle Antivirus-Software. Ich verwende lediglich den Microsoft hauseigenen "Viren- und Bedrohungsschutz". Diesen habe ich testweise gerade mal komplett deaktiviert, siehe Screenshot. Die Meldung bleibt bestehen, daran liegt es also nicht.

Als nächstes habe ich im Controller geprüft, was passiert, wenn ich mein WLAN mit der SSID "Gallien-Gäste" umbenenne in "Gallien-Gaeste".

Dann einmal kurz den Browser-Cache in Chrome gelöscht, Chrome neugestartet, im FHEM-WebUI in den Raum Netzwerk gewechselt und "BÄM!!!". Da haben wir die Problemursache. So taucht die Meldung nicht mehr auf.

@Dirk: Kannst du das mal bitte bei dir nachstellen?

Bleibt die Frage, warum das Problem mit dem Umlaut in der SSID (bzw. im Reading "Gallien-G_ste") nur mit Edge und Chrome auf einem Windows 10 PC besteht und ob ihr mit dieser Erkenntnis noch was am Modul bzw. an FHEMWEB verändern wollt?

Ich stünde für weitere Tests gern zur Verfügung.

Ich habe meinem Gäste-WLAN und dem zugrunde liegenden (V)LAN nun die englische Bezeichnung "Gallien-Guests" gegeben. Damit ist das Problem erstmal behoben, ohne dass ich longpoll benötige.

Kannst du bitte "attr WEB longpoll 1" auch testen? Verwendet die alte HTTP-longpoll Methode statt websocket.

Was ist denn eigentlich der Unterschied zwischen der alten HTTP-longpoll Methode und Websocket? Gibt es da signifikante Performance-Unterschiede?

Viele Grüße Hoppel

[Wuehler]

Hallo Hoppel,

ich habe mir die Chrome-Version von dir installiert und bekomme keine Meldung. An welcher Stelle wurde das ä eigentlich ersetzt? Im ReadingName oder im ReadingValue?
Das WLAN tauch ggf. mehrfach als ReadingValue auf. Und einmal im ReadingName -WLAN_<ssid>_state.
Beim Erzeugen des ReadingName wird die FHEM-Funktion makeGoodReadingName() verwendet. Diese ersetzt alle Sonderzeichen durch Unterstriche. Habe ich leider vorher nicht dran gedacht. Erst als ich mir testweise einen dummy angelegt habe und bei diesem mit setReading ein Sonderzeichen als Readingname setzen wollte. Es kam eine entsprechende Fehlermeldung von FHEM, dass Sonderzeichen im ReadingName nicht funktionieren.

Mein FHEMWEB longpoll steht dabei auf websocket.

Gruß,
Dirk

[hoppel118]

ich habe mir die Chrome-Version von dir installiert und bekomme keine Meldung. An welcher Stelle wurde das ä eigentlich ersetzt? Im ReadingName oder im ReadingValue?
Das WLAN tauch ggf. mehrfach als ReadingValue auf. Und einmal im ReadingName -WLAN_<ssid>_state.
Beim Erzeugen des ReadingName wird die FHEM-Funktion makeGoodReadingName() verwendet. Diese ersetzt alle Sonderzeichen durch Unterstriche. Habe ich leider vorher nicht dran gedacht. Erst als ich mir testweise einen dummy angelegt habe und bei diesem mit setReading ein Sonderzeichen als Readingname setzen wollte. Es kam eine entsprechende Fehlermeldung von FHEM, dass Sonderzeichen im ReadingName nicht funktionieren.

Ich finde den "_" an folgenden Stellen, habe gerade nochmal alles wieder rückgängig gemacht:

Code Auswählen Erweitern

-AP_wap-base_essid   Gallien-IoT,Gallien-G_ste,Gallien,Gallien-IoT,Gallien-G_ste,Gallien   2019-01-14 17:39:37
-AP_wap-kittchen_essid   Gallien-IoT,Gallien-G_ste,Gallien,Gallien-IoT,Gallien-G_ste,Gallien   2019-01-14 17:41:09
-AP_wap-office_essid   Gallien-IoT,Gallien-G_ste,Gallien,Gallien-IoT,Gallien-G_ste,Gallien   2019-01-14 17:42:10
-WLAN_Gallien-G_ste_state   enabled   2019-01-13 15:01:33

Zusätzlich dann wohl auch bei dem ReadingValue der Endgeräte "<unifi-alias>_essid".

Mein FHEMWEB longpoll steht dabei auf websocket.

Wenn ich das "attr WEB longpoll websocket" konfiguriere, besteht der beschriebene Fehler, bei "attr WEB longpoll 1" nicht. Außerdem besteht der Fehler, wenn das "attr WEB longpoll ..." gar nicht in der fhem.cfg enthalten ist. Ich gehe davon aus, dass das "websocket" per default gesetzt ist.

Was ist denn eigentlich der Unterschied zwischen der alten HTTP-longpoll Methode und Websocket? Gibt es da signifikante Performance-Unterschiede?

@rudolfkoenig: Hat sich erledigt. Google ist mein Freund:

https://forum.fhem.de/index.php?topic=59713.0
https://de.wikipedia.org/wiki/WebSocket

Gruß Hoppel

[rudolfkoenig]

Ich gehe davon, dass das "websocket" per default gesetzt ist.

Websocket ist default bei Chrome, weil er in bestimmten Faellen mit longpoll Probleme hat.
Da aber websocket nicht sauber von allen Browsern unterstuetzt wird (z.Bsp. kann Safari per Websocket keine Passwoerter uebertragen), ist es nur da die Voreinstellung.

Was ist denn eigentlich der Unterschied zwischen der alten HTTP-longpoll Methode und Websocket?

Es gibt einen Bedarf, Browser-Clients von Server zu benachrichtigen (neudeutsch push), wofuer HTTP _eigentlich_ nicht vorgesehen ist, da es ein Frage-Antwort Mechanismus implementiert. Wenn der Server aber nicht sofort antwortet (sondern erst dann, wenn Daten da sind), und der Client nicht zu ungeduldig ist, dann kann man per HTTP push doch realisieren, das nennt man longpoll. Der Haken: die Daten im Client wachsen immer an, und man muss die Verbindung erneut oeffnen, damit man den alten Puffer los wird.

Irgendwann sind die Standardisierungsleute aufgewacht, und haben websocket spezifiziert.
Jetzt kann der Benutzer es aussuchen, welcher der Methoden wo nicht funktioniert.

Gibt es da signifikante Performance-Unterschiede?

Nicht in unserem Fall.

[hoppel118]

Danke für die Erläuterung! Jetzt habe ich es auch verstanden.

[hoppel118]

Websocket ist default bei Chrome, weil er in bestimmten Faellen mit longpoll Probleme hat.
Da aber websocket nicht sauber von allen Browsern unterstuetzt wird (z.Bsp. kann Safari per Websocket keine Passwoerter uebertragen), ist es nur da die Voreinstellung.

Moinsen,

ich muss das Thema nun doch nochmal stressen.

Das Unifi-Modul wird wie folgt definiert:

Code Auswählen Erweitern

define UnifiController Unifi localhost 8443 <user> <password> <intervall> <site>

Ich habe mein WLAN umbenannt und seither gibt es, wenn ich "attr WEB longpoll websocket" setzte, keine Probleme mit Chrome, Edge und Firefox. Allerdings ist mir gerade aufgefallen, dass Safari nun komplett spinnt. Dort sehe ich die Meldung "Connection lost, trying a reconnect every 5 seconds" dauerhaft. FHEM reagiert aber ganz normal.

@Rudolf: Das hängt dann wahrscheinlich mit der Passwort-Thematik zusammen, oder?

Am Mac möchte ich gern bei Safari bleiben. Sobald ich longpoll komplett deaktiviere, funktioniert es auf allen Browsern, auch auf Safari.

@Dirk: Kann man das Passwort evtl. irgendwie anders übergeben?

Das ganze hat keine Prio, da ich ohne longpoll eine auf allen Browsern lauffähige Lösung habe.


EDIT: Habe gerade folgenden Beitrag in dem Thread unter meinem entdeckt: https://forum.fhem.de/index.php/topic,76983.msg890794.html#msg890794

Ich habe mein FHEM gerade aktualisiert. Deine Anpassung verändert an dem Verhalten von Safari nichts.

Danke euch und Gruß

[Wuehler]

Hallo Hoppel,

das Passwort des UnifiControllers kann ich mir nicht als Problem vorstellen. In Rudis Kommentar ging es denke ich um ein htaccess Passwort oder ähnliches. Im Modul wird das ja nur informatorisch und verschlüsselt in FhemWeb angezeigt.
Würde eher das Umalaute-Problem verfolgen. Auch wenn ch es bei mir nicht nachstellen kann.

Viele Grüße,
Dirk

[hoppel118]

Hallo Dirk,

Danke erstmal für die schnelle Rückmeldung.

Das Umlaute-Problem habe ich ja gelöst, indem ich das WLAN (und das dahinter liegende VLAN) umbenannt habe in ,,Gallien-Guests". Da kann ich jetzt so nichts mehr weiter verfolgen.

Hm..., ok, mal sehen, was Rudolf dazu sagt. Aber wie gesagt, ohne longpoll funktioniert es auf allen Browsern, wie es soll. Von daher bin ich da entspannt.

Viele Grüße Hoppel

[hoppel118]

Auch wenn ch es bei mir nicht nachstellen kann.

Bei mir tritt das Problem mit Chrome und Edge unter Windows 10 sofort auf, wenn longpoll websocket (default) gesetzt ist. Hattest du den Browser Cache geleert? Das musste ich, wenn ich mich recht entsinne, machen, damit die Readings nach der Umstellung der WLAN-Bezeichnung auch die Werte enthielten.

Evtl. hängt das auch mit der Controller Version zusammen. Da ich viel im Home-Office arbeite, bleibe ich aber lieber bei der LTS-Version.

Gruß Hoppel