da ich bei mir schwer am umbauen bin, war heute das netzwerk dran und da ich da wohl ein kabel falsch gesteckt hatte, war fuer einige zeit das netzwerk ausgefallen.
das war auch fuer die meisten geraete kein problem, ausser fuer den neuesten cerbo-gx mk2, der anfing zu piepen und die netzwerkschnittstelle deaktiviert hat.
nachdem das netzwerk wieder lief musste ich einen spannungsreset machen, um den cerbo neu zu starten!
dieses problem hatte ja auch schon der cerbo (gleiches modell) devor, als meine fritzbox, die ich dort als switch und wlan-basis im einsatz hatte, verrueckt gespielt hat! auch da half es nur, die spannung abzuklemmen, um den cerbo neu zu starten!
warum wird die lan-verbindung nicht einfach wieder aktiviert, wenn das netzwerk wieder geht. ob das wlan noch funktioniert hat, habe ich nicht ausprobiert, deshalb kann ich auch nicht sagen, ob der cerbo noch ueber das wlan erreichbar war.
hat irgendjemand schon mal aehnlicher erfahrungen gemacht?
Normalerweise sollte das schon funktionieren, ich habe in meiner Testumgebung schon häufig im laufenden Betrieb das LAN Kabel abgezogen und wieder angesteckt.
Auch in Kundenanlagen, bei der Wartung o.ä., wird mal das Kabel abgezogen oder der Router/Switch neu gestartet und idR gibt es da keine Probleme.
Falls doch macht man eben mal einen Neustart des GX Gerät.
Die meisten Systeme, die wir installiert haben bzw. betreuen, brauchen aber auch kein Netzwerk um zu laufen, da keine wichtigen Anlagenbestandteile ĂĽber Netzwerk eingebundene sind.
Aber es gibt auch die Option in den Einstellungen des GX Geräte, das nach Zeit X automatisch neu gestartet wird, wenn es keine Verbindung mehr zum Netzwerk/VRM Portal gibt.
Du musst nicht gleich wieder von einem einmaligen (vermutlich nicht reproduzierbaren) Problem auf einen Bug in der Software schlieĂźen.
der fehler ist zwar erst aufgetreten, nachdem ich einen switch getauscht hatte, wobei der cerbo am switch davor haengt, aber die letzten ausfaelle wurden definitiv nicht mehr durch probleme im netzwerk verursacht.
ich kann mich auch noch sehr gut daran erinnern, dass ich probleme hatte, eine ganz bestimmte datei von meinem alten novell-server zu kopieren, weil eine bestimmte zeichfolge in der datei dazu gefuehrt hat, dass der netzwerktreiber deaktiviert wurde. es ist also nicht auszuschliessen, dass es hier ein aehnliches problem gibt.
ich werde einmal einen downgrade auf die 3.70 vorbereiten und ich kann das system ja einmal so umstellen, dass nur das wlan aktiv ist und nicht mehr das lan. wenn es der treiber ist, sollte der cerbo dann ja nicht mehr abstuerzen.
hast du dir einmal das letzte log angesehen, da kam es definitiv zu einem software-problem, da der kernel einen trace geschrieben hat und davon habe ich mehrere im gesamten log gefunden! und jedesmal wurde eine verbindung zum lan-treiber gemeldet.
der error-count zaehlt fleissig hoch, nach der deaktivierung und reaktivierung des can-busses ist wieder alles ok!
da muss ich jetzt wieder den automatischen can-bus-reset einbauen, weil victron das nicht geregelt bekommt. aber hier gibt es wenigstens eine loesung, um das problem zu beheben. bei einem softwarefehler im treiber leider nicht!
ich werde es jetzt einmal mit einem downgrade auf version 3.70 probieren, ansonsten wlan funktioniert noch, so dass ich den cerbo auch ohne lan benutzen kann.
ich habe auch einmal probiert, die lan-schnittstelle von hand zu komfigurieren. das funktioniert zwar, aber die schnittstelle funktioniert danach trotzdem nicht wieder, hier hilft leider nur ein reboot!
Ich habe mir mal dein Log angesehen und was ich sehe sind “Martial Packets”. Die wollen irgendwo hin, wo es kein Ziel gibt.
Ein guter Router, selbst eine Fritzbox wertet das Angriff. Und schwups, bist du raus.
Deiner Netzwerk-Karte wird gesagt : Nö und die Verbindung ist weg.
Also such erst mal in Deinem Node-Red-Wahn und finde den Fehler!
Mein System läuft seit 3 Jahren in einem komplexen LAN und ich hatte niemals einen Netzwerkfehler.
uns wieso betrifft es dann nur den einen cerbo und nicht alle und wieso wird ein trace geschrieben und zwar vom lan-treiber!
und es gab ein problem mit dem shelly, auf den der cerbo zugreift, der hat auch einen bug in der software, wenn die weboberflaeche dauerhaft auf ist, dann gibt es verbindungsprobleme. allerdings greift der cerbo nicht direkt darauf zu, sondern auf die daten von einem mqtt-server.
und ich konnte die lan-karte auch nicht mehr reaktivieren und waere das die firewall gewesen, haette daruber auch etwas im log stehen muessen!
ich habe jedenfalls gestern abend die firmware 3.70 installiert, die laeuft auf dem anderen baugleichen geraet naemlich problemlos, seitdem sie dort installiert ist, waerend es mit der aelteren 3.6x auf dem geraet auch probleme gab!
abgesehen davon, das wlan war ja weiterhin verfuegbar und dort landen die gleichen packete, wenn die nicht direkt an die mac-adresse adressiert sind!
ich werde ja sehen, ob das teil morgen auch noch laeuft!
es kann sein, dass ich das netzwerkproblem gefunden habe. es besteht eine sehr hohe warscheinlichkeit, dass ein tp-link gigabitswitch daran schuld ist. ich hatte schon einmal probleme mit so einem switch der schon aelter war. in ein paar tagen werde ich sehen, ob es weiter fehlermeldungen hagelt oder nicht mehr!
ich hatte auch schon mal einen switch, der das ganze netzwerk lahmgelegt hat! es ist schon verdammt aergerlich mit den komponenten, die zwar noch so tun, als wuerden sie funktionieren, in wahrheit aber nur noch chaos anrichten!
wenn das netzwerk jetzt wieder fehlerfrei funktioniert werde ich den switch mal komplett ausbauen und schauen, ob da nicht auch ein paar kondensatoren defekt sind.
uebrigends haben sich inzwischen weitere cerbos vom lan verabschiedet und die schnittstelle ist ausgefallen, wlan hat aber noch funktioniert. und alle hatten eine firmware >= 3.70. die mit einer aelteren firmware haben keine probleme gemacht!
das netzwerkproblem habe ich jetzt erst einmal geloest und die beiden 7590er fritzboxen in ein eigenes vlan befoerdert. seitdem die nicht mehr im hauptnetz haengen, gibt es jedenfall nur noch die ueblichen probleme und keine ausfaelle mehr und jetzt werden ich den restlichen ursachen fuer ping-timeouts zu leibe ruecken! und es wird fuer die PV ein eigenes vlan geben!
