Totalausfall PV wegen ausfall ve-can auf cerbo!

Other languages Deutschsprachiger Bereich
41

hallo,

so sah das beim letzten neustart aus:

Mem: 539376K used, 489616K free, 9344K shrd, 22528K buff, 169152K cached
CPU: 25% usr 24% sys 0% nic 0% idle 0% io 27% irq 22% sirq
Load average: 18.75 12.57 9.07 20/290 18027

das problem ist nicht die cpu-last, sondern die anzahl gleichzeitig laufender und aktiver prozesse, die nicht auf ein ereignis warten und da stehen in der liste nur diese prozesse als laufend drin:

1869 937 nodered R 218m 22% 3% node-red
931 917 root R 180m 18% 3% /opt/victronenergy/gui/gui -neatvnc 127.0.0.1
972 969 root R 29556 3% 3% {dbus_systemcalc} /usr/bin/python3 -u /opt/victronenergy/dbus-systemcalc-py/dbus_systemcalc.py
8727 1 avahi R 3012 0% 3% avahi-daemon: running [venus-2.local]
18017 18013 root R 2700 0% 3% top -b -n1
912 902 root R 35836 3% 1% /opt/victronenergy/venus-platform/venus-platform

den avahi brauche ich eigentlich auf keinem system, aber ich weiss auch nicht, ob victron den braucht. ich koennte ihn ja mal testweise auf einem unkritischen system deaktivieren!

das problem dabei ist nur, dass man mit top oder ps nie alle laufenden prozesse gleichzeitig erwischt und die load-statistik vom kernel kommt. einige der prozesse laufen ja auch nur fuer einen sekundenbruchteil, nur sind das dann zuviele, die gleichzeitig cpu-zeit brauchen!

ich lasse aktuell mal ein log im sekundentakt mitlaufen und eine load avg >7 kommt da recht haeufig vor!

und so sieht die aktuelle load-statitik ueber den protokollzeitraum aus:

anzahl load

94 0

2060 1
12257 2
19557 3
18382 4
10988 5
4729 6
1368 7
221 8
8 9

ich habe deshalb die config der watchdog schon 2 mal geaender, da ich auch schon mal eine spitzen load avg von ueber 18 hatte!

sowas taucht im log natuerlich nicht auf, da man dafuer schon genau den richtigen moment fuer die abfrage erwischen muss und ich die auch nicht im 1/10 sekunden takt erfassen will.

aber das problem mit der avg load laesst sich ja loesen, fuer das problem mit dem can-bus habe ich dagegen noch keine loesung. zumindest wenn in der anzeige daten fehlen, reicht es aus, den zu deaktivieren und wieder zu aktivieren, ob das auch reicht, wenn er komplett ausgefallen ist, weil ich noch nicht. aber wenn die anzeiger der namen und der statistik nicht mehr stimmt, hat das jedenfalls keine auswirkung auf die funktion! wenn die geraete aber garnicht mehr angezeigt werden, dann wirkt sich das schon aus.

mit bms schaltet dann die pv komplett ab und ohne laeuft sie mit den einstellungen des mppts weiter! das ist auch einer der gruende, warum meine mppts im 48V-system inzwischen fast alle an einem eigenen cerbo ohne bms haengen! aber die sind alle so eingestellt, dass es keine probleme gibt, wenn die steuerung ausfaellt und mein akku ist dafuer auch gross genug!

bei dem anderen system waere das auch kein problem, aber wenn die mppts keine steuerdaten bekommen, gibts einen bms lost und die schalten einfach ab!

tschuess

42

12.5 fĂźr den 5-minute average is Ăźbel hoch.

Ob das eine Auswirkung auf die CAN Stabilität haben kann, weiß ich nicht, für allgemeine systemstabilität is das auf jeden Fall nich gut.

Hast du irgendwelche 3rd party scripts laufen?
Ähnlich hohe Warteschlange hab ich mal bei einem shelly meter script gesehen, das alle 100ms einen fetch task gequed hat, aber das shelly via wlan ca 300ms response time hatte.

43

hallo,

abgesehen von den programmen node-red laufen keine fremden programme auf dem cerbo. allerdings ist auf dem system ein shelly 3em pro ueber websocket angeschlossen, also ueber ein script von victron.

aber node-red ist nur ein process, was sind dann die anderen 17 prozesse, die gleichzeitig laufen? dabei ist die cpu-last nicht mal so hoch, ich glaube fast immer weniger als 50%! und wenn sie mal hoeher ist, dann steht die gui mit ca. 30% auch immer ganz oben!

