Totalausfall PV wegen ausfall ve-can auf cerbo!

Other languages Deutschsprachiger Bereich
21

Stell’ den Trigger mal bitte trotzdem etwas höher. Meiner Erfahrung nach ist der watchdog zu schnell mit dem Neustart. Die meisten Lastspitzen sind kurz genug, daß sich das System von alleine wieder erholt, aber dabei kann der max-load-5 durchaus mal für eine Minute auf 8 oder 9 steigen. Dann reagiert das System zwar langsamer, aber läuft weiter. Beim Neustart läuft es für eine Minute gar nicht, daher betrachte ich den Watchdog als letzten Notnagel, wenn was wirklich aus dem Ruder gelaufen ist.

Die häufigen Verbindungsprobleme sind nicht normal. Eine CPU-Last von “3.40” bedeutet übrigens nicht, daß die Last 3-fach zu hoch wäre, sondern nur, daß im Mittel etwas über drei Tasks in der Warteschlange sind, um Rechenzeit zugewiesen zu bekommen.

22

hallo,

ich weiss, aber ich beseitige lieber die ursachen fuer probleme, als nur die symptome zu bekaempfen.

ich habe auf den beiden cerbos jetzt einmal das vrm deaktiviert. dafuer zu sorgen, dass internetprobleme nicht zu neustarts fuehren, wenn der automatische neustart bei verbindungsproblemen deaktiviert ist, dafuer ist victron zustaendig!

und bei einer avarage load, die normalerweise unter 1-2 liegt, ist die aktuelle einstellung auch kein problem.

ich habe auch einen verdacht, was an der hohen load schuld ist, die uebertragung der kompletten mqtt-daten nach dem verbindungsaufbau ans vrm! ich musste deshalb bei mir schon ueber den mqtt-client die daten filtern, weil die alle 30s uebertragen wurden, nachdem ich die firmware aktualisiert hatte und mein programm diese datenmenge einfach nicht so schnell verarbeiten konnte. in 1 s wurden soviele daten geschickt, dass das programm ca. 25s fuer die verarbeitung brauchte!

hier wuerde es sehr helfen, wenn victron die mqtt-daten nicht auf einmal, sondern mit einer begrenzten rate uebeetragen wuerde, wobei geaenderte daten natuerlich bevorzugt uebertragen werden. eine einstellbare datenrate waere sehr gut, aber 60s fuer die uebertragung der nicht geaenderten daten waeren auch ok. ich muesste mal ausrechnen, wieviele datensaetze/sekunde das waeren!

mit dieser hohen datenmenge werden dann sehr langsame verbindungen minutenlang blockiert!

wo ich aber moeglichst schnell eine loesung brauche, ist das can-bus problem. bei meinem bekannten kann ich problemlos auf vedirect fuer die mppts ausweichen, bei mir ist das schwierig, weil ich schon zuviele mppts am 48V-system habe, so dass ich schon die vedirect-geraete nicht mehr alle an einen cerbo haengen kann. aber da ich dort 3 cerbos habe, kann ich die ein wenig verteilen. das macht nur die steuerung nicht einfacher, wenn man 3 cerbos mit mppts, 2 bms und 2 vebus-systemen in einem system, weil man verschiedes unabhaeng voneinander steuern will. dass die dvcc-spannungssteuerung ohne bms nicht funktioniert, ist auch keine hilfe!

tschuess

23

Ich auch, aber in meinem Fall war ich außerstande, eine eindeutige Ursache zu finden. Der Maulkorb für den watchdog hat für mich die Reboots dauerhaft eliminiert. Und an meinem Cerbo GX hängen ja mehr Geräte dran wie offiziell zulässig, plus Node-Red zur Regelung der Nulleinspeisung.

Das geht schon. Muß nur ein entsprechendes Interface an USB, z.B. mit USB-Hub und den Adaptern von Victron, oder ohne Hub mit Anschluß für vier Geräte von Duppa aus Italien.

24

hallo,

wenn ich die ursache fuer die neustarts nicht zufaellig gefunden haette, wuerde ich das auch so probieren, aber die kenne ich ja: kommunikationsprobleme mit dem vrm!

schwieriger war es mit dem totalabsturz der firmware 3.66, wo ich jedesmal den cerbo stromlos machen musste, damit er wieder funktioniert hat!

