WebUI hängt nach Anmeldung einige Sekunden

[KoMa1978]

Describe the issue you are experiencing

Hallo zusammen,

seit ein paar Versionen habe ich das Phänomen, das nach der Authentifizierung der WebUI für ca 20-30s "hängt".

Danach ist alles gut und auch wenn ich auf die Startseite klicke, ist alles gut. Man kann es sehr gut testen, indem man mit der Maus auf die Schaltflächen oben fährt, ist alles OK, klappen die Drop Downs auf. Hängt die WebUI, klappen sie nicht auf.

Wenn ich im Browser ein Refresh mache, passiert das ganze ebenfalls, das System hängt.

Was kann ich hier tun, um das zu vermeiden, bzw. was kann ich an Debugs/Tests liefern, um das Phänomen zu beseitigen?

Describe the behavior you expected

System sollte nicht hängen.

Steps to reproduce the issue

Login in die WebUI oder Refresh im Browser

What is the version this bug report is based on?

3.77.6.20240720

Which base platform are you running?

rpi3 (RaspberryPi3, ARM64/aarch64)

Which HomeMatic/homematicIP radio module are you using?

HmIP-RFUSB

Anything in the logs that might be useful for us?

In /var/log/lighttpd-access.log sind sehr viele POST Zugriffe auf /api/homematic.cgi zu sehen:

[10/Sep/2024:16:45:28 +0200] "POST /api/homematic.cgi HTTP/2.0" 200 59 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36"
[10/Sep/2024:16:45:28 +0200] "POST /api/homematic.cgi HTTP/2.0" 200 46 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36"
[10/Sep/2024:16:45:29 +0200] "POST /api/homematic.cgi HTTP/2.0" 200 59 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36"
[10/Sep/2024:16:45:29 +0200] "POST /api/homematic.cgi HTTP/2.0" 200 46 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36"
[10/Sep/2024:16:45:29 +0200] "POST /api/homematic.cgi HTTP/2.0" 200 59 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36"
[10/Sep/2024:16:45:29 +0200] "POST /api/homematic.cgi HTTP/2.0" 200 46 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36"
[10/Sep/2024:16:45:29 +0200] "POST /api/homematic.cgi HTTP/2.0" 200 59 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36"
[10/Sep/2024:16:45:30 +0200] "POST /api/homematic.cgi HTTP/2.0" 200 2364 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36"
[10/Sep/2024:16:45:30 +0200] "POST /esp/system.htm?sid=@6mgbXmm7TH@&action=UpdateUI HTTP/2.0" 200 867 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36"
[10/Sep/2024:16:45:30 +0200] "POST /api/homematic.cgi HTTP/2.0" 200 45 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36"
[10/Sep/2024:16:45:30 +0200] "POST /api/homematic.cgi HTTP/2.0" 200 2733 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36"

Additional information

Ähnliches wie aus den Logs oben sehe ich auch in den Developer Tools von Chrome. Viele Zugriffe auf /api/homematic.cgi mit wenig Datenübertragung:

Irgendwann "fängt" er sich wieder und es werden mehr Daten übertragen und die WebUI kann wieder genutzt werden:

Der erste Payload scheint ein "Event.poll" zu sein, dann kommt ein "Interface.ListDevices" und "BidCoS_RF.getConfigurationRF" und jetzt hängt er während immer im Wechsel ein "Interface.getMasterValue" und "Interface.setMetadata" für diverse Objekte kommt. Am Schluß kommt ein "Room.getAll" und die WebUI reagiert wieder:

[Baxxy13]

Das Thema ist ja schon eine Weile im Forum präsent, Ursache aber bisher unklar.
WebUI hängt nach Anmeldung ein paar Sekunden
Zumindest trifft es original CCU3 und RM wohl gleichermaßen.

Ich selbst sehe das hier auf keinem meiner Testsysteme, das "schwächste" ist ein Pi3B+.

Leg doch mal einen neuen User an und log dich mit dem ein. Der hat ja erstmal keine SysVars oder Favoriten so das man ggf. das Problem eingrenzen kann.

[jens-maus]

Das Thema ist ja schon eine Weile im Forum präsent, Ursache aber bisher unklar. WebUI hängt nach Anmeldung ein paar Sekunden Zumindest trifft es original CCU3 und RM wohl gleichermaßen.

Ich selbst sehe das hier auf keinem meiner Testsysteme, das "schwächste" ist ein Pi3B+.

