Totalausfall PV wegen ausfall ve-can auf cerbo!

Other languages Deutschsprachiger Bereich
1

hallo,

heute kam es auf einem system zu einem totalausfall der PV, weil der can-bus wohl komplette ausgefallen ist. nach einem neustart funktioniert dann das ganze zwar wieder, aber man kann doch nicht staendig kontrollieren, ob der can-bus noch funktioniert oder nicht!

gibt es da keine ueberwachung fuer den can-bus, die dann nur den can-bus neu startet, wenn auf einmal alle geraete verschwunden sind oder sonstige probleme bei der kommunikation festgestellt werden?

auf dem cerbo haengt ein lynx-shunt und 5 mppt rs 450/200 am can-bus.

ich installiere jetzt einmal die aktuelleste firmware und hoffe, dass es damit besser wird. das war jetzt zwar der erste totalausfall, aber probleme mit dem can-bus gab es schon des oefteren und die terminatoren sind beide installiert!

tschuess

2

hallo,

bei mir heute das gleiche problem, durch einen fehler auf dem can-bus wurden die beiden can-bus mppts nicht mehr richtig angezeigt und ich musste den cerbo neu starten!

muss ich die mppts jetzt alle ueber vedirect anschliessen, damit es damit keine probleme gibt?

tschuess

3

@thiemovanengelen @nickdb

hallo,

heute waren wieder alle mppts, die ueber can-bus angeschlossen sind, weg, so dass ich den cerbo neu starten musse. auf dem cerbo ist die aktuelleste version vom venus-os installiert!

was auch auffaellig ist, sowohl ethernet als auch wlan werden des oefteren gleichzeitig deaktiviert und wieder neu aktiviert.

ausserdem kam es auch zu mehreren neustarts und einer davon auf jeden fall wegen einer zu hohen load!

hier noch die gesammelten logfiles:

messages.zip (85,5 KB)

also so langsam faengt das gewaltig an zu nerven!

tschuess

4

hallo,

hat er wieder seine tropfen nicht genommen!

und fuehrt selbstgespraeche!

tschuess

PS: Könnte Spuren von Sarkasmus sowie fehlender Grammatik / Rechtschreibung enthalten…

2 Likes
5

hallo,

na dann freu du dich mal ueber ein problem mit der technik, auf das du keinen einfluss hast. dem ist die grammatik und die rechtschreibung naemlich voellig egal und wenn deine pv-anlage wegen so einem fehler ausfaellt, dann freust du dich bestimmt darueber!

tschuess

6

Gegen denn ĂĽbereifrigen watchdog kann man aber etwas tun. Mein Cerbo GX sagt gerade:

root@VictronCerboEinstein:~# uptime
21:29:01 up 118 days, 4:14, load average: 1.45, 1.84, 2.52

Da hängen 8x ve.direct MPPTs dran und ein weiterer MPPT sowie der Lynx Shunt am CAN-Bus und die 3~Multiplus 2-5000 am anderen CAN und noch zwei Shelly 3 EM als Zähler an Hausanschluß und AC-Wechselrichter. Die Softwareversion ist allerdings auch gut abgehangen.

7

hallo,

normalerweise liegt die load average unter bei meinem neuen cerbo unter 0.5. aber auch der wurde schon einmal mit einer load average > 10 neu gestartet!

seitdem ich die fritzbox, die fuer netzwerkprobleme gesorgt hat, ausgetauscht habe, laeuft er schon seit ueber 2 tagen, vorher nicht mal 24 stunden ohne neustart.

das problem ist nur, wenn ein wlan-router oder switch immer wieder neu startet, das faellt eben nicht so schnell auf, als wenn er einen totalausfall hat oder spinnt und das ganze netz blockiert! und wenn man jede menge switches und wlan-basen im haus hat, schau man auch nicht bei allen nach, ob vieleicht das log taeglich geloescht wird!

da sind mir totalausfaelle wesentlich lieber, als solche neustartprobleme. die vorgaengerbox hatte das netz lahmgelegt, indem sie behauptet hat, dass man ueber sie alle mac-adressen erreichen kann, sowas macht dann aerger beim routing im netz!

aber ich habe uebung darin, netzwerkfehler zu finden, wenn ich erst einmal weiss, dass einer da sein muss!

ich vermute einmal, der cerbo hatte probleme weil das netz immer mal wieder kurz weg war. und fuer mich klingt das sehr nach einem bug in der firmware! denn an der wlan-basis haengen noch andere geraete und damit gab es keine probleme, jedenfalls sind mir keine aufgefallen.

tschuess

8

Der load average Wert von 10 in der ersten Position löst nicht den Neustart aus, sondern der von 6 an Position 2. Die Werte sind das, was hinter “load average” beim Kommando “top” ausgegeben wird, und die Parameter vom watchdog stehen in max-load-5 und max-load-10 in /etc/watchdog.conf.

Ich habe diese Werte seit langer Zeit deutlich heraufgesetzt, sieht jetzt so aus:

watchdog-device = /dev/watchdog

log-dir = /var/volatile/log/watchdog
min-memory = 2500
max-load-5 = 10
max-load-15 = 8
repair-binary = /usr/sbin/store_watchdog_error.sh
test-prescaler = 60
retry-timeout = 0

Probleme mit dem Netzwerk hatte ich auch schon. Da ist dann aber nicht der Cerbo ausgestiegen, sondern die Regelung. Zähler am Hausanschluß per WLAN angebunden, ESS Regelung auf Nulleinspeisung mit Zielwert 50W Bezug. Dann fiel der WLAN Router aus und es kamen keine Werte mehr vom Zähler. In der Folge hat die Regelung versucht, die 50W Netzbezug zu erreichen, und die Multiplusse auf maximum hochgeregelt und aus dem Netz in den Akku geschoben.

9

hallo,

da koennte man zwar etwas gegen eine kurzzeitig zu hohe load tun, aber gegen out of memory wuerde das nicht helfen und das war ja auch mindestens einmal die ursache fuer den neustart.

da mein cerbo jetzt sauber zu laufen scheint, gehe ich davon aus, dass die netzwerkprobleme die ursache war, wobei das aber normalerweise weder zu einem out of memory problem noch zu einem problem mit einer zu hohen cpu-last fuehren duerfte!

aber hier geht es auch aktuell darum, dass der can-bus komplett oder teilweise aussteigt, die mppts auf bms-lost gehen und ihre arbeit einstellen! und aktuellen fallen mir dafuer nur die folgenden loesungen ein: anstatt den can-bus den vedirect-anschluss benutzen, das bms abklemmen und nur den lynx-shunt benutzen, aber der faellt dann ja leider auch aus oder die mppts an einen zusaetzlichen cerbo haengen oder das bms ueber das netzwerk einbinden, so dass ich die daten des bms habe, es aber nicht am cerbo haengt, damit die mppts mit ihrer eigenen konfiguration weiter arbeiten.

das loest aber nicht das raetsel, warum der can-bus aussteigt! schliesslich lief das system ja monatelang ohne probleme und selbst nach dem anschluss des 5. rs 450/200 gab es ueber mehrere monate keine probleme! und jetzt faellt der bus fast taeglich aus!

tschuess

10

out of memory hatte ich noch nicht. Aber dagegen hilft der watchdog ja mit etwas weniger aggressiver Einstellung immer noch, und die hat bei mir die Anzahl der Neustarts von mehrmals pro Tag auf seit Monaten nicht mehr reduziert.

Da der Bus monatelang stabil lief, muß sich irgendetwas verändert haben. Verkabelungs- oder EMV Problem? Oder einer der Busteilnehmer mit sich entwickelndem Hardwareproblem? Oder neue Softwareversion mit Verschlimmbesserung?

Ferndiagnosen sind da immer schwierig…

11

