Ausfall vebus mit venus os 3.66 und mp2 5000 mit aktueller firmware 558

Other languages Deutschsprachiger Bereich
, , ,
1

@M_Lange

hallo,

heute gab es probleme mit einem ess, weil die mp2 ueber den vebus nicht mehr erreichbar waren. weder vom cerbo aus, noch vom pc ueber einen mk2/3 usb-adapter!

ein neustart des cerbos brachte keine besserung, erst nachdem die mp2 alle am schalter aus- und wieder eingeschaltet wurden, hat das system wieder funktioniert!

wie kann das passieren, dass die kommunikation ueber den vebus eines mp2 einfach ausfaellt und nur durch ein- und ausschalten wieder hergestellt werden kann!

da das ess nur ueber ac-in angeschlossen ist und die mp2 laut led-anzeige fehlerfrei gearbeitet haben, aber natuerlich keine ess-funktion mehr vorhanden war, kann ich auch nicht sagen, ob die mp2 wirklich noch fehlerfrei gearbeitet haben!

aber ich wuerde sagen, hier hat definitiv ein bug in der firmware zugeschlagen. bisher hatte ich es nur ein einziges mal, dass ein mp2 ueber den vebus nicht mehr erreichbar war und in dem fall musste ich me veflash einen firmwareupdate durchfuehren, um das problem zu beheben. wobei sicher dieser mp2 auch nicht mehr einschalten lies, also alle led blieben nach dem einschalten aus!

jetzt bleibt die frage offen, wann dieser bug beseitigt wird oder ob man einen downgrade der firmware durchfuehren muss. das system ist erst seit ein paar monaten in betrieb und ich habe lediglich bei der konfiguration geholfen.

tschuess

2

Du immer gleich mit deinen Bugs in der FW wegen einem einmaligen Fehlers.

Wenn das öfter oder reproduzierbar passiert, kann man sich das vielleicht mal genauer anschauen, doch aber nicht sofort, wenn es einmal bei einem Nutzer passiert.

3

hallo,

wenn systeme ausfallen, die problemlos laufen sollten, sollte man sich das immer anschauen und nicht erst wenn viel sich beschweren! und wenn alle anderen ursachen ausgeschlossen werden koennen, dann muss es ein bug in der firmware sein!

das problem dabei ist, wenn man nicht weiss, was diesen bug triggert, kann man ihn auch nicht reproduzieren!

aber selbst wenn ein bug permanent und reproduzierbar vorhanden ist, scheint das victron nicht zu interessieren, solange er die victron-eigene software nicht beeinflusst! oder wurde der fehler bei den mppts mit dem slave-mode und der nicht funktionierenden spannungsregelung inzwischen beseitigt?

da die victron-software ja nur den bms und external controlled modus benutzt, tritt das problem mit einem gx ja nicht auf, also wird es ignoriert!

auch das problem mit dem can-bus, das seit dezember vermehrt auf meinen systemen und systemen die ich betreue aufgetreten ist, koennte sehr einfach korrigiert werden. bei meiner eigenen software wird die kommunikation immer ueberwacht und wenn die ausfaellt, wird die verbindung neu gestartet!

oder bist du wirklich der ueberzeugung, dass alle victron firmware zu 100% fehlerfrei ist?

und wenn sich keiner beschwert, weil der fehler ja nur in grossen abstaenden auftritt, wird erst recht nichts dagegen uebernommen!

vieleicht bist du aber auch einer der gluecklichen, die von softfehlern verschont bleiben, ich kann das leider nicht sagen, mich verfolgen softwarefehler schon seit jahrzehnten und bei den meisten bekomme ich dann immer zu hoeren, dass die nur bei mir auftreten und sonst bei niemandem! komisch ist nur, dass ich dann irgendwann im internet vermehrt berichte ueber den fehler finde, der ja nur bei mir auftritt! auch wenn das dann schon mal ein paar jahre dauert!

tschuess

4

Dann darf es aber auch keine Bastelbude sein und original Hardware muss verwendet werden und auch keine Script u.d.g. drauf und nach den Vorgaben von Victron installiert sein. Sonst kann man nie wirklich sagen an was es liegt!

1 Like
5

Und auch ganz schlecht finden ohne da Stunden an Arbeit zu investieren.

Auch das scheint ja nur bei dir zu passieren und bei keinem anderen, zumindest habe ich da noch keine weiteren Berichte gesehen.

Du kannst gerne Hinweise auf weitere Berichte geben, wenn du welche gefunden hast, damit man sich das genauer anschauen kann.

Nein, das ganz sicher nicht, aber ich sehe ja fast alles, was hier berichtet wird zudem verfolge ich zwei Facebook-Gruppen und wir haben etliche Kunden an die wir dutzende Anlagen verkaufen bzw. selbst installieren.
Wenn es da ein generelles Problem gäbe, gäbe es ganz sicher auch mehr Berichte dazu[1].
Wenn wir (die Moderatoren bzw. die Victron Mitarbeiter die z.T. in der Community aktiv sind) vermehrt Berichte zu ein und dem selben Fehler sehen, melden wir das dann auch entsprechend weiter.