Ich selbst sehe das hier auch auf meinem eigenen produktiven System. Dort loggt man sich ein und dann dauert es einige Sekunden (definitiv keine 20-30s) bis man mit der Maus die Menüstruktur oder ähnliches auswählen und somit "weitermachen" kann. Erste eigene Analysen haben nichts auffälliges gezeigt. Und da die CCU3 selbst auch betroffen ist kann es gut sein das es einfach am HMIPServer bzw. an der Abfrage des selbigen liegt. Beim initialen einloggen werden ja alle Geräte, usw. abgefragt und das kann natürlich mitunter dauern. Eine Lösung hab ich nicht wirklich parat und leider auch aktuell keinen Ansatz das ordentlich zu debuggen und kann nur sagen das es wohl auch mit der Gesamtanzahl der Geräte/Kanäle zusammenhängt.

[KoMa1978]

@jens-maus
OK, die 20-30s sind gefühlt gewesen ;-) Ich hab eben mal gestoppt und es sind so ca. 12-15s ;-)
Bei mir tritt es auch beim Browser Refresh auf, es ist also nicht nur nach dem ersten Login.

Und ja, es ist zum Glück nur nervig, ich habe noch keine wirkliche Einschränkung gesehen.

[Baxxy13]

Hmm, die Geräteanzahl könnte eine Rolle spielen.
Da kann ich schlecht mitreden weil alle meine Testsysteme eher klein sind.
Aber selbst das Hauptsystem mit 40 Geräten (38 IP / 2 HM) zeigt das Phänomen nicht.

Wenn ich das Einloggen auf dem Pi3B+ mit dem Firefox-Profiler mitschneide sehe ich teils Zeiten von max. 3,5s, also nichts außergewöhnliches.

[grmpf72]

Ich habe dasselbe Problem (entspricht exakt der obigen Beschreibung) - allerdings nicht auf RM sondern auf HM Original und CCU3. Installation ist recht umfangreich mit HMIPW und HMIP.

UND! WICHTIG!: Die Installation besteht seit 5 Jahren und ist recht statisch. Der Fehler tritt aber erst seit wenigen Monaten auf! Seit irgendeiner 3.7.x-Version.

[grmpf72]

Ich habe gerade eben auf meinem eigenen System die RM (auf PI3B+ mit RFUSB) 3.77.7 vom 26.8. eingespielt - und schwupp: Jetzt ist die Wartezeit auch dort angekommen!
Vorher (ohne Wartezeit): 3.75.7.20240601

[jens-maus]

Ich habe gerade eben auf meinem eigenen System die RM (auf PI3B+ mit RFUSB) 3.77.7 vom 26.8. eingespielt - und schwupp: Jetzt ist die Wartezeit auch dort angekommen!

Und von welcher Version kamst du wo das nicht aufgetreten ist? Diese wichtige Info fehlt.

[grmpf72]

Vorher (ohne Wartezeit): 3.75.7.20240601

[KoMa1978]

Das deckt sich ja auch mit meiner Erfahrung, dass es "seit ein paar Releases" auftritt und nicht erst seit dem letzten Release.

Edit: Wobei ich mir da nicht 100% sicher bin. ich bin auf der 3.77.6.20240720 und bin der Meinung, dass es schon mindestens seit 2 Releases auftritt, also müsste es mit 3.75.7.20240601 oder 3.75.7.20240420 angefangen haben.

[jens-maus]

Im Umkehrschluss bedeutet das aber – da es ja auch unter einer CCU3 auftritt – das es nicht nur hochwahrscheinlich am closed-sourceHMIPServer liegt, sondern das von RaspberryMatic-Seite aus wir daran dann nichts ändern können.

[grmpf72]

So sehe ich es auch. Aber was kann unsereins schon bei elv ausrichten?! Da kommen doch eh immer dieselben, stereotypen Antworten! Hilfe ist da kaum zu erwarten.
Noch mal ein paar Details:

• Ich habe im System vorher länger nix gemacht
• Der Update erfolgte über eine neue SDcard weil die alte laut Ansage im Update-Prozess recht langsam war
• Nach dem Update, beim ersten Anmelden stand die "Sanduhr" für ca. 10-15 Seiten auf der ansonsten leeren WebUI!
• Danach wie oben geschildert...

[KoMa1978]

Dazu kommt, dass vermutlich nur ein Service Request von jemandem eröffnet werden kann, der das Problem auch mit einer CCU3 und originaler FW hat.

[github-actions]

@KoMa1978, the issue you reported cannot be solved within this project or should be better directly solved in the upstream OCCU project RaspberryMatic is just using. However, for being able to reference and track this upstream issue we will keep this ticket open for the time being so that you can also reference it accordingly.

[Baxxy13]

Vorher (ohne Wartezeit): 3.75.7.20240601
also müsste es mit 3.75.7.20240601 oder 3.75.7.20240420 angefangen haben

Wäre schon gut wenn ihr euch einig werdet und mal definitiv sagen könnt ab welcher Version das auftrat.
Relevant ist primär die eQ-3 Versionierung (3.xx.yy) da es ja auch im Original auftritt. So könnte man gezielt gucken ob, und wenn ja was, da was von eQ-3 verändert wurde

