Support Thread für das smartvisu Plugin

[Volzor]

Hallo Wolfram,

vielen Dank für den Tipp, ein anderer Browser bzw. Browser Cache löschen und siehe da es geht. Jetzt lässt sich alles bedienen und der Schieberegler aktualisiert sich.
Er hatte vorher den Schwarzen Punkt des Schiebereglers einfach nicht angezeigt. Falls jemand auf ein ähnliches Problem stößt.

VG Christian

[Mike01]

Ich habe seit ein paar Tagen das Problem dass mein SmarthomeNG / SmartVisu Server beim Seitenaufbau sehr langsam reagiert.
Das verhalten tritt nur auf der Startseite auf, sobald eine unterseite geöffnet wird erfolgt der Seitenaufbau gewohnt schnell, klicke ich dann aber wieder auf das Haus-Symbol im oberen Menü, dauert es wieder einige Sekunden bis die Seite geladen wird.
Es hat den anschein, dass immer alle Daten von SmarthomeNG beim klick auf die Hauptseite neu eingelesen werden.
Das verhalten trat plötzlich auf, es wurde weder an SmarthomeNG noch an Smartvisu etwas verändert, allerdings wurden Debian pakete aktualisiert.
Im Logfile erhalte ich websocket fehler zu einem Item das ich in der Menüleiste abfrage, aber auch ein entfernen dieses Eintrags führt zu keiner verbesserung.

(Seitenaufbau der Hauptseite dauert ca. 10-20 sec.)

Betriebssystem: Debian Bookworm,
Python Version: 3.11.2
Smarthome version: 1.11.0 Master
SmartVisu version: 3.5.0

Fehlermeldungen im Logfile:

2025-11-09  14:05:20 WARNING  modules.websocket.sv Exception in 'await websocket.send(reply)': received 1001 (going away); then sent 1001 (going away) - reply = {"cmd": "proto", "ver": 4.1, "server": "module.websocket", "time": "2025-11-09T14:05:20.675406"} to 192.168.0.113:59264, 'some_visu'
2025-11-09  14:05:20 WARNING  modules.websocket.sv Exception in 'await websocket.send(reply)': received 1001 (going away); then sent 1001 (going away) - reply = {"cmd": "item", "items": [["env.location.night", false]]} to 192.168.0.113:59264, smartVISU v3.5.0, Firefox 144
2025-11-09  14:18:12 WARNING  modules.websocket.sv Exception in 'await websocket.send(reply)': received 1001 (going away); then sent 1001 (going away) - reply = {"cmd": "proto", "ver": 4.1, "server": "module.websocket", "time": "2025-11-09T14:17:58.336794"} to 192.168.0.113:59830, 'some_visu'
2025-11-09  14:18:12 WARNING  modules.websocket.sv Exception in 'await websocket.send(reply)': received 1001 (going away); then sent 1001 (going away) - reply = {"cmd": "item", "items": [["env.location.night", false]]} to 192.168.0.113:59830, smartVISU v3.5.0, Firefox 144
2025-11-09  14:19:23 WARNING  modules.websocket.sv Exception in 'await websocket.send(reply)': received 1001 (going away); then sent 1001 (going away) - reply = {"cmd": "proto", "ver": 4.1, "server": "module.websocket", "time": "2025-11-09T14:19:09.254719"} to 192.168.0.113:59890, 'some_visu'
2025-11-09  14:19:23 WARNING  modules.websocket.sv Exception in 'await websocket.send(reply)': received 1001 (going away); then sent 1001 (going away) - reply = {"cmd": "item", "items": [["env.location.night", false]]} to 192.168.0.113:59890, smartVISU v3.5.0, Firefox 144
2025-11-09  14:21:10 WARNING  modules.websocket.sv Exception in 'await websocket.send(reply)': received 1001 (going away); then sent 1001 (going away) - reply = {"cmd": "proto", "ver": 4.1, "server": "module.websocket", "time": "2025-11-09T14:20:28.919018"} to 192.168.0.113:59967, 'some_visu'
2025-11-09  14:21:11 WARNING  modules.websocket.sv Exception in 'await websocket.send(reply)': received 1001 (going away); then sent 1001 (going away) - reply = {"cmd": "item", "items": [["env.location.night", false]]} to 192.168.0.113:59967, smartVISU v3.5.0, Firefox 144
​