das mit dem usb-hub funktioniert so leider nicht. spaetestens mit 11-12 vedirect-usb-adaptern ist schluss. die sind zwar besser als die adapter, die ich hier habe, bei denen ist schon bei 5-6 spaetestens schluss, dann ist der usb-bus ueberlastet, weil das nur usb-1.1 adapter sind und mehr schafft der bus dann nicht mehr, wegen der begrenzten bandbreite!

ich kann es aber mal mit usb 2.0 adaptern probieren.

leider kommt es auch noch auf die kommunikation mit dem adapter selbst an, wieviele man davon installieren kann. an einem usb-netwerkserver brauchte einer der usb-seriell-adapter ganze 5 MByte/s an bandbreite! es gibt hier also erhebliche unterschiede.

ich hatte einmal an einem cerbo 30 vedirect-geraete eingebunden, aber ueber das netzwerk und nicht lokal. da kam ich dann aber an die leistungsgrenze der CPU!

nur hilft mir das alles nichts bei dem can-bus-problem! wenn das nach den letzten aenderungen immer noch auftritt, werde ich ja vieleicht herrausfinden, was die ursache ist. oft finde ich solche fehler naemlich, wenn ich das system nur lange genug beobachte! irgendwann faellt mir dann eben irgendeine kleinigkeit auf, die mir weiterhilft. aber in dem fall wird wohl nur victron das problem dauerhaft loesen koennen!

ich verwalte hier mit einem eigenen programm aktuell 49 vedirect-geraete und kann problemlos noch weitere einbinden. aber die haengen alle an seriellen portservern an 5 stellen im haus! und die sind in 5 oder 6 verschiedenen systemen installiert! mit der letzen aenderung am system wird jetzt auch der spannungsabfall auf der leitung von ein paar mppts kompensiert!

tschuess

25

Sorry, das ist Quatsch in vieler Hinsicht.

  1. Hab ich dir im damaligen Thread erklärt, dass du mit deinem Keep-Alive den 30s-full publish triggerst - und wie du das NICHT tun kannst.

  2. Wenn dein Script nicht mit 6.000 oder 10.000 Werten umgehen kann - warum subscribst du dann auf diese MQTT-Topic? Subscribe doch einfach auf die 35, die du brauchst. Das ist der Sinn von verschiedenen Topics im Broker.

  3. VRM tut genau das (nur 1x full publish request, normaler keepalive und selektive subscriptions) und verursacht daher einen Load im kB Bereich während der Live View - das sollte deiner Internetstabilität nichts anhaben können.

26

hallo,

hast du meinen text gelesen? wenn eine neue verbindung zum vrm aufgenaut wird, werden mit sicherheit vom vrm ALLE mqtt-daten abgerufen, damit die daten auf einem aktuellen stand sind. erst dann werden nur die aenderungen uebertragen!

und was glaubst du wohl, was passiert, wenn die internetverbindung lange genug weg ist, dass durch einen timeout die verbindungen beendet werden und eine neue verbindung zum vrm aufgebaut wird!

wenn das nicht so ist, dann erklaer mit bitte, warum internetprobleme dazu fuehren, dass die avg-load auf ueber 10 hoch geht, wo das system doch nur eine EINZIGE internetverbindung aufbaut, naemlich die zum vrm!

und ich habe meine programme inzwischen entsprechend geaendert, so dass sie nur einmal alle daten anfordern und der mqtt-client filtert die schon mal soweit vor, dass selbst dann, wenn alle 30s alle daten gesendet werden, keine probleme mehr auftreten. das vrm wuerde sich darueber aber bestimmt freuen, denn das muss die daten auch verarbeiten und jetzt rechne dir mal aus, was passiert, wenn das 1000 mal soviel daten verarbeiten muesste!

du musst immer auch den kontext beachten, es geht hier nicht um ein problem bei der datenverarbeitung sondern um einen staendigen verbindungsabbruch zum vrm auf dem cerbo und seine folgen!

du kannst aber gerne einmal bei deinem gx zyklisch die netzverbindung trennen und wieder herstellen. ich denke 30-60s waere ein gutes intervall, eventuell mal variieren. dann siehst du ja, was passiert.

tschuess

27