hallo,

ich weiss. es wurden inzwischen auch mehrere firmwareupdates eingespielt und der lynx-shunt hat schon des oefteren probleme am bus gemacht und war einfach verschwunden!

ich werde wohl erst mal versuchen, mit node-red einen automatischen neustart zu programmieren, wenn der bus ausfaellt. dafuer muss ich aber erst einmal herrausfinden, wie ich das feststellen kann!

aber das ist natuerlich auch nur eine notloesung!

tschuess

12

hallo,

koennte das problem vieleicht mit einem firmwareupdate der mppts und des lynx-shunts zusammen haengen? denn die beiden cerbos liefen vorher mit der firmware 3.54 stabil und ohne groessere probleme auf dem can-bus. nur die mppts wurden aktualisiert!

allerdings ist auch hier der fehler wohl nicht gleich aufgetreten.

tschuess

13

hallo,

ich habe jetzt einmal dir firmware der can-devices aktualisiert.

tschuess

14

@M_Lange

hallo,

hast du vieleicht irgendwelche ideen, was einen komplettausfall des ve-can-buses verursachen kann und wie man das verhindern kann?

seltsamerweise tritt der fehler wohl erst seit 1-2 wochen auf und das auf 2 verschiedenen systemen!

tschuess

15

Nicht wirklich.
Wurde denn in den letzten Wochen an den Systemen etwas geändert?
Läuft auf den Systemen Fremdsoftware oder NodeRed?
Welche FW ist installiert?

Falls möglich vielleicht mal den Can Port tauschen.

Ich wĂĽsste gerade nicht, das es da ein generelles Problem gibt.
Die Cerbo MK2 hatten mal eine Zeit lang Probleme mit einem der Can Ports, aber das wurde mit einem FW Update behoben.
Das wird es aber nicht sein, da du das Problem mit den Geräten schon immer gehabt hättest.

Die Systeme, die wir installiert haben bzw. betreuen laufen idR alle mit original SW und ohne NodeRed und da haben wir meines Wissens nach keine Probleme mit der VE.Can communication.
Da in den meisten Systemen Akkus mit Can-Bus sind, würden solche Ausfälle auffallen.

16

hallo,

also bisher habe ich solche ausfaelle festgestellt mit venus-os 3.54 und 3.67 und smart mppt 150/100 sowie rs 450/200 und dem lynx-shunt (der macht schon laenger probleme) die dann nicht mehr vorhanden sind. heute gabs noch probleme mit einem normalen mppt 150/100 und venus-os 3.54, so dass ich das system heute auch neu starten musste.

der mppt war zwar noch vorhanden und hat daten geliefert, aber in der remote-console nur noch die history von heute, die von gestern hat gefehlt und auch der name, den ich dem teil gegeben hatte, wurde nicht mehr angezeigt!

nach dem neustart war dann der name und die daten von gestern wieder da!

auf dem system gab es auch 27 fehler auf dem can-bus und ich habe bei mir auf allen cerbos mit can-bus und neuen mppts dropped packages.

auf einem cerbo mit firmware 3.22 und 2 ganz alten mppts, die nur einen can-bus als kommunikationsschnittstelle haben, hatte ich mit dem can-bus noch keine probleme.

dafuer scheint der aktuell regelmaessig cpu-maessig ueberlastet zu sein:

Mem: 574576K used, 455508K free, 2068K shrd, 114256K buff, 148092K cached
CPU: 53% usr 11% sys 0% nic 31% idle 0% io 2% irq 1% sirq
Load average: 3.40 3.39 2.74 3/290 9518
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
941 910 simple-u S 20596 2% 32% /bin/simple-upnpd --xml /var/run/simple-upnpd.xml -d

und hier ist de upnpd besonders auffaellig, der geht gerne mal auf ueber 40% cpu-last hoch und das fuer laengere zeit!

auf jeden fall braucht er mehr cpu-leistung als node-red!

da lag die ping-laufzeit bei ueber 50 ms im netz und es gingen auch viele packete verloren!

und dabei haengen an dem cerbo nur die 2 can-bus-mppts und 3 vebus-systeme und ein vedirect-inverter, da sollte der upnpd eigentlich nichts zu tun haben! ich werde den wohl auch mal neu starten, um zu sehen, ob das die sache verbessert!

so, nach dem neustart ist der simple-upnpd wieder friedlich und taucht nicht mehr in der hitliste als groesste cpu-last auf!

irgendwie habe ich wohl aktuell eine serie, ein problem geloest, dafuer gibt es dann 5 neue! nur wieso faellt der can-bus aus, nachdem er stundenlang fehlerfrei gearbeitet hat? und das quasi von heute auf morgen, wobei es monatelang gar keine probleme gab, dann aber gleich auf mindestens 3 systemen!

tschuess

17

hallo,

aber mir ist da mal eine idee gekommen. normalerweise duerfte das problem zwar nicht damit zusammenhaengen, aber da mir heute aufgefallen ist, dass der geraete-scan vom vrm probleme verursacht, habe ich einmal auf einem cerbo das vrm auf read only gesetzt und werde es einmal komplett deaktivieren, wenn der fehler nochmal auftritt.

als ich heute firmware-updates ueber das vrm gemacht habe, sind naemlich auch vedirect-geraete zeitweise verschwunden und spaeter wieder aufgetaucht. ich denke, das sollte eigentlich nicht passieren!

aber in solchen faellen klammert man sich ja an jeden strohhalm und da das problem erst seit ca. einer woche staendig auftritt und an den systemen schon seit wochen nichts mehr geaendert wurde, koennte das ja die ursache sein!

tschuess

18

Hi,

PrĂĽfe mal mit df -h deine Partitionsauslastung. Wenn Prozesse out of memory laufen, wird geswapped. Wenn dann die Partition aber voll ist, kommt es oft zu unendlichen, cpu intensiven retry loops.

Das Large image kommt mit Nodered und signal-k - die brauchen beide dick platz.

Wenn du signal-k nicht brauchst, kannst du das einfach droppen:

rm -rf /usr/lib/node_modules/signalk-server

19

hallo,

es ist genug speicher frei und auch auf der ssd ist genug platz. signal-k ist uebrigends nicht aktiviert.

ich vermute, dass auf diesem cerbo, aufgrund des netzwerkproblems, irgendwelche prozesse eventuell mehrfach gestartet wurden oder sehr viel speicher benoetigt haben.

aber der fehler ist auch nur einmal aufgetreten, der ausfall des can-buses tritt aktuell taeglich auf!

tschuess

20

hallo,

heute morgen schon wieder. bei mir wurden die mppts wieder nur mit der typenbezeichnung angezeigt uns es gab keine history mehr von gestern, bei dem anderen system das gleiche. aber die geraete waren wohl noch alle da, leider habe ich vergessen, das genau zu kontrollieren und auch den can-bus-status abzufragen. aber da bis morgen wohl wieder mit diesem fehler zu rechnen ist, muss ich daran denken, den can-bus-status abzufragen.

aber der fall, dass die mppts zwar noch gesteuert und mit der typenbezeichnung angezeigt werden, ist fuer mich eindeutig ein bug in der software!

aber es kommt eindeutig noch ein weiteres problem dazu: heute nacht hat bei meinem bekannten die internetverbindung so schlecht funktioniert, dass ich auf keinen der cerbos mehr draufkam, weder ueber eine der beiden vpn-verbindungen noch ueber das vrm! allerdings hatte das zur folge, dass der cerbo in sehr kurzen zeitabstaenden neu gestartet wurde obwohl er das bei verlust der verbindung zum vrm nicht machen sollte. es hat jedesmal die watchdog mit einer zu hohen load zugeschlagen!

ich habe auf den beiden jetzt das vrm einmal komplett deaktiviert!

tschuess