menu.html:

\\192.168.0.234\SmartVisu\pages\myvisu\menu.html (1 Treffer)
    Zeile 18:     {{ basic.stateswitch('Tasterbeleuchtung', 'env.location.night', 'icon', '', ['status_comfort.svg', 'status_night.svg']) }}​

Screenshot 2025-11-09 142736.png

Update:
Das entfernen des basic.stateswitch in der menu.html führt jetzt zu einer anderen Fehlermeldung im Smarthome-Logfile:
es werden jetzt plötzlich alle Items aufgelistet, das öffnen der Hauptseite dauert aber immer noch zw. 10-20 sec.

2025-11-09  15:21:08 WARNING  modules.websocket.sv Exception in 'await websocket.send(reply)': received 1001 (going away); then sent 1001 (going away) - reply = {"cmd": "proto", "ver": 4.1, "server": "module.websocket", "time": "2025-11-09T15:21:08.796230"} to 192.168.0.84:45982, 'some_visu'
2025-11-09  15:21:08 WARNING  modules.websocket.sv Exception in 'await websocket.send(reply)': received 1001 (going away); then sent 1001 (going away) - reply = {"cmd": "item", "items": [["uvr1611.temp.aussentemp", 7.0], ["og.flure.eingang", false], ["og.flure.garten", false], ["garten.brunnen.pumpe", true], ["garten.brunnen.licht", false], ["og.wohnen.heizung.ist", 19.36], ["og.wohnen.heizung.stellwert", 0], ["og.wohnen.decke1", false], ["og.wohnen.decke2", false], ["og.wohnen.decketv", false], ["og.wohnen.ledtv", false], ["og.wohnen.simtv", false], ["og.wohnen.rollo.pos", 0], ["og.kochen.heizung.ist", 19.37], ["og.kochen.tisch", false], ["og.kochen.decke2", false], ["og.kochen.spule", false], ["og.kochen.rollo.pos", 0], ["og.balkon.licht", false], ["og.balkon.markise.pos", 0], ["og.buero.heizung.ist", 16.75], ["og.buero.heizung.stellwert", 100.0], ["og.buero.decke", false], ["og.buero.rollo.pos", 0], ["og.buero.verbraucher.strom", 222.17998991012576], ["og.schlafen.heizung.ist", 12.31], ["og.schlafen.heizung.stellwert", 0], ["og.schlafen.decke", false], ["og.schlafen.rollo.pos", 0], ["og.badog.heizung.ist", 13.44], ["og.badog.heizung.stellwert", 0], ["og.badog.decke", false], ["og.badog.spiegel", false], ["og.flure.flurog", false], ["og.flure.treppe", false], ["og.speis.decke", false], ["og.flure.heizung.ist", 14.06], ["og.flure.heizung.stellwert", 0], ["og.flure.flur1eg", false], ["og.flure.flur2eg", false], ["eg.badeg.heizung.ist", 13.0], ["eg.badeg.heizung.stellwert", 0], ["eg.badeg.decke", false], ["eg.badeg.spiegel", false], ["eg.badeg.verbraucher.stromWA", 0], ["eg.badeg.verbraucher.stromTR", 0], ["eg.mike.heizung.ist", 13.97], ["eg.mike.heizung.stellwert", 0], ["eg.mike.decke", false], ["eg.mike.tvlicht", false], ["eg.mike.steckd3", false], ["eg.mike.rollo.pos", 0.0], ["eg.mike.verbraucher.strom", 27.29639856219292], ["eg.martina.heizung.ist", 11.83], ["eg.martina.heizung.stellwert", 0], ["eg.martina.decke", false], ["eg.martina.rollo.pos", 9.8], ["eg.heizraum.decke", false], ["eg.garage.decke1", false], ["eg.garage.decke2", false], ["eg.garage.decke3", false], ["eg.garage.decke4", false], ["eg.werkstatt.decke2", false], ["eg.werkstatt.decke", false], ["eg.garagentore.rmtor1", false], ["eg.garagentore.rmtor2", false], ["env.location.sunrise", "2025-11-10T07:07:12.148182+01:00"], ["env.location.sunset", "2025-11-09T16:35:37.951461+01:00"], ["env.location.moonrise", "2025-11-09T19:46:57.795886+01:00"], ["env.location.moonset", "2025-11-10T12:49:55.963048+01:00"], ["env.location.moonphase", 5], ["env.location.moonlight", 78]]} to 192.168.0.84:45982, smartVISU v3.5.0, Chrome 142