Nein werden sie nicht. VRM schickt einen initialen full-publish request, sodass der Broker LOKAL alle Topics erzeugt. VRM selbst hat davor nur auf eine Hand voll - für die Live View nötigen - Topics subscribed.

Nichts, denn das cerbo ist der Server VRM Live View nur der Client. Solange also das Internet down ist, macht der lokale Broker nichts mehr weiter, weil er keine keep-alives mehr bekommt.

Beachte dass alle Daten für VRM abseits der Live View NICHT via MQTT ubertragen werden, sondern gemäß deines konfigurierten reporting Intervals via VRMLogger / HTTPS.

28

hallo,

es ist mir absolut egal, wie der cerbo die daten zum vrm uebertraegt!

auf jeden fall habe ich 3 offene verbindungen gefunden:

nslookup 63.176.63.169
169.63.176.63.in-addr.arpa name = ec2-63-176-63-169.eu-central-1.compute.amazonaws.com.

nslookup 18.159.56.224
224.56.159.18.in-addr.arpa name = ec2-18-159-56-224.eu-central-1.compute.amazonaws.com.

nslookup 18.198.160.64
64.160.198.18.in-addr.arpa name = ec2-18-198-160-64.eu-central-1.compute.amazonaws.com.

diese 3 verbindungen sind nur offen, wenn eine vrm-verbindung exisitiert!

und als ich das problem damals analysiert habe, wurde die gleiche datenmenge ins internet uebertragen, die ich auch lokal bekommen habe und es wurde automatisch ein keep-alive gesetzt, der verhindert hat, dass die daten alle 30s uebertragen werden! ich muss also auf jeden fall davon ausgehen, dass das vrm zugriff auf den mqtt-server hat!

aber das spielt alles keine rolle, bei internetproblemen werden die cerbos regelmaessig neu gestartet und das in teilweise sehr kurzen intervallen und zwar ueber die watchdog und die avg load!

aber das ist ja inzwischen soweit geklaert, das titelthema aber noch nicht: warum faellt der can-bus ganz aus oder es kommt zu falschen und fehlenden anzeigen auf dem cerbo?

ich gehe einmal davon aus, dass es heute nacht keine neustarts des cerbos geben wird, wenn das internet wieder mal spinnt!

dass sich aus einem fehler aber auch immer gleich mehrere baustellen und probleme ergeben muessen!

tschuess

29

Das ist häufig die Natur der Sache, und das “beobachtbare Problem” ist an absolut anderer Stelle als die eigentliche Ursache :melting_face:

Hast du das can problem seit einem venus update? Wenn ja, welche Version hast du gerade?

30

hallo,

das problem tritt mit venus-os 3.54 und 3.67 auf, aber erst seit ca 1-2 wochen!

die mppts habe ich inzwischen alle aktualisiert und ich bin noch dabei, verschiedene andere moegliche ursachen zu ueberpruefen. da an dem system nichts geaendert wurde, als das problem aufgetreten ist, habe ich das vrm in verdacht!

denn das kann durchaus dafuer sorgen, dass mppts nicht mehr angezeigt werden, was dann auch passiert, wenn man die seite fuer die firmware-updates aufruft!

auf jeden fall werde ich das mal weiter beobachten!

was mir noch kummer macht ist aber die tatsache, dass ein cerbo immer noch regelmaessig mit load to high neu gestartet wird. ich habe jetzt einmal die einstellung der watchdog geaendert, so dass der neustart nicht mehr ausgeloest werden sollte.

zumindest die neustarts wegen problemen mit dem internet konnte ich beheben, indem ich das vrm abgeschaltet habe.

tschuess

31

Hallo, es gab eine Serie von Cerbos, die spinnen, frag deinen Händler, der wird die Seriennummer wissen wollen!

32

hallo,

die cerbos liefen jetzt seit ca. 2 jahren ohne probleme, wenn die spinnen, dann kann das nur die firmware sein. aber sie haben erst jetzt einen firmware-update bekommen. die probleme fingen an, ohne dass irgend etwas am system geaendert wurde.

aber ich bin noch bei der analyse des problems, nur eines ist schon mal sicher, einige probleme kommen von firmware-bugs oder falschen/schlechten einstellungen seitens des herstellers!

