@matzedonien2 Das gekürzte Log tritt nun nicht mehr auf. Habe die Ausgabe etwas angepasst. Ich hoffe die anderen Fragen haben sich soweit geklärt und es läuft nun bei Dir. Ich empfehle Dir den economical check auf 1 zu setzen, die Fixkosten für Deine Postleitzahl einzupflegen und dann auf Gesamtpreise umzustellen.
Gruß!
Christian
Moin Christian,
Die Fixkosten für meine PLZ hatte ich bereits eingetragen. Ich habe hierzu bei Tibber meine PLZ eingetragen und die dort genannten Fixkosten (Umlagen, Gebühren etc) bei mir unter "energy_fee" eingetragen.
Du schreibst ....dann auf Gesamtpreise umstellen. Muss ich das noch irgendwo extra aktivieren? Diese extra "Aktivierung" habe ich noch nicht gefunden.
Gruß Matthias
@matzedonien2 ...siehe Kommentare in der config... von energy auf total umstellen
@christian1980 sorry, oh man, hab ich nicht erkannt...
Wenns das für den Deye auch geben würde......
Würd auch gern so was realisieren aber ich bin ne 0 was Programmieren betrifft.
Was ich eventuell Beisteuern kann ist: Habe letztes WE einen Test gemacht mit dem 3p 12kW Deye und mit 10kW Akku geladen und wieder ins Netz Entladen.
Ermittelter Wirkungsgrad 80,5% wobei er vermutlich etwas höher ist da normalerweise mein Haus mehr zieht. Eventuell Wiederhole ich dies nochmals und schalte dann alle Sicherungen vom Haus aus.
@mobilesinmobile
Hi, wenn Du schaffst folgendes für Deinen Inverter folgendes herauszufinden und zu testen kann man das ganz einfach anpassen.
Auf der Shell musst Du folgendes können:
- zum Laden zwingen und wieder beenden, 2. SOC-Ladeziel setzen, 3. ESS abschalten und wieder einschalten, 4. SOC auslesen.
Vielleicht kannst Du die Deye Experten mal fragen. Du musst dann nur die folgenden Zeilen im Script austauschen:
charger_command_charge="dbus -y com.victronenergy.settings /Settings/CGwacs/BatteryLife/Schedule/Charge/0/Day SetValue -- 7"
charger_command_stop_charging="dbus -y com.victronenergy.settings /Settings/CGwacs/BatteryLife/Schedule/Charge/0/Day SetValue -- -7"
charger_command_set_SOC_target="dbus -y com.victronenergy.settings /Settings/CGwacs/BatteryLife/Schedule/Charge/0/Soc SetValue --"
charger_disable_inverter="dbus -y com.victronenergy.settings /Settings/CGwacs/MaxDischargePower SetValue -- 0"
charger_enable_inverter="dbus -y com.victronenergy.settings /Settings/CGwacs/MaxDischargePower SetValue -- $limit_inverter_power_after_enabling"
SOC_percent="$(dbus-send --system --print-reply --dest=com.victronenergy.system /Dc/Battery/Soc com.victronenergy.BusItem.GetValue | grep variant | awk '{print int($3)}' | tr -d '[:space:]')"
Gruß!
Christian
Sollte der DEYE alles können nur das mit Ab und Einschalten könnte ein Problem sein bzw. ich verstehe nicht wieso es nötig sein sollte den Wechselrichter Aus und Ein zu schalten. Hat das einen Speziellen Hintergrund oder ist dies einfach für Victron nötig um den Betriebsmodus zu ändern?
In meinem Regelbetrieb Speichert der Deye überschüssige PV in den Akku (kein Nezexport) und wenn der voll ist geht alles weitere in das Netz.
Man kann ihn aber auch Parametrieren (jederzeit) dass er vom Zeitpunkt x bis y, den Akku mit x Ampere bis x % SOC laden soll sowie dass er vom Zeitpunkt x bis y, den Akku mit x Ampere bis x % SOC entladen soll.
Sobald ich die entsprechenden Einstellungen ändere macht er das. Aus Einschalten muss man den Deye nicht damit er dies übernimmt.
Ein Ausschaltkommando gibt es leider nicht, das war schon öfter mal in der WhatsApp Grp ein Thema
SOC Übermitteln geht auch
Fals von Interesse: Wenn ich will dass der DEYE den Akku aus dem Netz lät muss ich ihm hier den Strom einstellen und das Laden aktivieren
danach die Zeit setzen, den SOC und hacken bei Grid Charge (rot). Will ich dass er ins Netzt entlät die Zeit setzen und den SOC bis wo hin, das Grid Charge Hackerl muss weg und er muss auf Selling First umgestellt werden
@mobilesinmobile
Wie gesagt, frag mal z.B. in einem Deye Forum. Ich habe keine Möglichkeit das zu testen.
Du musst nur das obige auf der Shell können, dann kann ich das Script um Deye erweitern.
Gruß!
Christian
Moin Christian,
ich habe ja nun einige Tage bereits getestet. Das funktioniert auch alles hervorragend und ich streite mich mit meinem Netzbetreiber, dass er mir einen Tibber kompatiblen Zähler einbaut. Hier weigert er sich noch ein wenig.
Heute fiel mir aber zum ersten Mal etwas auf, was ich nicht nachvollziehen kann und für mich unlogisch ist.
Die Preisbasis von Awattar sah so aus:
Der Speicher war zu 70% voll und die Log Datei sagte folgendes:
Nun meine Frage: Warum wird erst ab dem Preis 14 und folgende entladen? Der Speicher fing um 7 Uhr morgens mit dem entladen an. Aufgrund der Erwartung des PV-Ertrags gehe ich aber davon aus, dass die Menge nicht im Akku gespeichert werden kann, da der Kapazität bei 70% Füllstand nicht ausreichend ist.
Ich bekomme ca. 9,55 ct für meinen eingespeisten Strom. Speicherverlust beträgt etwas 23,3% und die Abschreibungskosten habe ich mit 3,55 ct/kWh kalkuliert. Das bedeutet für mich, dass der Strom aus dem Speicher bei Ladung durch die PV-Anlage ca. 15,32 ct/kWh kostet.
Nun habe ich die Befürchtung, dass der Speicher heute vormittag nur noch kaum entladen werden wird bis die Module Leistung bringen. Da heute aber niemand zu hause ist, wird der Speicher dann schnell voll sein und der Überschuss eingespeist.
Wie beeinfluße ich die Grenze für die Entladung am besten? Ich wäre davon ausgegangen, dass er den Speicher weiter entleert, da er 3,9 MJ pro m² erwartet?
Gruß Matthias
Hallo Matthias,
Du hast zwei Möglichkeiten. Entweder Du nutzt die Solarwetter-API um das Script ab einer bestimmten Ertragsprognose
ganz zu beenden oder Du konfiguriertst die Entladungsmatrix aggessiver. Schau mal ob Deine Matrix der aktuellen Beispielkonfiguration entspricht.
Wie Du weißt werden mehr Preise erst aktiviert wenn der Akku voller wird.
Bei mir geht heute auch was ins Netz weil der Akku voll ist, obwohl heute Nacht der Akku reserviert wurde.
Ggf. füge ich bald eine weitere Wetterapi hinzu die auch die Ausrichtung und Neigung der Panels berücksichtigt.
Das Feintuning ist momentan leider nicht ganz einfach und hängt von der individuellen Anlage ab.
Gruß!
Christian
@christian1980 bin gerade nicht zu Hause. Noch habe ich die Entladungsmatrix noch nicht angepasst. Ich habe diese glaube ich noch nicht ganz verstanden.
Vielleicht kannst du mir das nochmal erklären.
Es ist zwar nicht ganz dramatisch, wenn der Speicher voll ist, da dann als nächstes ab einer dauerhaften Einspeiseleistung von mehr als 500 Watt meine Warmwasserwärmepumpe startet und bei einer dauerhaften Einspeisung von mehr als 1.500 Watt nachfolgend auch noch ein Heizstab eingeschaltet wird. Dennoch würde ich den Strom zunächst lieber aus dem Speicher nehmen, als aus dem Netz, da das Sparpotential gegenüber der Warmwasserbereitung größer ist.
Gruß
Matthias
Ich würde sagen, mach erstmal ein Update auf die neueste Version und vergleich auch mal die Matrix mit der aktuellen Beispielmatrix.
Ich hatte die zuletzt schon etwas aggressiver konfiguriert damit früher entladen wird.
Moin Christian,
ich habe nun die Beispielmatrix verglichen und deine aktuelle Beispielmatrix eingefügt. Ich habe aber glaube ich immer noch nicht verstanden, wie die mittleren Werte der Matrix "Discharge_min_SOC" zu interpretieren sind.
Beispiel: Angenommen die Matrix sieht wie folgt aus:
"Charge Discharge_min_SOC Switch" # [0] Header
"1 96 1" # [1] Price 1
"1 92 1" # [2] Price 2
"1 88 1" # [3] Price 3
"0 84 0" # [4] Price 4
"0 80 0" # [5] Price 5
"0 76 0" # [6] Price 6
"0 72 0" # [7] Price 7
"0 68 0" # [8] Price 8
"0 64 0" # [9] Price 9
"0 60 0" # [10] Price 10
"0 56 0" # [11] Price 11
"0 52 0" # [12] Price 12
"0 48 0" # [13] Price 13
"0 44 0" # [14] Price 14
"0 40 0" # [15] Price 15
"0 36 0" # [16] Price 16
"0 32 0" # [17] Price 17
"0 28 0" # [18] Price 18
"0 24 0" # [19] Price 19
"0 20 0" # [20] Price 20
"0 16 0" # [21] Price 21
"0 14 0" # [22] Price 22
"0 12 0" # [23] Price 23
"0 10 0" # [24] Price 24
Im Log steht dann z.B.:
Dynamic ESS discharge (depending SOC) at prices: 20 21 22 23 24
Bis wieviel % SOC entlädt er nun den Speicher maximal?
Achso, meine Version des Spotmarket-switchers ist 2.4.11 und damit die neueste oder?
Hallo und erst einmal vielen Dank für dieses Skript! "Steinigt" mich bitte nicht, wenn ich irgendwas falsch formuliere oder so. Ich bin absoluter Laie in diesen Dingen...
Nach langem Probieren und Durchlesen der Beiträge hier, habe ich das Skript auf meinem Victron Cerbo GX zum Laufen bekommen. Der Eintrag in der Crontab war manuel zu erstellen (mit dem nano-Editor), dann hat aber alles so funktioniert wie es soll. Fehlermeldungen traten nicht auf. Die controller.sh ist planmäßig jede Stunde aufgeführt worden und in dem tmp-Ordner vom Cerbo sind die zu erwartenden Dateien (Preise, erwartete Solarenergie und die Log-Datei) ordungsgemäß aktualisiert worden.
Gestern habe ich die Firmware vom Cerbo auf die neueste offizielle Version 3.5 aktualisiert.
Nun wird der Skript nicht mehr ausgeführt. Die Log-Datei wird nicht mehr aktualisiert, es sei denn, die controller.sh wird manuell ausgeführt. DAs funktioniert auch weiterhin. Fehlermeldungen erscheinen nicht. In der Crontab vom Cerbo ist die Zeile "0 * * * * Link entfernt " weiterhin noch so eingetragen, uch nach einem Neustart vom Cerbo bzw. Überschreiten der Stundengrenze. Daher denke ich, dass das Nichtausführen des Skriptes an dem neuen Venus OS liegt.
Ist denn mit einem Update von dem Skript zu rechnen?
Grüße und vielen Dank im Voraus für eine Antwort!
Hi, das Script läuft auch unter 3.50 einwandfrei. Du musst Dich nur an die Installationsanleitung auf der Projektseite halten. Die Crontab kannst Du mit contab -e bearbeiten und dort wie beschrieben den Pfad zum controller-script eintragen.
Weiterentwicklung erfolgt immer noch, Updates sind auf der Projektseite zu finden (neueste Version ist im DEV branch).
Gruß!
Christian
Hallo,
Ich hatte das Script nach deinem letzten Update neu installiert. Nun läuft es! Danke nochmal.
Grüße