Es wird sich nur kein Entwickler hinsetzen und einen Fehler suchen, der nur bei einem Nutzer ein einziges mal aufgetreten ist.
Die Entwickler haben wirklich besseres zu tun als einer einzelnen Fehlermeldung nachzugehen, zu der es keine genaueren Details zu den Umständen gibt.

Selbst wenn, dann kommt zuerst die Aufforderung:
Deaktivieren sie bitte alles, was externen Einfluss auf das System nehmen kann, entfernen sie jegliche Fremdsoftware von den Geräten und deaktivieren sie NodeRed und melden sie sich wieder, wenn das Problem erneut auftritt.
Denn nur, wenn der Fehler auch in dieser Standardkonfiguration auftaucht, kann man auch wirklich von einem Fehler in der Victron-SW ausgehen.

PS: Bitte GroĂź-/Kleinschreibung und Umlaute benutzen, darum habe ich dich schon mehrfach gebeten.

  1. Siehe das Problem mit den pulsenden IP22 Ladegeräten oder dem Problem, das es scheinbar mit den 300A SmartShunts gibt ↩︎

6

hallo,

das system wurde nicht von mir aufgebaut, sondern nur das ess konfiguriert und dort laufen auch keine scripts und auch bei mir laeuft nur was mit node-red und nicht im venus-os selbst!

abgesehen davon, auf dem multi kann man KEINE scripts laufen lassen!

tschuess

7

hallo,

ich verlange ja nicht, dass sofort nach diesem fehler gesucht wird, aber er sollte wenigstens zur kenntnis genommen werden!

uebrigends, in der firmware 406 fuer den alten multi 5000 ist auch ein definitiv reproduzierbarer bug: wenn ich den powerassist auf 2 stelle und mein hauswasserwerk an oder abschalte (ich weiss es nicht mehr genau), speist das system fuer einige sekunden mit voller leistung, also ca. 12 kW ins netz ein. als ich das damals gemeldet habe, bekam ich nur zu hoeren, dass das nicht sein kann und kein entsprechender bug in der firmware ist. da ich das problem aber durch eine andere einstellung beheben konnte, war mir das dann egal!

und das problem mit dem ausfall des can-busses ist inzwischen auf allen systemen, die den can-bus benutzen und das sind aktuell 4 systeme, fast regelmaessig aufgetreten. und selbst wenn nur die eingetragenen namen fuer die mppts nicht mehr in der uebersicht angezeigt werden, beim geraet aber richtig angezeigt werden, ist das ein bug, der beseitigt werden sollte! mal abgesehen davon, dass der can-bus automatisch neu gestartet werden sollte, sobald hier etwas nicht mehr richtig funktioniert!

auch die funktion, dass die dvcc-spannungssteuerung deaktiviert wird, wenn nur ein bmv/smartshunt aber kein bms angeschlossen ist, ist inakzeptable!

tschuess

8

Hier wäre dann der erste Hinweis da mal die FW zu aktualisieren.
Im Changelog ist erst ab der 459 ein Datum mit angegeben und das ist da der 05.04.2019, also ist die 406 noch weitaus älter, laut Archiv müsste diese von Anfang 2016 sein, also etwa 10 Jahre.

Dann gib doch mal die VRM IDs dieser Systeme, damit sich das ggf. jemand genauer anschauen kann.
VRM ID = die Zahl in der URL
https://vrm.victronenergy.com/installation/>VRM ID</dashboard

Aber ich glaube da weiterhin nicht an ein generelles Problem, weil es sonst mehr Berichte dazu gäbe.

9

hallo,

die systeme mit can-bus haben folgende ids: 239113, 108167, 503116, 360446,

bei 360446 fehlen in der konsole 3 mppt-bezeichnungen und im vrm die tracker vom mppt 3. die werden auch in der konsole nicht mehr angezeigt, der mppt arbeitet aber noch! das ist auch einer der fehler, die regelmaessig auftreten! hier werde ich den can-bus also mal wieder neu starten muessen, das werde ich aber nicht direkt machen, der mppt arbeitet ja noch, es fehlen nur die daten in der anzeige!

gefuehlt hat sich die problematik mit dem can-bus verbessert, seitdem ich das vrm ganz deaktiviert oder auf read only-kommunikation gestellt habe! die regelmaessigen probleme mit dem can-bus sind erst im dezember aufgetreten, ohne dass vorher irgendwelche updates installiert wurden oder aenderungen an der konfiguration durchgefuehrt wurden! teilweise liefen die system bis zu diesem zeitpunkt schon mehrere jahre problemlos! zu diesem zeitpunkt war ein vollstaendiger zugriff des vrms aktiv!

ich habe jetzt auf allen systemen wenigstens die read-only-kommunikation zum vrm wieder aktiviert!

das ist das system, bei dem der vebus ausgefallen war: 756843.

tschuess