Also das python Skript überlebt jetzt einen Neustart, hab einfach eine /data/rc.local angelegt, und darin steht nur dieser Befehl:
ln -s /data/mqtttogrid/service /service/mqtttogrid
In der Venus OS Oberfläche (Konsole ?) taucht auch ein MQTT Meter auf, aber keine Daten, obwohl ich von meinem FHEM (MQTT Server) ein (Test)Datum publishe.
Glaube ich zumindest.
Dass keine Daten ankommen kann natürlich verschiedene Ursachen haben.
U. a. meint FHEM, dass das MQTT Gerät, also das Venus OS "disconnected" sei.
U. u. ist das MQTT Gerät in FHEM also nicht korrekt oder vollständig angelegt.
Es würde mir schon helfen, wenn die print Ausgaben im python Skript sichtbar wären, die sagen ja u. a. ob eine Verbindung zum MQTT Server besteht oder nicht.
Ich sehe allerdings gar nichts, weder "Connected to MQTT Broker!" noch "Failed to connect"
Soweit ich es verstanden habe läuft das Skript als Service oder daemon im Hintergrund und reagiert auf Ereignisse.
Hat jemand vielleicht einen Tip, wie ich die print Ausgaben des Skripts sichtbar machen könnte ?
Mit einem Neustart (Aufruf von kill_me.sh) habe ich es schon probiert.
Ich sehe dann mit svstat /service/mqtttogrid auch, dass das Skript wieder läuft.
EVE 16s/230Ah, JKBMS, MPII-48/3000/35-32, Raspi 2B mit VenusOS, Nulleinspeisung
Mal ein Update 
Also, wenn das python Skript nicht als service läuft, was ich dadurch erreichen kann, dass ich den symbolischen Link, der durch diesen Befehl erzeugt wurde:
ln -s /data/mqtttogrid/service /service/mqtttogrid
entferne (auch aus der rc.local, bzw. auskommentiere) und ich das Skrip einfach "von Hand" aufrufe:
python MQTTtoGridMeter.py
dann kommen auch die print Ausgaben durch.
Ich publishe scheinbar mit FHEM korrekt (bisher nur ein topic, die Gesamtleistung), und die kommt auch korrekt im python Skript an, was ich durch die Print Ausgabe sehe.
Zumindest in der Routine, die die MQTT Nachricht empfängt.
Jetzt muss ich entweder die vielen eingefügten dbus Werte, die mein EHZ und damit auch mein FHEM nicht liefern kann sinnvoll belegen (mit Konstanten ? Rechnen ?) oder vielleicht auch einfach weglassen.
Weiss zufällig jemand, durch welche Kennzeichen der MPII erkennt, dass das eingefügte "dbus Gerät" jetzt ein "Grid Meter" ist, auf dass er regeln soll ?
Und wie der dbus Wert heißt auf den geregelt wird, den ich also auf keinen Fall weglassen darf ?
EVE 16s/230Ah, JKBMS, MPII-48/3000/35-32, Raspi 2B mit VenusOS, Nulleinspeisung
Hallo zusammen, gibts hier jemand der jetzt mal wirklich einen MPPT-Lader an einen 18S Akku gehängt hat?
Edit:
sollte auf jeden Fall mit 64V möglich sein zu laden, habe das hier gefunden:
https://community.victronenergy.com/questions/143025/mppt-450200-maximum-battery-voltage-only-62v.html
Um das Thema mit den MPPT-Lader mal abzuschießen, da ists kein Problem mit der Ladespannung.
Bei dem RS450/xxx hat man schon ein Problem, die laden nur bis 62V.
@chrispv Vielen Dank für die Info, Plane alle paar Wochen im Kopf wieder ne Erweiterung und da wäre das wichtig 😀
mit welchem MPPT hast du jetzt endgültig gestestet/verbaut?
Ich habe selbst noch keinen im Einsatz. Ich werde wohl die 250er nehmen,
Habe mit jemanden der Li-Ionen Akkus hat korrespondiert, er meinte das es mit den MPPT Ladern da kein Problem gibt.
Lediglich die RS450/xxx haben die geringe Ladespannung von 62V
Hallo, mal ein Update von mir zu dem von Thread-Starter maßgeblich inspirierten Projekt 😀
Das System lief erstaunlicherweise gleich beim 1. Einschalten sehr zufriedenstellend.
Ich war sehr unsicher, ob ich die richtige Reihenfolge einhalte (erst Batterie am MP2 anschließen ? Dann AC ? MK3 ? LAN ? Einschalten ?) und vielleicht doch den teuren MP2 schrotte. Aber es ist alles gut gegangen 👍
Und es läuft jetzt schon viele Tage stabil. Ich hänge mal ein Systemschaubild und ein paar Betriebsdaten an.
Wie man da sieht arbeiten u. a. 3 raspis Hand in Hand - wie zuverlässig das läuft erstaunt mich dann doch.
Da ich keinen EM24 habe, sondern die Leistung des Hauseinspeisepunktes ins VenusOS raspi skripte (Abtastrate 5 s) hatte ich Bedenken ob das (zeitlich) reicht oder ob es evtl. zu Schwingungen kommt. Läuft aber für mich ausreichend genau.
Da sich so ein raspi trotz allem mal aufhängen kann, bzw. da bei Stromausfall (zumindest aktuell) die raspis aus sind habe ich jetzt mal Fehler simuliert:
1. Load-Dump nach Einfrieren des Wertes der Leistung am Hauseinspeisepunkt:
Ein Heizlüfter zieht - mit dem Rest des Hauses - ca. 2000 W.
Der MP2 regelt voll auf (ist z. Zt. auf 2000 W begrenzt).
Die LAN Verbindung zum VenusOS raspi wird unterbrochen, die Batterieleistung per Bluetooth Verbindung zum JKBMS beobachtet.
Der Heizlüfter wird ausgeschaltet.
Erwartung: das VenusOS erkennt (irgendwann, vielleicht nach 2 Minuten ?), dass der Wert der Leistung am Hauseinspeisepunkt eingefroren ist und schaltet den MP2 ab.
Ist: der MP2 läuft mit 2000 W weiter. Da keine Last vorhanden ist speist er ein (sollte er nicht, weil 0-Einspeisung).
Das VenusOS scheint nicht zu prüfen, ob die Leistung am Hauseinspeisepunkt aktualisiert wird.
Nach 6 Minuten habe ich den Test abgebrochen (die Regelung lief dann auch wieder korrekt an).
Hätte ich nicht abgebrochen wäre die Batterie mutmaßlich vollständig entladen worden.
2. Load-Dump nach Trennung des MK3 Interfaces vom VenusOS raspi:
Ein Heizlüfter zieht - mit dem Rest des Hauses - ca. 2000 W.
Der MP2 regelt voll auf.
Die Verbindung des MK3 zum VenusOS raspi wird unterbrochen, die Batterieleistung per Bluetooth Verbindung zum JKBMS beobachtet.
Der Heizlüfter wird ausgeschaltet.
Erwartung: Der MP2 erkennt den Ausfall und geht in "Stand-by"
Ist: der Batteriestrom geht nach ca. 10s auf 0 und bleibt da, bis die Verbindung wieder per MK3 hergestellt wird, danach läuft alles normal.
3. Invertierter Load-Dump nach Einfrieren des Wertes der Leistung am Hauseinspeisepunkt:
Der Solar WR liefert volle Leistung, der MP2 lädt die Batterie mit voller Leistung.
Die LAN Verbindung zum VenusOS raspi wird unterbrochen, die Batterieleistung per Bluetooth Verbindung zum JKBMS beobachtet.
Der Solar WR schaltet ab (muss mir noch überlegen wie ich das hinbekomme, vielleicht die Strings trennen).
Erwartung: Der MP2 lädt weiter bis die Batterie voll ist und nimmt die Leistung aus dem Netz, statt vom PV WR.
Ist: - Test noch nicht durchgeführt -
Schreibt gerne mal Eure Meinung - ich bin gespannt.
EVE 16s/230Ah, JKBMS, MPII-48/3000/35-32, Raspi 2B mit VenusOS, Nulleinspeisung
@pfalzkind sehr Interessant, gut zu Wissen wie sich der MP2 in solchen Situationen verhält.
Von mir gibts auch endlich mal wieder was neues, mein Stahlgehäuse ist nun auch fertig!
Aufgebaut ist es mit 3mm Stahlblech und Zusätzlich 10/12mm Gipfsfaserplatte innen.
Es gibt mal wieder was neues...
Mein geplanter PV Zubau nimmt nun endlich Formen an, es werden voraussichtlich:
- 8x405 JA Solar Full Black (JAM54S31-405/MR) auf dem Garagendach (fast Süd, ca. 30°)
- 4x405 JA Solar Full Black (JAM54S31-405/MR) an der Westfassade ohne Aufständerung
Bestands-PV ist ja ein Fronius Symo 8.2-3 mit 2 Strings: 9 Module und 21 Module.
Nun habe ich 2 große Fragezeichen bei denen ich mich über Input freuen würde 1. Wenn ich die neue(n) Anlage(n) regulär anmelde, fällt meine Einspeisevergütung (aktuell glaube 12,4cent) auf ca. 10,8cent. Kann ich das irgendwie umgehen? Macht es Sinn evtl. Victron MPPTs für die Strings zu verwenden und direkt auf die Batterie zu schalten? Macht das einen Unterschied für den VNB wenn ich mit den neuen Anlagen "theoretisch" nicht einspeisen kann?
2. Eben die WR Frage... vor allem die Garagenfläche wird Nachmittags zunehmend Verschattet, welchen normalen (1phasen) WR oder Victron MPPT würdet ihr dafür empfehlen? Können die Schattenmanagement oder muss ich evtl. sogar mit Optimierern im linken unteren Bereich arbeiten? Anbei mal noch ein Bild.
Könnte mir auch vorstellen den String der oberen Gaupe auf einen anderen WR/MPPT umzuhängen und den Bestands-Fronius das Schattenmanagement der Garage zu übernehmen?
Liebe Grüße
Eloeee