Die ganzen homematic.cgi - Aufrufe gehen ja auf die HomeMatic JSON API. (http://192.168.1.1/api/homematic.cgi)
Kann man gut mit 'Postman' bedienen und somit extern testen ohne sich laufend aus/einloggen zu müssen.

Nen Zusammenhang zum HmIP-Server sehe ich erstmal nicht.

Auf meinem Pi3B+ - Testsystem dauert am längsten Device.listAllDetail mit etwa 800ms. Aber das hat sehr wenige Geräte.

[grmpf72]

Ab 3.75.7 oder 3.77.6 - da bin ich mir relativ sicher

[Baxxy13]

Sei dir noch sicherer. 😉
Downgrade und teste!

Ich habe das Problem nicht, kann also nicht direkt mitspielen.

Ich kann auch nur empfehlen das so zu analysieren wie @KoMa1978 im Eingangspost.
Also Dev-Konsole im Browser, Netzwerk, Aufzeichnung starten und dann den "Anmelden - Butten" drücken.
Wenn das System dann bedienbar ist die Aufzeichnung stoppen.
Dann kann man schön sehen was gemacht wurde und wie lange das dauerte.
Wir brauchen ja erstmal nen konkreten Anhaltspunkt wo es denn "laggt".

Bei den homematic.cgi Aufrufen kann man dann bei "Nutzlast" sehen welche Methode aufgerufen wurde und bei Timing die gesamte Verarbeitungsdauer dieses einen Methodenaufrufs.

Die Abfrage ob ich kein Experte bin (User.isNoExpert) dauerte hier übrigens ~ 150ms. 😁

[grmpf72]

Also Dev-Konsole im Browser, Netzwerk, Aufzeichnung starten und dann den "Anmelden - Butten" drücken.
Wenn das System dann bedienbar ist die Aufzeichnung stoppen.
Dann kann man schön sehen was gemacht wurde und wie lange das dauerte.

Steht alles im Forum! Link oben.
Meine 2 Testsysteme haben nur 2-3 Geräte. Da tritt das nicht auf. Ich bin mir mittlerweile gaaanz sicher, dass das mit der Anzahl KANÄLE zusammenhängt. Die Anlage mit den meisten Kanälen (3xDRI32, 5xDRS8 etc.) dauert am längsten! Danach kommt meine eigene und am "schnellsten" ist mit so um die 5 Sekunden eine reine Rollladen und tw. Heizungssteuerung.

Die Abfrage ob ich kein Experte bin (User.isNoExpert) dauerte hier übrigens ~ 150ms

Wie war die Antwort?? ;-)

[Baxxy13]

Steht alles im Forum! Link oben.

Ja ich kenn den Thread, habe ihn ja selber verlinkt. (dein Link geht nicht)
Man sieht die homematic.cgi - Aufrufe, aber leider nicht was da wirklich dahinter steckt.
Speziell der Aufruf (die Methode) mit der Schildkröte wäre interessant.

Wie war die Antwort?? ;-)

{"version": "1.1","result": false,"error": null}
😎

[grmpf72]

Wenn ihr mir etwas detailierter sagt, was genau ich tun soll, dann probier ich das auch.
Aber ich kann nur ANSI 74 COBOL und folgende oder IBM Assembler/370...

Ab 3.75.7 oder 3.77.6 - da bin ich mir relativ sicher

Das ist schlecht formuliert! Ich meine Ab NACH 3.75.7.... Ich weiß nicht, was da alles noch zwischen war.

[Baxxy13]

Im Grunde genommen muss man erstmal die gesamte Verarbeitungszeit aller Aktionen beim Einloggen in einem A/B Vergleich untersuchen.

Also die letzte "gute Version" flashen und analysieren, danach die erste "schlechte Version".
Mal als Beispiel:

[grmpf72]

Also ich sagte ja schon, dass ich keine Testsysteme habe und nicht vor- und zurückflashen will. Das ist mir zu riskant!

Aber ich habe mal ein bisserl im Firefox Profiler gestöbert (unter Netzwerk) und da ist mir folgendes aufgefallen. Vielleicht sagt es was aus; vielleicht auch nicht...

[Baxxy13]

Firefox dröselt die Aufrufe leider nicht so detailliert auf wie die Dev-Console von "Chromium-based-Browsern", siehst du ja selber.
Man sieht nicht welche Methode da so lange braucht.

Und ohne A/B Vergleich kommt man eh nicht weiter.
Wenn sich also niemand findet der das akribisch analysiert um das Problem festzunageln (oder ihr schafft es eQ-3 einzuspannen) dann wird man sich wohl damit abfinden müssen.

[jens-maus]

