openhabforum.de

Falls dieses Thema schon existiert bitte ich um einen Hinweis. Ich konnte es trotz Suche nicht finden.

Seit dem Update auf OH 4 habe ich massive Probleme mit dem Zugriff auf die Openhab Steuerung mittels Webbrowser.
Alleine der Seitenaufbau bis zum Login dauert etwa eine Minute. Und auch wenn ich eingeloggt bin geht vieles extrem langsam.
Auch im Openhab plagen mich Ärgernisse wie z.B. eine IP Kamera die dauernd on- und offline geht...

Ich habe bereits vor lauter Verzweifelung ein vorher mal komplett funktionierendes OH-System auf Ubuntu Basis platt gemacht und mit Debian 12 ganz neu aufgesetzt und völlig frisch installiert.
Meine logs (openhab und events) liefern mir keine wirklichen Erkenntnisse zur GUI Nutzung oder diesbezüglichen Problemen. Übersehe ich vielleicht andere wichtige logs (bin ziemlicher Anfänger in diesen Dingen).

Zu meinem System:
OH4 frisch installiert auf einem alten PC mit Debian 12 bookworm (ebenfalls gerade frisch installiert).
Java Version 17 installiert und läuft.
Der OH Server ist im Netzwerk über LAN mit einem Fritz Mesh Repeater 3000AX verbunden und dieser mit (mittelmäßiger) WLan Verbindung mit meinem Router, einer Fritz!Box 7530. An letzterer hängt mein Windows 10 Rechner mit dem ich per Browser oder ssh auf den OH Rechner zugreife.
Bevor das Elend mit dem Upgrade auf Ubuntu 22.04 von 20.irgendwas und von OH3 auf 4 seinen Lauf nahm hatte ich den OH Rechner direkt per LAN mit dem Hauptrouter verbunden und da lief alles gut. Ich will also die Wlan Verbindung als Ursache nicht ausschließen. Pings in beide Richtungen ergeben aber keine Timeouts bei Latenzen zw. 2 und 4 ms.

Bevor ich nun Romane schreibe:
Was braucht ihr von mir für Infos, logs oder sonstige Outputs, um dem Elend auf die Spur zu kommen. Ich hab es schon tagelang gegoogelt und es mit KI versucht... Bin am Ende meines sehr begrenzten Anfängerlateins!

Danke Vorab!
Christoph

Was heißt "alter PC"?
Grundsätzlich sollte openHAB4 sogar noch auf einem Raspberry 3B einigermaßen flüssig laufen, ein Pi4 sollte sogar gute Resultate liefern.
Wo ordnest Du Deine Hardware ein, unterhalb/oberhalb Pi3, unterhalb/oberhalb Pi4, weit oberhalb Pi4?
Wie viel RAM hast Du zur Verfügung? Welcher Prozessor ist verbaut, wie viele Kerne, welche Taktfrequenz?

Aber ganz grundsätzlich... die Anforderungen von openHAB4 an die Hardware sind nicht höher als die von openHAB3, jedenfalls wäre mir da nichts bekannt.
Ich nehme an, Du hast ursprünglich ein Upgrade von openHAB3 auf openHAB4 ausgeführt.
Was ich mir vorstellen könnte, ist, dass dabei Konfigurationsdaten durcheinander geraten sind. Da Du mutmaßlich immer die alten Daten einspielst, holst Du Dir dann den Fehler immer wieder ins System zurück.

Das Blöde: es ist nicht einfach, zu analysieren, wo der mutmaßliche Fehler in der Konfiguration steckt. Und eine Datenübernahme Stück für Stück von alt nach neu ist auch nicht trivial, am ehesten geht das noch, wenn man die Konfiguration komplett über Textdateien erstellt hat.

Also am Rechner wirds nicht liegen. Wenngleich die Staubschicht schon ordentlich ist.
Amd Athlon II X2 260, mit 8 Gig Ram und ner 500G SSD.

Von OH 3 auf 4 hat es noch recht gut funktioniert, wobei da schon die ersten kleineren Zickigkeiten auftauchten.
Dann kam meine super Idee doch auch gleich Ubuntu auf 22.04 anzuheben. Damit wurde es dann schlimmer und die beschriebenen langen Zugriffszeiten waren da und die Internetsteuerung per App und OH Cloud hing immer mal wieder.
Hab Stunden investiert um Fehler zu suchen und auszumerzen. Nichts hat geholfen.
Aus Verzweifelung beschlossen alles neu aufzusetzen und damit allen eventuellen alten Daten-, Konfigurations- und Verknüpfungsmüll zu eleminieren.
Mit frischem Debian 12 gebootet, alle vorherigen Daten gelöscht und neu partitioniert.
Java 17 installiert nach OH Vorgabe.
Und dann OH per apt installiert. Addons via apt wie in der Anleitung beschrieben.
Es kann also spätestens jetzt nichts mehr mit einer Datenübernahme oder Cacheproblematik zu tun haben.

