Hallo,
ich betreibe mein Netzwerk mit Komponenten von Unifi, was mir eine bessere Kontrolle über das Netzwerk ermöglicht. Der Router ist in dem Fall ein Unifi Cloud Gateway Max (kurz UCG).
Mein GX (Cerbo V2) ins nur über LAN angeschlossen und erhält die IP vom DHCP. Ich kann aber im UCG die IP manuelle eingeben, so das der DHCP immer die selbe IP zuweist.
Das GX meldet sich aber auch über einen zweite Verbindung an. Das führt dazu das unbekannte Geräte in meinem Netzwerk auftauchen, welche sich lediglich durch einen MAC- und eine IP-Adresse identifizieren. Dies ist erst mal nicht schlimm, aber die MAC und IP-Adresse ändert sich in unbekannten Abständen, so dass immer wieder scheinbar neue Geräte in meinem Netzwerk auftauchen, und Leichen übrig bleiben.
Wie man sehen kann ist die “Lokale IP-Adresse verknüpfen” identisch mit dem aktiven Gerät.
Wozu dient diese zweite Adresse, kann diese irgendwie deaktiviert werden, oder zu mindestens fest gelegt werden?
Ich möchte nicht unbedingt ein manuelle IP-Konfiguration im GX machen, da ich so alle Netzwerkgeräte über das UCG verwalten kann.
Ich möchte aber auch nicht immer wieder Leichen aus der Geräteübersicht des UCG löschen, außederm bekomme ich jedes mal ein Schreck, wenn ein unbekanntes Gerät in meinem Netzwerk auftaucht.
In dem Artikel steht, das das eine Art Reserve-Adresse ist, die verwendet wird, wenn das Gerät keine IP Adresse vom DHCP erhält.
Das GX hat aber eine Adresse, ist über diese im Netzwerk als auch vom VRM-Portal erreichbar. Im VRM-Portal wird diese sogar richtig angezeigt.
Da einzige wo das GX keine IP erhält ist auf der WLAN-Schnittstelle. Versuchsweise hab ich mal auch die WLAN-Verbindung zugelassen. Das GX meldet sich dann mit einer dritten IP an. Die 169.254.13.87 beliebt trotzdem erhalten. Also am WLAN-Port kann es dann nicht liegen.
Verwende auch Unifi, allerdings eine UDM und Cerbos über Wifi angebunden. Sehe keine doppelten IPs oder generische MAC Adressen, auch bei einem Neustart vom Cerbo taucht nur eine einzelne MAC auf im Log.
Heute ist es wieder passiert. Das interessante daran ist, das der Cerbo einen Neustart aus unbekannten Grund gemacht hat. Das war um 11:34. Ich hab es daran gesehen, das in meinen Graphen in HomeAssist die Kurven für 1-2 Minuten fehlten. Auch meine Anzeigen von NodeRed, welches auf dem GX läuft beginnen an diesem Zeitpunkt neu. Das GX ist noch über das VRM-Portal erreichbar, aber die RemoteKonsole funktioniert nicht mehr aus dem lokalen Netz. Das war so gegen 12:15. Jetzt (12:50) wo ich die Zeilen schreibe, und nochmal nachschauen wollte was die RM ausgibt, funktioniert sie wieder.
Hat jemand eine Idee, was den Rest ausgelöst haben kann? Das Netzwerk, als auch die Internetverbindung scheinen keinen Ausfall gehabt zu haben. Außerdem ist der Cerbo nicht konfiguriert bei Ausfall der VRM-Verbindung neu zu starten.
Danke, Logs schau ich mir mal an. Hast du da einen Tip wie ich am besten einsteigen kann. Da gibt es ja ne menge Logs, und ich versteh nur die Hälfte wenn überhaupt. Mit Linux kenne ich mich nur begrenzt aus.
Ne die sich ändernde LLA ist nur die Folge des Reboots.
Hier gabs schon mal ein Thema/Topic, wo das sporadische Booten des gx OS besprochen wurde. Hing damals an der Auslastung des Systems, war damals sehr viel installiert.
Die log names sind selbstredend.
/data/log/dmesg und
/data/log/messages
wären ein Anfang.
Dort nach den Zeitstempeln Deines Reboots suchen und schauen…
Unter linux gibts zwei schöne tools dazu:
tail ((ohne parameter) zeigt das Ende der Datei
less (kann man mit PgUp un PgDn) blättern
mit grep kann man in den Logfiles schön nach bestimmten Begriffen suchen
Lies man im inet ein bissel über die command genaue syntax!
Hier noch zwei gute Informationsquellen.
gx GUI:
root access
ABER BITTE ALLES MIT VORSICHT AUSFÜHREN!
EIN VERSEHENTLICHES DELETE MACHT EIN DELETE OHNE RÜCKKEHR!
Hier im Forum gibt es venus OS Cracks, die können Dir sicher besser weiterhelfen.
In messages.0 hab ich was gefunden. Der Zeitstempel hat zwar eine Stunde Versatz, aber das hat bestimmt mit der Winterzeit was zu tun.
Hier die Daten aus dem Log, bevor das GX neu gebootet hat:
Feb 18 02:37:16 einstein cron.info CROND[19714]: (root) CMDEND (/opt/victronenergy/swupdate-scripts/check-updates.sh -auto -delay)
Feb 18 10:30:50 einstein daemon.err watchdog[512]: loadavg 8 7 7 is higher than the given threshold 0 10 6!
Feb 18 10:30:50 einstein daemon.err watchdog[512]: repair binary /usr/sbin/store_watchdog_error.sh returned 253 = ‘load average too high’
Feb 18 10:30:50 einstein daemon.alert watchdog[512]: shutting down the system because of error 253 = ‘load average too high’
Feb 18 10:30:50 einstein daemon.err watchdog[7511]: /usr/sbin/sendmail does not exist or is not executable (errno = 2)
Feb 18 10:30:52 einstein syslog.info syslogd exiting
Feb 18 10:33:02 einstein syslog.info syslogd started: BusyBox v1.36.1
Feb 18 10:33:02 einstein kern.notice kernel: klogd started: BusyBox v1.36.1 ()
Feb 18 10:33:02 einstein kern.info kernel: [ 0.000000] Booting Linux on physical CPU 0x0
Sieht wohl nach einer Überlastung aus. Auf dem GX läuft NodeRed, in dem meine Steuerung der Anlage programmiert ist. Mit “top” hab ich mir mal die Systemauslastung anzeigen lassen. Die Prozessorauslastung liegt irgendwo zwischen 40% - 50%. Da ist eigentlich noch genug Reserve.
Das System lief aber seit der Umstellung auf den Cerbo (vorher RPI) im letzten Jahr unauffällig. Ich habe vor kurzem ein Energymeter VM3P75CT installiert. Dieser ist am ve.CAN2 angeschlossen, aber hat auch einen LAN-Verbindung. Ich hatte gehofft, über letztere direkt auf das Energymeter zuzugreifen, um damit die Daten in Homeassist anzuzeigen, was aber nicht ohne weiteres funktioniert. Daher greife ich die Daten nun vom GX am.
Vielleicht liegt es an der doppelten Anbindung. Ich werde mal die LAN-Verbindung trennen.
Ich kenne das mit den zwei VM3 in der gx Anzeige , weil ich von der anfänglichen LAN Anbindung zur VE.Can Anbindung aufgerüstet habe im Sommer. Ich hatte beide auch viele Tage beide aktiv, aber keine Pobleme mit dem gx. Das gx nimmt die VM3 Instanz #0 und ignoriert das LAN gekoppelte VM3. (Ist bei mir jetzt die Backupleitung für das erdverlegte VE.Can Kabel…)
DU hast den Grund f.d. Reboot, ein load problem.
Das geht aber über die LAN Schnittstelle des VM3, aber ich greife die VM3 Daten vom gerbo gx ab, hatte auch mal geschrieben warum. Der Vorteil der VM3 LAN Anbindung ist für mich, ich sehe es direkt in der VictronConnect App.
Hast Du evtl. sehr kurze Abfrageperioden im HA konfiguriert? Viele HA modbus Anfragen in zu kurzen Abständen stresst das cerbo gx. Der HA ist ja auch kein System, was im Sekundentakt requests machen soll/kann. Für die 100ms Updates aus dem VM3 ist der HA überhaupt nicht geeignet.
Ich habe in HA einfach nur die “Victron MQTT Integration” verwendet. Keine Ahnung ob da ein Zeitintervall für ein Request drin ist. Ich denke aber der zeiht sich die Daten vom Broker, und der bekommt sie vom GX. Also dürfte das GX dadurch nicht mehr belastet werden.
Was ich mittlerer Weile festgestellt habe, das NodeRed viel Prozessorleistung in Anspruch nimmt. Ich habe auch dauerhaft das NR-Dashboard offen. Das hab ich jetzt mal geschlossen und somit die Auslastung verringert.
In den Logs hab ich eine Datei gefunden. Ich denke mal das wird der top-Befehl zum Zeitpunkt des Auslösens des Watchdogs sein. Zu mindest deuten die Werte von load average darauf hin. weiter unten ist ein error, das er eine Datei nicht öffnen kann. Vielleicht ist das ja der Grund?
Bei mir aktuell 337 Entitäten. Die schau ich dann mal durch, da könne sicher welche deaktiviert werden, das ganze ESS hab ich ja gar nicht in Benutzung.
In NodeRed habe ich jetzt auch schon ein wenig aufgeräumt, und ein paar alte Sachen gelöscht die ich mittlerer Weile über HA mir anzeigen lasse.
Außerdem hab ich Signak-K gelöscht, wie es dognose in dem oben verlinkten Thread empfohlen hat. Dadurch ist jetz auf der root-Partition mehr Platz.
Hallo Steffen,
hab auch ein UniFi System und dasselbe Phänomen. Die MAC für die Backup-IP wird bei jedem Reboot zufällig neu generiert, die Haupt-MAC bleibt statisch. Kann man schön sehen, wenn man auf den Port am Switch schaut. Dort sieht man mehrere Einträge in der MAC-Table. Mich stört es aber nicht weiter, da ich den Cerbo GX fast nie reboote. Wenn doch mal, werf ich die “alte” Pseudo-MAC raus.
Ich habe das Standard-Image auf dem Cerbo. Hatte früher das Large inkl. Node-Red um allmöglichen Krimskrams zu steuern. Seit die GUI V2 eingeführt wurde, hatte ich auch häufige und erratische Reboots, was an der CPU Load lag. Ist die zu lange zu hoch, führt der Watchdog einen Reboot durch. Betreibe seither Node-Red extern und hole mir nur per Modbus-TCP die nötigen Daten vom Cerbo GX (brauche nur ein paar Werte). Seither ist Frieden.
Tipp - Hatte mir damals in VRM die DBUS Roundtrip Time und den Zustand der Quattros unter Erweitert als Widget hinzugefügt zur Diagnose. An der Roundtrip-Time habe ich immer gesehen, wenn er (augenscheinlich) zu viel Last hatte und am Status, wenn er kurz auf “Passthrough” ging, sah ich das er wieder einen Reboot gefahren hat. Seit der Rückkehr auf das Standard-Image läuft das System jetzt schon seit Monaten durch ohne irgendwelche ungewollten Reboots zu fahren.
, weil ich von der anfänglichen LAN Anbindung zur VE.Can Anbindung aufgerüstet habe im Sommer. Ich hatte beide auch viele Tage beide aktiv, aber keine Pobleme mit dem gx. Das gx nimmt die VM3 Instanz 
