Skalierbare high-end, cheap-tech Nulleinspeisung mit Volkszähler-Monitor und tibber-Integration

Elektrik, DIY, Softwareprojekte, Neue Ideen Open Source - Software Projekte
201

Moin @e-T0m,

ich baue das Script gerad auf ei 24V System um und schaue deswegen gerade etwas genauer in das Skript rein um es zu verstehen.

Folgende Fragen sind mir dabei bisher gekommen:

  1. Du definierst ein max_bat_discharge. Das wird am Ende zu dem d['chg_power'] vom eSmart addiert. Kann man hier nicht direkt die max discharge Power die im eSmart hinterlegt ist nehmen oder übersehe ich funktional vielleicht etwas dass du es so löst?

  2. Du schränkst die Batterieleistung ja zwischen 48V und 50V ein. Wofür ist der zusätzliche PV_red_factor? Du berechnest ja schon eine niedrigere Batterieleistung mit der Powercurve. Aus dem Faktor werde ich leider nicht ganz schlau.

  3. Sobald die PV-Leistung 0 ist sendest du den max_night_input. Das heisst also wenn über Tag gerade mal gar nichts rein kommt wird auch nur max_night_input aus der Batterie gezogen auch wenn die Batterie voll ist und gerade mehr angefordert wird? ALso bzw. eigentlich immer wenn keine PV Leistung da ist wird auch nur 200W raus gesendet? Was ist der Hintergrund hier von? :slight_smile: /p>

  4. Nur zur Kontrolle dass ich das Script richtig verstanden habe:

Wenn die Batteriespannung >50V und kleiner 53V ist und PV_Leistung > 0, sendest du immer genau den Wert der zur Nullung des Zählers erforderlich ist. Also dass was vom Zähler über den Lesekopf kommt, korrekt? :slight_smile: /p>

Ich entschuldige mich schonmal wenn ich ein paar Sachen komplett falsch verstanden habe :d

Freue mich wenn du mir hier helfen kannst.

Danke :slight_smile: /p>

Schöne Grüße
Rainer

202

Hallo Rainer, ja das Einstellen der Systemspannung wollte ich längst mal einbauen... mal sehen...

  1. max_bat_discharge, ist dafür gedacht, den Entladestrom der Batterie zu begrenzen, deshalb wird die PV-Leistung dazu addiert. Die Energie aus der PV soll nicht beschränkt werden.

Erreicht der esmart seine discharge power, schaltet er die Last ab!

Ein 25 Ah Akku soll nur mit 1C entladen werden, also 25A, das würde aber nicht reichen um die 40A von 2 Soyo zu liefern.

Wenn also genug PV da ist, kann man damit trotzdem 2 Soyo fahren. Übrigens ist das je nach Spannung eine sehr knappe Angelegenheit :wink:

  1. pv_red_factor = 0.87 # PV reduction on low battery in % / 100, also eine Reduktion der PV-Leistung bei niedriger Spannung in % / 100

Du kannst es als Wirkungsgrad des PV-Anteils sehen.

Der zweite Teil ist dann die Leistung, die der Akku liefert, je nach (geglätteter) Spannung.

Der dritte Teil ist der statische "Verlustfaktor".

Das Gesamtsystem aus Laderegler, Soyo(s) und Akku haben verschiedene Verluste.

Die Regelung ist immer nur eine Annäherung daran, damit nichts schwingt, oder ins Takten (an-aus-an-aus) kommt.

Es ist Open-Source, spiel damit! :wink:

  1. max_night_input, die maximale Einspeisung in der Nacht

Sobald pv_cont (kontinuierliche PV-Leistung der letzten 24 Sekunden) gleich 0 ist, springt der Nacht-Modus an.

WENN zusätzlich die angeforderte Leistung größer ist als max_night_input, wird darauf begrenzt.

  1. Ja zwischen 50 und 53V wird das unveränderte Ziel angefordert, denn sämtliche Verluste sind in der Messung schon enthalten.

Ausnahme: Schwingungsunterdrückung!

Wenn ich helfen kann, tu ich das gerne! Viel Spaß beim Basteln!

203

Ansonsten ist soweit alles verstanden denke ich bis auf eine zusätzliche Frage bzgl. des eSmart:

Wie verhält sich der eSmart wenn er über die "Saturation Charging Voltage" kommt?