fuer ein problem mit dem cerbo ist aber eine gestoerte internetverbindung verantwortlich. dass sowas zu problemen fuehrt ist klar, aber es duerfte nicht zu einem automatischen neustart des systems fuehren und das teilweise im abstand weniger minuten!

und es ist ja auch auf jeden fall auffaellig, wenn der cerbo jedesmal neu startet, wenn der wlan-router mit switch neu startet!

tschuess

33

Habe ich weiter oben schon geschrieben.
Das VE.Can Problem mit den Cerbo MK2 wurde schon vor ein paar Monaten mit der 3.60 behoben.

Andere VE.Can Probleme wären mir nicht bekannt.

34

War bei mir auch so: jahrelang gut (seit 2021) und auf einmal ging’s los, mein Händler hat nach Bekanntgabe der Seriennummer sofort auf Garantie eine neue geschickt
Frohes Fest!

35

hallo,

das problem dabei ist, erst einmal feststellen, was die ursache ist und das gleiche problem gleichzeitig auf 2 verschiedenen cerbos, die unterschiedlich alt sind, ist doch sehr auffaellig und normalerweise nicht auf die hardware zurueckzufuehren!

da sind erst mal weitere analysen noetig!

tschuess

36

hallo,

wisst ihr, was komisch ist? ich habe bei den cerbos, bei denen es probleme mit dem can-bus gab, gestern morgen oder vorgestern das vrm deaktiviert und vorher ist der fehler durchaus mehrmals taeglich aufgetreten, seit dem deaktivieren des vrms aber nicht mehr!

mal sehen, wie lange das so bleibt.

aber da muss man sich doch die frage stellen, was das vrm beim cerbo abfragt, dass es dadurch zu einem kommunikationsproblem oder einem ausfall des can-busses fuehren kann?

wenn die systeme jetzt ueber weihnachten fehlerfrei druchlaufen, duerfte das der beweis dafuer sein, dass das vrm fuer die can-bus-probleme verantwortlich ist. ob dadurch ein bug in der software auf dem gx getriggert wird oder es ein anderes problem ist, muss man dann eben herrausfinden.

wenn es keine probleme mehr gibt, werde ich nach weihnachten das vrm einmal auf read only aktivieren, dann sollte das vrm ja aktiv keine anfragen an den cerbo schicken!

tschuess

37

Nur wenn das so sein sollte dass das VRM schuld daran ist, ist es aber auch komisch das du da der einzige bist der das Aufzeigt und die Tausenden von Cerbo alle anscheinend das nicht habe!
Ich hatte früher Probleme dass das VenusOS immer wieder mal weg und nicht mehr zu erreichen war, teilweise von einer halben Stunde und mehr. Script oder NR liefen dort nicht drauf und es war die v.3.4x installiert. Das Problem war einfach das VenusGX Gerät einfach ständig an ihre Grenzen gekommen ist und durch das immer wieder eine Pause gemacht hat. Auch auf den Cerbo ist es nicht optimal wenn man viele Script und NR mit vielen Nodes laufen hat, da kann auch der schnell mal an seine grenzen kommen und alle möglichen Probleme machen.

38

hallo,

ich habe auf dem cerbo nur soviel in node-red programmiert wie noetig, der rest meiner programme laeuft auf einem odroid-m1. aber gewisse dinge muss ich nun mal auf dem cerbo direkt in node-red laufen lassen, weil ich sonst nicht auf einen netzwerkausfall reagieren kann!

abgesehen davon, wenn es 2 jahre problemlos lief und dann ploetzlich fehler und ausfaelle auftreten, ohne dass irgend etwas geaendert wurde, was glaubst du denn, was dann noch fuer moeglichkeiten uebrig bleiben?

und es ist nun einmal so, dass das vrm einen vollzugriff auf den cerbo hat und keiner ausser victron weiss, was es dort alles macht.

wenn man z.B. ueber das vrm firmware-updates einspielt, ruft es ab, welche geraete installiert sind, bei denen man eine neue firmware installieren kann und bereits dieser scan fuehrt zu anzeigefehlern auf dem cerbo oder der anzeige, dass das geraet nicht vorhanden ist.

