Smarthome auf Pi - Service startet beim Booten, aber 8383 hat kaputte Darstellung

[ralf9000]

Hallo,

vielleicht hat ja einer dieselbe Herausforderung: nach irgendeinem 64Bit-Update klappt das auto. Aufstarten beim Booten von Smarthome v1.10 in einer "Nebensache" nicht mehr:

Das Web-Interface ist zwar abrufbar, aber da wird nichts mehr ausgefüllt und die Menu-Texte kommen nicht. Smarthome über Smartvisu verhält sich vollständig normal.

Habe ich irgendwas verpasst? Meine /etc/systemd/system/smarthome.service sieht folgendermaßen aus und hat bis jetzt immer auch "das Web-Interface richtig gestartet":

pi@cm4-io-base-box-2:~ $ cat /etc/systemd/system/smarthome.service
[Unit]
Description=SmartHomeNG daemon
After=network.target
After=knxd.service
After=knxd.socket

[Service]
Type=forking
ExecStart=/usr/bin/python3 /usr/local/smarthome/bin/smarthome.py
WorkingDirectory=/usr/local/smarthome
User=smarthome
PIDFile=/usr/local/smarthome/var/run/smarthome.pid
Restart=on-failure
TimeoutStartSec=900
RestartForceExitStatus=5

[Install]
WantedBy=default.target

Irgendwie komme ich nicht auf den Fehler, wenn ich von Kommandozeile das python3-Kommando starte, kommt der Daemon hoch und im Webinterface ist alles ok ...

Wahrscheinlich eine dumme Kleinigkeit ..... vielen Dank schon mal im Voraus!

Ralf

[startrix]

Hi ralf9000,

was sagt den die Logfile beim starten?
Irgendwelche Auffälligkeiten?

Viele Grüße
Jannis

[ralf9000]

smarthome-warnings.log sieht so aus (beides mal):

2025-04-25  12:00:32 NOTICE   lib.smarthome       --------------------   Init SmartHomeNG v1.10.0-master (4b25822a0)   --------------------
2025-04-25  12:00:32 NOTICE   lib.smarthome       Running in Python interpreter 'v3.11.2 final', from directory /usr/local/smarthome
2025-04-25  12:00:32 NOTICE   lib.smarthome        - operating system 'Debian GNU/Linux 12 (bookworm)' (pid=1100)
2025-04-25  12:00:32 NOTICE   lib.smarthome        - on 'Raspberry Pi (Rev. d03140)'
2025-04-25  12:00:32 NOTICE   lib.smarthome        - Loglevel NOTICE is set to value 31 because handler of root logger is set to level WARNING or higher  -  Set level of handler 'shng_warnings_file' to 'NOTICE'!
2025-04-25  12:00:33 NOTICE   lib.smarthome        - Nutze Feiertage für Land 'DE', Provinz 'NW', 1 benutzerdefinierte(r) Feiertag(e) definiert
​

Allerdings gab es mal diese Fehlermeldung (nach dem Stromausfall bei uns heute), beim erneuten booten oder manuellen aufstarten war diese dann nicht mehr da:

2025-04-25  11:46:46 ERROR    plugins.database    Exception in function deleteLog: database disk image is malformed

Werde gleich aber die Logs mal löschen, nochmals booten und sehen.

Ralf

[ralf9000]

So gemacht, in beiden Szenarien "via systemctl" und "python3 bin/smarthome.py" manuel sind die logs inhaltlich gleich, aber im 1ten Fall läuft Admin-Interface auf 8383 nicht und im 2ten Fall läuft es .... in beiden Fällen funtioniert alles mit SmartVISU. Ratlos ...

[startrix]

Sorry, der Ratlosigkeit muss ich mich wohl anschließen Ralf, da müssen die Profis wohl mal sich dein Problem anschauen ;-), liebe Grüße nach NRW

[wvhn]

Moin Ralf,

in Bookworm solltest Du shNG mit Python v3.11 in einem virtuellen Environment laufen lassen. Möglicherweise machst Du das beim manuellen Start auch, aber in den Terminal-Ausgaben sehe ich davon nichts.

Im smarthome.service muss das venv dann auch entsprechend angegeben werden (siehe Doku):

...
[Service]
 Type=forking
 ExecStart=/usr/local/smarthome/venvs/py_shng/bin/python3 /usr/local/smarthome/bin/smarthome.py
...
​

Meine laienhafte Vermutung: wenn Du im manuellen Modus ein venv verwendest und im automatischen Modus nicht, dann werden unterschiedliche Python-Paketversionen verwendet und da gab es in der v1.10 ein paar Probleme mit zu neuen Paketen z.B. pyjwt, die sich negativ auf das Admin Interface ausgewirkt haben. Dazu ist hier im Forum einiges zu finden.

Alternative: shNG v1.11 nach Anleitung installieren. Das hat bei mir sehr gut geklappt.

Gruß
Wolfram

[ralf9000]

Hallo Wolfram,

ich habe mal auf die ExecStart-Zeile, die Du gepostet hast, geändert. Es funktioniert nun, super, vielen Dank!

Ich verstehe nur nicht warum es vorher funktioniert hat, da ist irgendwas nun durch das allerletzte Pi-Update reingekommen, wodurch es so nun nicht mehr funktioniert. Das pyhton3.exe ist auf beiden Verzeichnissen /usr/local/smarthome/venvs/py_shng/bin/ und /usr/bin/ auf Byte genau identisch und das virtuelle Python setze ich in der .bashc von User smarthome richtig ...

Ich werde im redundanten identischen Backupsystem (wird bei Ausfällen herangezogen) am WE mal von v1.10 auf v1.11 gehen .... und gebe dann Feedback.

Grüße und nochmal Danke,

Ralf

[ralf9000]

Hallo Wolfram,

habe jetzt sowohl das Test/Backup-System als auch das produktive System auf 1.11. upgedatet, alles ohne größere Probleme.

Im Test-System hatte ich bemerkt, das die Timer(USZU)-Einstellungen verloren gingen (war wahrscheinlich der erweitererten Funktionalität geschuldet), dann habe ich mir Screenshots der Timer-Konfigurationen im 1.10er Produktivsystem gemacht und nach dem Update dort wieder eingegeben.

Nach 15 Minuten war ich mit beiden System durch, Danke für die super gute Qualität 👍

Grüße,

Ralf

[wvhn]

Moin Ralf,

die UZSU-Schaltzeiten sollten eigentlich erhalten bleiben. Ich hatte bei meinem Update kein Problem damit. Dazu muss in der item-Definition "cache: true" angegeben sein. Am besten verwendet man eh das struct "uzsu.child". Da ist alles wichtige drin

beispielraum:
    licht:
        type: bool
        visu_acl: rw
        knx_dpt: 1
        knx_listen: 1/0/xx
        knx_send: 1/0/xx
        struct: uzsu.child​

Der Cache-Ordner ist /usr/local/smarthome/var/cache. Den sollte man bei einem Update nicht löschen.

Gruß
Wolfram

[ralf9000]

So war es auch bei mir bei insg. 4 UZSUs (struct verwendet) definiert, den Cache .../var/cache war beim Update noch da, aber trotzdem war bis auf das Aktiv-Häckchen auf beiden Systemen alles weg. Ich kann jetzt die Ursache nicht mehr klären (will nicht wieder das Backup drüber spielen), war aber kein großes Problem (dafür mache ich es ja auf den Systemen hintereinander) .... nochmals Danke!

Ralf