Kann man irgendwo sehen oder einstellen wie der Ladestrom dann runter gefahren wird?

Generell auch noch die Frage: Versucht der Soyosource immer mit der Nominalspannung zu laden?

Ein Nachtrag noch:

bat_p_percent = (bat_cont - 47.1 ) **4.326 -> Wäre noch interessant zu verstehen wo die Formel her kommt. Generell entsprechen die 4.326 ja dem geteilt durch Wurzel 2. (Was sich schonmal nach irgendwas mit Sinn und Verstand anhört :D). Wenn ich mir den Arbeitsbereich anschaue begrenzt du die Batterieleistung der Formel bei 48V - 50V somit auf ~63% -100%.

Hast du das aus dem Datenblatt von der Batterie?

Danke!

204

Moin Rainer.

300 W maximaler Batterie Entladestrom deshalb: jetzt im Winter reicht die Menge an PV-Energie längst nicht aus.

Viele Geräte takten und durch den Überhang bei deren Abschalten wird viel Energie verschenkt, aber auf kleinere Sprünge reagiert der Soyo schneller. (ramp speed)

Auch das neulich eingebaute "zero shift" hilft gegen diesen Effekt.

Es geht also dabei darum, den wenigen Strom möglichst effektiv zu verwerten. Der aktuelle PV-Strom kommt sowieso unbegrenzt dazu.

Der Esmart3 regelt wie alle MPPT-Regler: er zieht die PV-Spannung hoch, wenn der Strom reduziert werden soll.

Das funktioniert sehr zuverlässig. Was willst du denn da einstellen?

Schau dir mal "pv_u" im Volkszähler an, wenn der Akku in ferner Zukunft mal wieder voll wird.

Der Soyo liegt immer leicht über der Netzspannung, sonst könnte er nicht einspeisen.

Die Formel ahmt den Spannungsverlauf von LiFePo4 Zellen nach.

Die exakten Nachkommastellen und das Minus sind angepasst an die Rahmenbedingungen.

PS: deine github-links stören die Forensoftware

205
206

Die Spannung liegt laut Esmart immer 3V über dem Akku.

Bei A bin ich mir gerade auch nicht ganz sicher :wink:

Du kannst erstmal die B-Variante nehmen, statt 480 nimmst du 240:

bat_p_percent = powercurve[int(bat_cont*10-240)]

207

Der Verlauf ergibt sich aus der Kennlinie deiner PV-Module, aber den zeitlichen Ablauf kennt nur der Esmart.

208

Super! Dann noch eine letzte Frage bevor ich für mich weiter machen kann.

Da ich die Daten von einem Shelly3Em bekomme (wird im vzlogger per curl abgerufen) ist der identifier "total_power".

Es sollte ja reichen wenn ich im Script die Stelle if "1-0:16.7.0" in if "total_power" in l: ersetze oder?

Der Teil der danach kommt und wo er sich den Wert aus der Log holt sollte ja immer an der gleichen Stelle sein egal welcher identifier gesetzt ist oder?

Oder müsste man da eventuell noch ein paar Zahlen anpassen dass er an die richtige Stelle in der Zeile springt?

209

Das ist nicht ganz richtig, denn es kommen dann nur die ersten 10 Werte aus der Variable powercurve zum Einsatz.

Weil der Bereich von 24,0V bis 25,0V bei einer Kommastelle eben nur 10 Werte hat...

Mit ein wenig Glück, klappt das! ?

Wenn du es nicht hinbekommst, kannst du mal die entsprechende Zeile vom vzlogger.log zeigen.

210

Achtung veraltet! Inzwischen wird zwischen 48 und 51 V geregelt!

Wenn es nochmal gebraucht wird, bitte fragen.

Ich wollte es jetzt auch wissen. Die Formel für 24V (8S) Akkus ist:

bat_p_percent = (bat_cont - 23.55 ) **4.333 *20

211

Vielen Dank für die ganze Hilfe! Habe es gestern ohne PV Input in Betrieb genommen und es hat quasi auf Anhieb funktioniert.

Musste nur nachträglich dem vzlogger noch Rechte auf die /var/log/vzlogger.log gebe und den Serial Port auf meinen USB Dongle umstellen. Werde ich per UDev noch auf /udev/rs485 umstellen. :slight_smile:

