Neues YouTube-Video: Visualisierung im Devices-Adapter

[grubaer]

Ich habe ein ganz sonderbares Problem mit meinem Raspi. Ich habe gestern mal wieder meine ganzen Updates installiert. Hatte ich schon 4 Wochen nicht mehr gemacht. Folgende Befehle habe ich dazu ausgeführt.

-sudo apt update
-sudo apt full-upgrade -y
-sudo reboot
-sudo apt autoremove --purge -y
-sudo apt clean

Danach lief der Raspy nicht mehr. Erster Gedanke. Scheisse. Das ist doch schon wie bei Windows. Also Raspy vom Kellerschaltschrank hoch und ins Büro. Und juhuu, er funktioniert doch noch.
Dann wieder zurück in den Keller. Eine Zeit lang lässt er sich anpingen, dann ists aber bald wieder vorbei. Im Büro läuft er aktuell seit 4 Stunden ohne Probleme.

Ich will jetzt auch nicht groß auf die Historie eingehen. Fakt ist, dass er im Keller, mit gleichem Netzteil nur ca. 1 Minute funktioniert und im Büro ohne Probleme läuft.
PI hängt per Lan dran. Ich habe schon mehrere Switchports (auch Lan Kabel) und mehrere Steckdosen probiert, und leider keinen Erfolg. Das andere Gerät auf dem Switch (Cerbo GX von Victron) läuft auch ohne Problem. KI hat mich auch nur die Treppen rauf und runter gehen lassen.

Auch mit Verlängerungskabel und längerem Netzwerkkabel aus dem Schaltschrank (ca. 2m Entfernt) funktioniert er auch nicht. Ich bin absolut ratlos was das sein kann.
Hat jemand evtl. eine Idee woran es liegen könnte.

Danke im voraus.

• Adaptername: System selbst
• js-controller Version: 7.0.7
• Admin Version: v7.8.23
• Hardwaresystem: Pi4B (Cortex-A72)
• Arbeitsspeicher: 4GB
• Festplattenart: HDD
• Betriebssystem: linux arm64
• Nodejs-Version: v24.15.0
• NPM-Version: 11.12.1
• Image, Docker genutzt: Nein

[OliverIO]

@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

[Homoran]

@grubaer ich hab das mal hierhin verschoben.
Ein Bug von ioBroker wird es wohl nicht sein.

[grubaer]

So nach Startschwierigkeiten für das Journal habe ich es jetzt endlich geschafft. Schön langsam habe ich Beine wie ein Eiskunstläufer vom Treppen steigen :)

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

[Homoran]

@grubaer bitte keine Dateien sondern als Text in code-tags posten.

[OliverIO]

@grubaer

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.

[OliverIO]

@grubaer

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

[grubaer]

Erste Frage. Welche KI war das. Copilot und Gemini haben mich total in die Irre geführt. Ich greife mit Mobaxterm und der IP auf den IO-Broker zu. Egal ob Büro oder Keller. Nach einen "Absturz" zeigt er mir auch keinen Ping mehr an.

[OliverIO]

@grubaer

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

[Homoran]

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

[grubaer]

Dann muss ich da auch mal hinwechseln. Ich bin gerade am überlegen, ob es irgendwo an meinem Netzwerk liegt. Im Prinzip ist eine Hauptfritzbox 7590, da geht ein Patchkabel an einen größeren Switch. Und im Keller habe ich nochmal einen kleinen Switch. Die Switches sind alle unmanaged. Ich habe auch mal im Keller den Switch übergangen und mit so einem Patchverbinder verbunden. Hatte allerdings auch keine Verbesserung gebracht.

[OliverIO]

@grubaer
ja, das ist das selbe cache thema, am besten auch auf allen geräten die auf der strecke liegen. bei router und switch dürfte es nur die arp table betreffen und die reagiert eigentlich schneller, insbesondere wenn das gerät mit der ip/mac kombination nicht mehr erreichbar ist.

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

[grubaer]

Aber das ist eine Gute Idee. Ich hab normalerweise noch irgendwo ein 25m Patchkabel rumliegen. Evtl. test ich da morgen mal ein paar Ports durch. Aber heute kann ich nicht mehr. Frau steht schon midm Kochlöffel da.
Ich möchte dir dann noch sehr bei dir bedanken. Ich meld mich auf jeden Fall wieder, wenn ich was neues weiß. Schönen Abend noch

[OliverIO]

@grubaer

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)