Gelöst: Neuer rpi: FHEM startet nicht AUTOMATISCH (Stand Jan. 2025)

Begonnen von Thomas24568, 22 Januar 2025, 13:25:12

Vorheriges Thema - Nächstes Thema

passibe

Zitat von: Thomas24568 am 22 Januar 2025, 22:55:23Tja, da habe ich mutigerweise als Test einen shutdown gemacht, nach ca. 2 min wieder gestartet, und WIEDER NIX. Laut service fhem status läuft fhem, aber die Webseite läßt sich nicht laden.
Was sagt denn das FHEM-Log in so einem Fall? Das müsste dir eigentlich zeigen, an welchem Schritt FHEM hängen bleibt.

Thomas24568

Irgendwie schaffe ich es im Moment nicht, die Ausgabe zu kopieren, daher ein Bildschirmfoto:


Otto123

#32
nochmal, Du weißt doch jetzt wie Du FHEM zum Leben erweckst, wenn es lebt dann:
Zitat von: Otto123 am 22 Januar 2025, 22:45:16Dann mach jetzt in der FHEM Web Kommandozeile
Code Auswählen Erweitern
delete initialUsbCheckdanach save.
Hilft das den Start glatt durchgehen zu lassen? Nein? Dann:
Zitat von: Otto123 am 22 Januar 2025, 22:58:26Falls es Raspbian OS ist (bevorzugt lite) dann kannst Du mal den von Dir schon besprochenen Patch in der systemd unit anwenden.

ZitatWants=network-online.target
After=network-online.target
Oder vielleicht fängst noch mal mit dem Image und der SD Card neu an. Du weiß doch jetzt wo steht, wie FHEM auf einem Raspberry Pi installiert wird.
https://wiki.fhem.de/wiki/Raspberry_Pi

Immer wieder auf ein blockiertes System warten bringt Dich ja nicht voran ;)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

passibe

Zitat von: Thomas24568 am 22 Januar 2025, 23:36:11Irgendwie schaffe ich es im Moment nicht, die Ausgabe zu kopieren, daher ein Bildschirmfoto:
Aber wieso macht es da immer noch den initialUsbCheck?
Es hängt jetzt zwar augenscheinlich nicht mehr da, aber es checkt ja immer noch die USB-Geräte. Das sollte durch das Hinzufügen des disable-Attributs oder das delete initialUsbCheck eigentlich nicht mehr der Fall sein.

Naja. Ich glaube auch, dass hier ein frisches Betriebssystem + Neuinstallation die schnellste Lösung ist.

Thomas24568

Zitat von: Otto123 am 23 Januar 2025, 00:07:09Oder vielleicht fängst noch mal mit dem Image und der SD Card neu an

Moin!
Neuer Tag, neuer Versuch. Ich werde die SSD und anschließend FHEM neu installieren. Aber warum wurde mehrfach "lite" empfohlen? Was hat "voll" für Nachteile? Plat und Rechenleistung habe ich mehr als genug...

passibe

Also es ist für einen Server mE jedenfalls unnötig. Ist bei "voll" nicht sogar eine Desktopumgebung dabei?

Es ist nicht so, dass dann ab sofort irgendwas nicht funktioniert. Aber es bläht das ganze System auf, wodurch sich das Risiko erhöht, dass irgendwann in Zukunft eines der unnötigen Bestandteile zu Sand im Getriebe wird (auch performancemäßig, sobald die Hardware altert). Das macht dann auch die Fehlersuche komplizierter, weil eben nicht nur 10 Pakete als Ursache für ein Problem in Frage kommen, sondern 30 (gegriffene Zahlen). Lite dürfte insgesamt also stabiler sein, insbesondere langfristig. Das ist jedenfalls für mich schon ein wichtiger Faktor für einen ja doch einigermaßen "kritischen" Dienst wie FHEM.

Du hast vor allem auch keine wirklichen Nachteile mit lite. Das Hinzufügen von eventuell fehlenden Paketen geht immer, deinstallieren von unnötigen Paketen ist eventuell schwieriger.

Otto123

Server = kein Desktop!
Nur unnötiger Ballast und jede Menge potentielle Sicherheitslöcher. Je mehr installiert ist um so größer wird der Wartungsaufwand.

Passibe war schneller ;)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Thomas24568

Vielen Dank für die Erläuterungen. Doch ich muß euch in einigen Punkten widersprechen:

- ICH benötige den Desktop sporadisch, denn es läuft nicht nur fhem drauf (Pi-hole wird noch dazukommen, vielleicht noch mehr).

- Der Desktop (also die volle Installation) hat mich eben gerettet: Der Pi war nach Installation nicht erreichbar!

Ich hatte von der SD-Karte gebootet, den Pi-Imager (Desktop) aufgerufen, die SSD neu formatiert, das 64 Bit Raspian als OS ausgewählt, in den Einstellungen Rechnername, Sprache usw. eingestellt. Danach die Einstellungen kontrolliert, stimmte alles. Dann OS installiert, in den Konfigs (Terminal) wieder "SSD boot zuerst" eingestellt.

Der Pi5 fährt hoch, ist aber nicht per SSH oder VNC erreichbar!!!

Nach fast einer Stunde Suche (nach dem passendem Monitorkabel incl. Mini-Adapter, Arbeitsmonitor anschließen) dann die Lösung: Der Rechner ist mit einer neuen Abfrage nach Name, PW, Sprache hochgekommen. Ohne Desktop hätte ich das nicht gesehen!

Gut, das Problem ist dann schnell erledigt.

Dann nach der "offiziellen" Anleitung (debian.fhem.de) das reposity erweitert, upgedatet, und per apt fhem installiert. Browser aufgerufen mit pi5:8083/fhem - läuft.

Mißtrauisch geworden folgt ein Neustart des Pi5, und dann der Aufruf von fhem per Webbrowser - NICHTS!!! Trotz