Am Wochenende baue ich dann die PV-Verschaltung um damit ich unter die 150V komme und dann teste ich weiter.

Danke für das geile Projekt! Funktioniert bisher echt super und die implementierten Funktionen machen definitiv Sinn.

212

Jetzt bin ich aber neugierig. Hast du vielleicht einen Link zur Formel bzw. dem technischen Hintergrund? Würde mich da gerne einlesen. :slight_smile:

213

Kein Ding, wer vernünftig fragt, bekommt immer eine Antwort!

Ich freue mich, das deine 24-Adaption auch geklappt hat! Hast du einfach alle festen Spannungswerte im Script geändert?

Es gibt doch diese typischen Spannungskurven für LiFePo4 Zellen.

Da habe ich den entsprechenden Spannungsbereich angesehen: 3V bis 3.125V

Und dann eine mathematische Funktion gesucht, die dem ungefähr entspricht.

Die 2. und 3. Kommastelle sind einfach so angepasst, das bei 50V 100% rauskommen.

Es geht (mir) auch nicht darum, exakt diese Kurve zu treffen! Das ist nicht entscheidend.

Wichtig ist nur, den linearen Spannungverlauf auf den exponentiellen Abfall der Leistung zu übertragen.

Hier mein Code für Feintuning: ACHTUNG 24V (8S) Werte!

#!/usr/bin/env python3
max_bat_discharge = 900
for i in range(240,251):
bat_cont = 0.1*i
bat_p_percent = (bat_cont - 23.55 ) **4.333 *20
bat_power = int(0.01 * max_bat_discharge * bat_p_percent)
print('%.1f\t%.2f\t%.1f' % (bat_cont,bat_p_percent, bat_power) )
214
215

Das ist ein eigenständiges Script, nicht zum Einbau!

216

@e-t0m schon verstanden :wink: Aber die benötigten Teile davon werde ich dann nehmen wenn es funktioniert und in das Script einbauen

217

So. Nochmal ein Update. Es scheint soweit alles zu laufen.

Leider hab ich noch folgendes Problem:

Das Interface vom Volkszähler wird über die Tage immer langsamer bis man es dann irgendwann garnicht mehr aufrufen kann oder keine Daten mehr angezeigt werden. Das Script scheint aber im Hintergrund sauber weiter zu laufen.

Heute schien es aber zusätzlich noch so dass der Raspberry Pi sich ganz aufgehängt hat. Am Datenbank Überlauf sollte es nicht liegen da ich hier fest eingebaut hat dass die Daten alle 7 Tage gelöscht werden sollen.

Vielleicht reicht der Raspberry Pi 2 von der Leistung nicht aus um beides ziehen zu können? Script inkl. VZ Web Interface?

@e-T0m: Welche Befehle hast du in der crontab zum Umgang mit den Datenmengen?

218

Das zeroinput script braucht nur minimale Ressourcen.

Das wahrscheinlichste Nadelöhr ist die Datenbank des volkszählers.

Die ist aber nur indirekt Verursacher des eigentlichen Problems: laaaaangsamer Dateizugriff auf der Speicherkarte.

Du kannst das mit einer schnelleren SSD/Platte/Stick testen/lösen.

Ich will hier aber nicht zu sehr auf den volkszähler eingehen, das wurde/wird an anderer Stelle sehr ausführlich getan.

Die Notfall-Brechstangen Methode mit komplettem volkszähler-Datenverlust:

mariadb
use volkszaehler
show tables;
truncate data;
systemctl restart mariadb.service

Bei meinem Pi4b mit schneller Speicherkarte und sehr vielen hochauflösenden Kanälen (1sec),

ist die "Lebensdauer" ca. 3 Monate.

Allerdings mache ich die Langzeitauswertung auch nicht mit dem Volkszähler.

Sondern rufe die Tageswerte mit diesem script ab: zeroinput/read_vz.py at main · E-t0m/zeroinput · GitHub

219
220

"TRUNCATE TABLE empties a table completely."

Ja so ist das oft bei freier Software: suchen und selber machen :wink:

Bei mir kommt die mariadb nach 3 Monaten auf ca. 4GB und damit kommt sie nicht klar.

Woran das genau liegt habe ich nicht untersucht.

kuck mal da: https://wiki.volkszaehler.org/howto/performance-optimierung_des_raspberry_pi