warum greift victron dafuer nicht auf die informationen zurueck, die sie sowieso schon vom cerbo bekommen haben und scannt stattdessen jedesmal wenn die seit fuer den firmwareupdate geladen wird, alles nochmal. bei 20 geraeten, die aktualisiert werden, sind das dann 21 scans, wobei einer mit sicherheit ausreichend waere, denn mit jedem scan wird die datenverarbeitung auf dem cerbo definitiv gestoert!!!

probier es doch selbst mal aus, beobachte die remote-console waerend du im vrm einen geraetescan startest!

es kann zwar sein, dass das bei sehr wenig geraeten nicht auffaellt, aber wenn genug geraete installiert sind, bestimmt!

bisher habe ich das zwar nur bei den mppts und dem vebus-system (bei der fernkonfiguration) festgestellt, aber nur beim vebus-system ist das normal. das passiert auch, wenn ich einen mk2/3 mit einem pc anschliessen und die konfigurations-software starte!

selbst auf einem system, auf dem node-red viel cpu-leistung braucht, achte ich darauf dass das immer weniger als 50% sind. normal sind da sogar eher weniger als 30%!

tschuess

39

hallo,

das problem mit den datenfehlern ist wieder aufgetreten, aber noch arbeitet der can-bus:

can-bus4
can-bus4502×295 24.5 KB

can-bus
can-bus491×291 20.5 KB

can-bus1
can-bus1497×289 17.5 KB

can-bus2
can-bus2501×297 18.3 KB

can-bus3
can-bus3504×298 13 KB

es ist, laut can-bus-statistik, ein fehler und ein overrun aufgetreten, ausserdem gingen daten verloren. das mit den verlorenen daten scheint aber keine auswirkung zu haben, was die anderen beiden fehler angeht, weiss ich das nicht!

in der geraeteliste fehlen aber wieder die namen der mppts, nach einem neustart sind die wieder da, und bei der history fehlen immer alle daten von gestern, wenn dieser fehler auftritt!

da aber alle aktuellen werte noch vorhanden sind und sich die mppts noch steuern lassen, ist das kein so grosses problem, aergerlich ist es aber trotzdem!

dieser fehler hat auch wieder auf 2 systemen zugeschlagen, ob gleichzeitig oder zeitversetzt, kann ich aber nicht sagen!

mein system habe ich inzwischen neu gestartet, um meine ueberwachung zu erweitern, damit ich von node-red aus feststellen kann, wenn dieser fehler aufgetreten ist! ueber meine datenbank geht das leider nicht, da ich die daten, die jetzt fehlen nicht zyklisch speichere, auch wenn sie in der tabelle mit den aktuellen daten vorhanden sind!

ich glaube auch nicht, dass dieses problem mit node-red zusammen haengt, auch wenn ich die steuerung, die node-red auf dem cerbo uebernimmt, von einem anderen system ueber mqtt machen koennte!

mal abgesehen davon, dass node-red und das steuerungsprogramm schon seit der installation auf den cerbos laufen und es bis anfang des monats auch keinerlei probleme gab!

und es ist auch sehr seltsam, dass in der can-bus-geraeteliste die mppts mit ihrem richtigen namen stehen, in der geraetliste aber nicht!

tschuess

40

Wenn Fehler ohne Konfigurationsänderung auftreten, könnte auch ein Hardwareproblem “eintreten”.

Wenn Bauteile altern, weichen sie immer mehr von ihrer eigentlichen Spezifikation ab - und irgendwann uberschreiten sie sporadisch irgendwo Toleranzen.

Wegen der CPU Load: Je nachdem wie voll du dein cerbo packst, ist das natürlich ein enges Thema.

Venus logt bei einem Watchdog Neistart die aktuelle Ausgabe von top unter /data/log/watchdog_processlist.txt - könntest mal reinschauen, ob dort wiederholt der selbe Prozess ganz oben steht.

Momentan ist ja die gui-v1 noch voll aktiv, dieser prozess benötigt bei mir zuweilen eine gute Menge CPU, obwohl ich die v1 uberhaupt nicht mehr benutze.

(Mein cerbo ist aber auch mit allerhand dev-dingen zusätzlich beladen, “normal” pssst das ins Budget)

Ich habe daher ein svc -d /service/start-gui gemacht und auch glrich in die /data/rc.local geschrieben, ohne den läuft mein gx viel load-freier, und startet nur außerplanmäßig neu, wenn ich dran Schuld bin :stuck_out_tongue: