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