Ich hab nun einmal selbst nochmal danach geschaut und auch die Chrome Developer Umgebung mal aktiviert und Profiling betrieben. Probiert mal bitte die folgenden Zeilen in der /www/webui/webui.js auszukommentieren. Bei mir bringt das eine merkliche Beschleunigung des ganzen:

https://github.com/eq-3/occu/blob/c7b28663068518996ebeebfd9c60c8edad66e5f3/WebUI/www/webui/webui.js#L10310-L10315

Meiner Erinnerung nach sind das auch Sachen die in der Tat erst in den letzten Versionen einzug gehalten haben und das langsame Reagieren nach dem Login erklären könnte. Wenn das bei euch auch ohne diese Zeilen besser klappt müsste man mal schauen wie man das beschleunigt bekommt bzw. was da der root-cause ist.

[jens-maus]

Ok, noch mehr neue Erkenntnisse nachdem ich die besagte Stelle in der webui.js mit der aktuellsten Version (3.79.1) im OCCU verglichen habe. Dort ist die folgende Änderung gegenüber der 3.77.7 vorgenommen worden:

Diese Änderung habe ich gerade mal kurzerhand auf meine produktive 3.77.7 angewendet und was soll ich sagen? Nun ist der Loginprozess genauso flott wie wenn dieser ganze Bereich auskommentiert ist.

Daher mal die bitte hier in die Runde bitte die besagten Zeilen in der webui.js auch gegen die aus der webui.js aus der Betaversion der 3.79.1 zu ersetzen (oder aber kurzerhand auf das aktuelle 3.79.1 nightly build zu updaten) um zu schauen ob damit dann wieder alles schnell ist. Wenn ja, war wohl eQ3 hier bereits tätig und hat das Problem bereits selbst erkannt und beseitigt.

[grmpf72]

Wäre es eine Möglichkeit die Test-webui.js hier zum Download einzustellen? Ich komm gerade nicht damit klar, was ich wo austauschen soll. Die Zeilen 10292ff sehen bei meiner webui ganz anders aus (notepad++)

[jens-maus]

Wäre es eine Möglichkeit die Test-webui.js hier zum Download einzustellen? Ich komm gerade nicht damit klar, was ich wo austauschen soll. Die Zeilen 10292ff sehen bei meiner webui ganz anders aus (notepad++)

Installier dir doch einfach den aktuellsten 3.79.1 nightly snapshot und teste damit (siehe https://github.com/jens-maus/RaspberryMatic/releases/snapshots)

[grmpf72]

Naja - ich wollte die webui.js im Live-System ersetzen weil ich ja nur da den Hänger habe...
Im Testsystem würde ich es nicht merken!

[jens-maus]

Na du sollst ja auch im Live-System das Update zur 3.79.1 nightly machen und damit testen... Soviel Mut muss sein! ;-)

[grmpf72]

Niemals!!!! In 12 Jahren HM habe ich schon soviel Sch... erlebt dass ich mir das nicht antue!

[jens-maus]

Niemals!!!! In 12 Jahren HM habe ich schon soviel Sch... erlebt dass ich mir das nicht antue!

Dann musst du zwangsläufig warten bis 3.79.1 draussen ist oder dich fortbilden wie man die webui.js entsprechend direkt unter RaspberryMatic patcht und keinen download auf windows und wieder upload auf RM macht und damit potentiell mehr kaputt macht als man gewinnen will.... Wer nicht wagt, der nicht gewinnt...

[Baxxy13]

Man kann sich bei einem laufenden System nicht an den Zeilennummern aus der OCCU orientieren weil sich die durch die ganzen RM-Patches verschieben.

Einfach den Abschnitt suchen und dann ersetzen.

[KoMa1978]

Ich bin schon mal happy, dass das Problem (vermutlich) gefunden und schon beseitigt ist. Was das patchen angeht, ja ist ein wenig aufwändiger, auch mit dem RO Dateisystem, ich warte und teste, sobald das Release raus ist.

[grmpf72]

Ich bin geduldig und warte dann mal auf die offizielle 3.79.x! Danke an alle "Macher"!

[jens-maus]

So, nachdem ich die 3.79.x nightly snapshots nun selbst mal mit meiner produktiven Umgebung testen konnte, kann ich bestätigen das damit das hier geschilderte Problem wohl von eQ3 selbst beseitigt wurde und das hängen der WebUI beim Anmelden nicht mehr auftritt. Ergo kann hier zugemacht werden.

[grmpf72]

So, nachdem ich die 3.79.x nightly snapshots nun selbst mal mit meiner produktiven Umgebung testen konnte, kann ich bestätigen das damit das hier geschilderte Problem wohl von eQ3 selbst beseitigt wurde und das hängen der WebUI beim Anmelden nicht mehr auftritt. Ergo kann hier zugemacht werden.

Habe jetzt auch getestet und kann bestätigen dass bei 3.79.1 v. 14.9. der Fehler nicht auftritt.