Habe auf Verdacht einzeln meinen Antivir und meinen Defender von meiner Windows-Maschine abgeschaltet um Auszuschließen, dass dort das Problem liegt. Keine Veränderung.
Hat Debian 12 sowas wie ein Antivir oder ne eigene Firewall automatisch an Bord?

Allerdings kommen jetzt doch einige Warnmeldungen ins openhab.log:

Code: Alles auswählen

2023-11-10 19:20:09.043 [INFO ] [org.openhab.core.Activator          ] - Starting openHAB 4.0.4 (build Release Build)
2023-11-10 19:20:09.245 [INFO ] [core.karaf.internal.FeatureInstaller] - Some .kar files are not installed yet. Delaying add-on installation by 15s.
2023-11-10 19:20:11.524 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Time zone set to 'Europe/Berlin'.
2023-11-10 19:20:11.529 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Location set to '....'.
2023-11-10 19:20:11.535 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Locale set to 'de_DE'.
2023-11-10 19:20:16.536 [INFO ] [.core.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007
2023-11-10 19:20:20.455 [INFO ] [e.automation.internal.RuleEngineImpl] - Rule engine started.
2023-11-10 19:20:28.397 [WARN ] [ty.util.ssl.SslContextFactory.config] - Trusting all certificates configured for Client@1b53df6f[provider=null,keyStore=null,trustStore=null]
2023-11-10 19:20:28.398 [WARN ] [ty.util.ssl.SslContextFactory.config] - No Client EndPointIdentificationAlgorithm configured for Client@1b53df6f[provider=null,keyStore=null,trustStore=null]
2023-11-10 19:20:28.701 [INFO ] [ab.ui.habpanel.internal.HABPanelTile] - Started HABPanel at /habpanel
2023-11-10 19:20:29.546 [INFO ] [internal.ModuleHandlerFactoryStarter] - WebPushNotificationModuleHandlerFactory started by ModuleHandlerFactoryStarter
2023-11-10 19:20:29.962 [INFO ] [hab.ui.habot.tile.internal.HABotTile] - Started HABot at /habot
2023-11-10 19:20:30.341 [WARN ] [ty.util.ssl.SslContextFactory.config] - Trusting all certificates configured for Client@54092524[provider=null,keyStore=null,trustStore=null]
2023-11-10 19:20:30.342 [WARN ] [ty.util.ssl.SslContextFactory.config] - No Client EndPointIdentificationAlgorithm configured for Client@54092524[provider=null,keyStore=null,trustStore=null]
2023-11-10 19:20:32.309 [INFO ] [io.openhabcloud.internal.CloudClient] - Connected to the openHAB Cloud service (UUID = 17...e2, base URL = http://localhost:8080)
2023-11-10 20:03:12.618 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'upnpcontrol:upnprenderer:23456789-1234-1010-8000-70260519EB01' to inbox.
2023-11-11 03:13:15.527 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'upnpcontrol:upnpserver:fa095ecc-e13e-40e7-8e6c-485d3530ed1e' to inbox.
2023-11-11 03:13:18.098 [WARN ] [io.openhabcloud.internal.CloudClient] - Error during communication: EngineIOException websocket error
2023-11-11 03:13:18.100 [WARN ] [io.openhabcloud.internal.CloudClient] - Socket.IO disconnected: transport error
2023-11-11 03:13:18.101 [INFO ] [io.openhabcloud.internal.CloudClient] - Disconnected from the openHAB Cloud service (UUID = 17...e2, base URL = http://localhost:8080)
2023-11-11 03:13:21.907 [WARN ] [io.openhabcloud.internal.CloudClient] - Error connecting to the openHAB Cloud instance: already connected. Reconnecting after 1589 ms.
2023-11-11 03:13:23.991 [WARN ] [io.openhabcloud.internal.CloudClient] - Error connecting to the openHAB Cloud instance: already connected. Reconnecting after 6830 ms.
2023-11-11 03:13:31.315 [WARN ] [io.openhabcloud.internal.CloudClient] - Error connecting to the openHAB Cloud instance: already connected. Reconnecting after 10167 ms.
2023-11-11 03:13:41.540 [INFO ] [io.openhabcloud.internal.CloudClient] - Connected to the openHAB Cloud service (UUID = 17...e2, base URL = http://localhost:8080)
2023-11-11 05:13:32.392 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'upnpcontrol:upnpserver:fa095ecc-e13e-40e7-8e6c-485d3530ed1e' to inbox.
2023-11-11 05:21:46.256 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'upnpcontrol:upnpserver:fa095ecc-e13e-40e7-8e6c-485d3530ed1e' to inbox.
2023-11-11 12:16:00.469 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'upnpcontrol:upnprenderer:23456789-1234-1010-8000-70260519EB01' to inbox.
2023-11-11 15:21:22.748 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'upnpcontrol:upnprenderer:23456789-1234-1010-8000-70260519EB01' to inbox.

Nein, Debian 12 hat keine Antivirensoftware als default installiert.

Hast Du einen Desktop mit installiert?

Grundsätzlich ist der Athlon in etwa vergleichbar mit dem Pi 4

also natürlich bis auf die theoretische Stromaufnahme (TDP beim Athlon um Faktor 10 höher), im Zweifel müsste man nachmessen, was die alte Kiste tatsächlich zieht, aber mutmaßlich wird es so oder so wesentlich mehr sein als ein Pi4. Spätestens der Pi 5 zieht dem Athlon aber davon, vermutlich in jeder Disziplin...
Aber es soll hier nicht um die Sinnhaftigkeit des ganzen Unterfangens gehen

Grundsätzlich sollte Debian 12 keine Probleme mit dem Athlon haben, wobei es natürlich sein kann, dass irgendwelche Teile der Hardware tatsächlich nicht mehr vom Standard Kernel unterstützt werden. Hinweise dazu sollte der Befehl dmesg liefern können (System neu starten und dann dmesg aufrufen und nach Auffälligkeiten ab Sekunde 0 suchen)

Die Warnmeldungen beziehen sich vor allem auf Zertifikate, das kann zu Verzögerungen führen, wenn Du über https zugreifst. Ob das aber die Ursache für die fehlende Schwuppdizität ist?

Also den Wettbewerb, mein Rechner verbraucht weniger Strom als Deiner, gewinnt der PI 4 dann wohl. Pfff.
Dafür ist mein Speicher durch den Athlon schön geheizt und die 10 Euro im Jahr sind es mir Wert einfach keinen neuen PI oder anderen Stromsparer zu kaufen.
Egal Offtopic

Gnome ist als Desktop mit installiert.

dmesg ist recht unauffällig bis auf gemoser bei der Grafikkarte... glaub ich... "nouveau". Das halte ich aber für wenig bedeutsam, da der Desktop jedenfalls ein Bild liefert...

nouveau 0000:02:00.0: firmware: failed to load nouveau/nv106_fuc084 (-2)
[ 8.472082] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
[ 8.472091] nouveau 0000:02:00.0: firmware: failed to load nouveau/nv106_fuc084 (-2)
[ 8.472094] nouveau 0000:02:00.0: Direct firmware load for nouveau/nv106_fuc084 failed with error -2
[ 8.472105] nouveau 0000:02:00.0: firmware: failed to load nouveau/nv106_fuc084d (-2)
[ 8.472112] nouveau 0000:02:00.0: firmware: failed to load nouveau/nv106_fuc084d (-2)
[ 8.472114] nouveau 0000:02:00.0: Direct firmware load for nouveau/nv106_fuc084d failed with error -2
[ 8.472116] nouveau 0000:02:00.0: msvld: unable to load firmware data
[ 8.472118] nouveau 0000:02:00.0: msvld: init failed, -19

Hardwareprobleme sollten dann wohl nicht sein.

Das mit den Zertifikaten im openhab.log hatte ich gesehen. Kann mir nur keinen Reim drauf machen. Würde ich gerne ausmerzen, aber weiß nicht wie.

Ich hadere noch immer mit meiner W-Lan Verbindung als mögliche Ursache, denn meine IP Kamera- die per Lan am W-Lan Extender hängt produziert lt. Openhab in unregelmäßigen Abständen (30 bis 90 sek) Connection Timeout Meldungen und verbindet sich dann wieder.
Allerdings laden Videos von dieser Kamera rasend fix über das W-Lan Netz...
Das dürfte dann unproblematisch sein, was das bisschen Browsertraffic betrifft.
Ich schau mal, ob ich so ne lange LAN Kabel verlängerung gebastelt bekomme, dass ich den OH Server direkt an den Router hänge...

Ich fass es nicht... Problem gelöst!
25m Lan Kabel, und 2 Kupplungen später:
Es war die WLan Verbindung!
Hätte mir die ganze Arbeit sparen können und Dir auch! Danke mal wieder Udo1toni für Deine Bemühungen.
Aber jedenfalls hat es geholfen mich auf das Kabel zu bringen.

Wie setzt man das Thema auf gelöst?

Du kannst z.B. das Thema editieren (also im ersten Posting)

openhabforum.de

Browser Zugriff extrem langsam -GELÖST-

Browser Zugriff extrem langsam -GELÖST-

Re: Browser Zugriff extrem langsam

Re: Browser Zugriff extrem langsam

Re: Browser Zugriff extrem langsam

Re: Browser Zugriff extrem langsam

Re: Browser Zugriff extrem langsam

Re: Browser Zugriff extrem langsam