​

[Msinn]

Die Meldung im Log (going away) bedeutet, dass der Browser in dem die smartVISU läuft sich abmeldet / die Websocket Verbindung beendet. Hast Du am Client etwas verändert (Browser, Betriebssystem)?

[wvhn]

Die Seiten werden in smartVISU immer zuerst aufgebaut und dann mit den item-Werten befüllt. Wenn der Seitenaufbau lange dauert, ist es unwahrscheinlich, dass die Websocket-Verbindung die Ursache dafür ist. Die Ursache liegt dann eher im Server. Hier könntest Du mal die error.log des Servers durchsuchen.

Die Hauptseite lädt in der Regel nicht alle Daten neu. Sie verhält sich wie jede andere Seite auch. JQuery mobile ermöglicht den sog. multi-page Modus. Dabei bleiben alle geladenen Seiten im Speicher und werden per Ajax-Navigation aufgerufen. ( Genau genommen sind die Seiten dann keine Seiten mehr, sondern <div> mit dem Kennzeichen date-role=page. ) Dies kann man verhindern, indem man im Menü beim Seitenlink „data-ajax=false“ angibt und damit das Neuladen der Seite erzwingt. Ich vermute, dass das in Deiner Menu.html für die Hauptseite der Fall ist. Am besten nimmst Du das raus.

Interessant wäre natürlich trotzdem, warum der Server durch das Update der Debian-Pakete langsamer geworden ist.

Gruß
Wolfram

[Mike01]

Danke für die Tipps,

Msinn Am Client wurde nichts verändert, bzw es betrifft eigentlich alle Clients, egal ob PC Browser (Firefox), oder Handybrowser (Chrome).

wvhn
das neuladen der Seite durch "data-ajax=false" hatte ich tatsächlich in der menu.html beim Haussymbol (Hauptseite) und bei der Wetterseite,
Ich habe ich es jetzt mal deaktiviert, dadurch kann man zumindest beim Handy aus einer unterseite wieder zur Hauptseite zurückwechseln ohne lange Ladezeit.
Der längere Seitenaufbau beim ersten Seitenaufruf der Hauptseite bleibt allerdings weiterhin vorhanden.

In den Logfiles am Server ist auch nichts auffälliges feststellbar.

error.log:

[Sun Nov 09 00:00:08.314505 2025] [mpm_prefork:notice] [pid 263228:tid 263228] AH00163: Apache/2.4.65 (Debian) configured -- resuming normal operations
[Sun Nov 09 00:00:08.314586 2025] [core:notice] [pid 263228:tid 263228] AH00094: Command line: '/usr/sbin/apache2'​

access.log:

192.168.0.113 - - [09/Nov/2025:15:21:00 +0100] "GET /smartvisu/lib/clock/pics/21-2.png HTTP/1.1" 200 5067 "http://192.168.0.234/smartvisu/index.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:144.0) Gecko/20100101 Firefox/144.0"
192.168.0.113 - - [09/Nov/2025:15:21:00 +0100] "GET /smartvisu/lib/clock/pics/0-2.png HTTP/1.1" 200 4609 "http://192.168.0.234/smartvisu/index.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:144.0) Gecko/20100101 Firefox/144.0"
192.168.0.113 - - [09/Nov/2025:15:21:00 +0100] "GET /smartvisu/lib/clock/pics/21-3.png HTTP/1.1" 200 4824 "http://192.168.0.234/smartvisu/index.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:144.0) Gecko/20100101 Firefox/144.0"
192.168.0.113 - - [09/Nov/2025:15:21:00 +0100] "GET /smartvisu/lib/clock/pics/0-3.png HTTP/1.1" 200 4066 "http://192.168.0.234/smartvisu/index.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:144.0) Gecko/20100101 Firefox/144.0"
192.168.0.84 - - [09/Nov/2025:15:21:00 +0100] "GET /smartvisu/lib/clock/pics/21-1.png HTTP/1.1" 200 5126 "http://192.168.0.234/smartvisu/index.php" "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Mobile Safari/537.36"
192.168.0.84 - - [09/Nov/2025:15:21:00 +0100] "GET /smartvisu/lib/clock/pics/21-2.png HTTP/1.1" 200 5067 "http://192.168.0.234/smartvisu/index.php" "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Mobile Safari/537.36"
192.168.0.84 - - [09/Nov/2025:15:21:00 +0100] "GET /smartvisu/lib/clock/pics/21-3.png HTTP/1.1" 200 4824 "http://192.168.0.234/smartvisu/index.php" "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Mobile Safari/537.36"