ich versuche prinzipiel die ganzen programme auf einem odroid-m1 laufen zu lassen und auf dem cerbo unter node-red nur soviel wie unbedingt noetig. dass node-red auf diesem cerbo mehr cpu-zeit braucht, liegt auch daran, dass ich ein paar diagramme erstellt habe, um das regelverhalten zu ermitteln und herrauszufinden, warum ich am netz leistungsschwankungen von bis zu +/- 300W habe!

ich habe inzwischen bei mir auch das vrm wieder aktiviert, aber bisher laeuft er ohne probleme mit den can-bus-mppts. vor weihnachten hatte ich auch immer mal wieder das problem, dass er die geraetenamen nicht mehr angezeigt hat, aber nur ein einziges mal waren die mppts aus der geraeteliste verschwunden. bei meinem bekannten war das aber fast jeden tag, teilweise auch mehrmals, der fall. wenn nur noch der mppt-typ anstatt der eingetragene name angezeigt wird, fehlern zwar daten, aber auf die steuerung hat das gluecklicherweise keine auswirkung!

ob sich auch im vrm die namen aendern, kann ich im moment nicht feststellen, da auf diesem cerbo das vrm noch deaktiviert ist. seitdem gab es aber auch keinen totalausfall des can-busses mehr! alles sehr seltsam!

set der letzten aenderung der watchdog-config laeuft der cerbo auch schon seit ueber 2 tagen ohne neustart!

die sache mit scripten auf dem cerbo habe ich auch nur einmal ausprobiert, aber weil das nicht zuverlaessig funktioniert hat, schnell wieder deinstalliert und benutze jetzt das virtual device in node-red oder steuere die gerate, indem ich die dafuer noetigen parameter direkt setze. leider fehlt mir dabei noch ein virtueller mppt und shunt. man kann nur einen akku und ac-leistungen einbinden. das finde ich schon bedauerlich! so koennte ich die PV-leistung meiner beiden anderen akkus nur ueber einen rs232-adapter und eine externe emulation eines shunts oder mppts einbinden! oder ich muesste sie als ac-pv ausgeben, dann passt das aber nicht zur akkuleistung!

tschuess

44

@thiemovanengelen @nickdb

hallo,

heute gab es wieder probleme mit den can-bus-mppts, weil die kommunikation ausgefallen war. dabei wurden diesmal alle mppts noch in der console angezeigt, aber die tracker fehlten in der anzeige komplett!

ich brauche dringend eine loesung fuer dieses problem oder ich muss die mppts alle von can-bus auf vedirekt umstellen!

wenn KEIN bms angeschlossen waere, waere das problem nicht so gross, dann wuerde die PV naemlich nicht komplette ausfallen!

die einfachste loesung waere ein reset des can-busses, sobald das system hier einen fehler feststellt.

tschuess

45

@M_Lange @thiemovanengelen @nickdb

hallo,

gibt es vieleicht wenigstens eine moeglichkeit, den can-bus ueber ssh oder node-red neu zu starten?

tschuess

46

@M_Lange @thiemovanengelen @nickdb

hallo,

ich habe jetzt venus-os 3.70 installiert, aber das problem besteht immer noch und wenn der mppt noch angezeigt wird, die tracker aber nicht mehr, dann funktioniert auch meine steuerung mit node-red nicht mehr richtig, weil dann wichtige daten fehlen!

fuer dieses problem muss es doch noch eine andere loesung geben, als die, keine mppts ueber can-bus anzuschliessen!

tschuess

47

hallo,

ich habe inzwischen eine moeglichkeit gefunden, den can-bus ueber node-red neu zu starten und der erste test war auch schon erfolgreich. allerdings duerfte der aktuelle flow nur mit dem rs 450 funktionieren, da ich bisher nur dafuer eine sichere moeglichkeit habe, einen ausfall/stoerung des can-busses festzustellen. fuer die anderen can-bus geraete muss ich diese fehlererkennung erst einmal finden und testen!

aber eigentlich sollte das system das selbst machen ohne dass man dafuer einen node-red-flow braucht!

tschuess

48

@M_Lange

hallo,

heute morgen waren beide can-bus-schnittstellen ausgefallen und nach einem reset liefen sie wieder. da ich gesten die mppts auf vedirect umgestellt habe, waren die zwar nicht direkt betroffen, weil aber durch den ausfall des can-busses auch das bms weg war, war die pv natuerlich auch wieder ausgefallen.

