nicht nur netzwerkkabel probieren auch die anderen dinge.
wenn das gerät woanders angeschlossen wird, ist das routing auch ein anderes, zumindest minimal (gut zu Hause wird dein Netzwerk wahrscheinlich nicht so komplex sein)

hast du mal den Switch im Keller stromlos gemacht?
Nicht dass da noch alte/korrupte Tables rumspuken

chat gpt 5.5 instant model

windows copilot habe ich schlechte erfahrungen gemacht.
schon lang deswegen nicht mehr benutzt

egal welcher windows client, die nutzen alle die vom betriebssystem bereitgestellten funktionen des netzwerk stacks

greifst du per hostname oder per ip zu?

wenn du kein anderes gerät findest das iobroker als hostname hat, ist der name ggfs noch im cache auf verschiedenen geräten

ggfs ist der name auch noch im cache deiner maschine von der du zugreifen willst.
das würde sich über die Zeit selber lösen, aber hier zur sicherheit noch

DNS cache löschen (also auf deinem windows rechner)
muss in einer shell mit administrator berechtigung ausgeführt werden

ipconfig /flushdns

dann den bonjour service neu starten, entweder auch über shell

net stop "Bonjour Service"
net start "Bonjour Service"

oder über taskmanager / Dienste

zusätzlich noch im router schauen ob du irgendwann mal den iobroker auf die ip adresse gemappt hast, da prüfen ob da noch die ip adresse stimmt, falls sie sich geändert hat

ggfs dann auch den windows rechner neu starten

ich habe das log file mit einer kurzen beschreibung in die ki geworfen, das ist das ergebnis

Die auffälligsten Punkte im Log:

1. Hostname-Konflikt

   avahi-daemon: Host name conflict, retrying with iobroker-2
   

   Der Rechner meldet sich erst als iobroker.local, dann erkennt Avahi einen Namenskonflikt und wechselt auf iobroker-2.local.

   Auswirkung: Zugriff über iobroker.local kann kurz funktionieren und danach abbrechen, weil der Name im Netz plötzlich anders aufgelöst wird.

2. IP-Adresse ist vorhanden

   eth0: Link is Up - 1Gbps/Full
   address 192.168.178.7
   NetworkManager state is now CONNECTED_GLOBAL
   

   Das Netzwerk selbst kommt hoch. Per IP 192.168.178.7 sollte der Rechner erreichbar sein.

3. mDNS/Avahi zieht Adresse kurz zurück

   Withdrawing address record for 192.168.178.7 on eth0
   Host name conflict, retrying with iobroker-2
   Registering new address record for 192.168.178.7
   

   Das passt sehr gut zur Beschreibung: erst erreichbar, dann nicht mehr — vor allem, wenn über Hostname statt IP zugegriffen wird.

4. SSH läuft

   sshd: Server listening on 0.0.0.0 port 22
   

   SSH ist nicht das Problem.

5. Spätere Netzwerkprobleme möglich

   systemd-timesyncd: Timed out waiting for reply
   

   NTP-Zeitserver antworten später nicht mehr. Das kann auf Routing/DNS/Firewall/Internetproblem hindeuten, erklärt aber nicht direkt den lokalen Verlust nach 1 Minute.

6. CIFS-Mount zu 192.168.178.6

   CIFS: Attempting to mount //192.168.178.6/a/Sicherungen/iobroker
   opt-iobroker-backups.mount: Deactivated successfully.
   

   Ein Netzlaufwerk wird versucht und kurz danach deaktiviert. Eher Nebenbaustelle, aber prüfen, ob dieser Mount beim Boot blockiert oder Fehler verursacht.

Wahrscheinlichste Ursache: Es gibt zwei Geräte mit dem Hostnamen iobroker im Netz oder ein alter mDNS/Avahi-Eintrag kollidiert. Zugriff über iobroker.local bricht deshalb scheinbar ab.

Empfehlung:

hostnamectl set-hostname iobroker-rpi
sudo systemctl restart avahi-daemon

Dann in der FritzBox/DHCP-Liste prüfen, ob ein zweites Gerät iobroker oder iobroker-2 existiert. Zum Test immer direkt per IP zugreifen:

ssh pi@192.168.178.7

Wenn IP stabil geht, aber iobroker.local nicht, ist der Fall ziemlich klar: Namensauflösung/mDNS-Konflikt.

Anbei das Journal
Journal.txt

Lt. Copilot wurde der PI nicht sauber heruntergefahren. Ist ja auch logisch, hatte keine Verbindung mehr.

Vorher hatte ich noch vergessen den IOB Diag mitzuschicken. (bei laufendem System im Büro)
iob_diag.txt

Hoffentlich kann mir jemand helfen. Ich kanns mir einfach nicht mehr erklären.

Gruß und Danke

Grubaer

die logdateien des iobrokers
und wahrscheinlich noch eher des raspy reinschauen
an was es liegt.

das könnte man wie folgt machen.
1.start an kellerposition bis er nicht mehr funktioniert
2. dann raspi an position geben wo er funktioniert und starten
3 dann systemlog des letzten starts anschauen

journalctl -b -1

im speziellen nach ERROR oder auch WARN schauen