pi5@pi5:~ $ service fhem status
� fhem.service - FHEM Home Automation
     Loaded: loaded (/etc/systemd/system/fhem.service; enabled; preset: enabled)
     Active: active (running) since Thu 2025-01-23 13:07:39 CET; 17min ago
    Process: 743 ExecStart=/usr/bin/perl fhem.pl fhem.cfg (code=exited, status=>
   Main PID: 819 (perl)
      Tasks: 1 (limit: 9559)
        CPU: 17min 42.194s
     CGroup: /system.slice/fhem.service
             â��â�€819 /usr/bin/perl fhem.pl fhem.cfg

Jan 23 13:07:39 pi5 systemd[1]: Starting fhem.service - FHEM Home Automation...
Jan 23 13:07:39 pi5 systemd[1]: Started fhem.service - FHEM Home Automation.
lines 1-12/12 (END)


So, nun bin ich einerseits enttäusch (das fhem immer noch nicht läuft) und andererseits etwas erfreut (das meine vorherige Installation nicht das Problem war).

pi5@pi5:~ $ sudo ss -tulp
Netid   State    Recv-Q   Send-Q                  Local Address:Port                    Peer Address:Port       Process                                        
udp     UNCONN   0        0                             0.0.0.0:mdns                         0.0.0.0:*           users:(("avahi-daemon",pid=588,fd=12))        
udp     UNCONN   0        0                             0.0.0.0:38965                        0.0.0.0:*           users:(("avahi-daemon",pid=588,fd=14))        
udp     UNCONN   0        0                                   *:36818                              *:*           users:(("avahi-daemon",pid=588,fd=15))        
udp     UNCONN   0        0          [fe80::5647:639d:373b:3b5]:dhcpv6-client                      *:*           users:(("NetworkManager",pid=651,fd=28))      
udp     UNCONN   0        0                                   *:mdns                               *:*           users:(("avahi-daemon",pid=588,fd=13))        
tcp     LISTEN   0        128                         127.0.0.1:ipp                          0.0.0.0:*           users:(("cupsd",pid=742,fd=7))                
tcp     LISTEN   0        128                           0.0.0.0:ssh                          0.0.0.0:*           users:(("sshd",pid=773,fd=3))                 
tcp     LISTEN   4        32                            0.0.0.0:8083                         0.0.0.0:*           users:(("perl",pid=819,fd=5))                 
tcp     LISTEN   0        16                                  *:5900                               *:*           users:(("wayvnc",pid=798,fd=8))               
tcp     LISTEN   0        128                             [::1]:ipp                             [::]:*           users:(("cupsd",pid=742,fd=6))                
tcp     LISTEN   0        128                              [::]:ssh                             [::]:*           users:(("sshd",pid=773,fd=4))                 
pi5@pi5:~ $

pi5@pi5:~ $ curl -v localhost:8083
*   Trying 127.0.0.1:8083...
* Connected to localhost (127.0.0.1) port 8083 (#0)
> GET / HTTP/1.1
> Host: localhost:8083
> User-Agent: curl/7.88.1
> Accept: */*
>

pi5@pi5:~ $ ip -4 a | grep inet | grep -v 127.0.0.1 | grep -oP '(?<=inet\s)\d+(\.\d+){3}'
192.168.180.161
pi5@pi5:~ $

pi5@pi5:~ $ tail -n 50 /opt/fhem/log/fhem-$(date '+%Y-%m').log
2025.01.23 13:06:45 1: Including fhem.cfg
2025.01.23 13:06:45 3: WEB: port 8083 opened
2025.01.23 13:06:45 2: eventTypes: loaded 0 lines from ./log/eventTypes.txt
2025.01.23 13:06:45 1: Messages collected while initializing FHEM:SecurityCheck:
  WEB is not password protected

Protect this FHEM installation by defining an allowed device with define allowed allowed
You can disable this message with attr global motd none

2025.01.23 13:06:45 1: usb create starting
2025.01.23 13:06:45 3: Probing ZWDongle device /dev/serial0
2025.01.23 13:06:45 3: Probing CUL device /dev/ttyAMA10
2025.01.23 13:06:46 3: Probing TCM_ESP3 device /dev/ttyAMA10
2025.01.23 13:06:46 3: Probing ZWDongle device /dev/ttyAMA10
2025.01.23 13:06:46 3: Probing SIGNALDuino device /dev/ttyAMA10
2025.01.23 13:06:46 3: Probing MYSENSORS device /dev/ttyAMA10
2025.01.23 13:06:46 3: Probing ArduCounter device /dev/ttyAMA10
2025.01.23 13:06:46 3: Probing ElsnerWS device /dev/ttyAMA10
2025.01.23 13:06:47 3: Probing FRM device /dev/ttyAMA10
2025.01.23 13:06:52 1: usb create end
2025.01.23 13:06:52 0: Featurelevel: 6.3
2025.01.23 13:06:52 0: Server started with 6 defined entities (fhem.pl:29402/2024-12-05 perl:5.036000 os:linux user:fhem pid:3086)
2025.01.23 13:07:22 0: Server shutdown
2025.01.23 13:07:39 1: Including fhem.cfg
2025.01.23 13:07:39 3: WEB: port 8083 opened
2025.01.23 13:07:39 2: eventTypes: loaded 0 lines from ./log/eventTypes.txt
2025.01.23 13:07:39 1: Including ./log/fhem.save
2025.01.23 13:07:39 1: Messages collected while initializing FHEM:SecurityCheck:
  WEB is not password protected

Protect this FHEM installation by defining an allowed device with define allowed allowed
You can disable this message with attr global motd none

2025.01.23 13:07:39 1: usb create starting
2025.01.23 13:07:39 3: Probing ZWDongle device /dev/serial0
2025.01.23 13:07:39 3: Probing CUL device /dev/ttyAMA10
2025.01.23 13:07:39 3: Probing TCM_ESP3 device /dev/ttyAMA10
2025.01.23 13:07:40 3: Probing ZWDongle device /dev/ttyAMA10
2025.01.23 13:07:40 3: Probing SIGNALDuino device /dev/ttyAMA10
2025.01.23 13:07:40 3: Probing MYSENSORS device /dev/ttyAMA10
2025.01.23 13:07:40 3: Probing ArduCounter device /dev/ttyAMA10
2025.01.23 13:07:40 3: Probing ElsnerWS device /dev/ttyAMA10
2025.01.23 13:07:41 3: Probing FRM device /dev/ttyAMA10
pi5@pi5:~ $


"Wants" und "After" habe ich im Moment noch belassen, um euch für die Fehlersuche ein echt frisches System zu bieten.

Beta-User

Zitat von: Thomas24568 am 23 Januar 2025, 13:35:47- ICH benötige den Desktop sporadisch, denn es läuft nicht nur fhem drauf (Pi-hole wird noch dazukommen, vielleicht noch mehr).
Meinst du "Desktop" oder "Bildschirm"?
Hin und wieder schließe ich an meinen Server (viel potenter wie der Pi5) einen Bildschirm und eine Tastatur an - z.B. wenn ich was am BIOS einstellen will oder bei der Erstinstallation. Aber sobald die Kiste läuft und remote erreichbar ist, braucht man diesen Ballast (und irgendein VNC-Gruscht) nicht!
(Man kann sogar Anwendungen per ssh weitergeben, die einen X-Server brauchen! OK, deCONZ-GUI war in der Beziehung wirklich grausam, aber das lag weniger an ssh mit X-forward, sondern an deconz).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Thomas24568

Zitat von: Beta-User am 23 Januar 2025, 13:52:50Meinst du "Desktop" oder "Bildschirm"?

Beides, wobei Desktop wichtiger (häufiger {5-10 mal im Jahr außerhalb von Installationssachen} verwendet, meist per vnc) als Bildschirm ist (nur 2-3 mal im Jahr für wenige Stunden an).

Zitat von: Beta-User am 23 Januar 2025, 13:52:50(und irgendein VNC-Gruscht) nicht!

Du vielleicht. Ich bin seit 1985 "Mausschubser", auch wenn ich schon vor langer Zeit das Terminal kennengelernt habe. Aber der Schreibtisch ist für mich immer noch die erste Wahl, dann kommt laaaange nichts, dann erst das Terminal.

Zitat von: Beta-User am 23 Januar 2025, 13:52:50die einen X-Server brauchen!
Ich kenne den Begriff, kann aber trotzdem nicht genau sagen was das ist. "Irgendein *nix-Kram um Rechner fernzusteuern"

Beta-User

Zitat von: Thomas24568 am 23 Januar 2025, 14:02:59Du vielleicht. Ich bin seit 1985 "Mausschubser", auch wenn ich schon vor langer Zeit das Terminal kennengelernt habe. Aber der Schreibtisch ist für mich immer noch die erste Wahl, dann kommt laaaange nichts, dann erst das Terminal.
Wir haben uns vermutlich alle mal ans Mausschubsen gewöhnt.

Für alle, die ggf. noch dazulernen wollen und keinen *ix-Rechner mit bereits installiertem X-System als ssh-Client haben hier eine (nicht näher geprüfte (putty ist "out"!), aber in Deutsch verfasste) Fundstelle für Win.*:
https://www.rz.uni-wuerzburg.de/dienste/it-sicherheit/sshlinux/ssh-client-unter-windows/#c184431
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

passibe

#41
Zitat von: Thomas24568 am 23 Januar 2025, 13:35:47Der Rechner ist mit einer neuen Abfrage nach Name, PW, Sprache hochgekommen. Ohne Desktop hätte ich das nicht gesehen!
Ich glaube der ist nur deshalb mit dieser Abfrage gekommen, weil du überhaupt das Desktop-System installiert hattest :D Dann hat er logischerweise auch erwartet, dass du einen Monitor dranhängst, um fertig zu konfigurieren ... aber sei's drum

Wie schon von den anderen hier gesagt, kann man auch an ein Nicht-Desktop-Betriebssystem im Notfall immer einen Monitor dranhängen und kriegt dann halt einfach direkt ein Terminal, so als würde SSH wieder funktionieren.

Jedenfalls:
Zitat von: Thomas24568 am 23 Januar 2025, 13:35:472025.01.23 13:07:22 0: Server shutdown
Hast du FHEM an dieser Stelle manuell neugestartet oder hat es das von selbst gemacht?

Zitat von: Thomas24568 am 23 Januar 2025, 13:35:472025.01.23 13:07:41 3: Probing FRM device /dev/ttyAMA10
Weil das Log hier endet, sieht es nach wie vor so aus, dass dein InitialUsbCheck hängt. Also im Zweifel gleiches Problem wie gestern. Du musst die fhem.cfg bearbeiten, das auf disable setzen (oder ganz löschen) und dann mal den Pi komplett neustarten.
Dasssudo service fhem stopeventuell eine ganze Weile hängt, ist normal. Da einfach abwarten. Erst danach die fhem.cfg bearbeiten.

Falls FHEM nach Bearbeitung der fhem.cfg + Neustart des gesamten Systems immer noch nicht erreichbar ist, bitte mal einen Auszug vom FHEM-Log posten. Bitte dort die Uhrzeit, wann du das System neugestartet hast, dazuschreiben und auch die Uhrzeit, wann du den Log-Ausschnitt kopiert hast. Sorry, ist etwas mühsam, aber das macht es (jedenfalls für mich) viel nachvollziehbarer.

Thomas24568

Zitat von: passibe am 23 Januar 2025, 14:37:34Hast du FHEM an dieser Stelle manuell neugestartet oder hat es das von selbst gemacht?

Weder noch. Ich habe dem OS den Befehlt "Neustart" gegeben.

Rest kommt kurzfristig.

Otto123

#43
ich vermute immer noch: FHEM startet mehrfach (oder zu schnell hintereinander neu), vielleicht gerade wegen dem Desktop.
Systemd denkt ev. der Dienst ist (noch) nicht gestartet und startet ihn neu.
Beim ersten Start beendet er auch usb create ... Zum Schluss bleibt er dort hängen, das Web ist da liefert aber nichts aus.
Zitat2025.01.23 13:06:52 1: usb create end
2025.01.23 13:06:52 0: Featurelevel: 6.3
2025.01.23 13:06:52 0: Server started with 6 defined entities (fhem.pl:29402/2024-12-05 perl:5.036000 os:linux user:fhem pid:3086)
2025.01.23 13:07:22 0: Server shutdown
2025.01.23 13:07:39 1: Including fhem.cfg
Das müsste man eigentlich mit journalctl sehen
journalctl -b -u fhem.service
Zitat von: Thomas24568 am 23 Januar 2025, 13:35:47- ICH benötige den Desktop sporadisch, denn es läuft nicht nur fhem drauf (Pi-hole wird noch dazukommen, vielleicht noch mehr).

- Der Desktop (also die volle Installation) hat mich eben gerettet: Der Pi war nach Installation nicht erreichbar!
Das sind "Ausreden", glaube mir  ;D
ssh aktivieren nicht vergessen - und man braucht für  die Administration vieler, vieler Server Dienst nie wieder extra Monitor und Tastatur - Bios (gibt es beim Pi nicht)  und Problemfälle ausgenommen.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Thomas24568

Zitat von: passibe am 23 Januar 2025, 14:37:34Bitte dort die Uhrzeit,
Ich schreibe mal vorsorglich mit:
- 15:38 fhem service stop eingegeben
- 15:41 fhem.cfg initial usb auskommentiert
- 15:42 OS-Befehl "Neustart"
- 15:43 Pi5 per vnc erreichtbar
- 15:44 Webseite local + remote erreichbar
- 15:45 Wartezeit vor Neustart
- 15:48 Neustart
- 15:49 fhem Webseite ist erreichbar.

Das Problem ist damit wohl erledigt, die Ursache gefunden. Nur der Grund würde mich noch interessieren. Vorbeugend die Frage: Da der initial USB-Check jetzt "aus" ist, wie bekomme ich die USB-Adapter zu sehen? Das wäre einmal ein Z-Wave Master und ein esera E-Bus-Adapter. Vielleicht in Zukunft noch Weiteres.