ob vieleicht ein kabel nicht mehr zu 100% in der buchse ist, lasse ich pruefen, aber sowas darf einfach nicht passieren!

oder bist du der meinung, dass das normal ist, dass ich ueber node-red alle can-bus-geraete ueberwachen muss, um den bus automatisch neu zu starten?

dass der lynx shunt mal verloren geht, das war ja schon von anfang so und an der verkabelung kann das auch nicht gelegen haben, da der stunt nicht direkt am cerbo hing, sondern hinter einem der mppts!

victron sollte hier wirklich einmal seine hausaufgaben machen!

tschuess

49

hallo,

aktuell benutze ich diesen flow um die can-bus-systeme zu reseten, wenn die geraete ausfallen:

flows (9).zip (2,0 KB)

allerdings ist er noch im testbetrieb.

aber nach der umstellung der rs450 von can-bus auf vedirect sind an diesem system sowohl lynx als auch bms ausgefallen, wegen probleme mit dem can-bus. dabei kann ich ein hardware- oder verkabelungsproblem mit sicherheit ausschliessen. es muss also ein bug in der software sein!

und seltsamerweise war das das erste mal, dass es auch mit dem bms-can probleme gab.

tschuess

50

Auch hier wieder die Frage, wieso hast anscheinend nur Du alleine dieses Problem und sonst niemand hier?! CAN läuft problemlos bei Victron. Ich betreue mittlerweile 4 Anlagen im Bekanntenkreis inkl. meiner und bei allen sind die Laderegler + BMS per CAN angeschlossen… Ohne auch nur ein einziges Problem. Bei mir z.B. 3 Akkus und zwei 250/85 Laderegler. Auch liest man hier im Forum nichts über Probleme wie die deinen… Entweder es liegt an deiner Anlage, an Dir oder der Kombi aus beidem :grimacing:

51

hallo,

das liegt daran, dass ich bei solchen fehlern immer das glueck habe, dass die gerne bei mir auftreten! und in einigen faellen auch daran, dass ich ausgerechtet eine kombination benutze, bei der die fehler auftreten.

aber das problem, dass der lynx-shunt einfach mal verloren geht, das gab es bei dem system schon von anfang an. komisch ist nur, dass der irgendwo in der mitte des can-busses angschlossen war und die mppts fehlerfrei weiterliefen!

und gehaeuft treten die can-bus-probleme erst seit letzten dezember auf und das ohne dass vorher irgendetwas am system geaendert wurde! selbst bei meinen ersten can-bus-ladereglern gab es auf einmal probleme mit fehlernden daten oder verschwundenen mppts, obwohl die vorher 10 jahre lang fehlerfrei an einem gx liefen und nir probleme bereitet hatten.

inzwischen muss ich auf allen systemen den can-bus ueberwachen und neu starten, wenn die geraete verschwinden!

und wie erklaerst du dir die tatsache, dass anstatt des custom name in der uebersicht ploetzlich wieder der mppt-typ steht, obwohl der vergebene name beim geraet selbst angezeigt wird. glaubst du, das koennte ein hardware-fehler sein? nein!!! victron hat definitiv in der can-bus-software mehrere bugs, wovon einige aber verdammt aergerlich sind!

oder dass beim rs450 ploetzlich die anzeige der tracker fehlt und nur noch die summenwerte angezeigt werden?

als ich die ersten geraete installiert habe, gab es wenigstens noch einen kundenservice, an den man sich wenden konnte, aber heute geht das ja nur noch ueber das forum und in der hoffnung, dass jemand von victron das liest und sich darum kuemmert!

was glaubst du wohl, wie hoch ist die warscheinlichkeit, genau den zeitpunkt zu erwischen, wenn die cmos-uhr im pc gestellt wird, wenn das jede minute erfolgt? ich kann es die sagen: bei mir mindestens 50%, obwohl das ein zeitraum von weniger als 1 ms alle 60 minuten ist! ich habe daraufhin das programm geaendert, dass es nur noch einmal pro stunde die uhr gestellt hat!

wenn du gerne eine liste der bugs haben moechtest, die ich bisher bei victron gefunden habe, kann ich gerne mal eine erstellen. du kannst dir aber auch meine beitraege im forum alle durchlesen und auch im archive, da muss man aber google fuer die suche benutzen!

tschuess

52