php8.2-fpm.log

[09-Nov-2025 00:00:08] NOTICE: error log file re-opened

Server ist übrigens ein Raspberry 4 CM mit 4 GB RAM, der nicht sonderlich ausgelastet ist.
auf dem CM4 läuft zus. noch MQTT und NodeRed

top:

top - 19:44:59 up 7 days,  9:48,  1 user,  load average: 0,15, 0,14, 0,09
Tasks: 189 total,   1 running, 188 sleeping,   0 stopped,   0 zombie
%CPU(s):  0,5 us,  0,3 sy,  0,0 ni, 99,2 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Spch:   3790,9 total,   1897,3 free,    584,1 used,   1455,8 buff/cache
MiB Swap:    512,0 total,    512,0 free,      0,0 used.   3206,7 avail Spch
​

[wvhn]

Moin Mike01,

sorry, ich habe das Thema aus den Augen verloren. Bist Du weiter gekommen? Damals hatte ich zeitnah bei meinem Testsystem die Debian-Pakete aktualisiert, aber keinen Effekt feststellen können. Falls Dein Handy ein iPhone ist, versuche es mal mit einem anderen Browser, z.B. Firefox. Safari hat seit v26 Bugs in der Implementierung des Websocket-Protokolls.

Bei ausgeschaltetem Cache und/oder dem Eintrag „debug=1“ in der config.ini ist die Browser-Konsole recht auskunftsfreudig und Du siehst vielleicht, woran es hakt.

Gruß
Wolfram

[knxms]

Moin!
Ich möchte mich an das Thema von #62 (...langsamer Seitenaufbau der SmartVisu-Hauptseite...) dranhängen, was auch bei mir seit Wochen/Monaten auftritt:
Debian: Bullseye
SmarthomeNG: 1.10
SmartVisu: 3.5

Status:
1. Bei mir tritt der langsame Aufbau der Hauptseite (>= 5s) mit einem iPad (iOS 17.7.10) auf. Unabhängig ob der Aufruf mit Safari (V17) oder Firefox gemacht wird.
2. Den Hinweis mit "data-ajax=false" habe ich bereits eingebaut. Das hat dazu geführt, dass die Rückkehr zur Hauptseite mit normaler Geschwindigkeit funktioniert. Davor war das ebenfalls langsam.
3. Der Aufbau der Hauptseite mittels PC-Browser funktioniert mit normaler Geschwindigkeit (<=1s).

Schon getestet:
1. Ein Neustart von SmarthomeNG oder das Leeren vom Cache (SmartVisu) ändert nichts.
2. Was für eine "kurzfristige" (...für einige Aufrufe; genauer kann ich das nicht angeben...) Abhilfe sorgt: Neustart des Routers (hier: Fritzbox 7530 AX, mit 8.20). Nach einem Neustart funktioniert der Seitenaufbau mit normaler Geschwindigkeit.

Was scheinbar immer mit normaler Aufbaugeschwindigkeit funktioniert:
1. Mit dem iPad von "extern" mittels VPN auf den Webserver zugreifen.

Besten Gruß, Michael

PS: Die Warnung "modules.websocket.sv Exception in 'await websocket.send(reply)': received 1005" tritt bei mir ebenfalls öfter auf.

[wvhn]

Bei den 5 Sekunden könnte es sich auch um die Standard-Wartezeit für den Reconnect handeln. Das ist die Zeit, nach der der Treiber prüft, ob er noch verbunden ist und dann den Websocket neu initialisiert. Das passiert, wenn der Tab mit der Visu im Browser offen ist und das iPad aus dem Ruhezustand geholt wird. Dann erscheint auch kurz das rote Fehlerdreieck oben rechts, bis die Verbindung wieder steht. Die Zeit kannst Du mal runter setzen auf z.B. 2 Sekunden. In der config.in die folgende Zeile anlegen:

reconnect_time = 2000

