Ging mir mit der Sygic Navigation genauso. Die 19er Variante lief super bis zum upgrade auf 20.
Danach mußte man die SW ca. 10 mal neustarten, außerdem stürzte sie oft ab.
Antwort, laden Sie halt nur Europa! Mein Gedanken beim Lesen der mail waren ungefähr: @#€^^%#@#€#'●■♤■●}$¥◇ !!!
Gerade weil wir international zusammengesetzt sind und auch arbeiten (in diesem Fall war das aber nichtgewerblich ein Forschungsprojekt, später war geplant das System mit zu vermarkten) haben wir die offline-Weltkarte auf unseren Geräten! Ist nicht das erste Mal wenn man zusammensitzt und Tipps zu Locations vor Ort austauschen will oder muß.
Also ging eine “nette” mail raus wo das Problem beschrieben wurde.
Einige Zeit später gab es mehrere updates.
Seitdem läuft alles top. Manchmal müssen wir halt die Scheuklappen abreißen oder die Entwicklung in die richtige Richtung lenken (ein Komilitone hatte die zweifelhafte Ehre, in seiner Diplomarbeit einer Firma nachzuweisen warum die geplante Produktentwicklung nicht funktionieren kann. Er hätte gerne ein Muster gebaut aber daraus wurde nichts)
Prüfe in deinem Fall die Verbindung wie die PV Regler angebunden sind.
in meinem fall haengt an diesem system keine PV, fuer die PV habe ich einen extra-cerbo installiert! und der rest meine PV wird von einer eigenen software ueber tcp-v24-server gesteuert. damals gabs noch keinen cerbo, also musste ich mir selbst etwas schreiben.
was mich nur jedesmal aergert ist, wenn das ganze nicht so funktioniert, wie es in der anleitung steht oder dort fehler drin sind oder wichtige informationen fehlen!
aber wenn nur einer meckert, wird da sowieso nichts geaendert und das gilt leider fuer alle firmen. ausser bei sicherheitsluecken, wenn man damit droht, die oeffentlich zu machen, dann kommt ploetzlich bewegung in die sache oder auch nicht!
die mppts kann man ueber den cerbo auch direkt steuern, indem man die */link/* parameter setzt. funktioniert aber nur sauber, wenn keine andere einstellung dazwischenfunkt. mit multi kann man das dann indirekt ueber die batteryoperationallimits.
ich habe zwar ein oder besser gesagt mehrere bms an dem system haengen, ein physikalisches, einen smartshunt und ein virtuelles bms, aber das bms steuert nicht das system.
wenn du ein bms zur steuerung benutzt, kannst du die ladespannung und den ladestrom ueber dvcc einstellen. ist kein bms vorhanden oder deaktiviert, kannst du ueber dvcc nur noch den ladestrom steuern, aber nicht mehr die spannung, die wird dann vom vebus-system gesteuert. wobei ich aber noch noch getestet habe, wer die ladespannung festlegt, wenn das vebus-system aus ist.
ist auch kein vebus-system installiert muessten die einstellungen der mppts die ladung steuern. man kann aber, durch setzen der richtigen werte ueber mqtt, die mppts steuern!
zumindest bleibt die ladespannung der mppts auf dem wert, den das vebus-system zuletzt benutzt hat, wenn es abgeschaltet wurde.
es ist eben nicht ganz so einfach, die ladespannung des systems zu steuern, wenn kein bms vorhanden ist. deshalb emuliere ich entweder ein bms oder wenn der multi laedt, setze ich die noetigen limits fuer den multi.
eigentlich muesste dvcc immer funktionieren und hier sollten immer die niedrigeren werte gueltig sein, falls es noch eine andere quelle fuer die werte gibt! leider ist das nicht immer der fall!
ich habe inzwischen auch neben dem JK noch ein virtuelles BMS (einen SmartShunt auch, aber das ist ja kein BMS?!?), das /Info/MaxChargeVoltage und /Info/MaxChargeCurrent nach meinem Belieben steuert. Vorher hatte ich die beiden Werte direkt im DVCC/Settings geschrieben, aber das sind Parameter, die irgendwo nicht-flüchtig gespeichert werden, verbunden mit der bekannten Flash Problematik…
aber das funktioniert eben nur solange, wie der Multi taktet oder man ihm den Mund verbietet. Das Auskommentieren der beiden Zeilen ist für mich die einfachere und ‘staightere’ Variante, als ein
emuliere ich entweder ein bms oder wenn der multi laedt, setze ich die noetigen limits fuer den multi.
Es kann einem schon schwindelig werden bei den ganzen MaxChargeXxx, die auch noch alle unterschiedliche Werte haben…
die kannst du aber nur problemlos benutzen, wenn KEIN steuerndes bms aktiv ist, ansonsten werden die auch vom system gesetzt!
ueber beide wege, wenn ein vebus-system vorhanden ist, kannst du ladestrom und spannung steuern. wobei ob damit auch der ladestrom der mppts beeinflusst wird, kann ich sagen, das habe ich noch nicht ausprobiert, aber die spannung wird von den mppts uebernommen, wenn kein bms aktiviert ist.
welches bms benutzt wird, kannst du in den dvcc-einstellungen einstellen! solange du da nicht auf automatik stellst, wird das system da auch nichts aendern!
ich stelle das ganze inzwischen prinzipiell so ein, dass kein bms benutzt wird, denn dann fallen die mppta nicht aus, wenn das bms ploetzlich weg ist und auch der multi schaltet dann nicht automatisch aus. wenn ich dann den multi trotzdem steuern will, nutze ich die 4 limits. da die daten ja auch an die mppts uebertragen werden, sollte es also keine probleme geben.
der strom verteilt sich immer auf die mppts und den multi, deshalb bekommt der multi hier auch immer nur noch das, was uebrig ist!
mit dem virtuellen bms ist eine stoeren, z.B. weil man versehentlich das kabel gezogen hat, wesentlich unwarscheinlicher. vor allem wenn die vorgaben fuer die steuerung aus anderen quellen kommen.
aber wenn du die maxladestroeme zusammenrechnest, solltest du auf den strom kommen, den das bms erlaubt!
es ist eben alles nicht so einfach, wegen der vielen zusaetzlichen bedingungen, ueber die es keine doku gibt!
das ist interessant und könnte sogar passen. Aber dann nutzen mir die /vebus/xxx/BatteryOperationalLimits ja nix, um das Laden des Akkus durch die MPPTs zu steuern?!
Und sowieso - werden diese Limits nicht ständig irgendwoher überschrieben?
bms setzt die limit fuer das vebus-system, deshalb bringt es nichts, die zu setzen, wenn ein bms aktiv ist!
wenn man die limits selbst setzt, kann man damit die systemladespannung und den ladestrom des multis steuern, aber nicht den ladestrom der mppts, das geht dann nur ueber dvcc oder ein bms!
wenn die limits vom system oder dir gesetzt werden und das dann nicht mehr passiert, schaltet das vebus-system wegen bms-lost ab. denn die limits kommen fuer das vebus-system vom bms, auch wenn du sie ueber node-red oder mqtt selbst setzt!
und ohne bms werden auch die limits nicht gesetzt, auch wenn man ueber dvcc trotzdem den ladestrom des multis steuern kann.
mit bms wird der gesamte ladestrom gesteuert und die spannung.
ich weiss, ist etwas kompliziert, da kann ich aber nichts dafuer!
ja, durchaus kompliziert. also nochmal zurück auf los:
ich habe 7 MPPT Lader, die alle ‘zentral’ gesteuert werden sollen (Vorgabe der Lade-Sollspannung, Begrenzung des Akku-Ladestroms)
ich habe einen Multi, der aber nicht die Batterie laden soll (aus AC), und dessen Leistungsstufe zu 95% aus ist, weil ein kleiner WR die Grundlast übernimmt (der hat in dem Arbeitspunkt ~100W weniger Verluste und regelt besser).
ich habe ein Virtuelles BMS (läuft auf dem Venus OS), welches eigenständig /Info/MaxChargeVoltage und -Current berechnet und setzt (per dbus). Das BMS ist im DVCC als steuerndes BMS ausgewählt.
ich habe DVCC aktiviert und ESS auf “external controlled”
Die Sache funktioniert wunderbar, solange ich die beiden Zeilen im DVCC auskommentiere, in denen der Multi die (systemweite) Lade-Sollspannung mit 0 überschreibt, wenn er present aber seine Leistungsstufe aus ist (und noch ein kleiner Mod für die Stormrechnung).
-> Verstehe ich dich richtig, dass es deiner Meinung nach hierfür auch eine Lösung gibt, die ohne die Venus Modifikation funktioniert? (DVCC muss aktiv bleiben, damit die genaueren Werte vom SmartShunt systemweit gelten)
wenn du den multi nicht als ess, sondern im inselbetrieb betreibst, dann kannst du einfach das ladegeraet ueber veconfig ausschalten, damit kann er nicht mehr laden. wenn du ihn nur im inselbetrieb laufen laesst, kannst du ihn auch automatisch abschalten lassen, zu zeiten wo du ihn nicht brauchst und wenn er an ist, in einem der beiden energiesparmodi laufen lassen!
wenn der multi als ess laeuft kannst du die ladung ueber die bat-parameter fuer das vebus-system unterbinden. aber wichtig, das system muss ohne bms-steuerung und dvcc laufen!
ich steuere mit diesem flow die ladespannung der mppts:
aber das system hat weder ein bms, noch ein vebus-system. auf einem ess nutze ich die bat-parameter des ve-bus-systems um die ladespannung der mppts zu steuern. allerdings habe ich da noch nicht getestet, was das system einstellt, wenn der mp2 aus ist.
auf jeden fall, egal welche kombination zum einsatz kommt, ich habe immer eine loesung gefunden, die ladespannung der mppts zu steuern!
manchmal muss man eben verschiedene varianten durchprobieren.
naja, ich habe 6 lange Tage versucht, eine Lösung zu finden, unter anderem mit Unterstützung von Victron Experts und diversen anderen Usern - niemandem ist es gelungen.
der Multi läuft ja nicht als Insel, sondern in einer Null-Einspeisung/Null-Bezug (naja, mit begrenzter Überschusseinspeisung bei Überschuss eben). Das geht meines Wissens nur mit ESS. DVCC brauche ich. Die Energiesparmodi sind in meinem Fall ungeeignet.
Klar kann ich auch komplett ohne Venus/GX arbeiten und alles selber programmieren, aber das wäre ja ziemlicher Aufwand und auch ziemlicher Unsinn…
in dem fall ueber ein vituelles bms oder die bat-limits des vebus-systems die ladespannung steuern, damit kannst du dann auch gleich die dc-ueberschusseinspeisung steuern. ich gehe einmal davon aus, dass dein multi dann immer an ist. ohne aktives dvcc kannst du den akku ueber das ess nicht laden, sofern du die neueste firmware und den neuesten assisten benutzt. wie es m it einer aelteren firmware und dem neuesten assistenten ist, kann ich nicht sagen, da ich jeweils immer nur die aktuellen versionen teste, wenn ich mal wieder was neues installiere!
wenn do den multi nur auf ac-in-seite angeschlossen hast, kannst du den natuerlich auch automatisch abschalten, wenn nicht genig PV reinkommt!
und ich habe die erfahrung gemacht, dass vieles, von denen die victron-experten sagen, dass es nie funktioniert, bei mir prima funktioniert, wie z.B. die erweiterung eines 24V blei-akkus mit einem 36V Li-akku!
man darf nicht alles glauben, was einem erzaehlt wird. so steht z.B. in den meisten online-shops bei den hauptleitungsklemmen 25², wenn sie dann aber ankommen, sind die haelfte der klemmstellen 25² und die andere haelfte 16² und dort bekommt man kein 16² kabel mit aderendhuelse rein und die braucht man zwingend bei flexiblem kabel!
also immer misstrauisch sein und verstand benutzen!
und der satz geht nicht, wurde bei mir weitestgehend aus dem vokabular gestrichen!
inzwischen ist es sicher, das das ess mit der neuesten firmware nur funktioniert, wenn der multi daten von einem bms bekommt. nachdem ich ihm die wieder gesendet habe, hat auch das ess wieder funktioniert!
auf meinem ersten ess mit einem mp2 3000 funktioniert es auch ohne bms, aber der multi hat eine aeltere firmware und einen aelteren ess-assistenten. ich gehen einmal davon aus, dass es am ess-assistenten liegt. das werde ich jetzt aber nicht ausprobieren, ich bin froh, dass das erste system sauber laeuft, so wie es konfiguriert ist.
lediglich die firmware auf dem venus-gx habe ich aktualisiert und dafuer wurde ich dann mit einigen abstuerzen von node-red belohnt und wohl auch ein paar neustarts, bis ich saemliche probleme beseitigt hatte. jetzt laeuft das teil auch mit dem neuen venus-os stabil.
■●}$¥◇ !!!