Ich Frage nochmals, wieso tauchen die Fehler (anscheinend) nur bei dir auf?! Bugs in der Software würden sich, bei der Anzahl der im Umlauf befindlichen Systeme, in der breiten Masse zeigen und früher oder später dazu Threads hier im Forum oder auch anderen auftauchen. Passiert aber nicht. Ich gehe eher davon aus, dass Du dein System zu stark verbastelt hast, wenn man mal den Rest deiner Threads hier im Forum betrachtet und 1&1 zusammenzählt…

53

hallo,

das haengt mit verschiedenen faktoren zusammen:

  • nicht jeder hat, abgesehen vom bms, geraete am can-bus haengen und mit dem bms hatte ich bisher nur einmal probleme, nachdem die mppts vom can-bus entfernt und ueber vedirect angebunden wurden. mit dem lynx gab es dagegen immer mal wieder probleme
  • bei den meisten haengen die mppts ueber vedirect am gx
  • der firmwarefehler bei den mppts (15-50A), der bei mir aufgetreten ist und sehr nervte (erkennung sonnenuntergang) tritt nur auf, wenn die pv-spannung auch nachts nicht unter 10-11V abfaellt, was bei mir nur bei den mppts der fall war, denen ich einen widerstand fuer die stromversorgung nachts verpasst habe oder die nachts von der strassenlateren beleuchtet werden!
  • das problem beim mppt mit dem slave-mode, dass hier nur die strombegrenzung funktioniert und nicht die spannungsbegrenzung, kann man umgehen, indem man einen anderen modus benutzt und victron benutzt den slave mode wohl nicht mehr, sondern nur den external und bms controlled modus
  • das problem mit einem wackelkontakt in der ac-in netzerkennung hatte ich nur bei meinem mp 24/3000 und der ist leider immer wieder verschwunden, einschicken haette also nichts gebracht.
  • bei einem multi war nur noch ein firmware-update moeglich, sonst nichts mehr. danach lief er aber wieder
  • bei einem dreiphasen-system war der vebus ausgefallen (keines meiner systeme, ich habe nur bei der konfiguration geholfen)
  • cerbo totalabsturz wegen neustarts switch/wlan-basis
  • dauerabsturz node-red wegen bug in einem victron-node

mein system ist nicht verbastelt und ich habe inzwischen auch angefangen, einiges weniger komplex zu realisieren, nachdem die dafuer noetigen funktionen bei victron dazu gekommen sind.

aber ich habe nun einmal eine magische anziehungskraft auf hard- und software-fehler und leider kann ich daran absolut nichts aendern. es gab sogar einmal ein jahr, da musste ich jede bestellung reklamieren: defekte artikel, fehlende artikel, falsche artikel, falsche rechnung!

glaub mit, so was nervt gewaltig. mein vater hat mal eine staubsauger gekauft und die packung im geschaeft oeffnen und ueberpruefen lassen. der schlauch hat natuerlich gefehlt! das liegt eben in der familie!

deshalb waere ich auch ein prima betatester. wenn es bei mir laeuft, dann laeuft es wohl bei jedem.

tschuess

54

Ich hab zwar keine Ahnung vom can-Bus aber die Erscheinungen kommen mir bekannt vor, wenn nicht die Isolierten Interfacekabel benutzt werden. Sind da selbtgebaute dabei? Oder USB Kabel zur Verbindung zu einem Laptop, weil sie billiger sind?

55

hallo,

es wurden standard-patchkabel benutzt und bei patchkabeln gibt es keine isolierung zwischen den geraeten, ansonsten sind die alle isoliert.

es gibt lediglich welche mit schirm und welche ohne, was aber bedeutungslos sein duerfte.

es ist auch definitiv kein verkabelungsproblem, denn es treten auf dem bus selbst keine fehler auf, es fehlen lediglich daten oder die geraete sind komplett verschwunden. waere es ein bus-problem, dann koennten gelegentlich einmal daten wegen einem uebertragungsfehler fehlen, aber ich konnte keine uebertragungsfehler feststellen.

und wenn vom mppt alle summen-daten vorhanden sind, aber die daten der tracker oder die history fehlen, dann liegt das definitiv nicht am bus, sondern an der software. auch die tatsache, dass nicht der eingetragene name sondern der mppt-typ in der uebersicht angezeigt wird, laesst nur den schluss zu, dass es ein softwarefehler ist.

das gleiche gilt fuer die tatsache, dass diese fehler erst seit letzten dezember auf 4 geraeten auftreten! und das, obwohl sich zu diesem zeitpunkt weder etwas an der verkabelung noch der firmware geaendert hat! ich vermute deshalb auch einen zusammenhang mit dem vrm, denn nachdem ich das deaktiviert hatte, wurde es wieder besser.

tschuess