Client-seitig ist der Websocket leider eine totale black box, d.h. ich habe keine Diagnosemöglichkeit in javaScript. Hier könnte Msinn vielleicht mal prüfen, ob er auf der Server-Seite an mehr Informationen über den Zustand der Verbindung kommt. Interessant wäre auch zu wissen, ob Ihr die gleichen Verzögerungen im Admin-Interface von shNG auf der Seite "Resource Charts" habt. Diese Daten werden auch über das Websocket-Modul übertragen.

Wenn Du von extern auf den Webserver gehst, dann wahrscheinlich mit einer Adresse wie "www.meinPrivaterServer.de/smartVISU", oder? In diesem Fall läuft die Verbindung über Port 80 / 443 und nicht über die eingestellten Websocket-Ports. Das könnte ein interessanter Hinweis sein.

Gruß
Wolfram

[Mike01]

Hallo wvhn,

Danke für die Nachfrage,
Bei mir tritt das Problem mit jedem Endgerät auf, egal ob Handy oder PC, und es ist Browserunabhängig.
Das Laden des shNG Backend hingegen funktioniert einwandfrei und schnell.
Die Seite mit den "Resource Charts" wird bei mir allerdings auch nicht richtig angezeigt, die Charts werden zwar dargestellt, aber enthalten keine Werte.

Bin leider noch nicht richtig weitergekommen, hab das ganze aber auch aus Zeitmangel im Moment etwas zurückstellen müssen.
Durch das entfernen des Eintrags "data-ajax=false" ist der Wechsel zwischen den Seiten zumindest wieder über jedes Endgerät möglich.
Das einmalige längere Laden am Anfang ist zwar nervig, aber man kann sich daran gewöhnen.

Hab inzwischen auch testweise mal zwischen Ajax und NGINX gewechselt, was aber auch keinen Unterschied macht.

Werde wohl während der Feiertage versuchen den R4CM mal neu aufzusetzen..
Kann man eigentlich schon abschätzen wann shNG für Debian 13 freigegeben wird ?
Dann könnte ich das evtl. auch noch abwarten.

Gruß,
Mike

[wvhn]

Der Wechsel zwischen Apache2 und nginx bringt deshalb nichts, weil die Websocket-Verbindung nicht zum Webserver geht, sondern direkt zum Websocket-Modul von shNG. Die Tatsache, dass die Ressource Charts leer bleiben (die Daten kommen auch über das Websocket-Modul), passt in das Fehlerbild. Irgendwas blockiert bzw. verzögert die Verbindungen von Deinen Endgeräten zu dem Server, auf dem shNG läuft. IMHO ist die Ursache im Netzwerk zu suchen. Im Anhang eine interessante Antwort von Gemini zu dem Hinweis von knxms mit dem Neustart der Frizbox.

Gruß
Wolfram

[knxms]

Frage (zu #67 im Zusammenhang mit #70):
Könnte es daran liegen, dass das iPad in den Systemeinstellungen unter WLAN eine „Private WLAN“- Adresse haben kann. Unter Vers. iOS 17 geht wohl nur an/aus. Bedeutet aber, soweit ich das verstehe, dass im Abstand von zwei Wochen die zugewiesene MAC-Adresse verändert wird, um das Tracking zu erschweren.
Ist das der Zeitpunkt ab dem die Probleme entstehen könnten? Dann müsste ich bis zum nächsten Auftritt des Problems noch ca. 2 Wochen warten…

Das iPad hat eine statische IP.

[Mike01]

wvhn YMMD
Danke für den interessanten Ansatz,
Ich habe tatsächlich vor ca. 2-3 Jahren einen weiteren Raspberry mit AdGuard in meinem Netzwerk installiert, an den hatte ich gar nicht mehr gedacht.

Bisher habe ich den Smarthome Server auch immer mit fester IP konfiguriert, seit dem R4CM, den ich vor ca. 3 Monaten neu gekauft und aufgesetzt habe hatte ich der einfachheit halber die IP Konfiguration über die IP Adressreservierung in der FritzBox konfiguriert.

Ich habe gerade die DNS umleitung zum AdGuard Server in der FritzBox deaktiviert, und alles neu gestartet, dadurch funktioniert der Zugriff auf die Visu wieder in gewohnter schneller Geschwindigkeit.

Gruß, Mike