OpenDTU mit Batterie und Zeitsteuerung?

[3aau]

moin, ich habe hier eine balkonanlage mit einem hm1500 (4 panel a 400watt) plus eine batterie.
diese hat bms mit drinn und kommt zwischen panel und hm1500.
da ich noch keinen leistungsmesser im schaltschrank habe soll das per zeit gesteuert werden.
also von 22:00 bis 8:00 soll der HM1500 nur die nachtabdeckung ( c.a 200watt ) aus der batterie nehmen.
wie und was muss ich da bei der openDTU-onbattery einstellen?
danke.

[schlimmchen]

Das wird nicht unterstützt.

Du kannst feste Limits für deinen Inverter über MQTT einstellen. Mit einem kleinen Stück Software (auf einem Server der eh läuft, auf einem Raspberry Pi, oder auf einem anderen Mikrocontroller) kannst du die entsprechenden Topics beschreiben, und der Inverter wird das entsprechende Limit haben. Das tust du dann um 22 Uhr und um 8 Uhr. Oder mit passender Bibliothek machst du das zum Sonnenuntergang bzw. Sonnenaufgang.

[rs3hc]

Wie @schlimmchen schreibt, kannst du das z.b. in Home Assistant per Automation machen.

Ist ein guter Ansatz

[3aau]

ups...
danke erstmal für die antwort. hatte mich schon gewundert das ich hier nichts im forum darüber gefunden habe.
ich hatte gehoft das dieses als minimal-basis funktion mit drinn wäre. ich habe leider keinen zusätzlichen server am laufen.
und nur dafür einen aufzubauen ist etwas viel aufwand. das könnte die OpenDTU doch gleich mit erledigen.

[spcqike]

Wenn es wirklich nur nachts feste 200W sein sollen, tagsüber in Ermangelung des powermeters nichts, dann vielleicht Mit nem Shelly oder smarten Zwischenstecker Den wechselrichter AC seitig trennen.

Die Shelly’s und co haben ja Timer integriert.

[3aau]

eigentlich bräuchte ich Tags über Phigh und nachts Plow.
ist das über hardware also einen Pin steuerbar?
Px high = HM1500 Plow (200watt)
Px low = HM1500 Phigh (800watt)
die batterie ist eine BluePalm mit 2.5 kW/h und eigenem BMS . die hängt zwischen Panel und HM.
ist die sonne weg muss der HM halt gedrosselt werden. eigentlcih ganz einfach.

[Manos1966]

kommt zwischen panel und hm1500

Wie wird die Batterie geladen?
Wieviele Volt hat die Batterie? (12-24-48V)
Wieviele Eingaenge der HM1500 sind an die Batterie angeschlossen?

...und wie gross ist die Kapazitaet der Batterie? (kWh)

[3aau]

erledigt das eingebaute BMS.
48Volt
2

[Manos1966]

Gute Batterie 👍

200W x 10 Stunden = 2kWh bei 100% Batterie Nutzung,
besser waere natuerlich bis 10% max leer machen und bis 90% voll (oder? "Frage an alle Forum Mitglieder")
also 2,5kWh waere die optimale Grosse (und die hast du 😄 )

[genmad]

Verstehe ich das richtig, du sparst das Batterieladegerät weg, in dem du die panele direkt an die Batterie hängst? Die arbeiten dann aber nicht an ihrem optimalen Leistungspunkt, oder?

[spcqike]

erledigt das eingebaute BMS.

Halte ich für keine gute Idee. Abgesehen vom fehlenden MPPT und den daraus resultierenden Effizienzverlusten, wie stellst du sicher, dass die Paneele nachts keinen Strom ziehen und die Batterie zusätzlich entladen?

[Manos1966]

@3aau Ich glaube die Antwort ist nicht genau die, die du erhofft hast:

Die OpenDTUonBattery ist fuer die Nulleinspeisung optimiert.
Die bedeutet dynamische Steuerung auf Basis:

1. der Solar-Produktion
2. des Stromverbrauchs
3. der Batterie-Kapazität %

Da du teilweise 1 aber weder 2 noch 3 hast, ist es etwas "unglücklich"

Die Loesung wäre schnellstmöglich einen Leistungsmesser (WiFi Hichi fuer Digitale Stromzaehler oder Shelly 3EM fuer Ferrari Stromzaehler) zu installieren.

[Sorbat]

Ist der shelly für digitale Zähler nicht zu empfehlen?

[genmad]

Man kann den shelly auch für digitale ZÄHLER verwenden, aber der hitchi ist billiger und ohne elektriker zu installieren, wenn man denn einen digitalen zähler hat.

[Manos1966]

Ist der shelly für digitale Zähler nicht zu empfehlen?

Der Hichi ist fuer digitale Zähler besser weil er direkt die Daten des Zählers wiederspiegelt.
Der Shelly muss sie berechnen.
Ausserdem, Hichi kostet 25EUR, der Shelly 120EUR.

[3aau]

Manos1966
tja, ist etwas enttäuschend. ist doch eigentlich eine grundfunktion.
für alle die es noch nicht verstanden haben:
der akku hat einen eingang der kommt das pannel drann
einen ausgang der kommt der wr drann
im akku ist ein BMS verbaut das sich um laden/entladen kümmert
kommt vom panel saft wird der akku geladen und was zuviel ist wird an den wr durchgereicht
kommt nix vom panel speist der akku den wr
tags über alles ok bei kurzen abschattungen wird halt der maximale strom aus dem akku genommen
wirds dunkel macht das natürlich keinen sinn und der wr muss auf nächtliche grundlast gedrosselt werden bis die nacht vorbei ist
genau dafür wäre eine einfache zeitsteurung gut. man braucht nur die panels, wr, akku und die opendtu. keine externen server oder internet am standort. also eine schöne kleine minimal instaltion.
als luxus könnte man den wr bei tagsabschattung auch auf einen kleineren wert drossel. hierzu müsste man allerdings die leistung an einem der direkt angeschlossenen panel erfassen. also
if (tag)
{
if(freiespanel > akkupanel) wr=tages_maxwert
else wr=tages_minwert
} else wr=nacht_wert

[3aau]

@Manos1966
moin, da das ganze dann auf meinem teensy4.1 datenlogger läuft und nicht im opendtu wird das wohl eher nicht hilfreich für die allgemeinheit sein. aber ich kann gern darüber berichten.

[3aau]

moin,
erster kleiner zwischenbericht.
funktion läuft und ist auch nach einem stromausfall sicher wieder gestartet.
im moment läuft das ganze noch ohne batterie. die kommt drann wenn genug sonne das ist.
leider hatte ich zwei mal das morgens beim hochfahren des WR die MQTT verbindung nicht aufgebaut worden ist.
im menue einstellungen/mqtt/ speichern und schon ging der datentranver wieder.
kennt das problem irgend wer?

[Artikel14]

Eine solche Zeitsteuerung des Leistungslimits direkt im ESP32/OpenDTU benötigen Bekannte von uns.
Derzeit können sie die Leistung nicht genau messen und wollen auch keinen zweiten Stromverbraucher für MQTT.
Nachts ist es die Grundlast z.B. 62 Watt, tagsüber etwas mehr (rund 100W). Abends und am Putztag ca. 200/300W.
Im Forum zu OpenDTU habe ich dazu etwas geschrieben:
tbnobody#1095 (comment)

In C++ habe jetzt mal angefangen ein Beispiel zu programmieren, um zeitabhängige Leistungsprofile erstellen, ändern und nutzen zu können.
tbnobody#1095 (reply in thread)

Da es um eine preiswerte besonders nachhaltige Eisenphosphat-Akkulösung mit sehr hohen Wirkungsgraden geht, passt es eigentlich wohl eher hier zu OpenDTU-OnBattery statt zur ursprünglichen OpenDTU.

Falls diese Funktion hier aber nicht relevant wäre, würde ich überlegen erstmal einen sogenannten Fork anzulegen.
Ein Fork bedeutet, dass ein neues, separates Repository erstellt wird, das zunächst unabhängig vom Original wäre.
Der Fork erfolgt in der Regel, wenn ein Benutzer beabsichtigt, signifikante Änderungen am Projekt vorzunehmen. Für Tipps, Anregungen und Hilfe bin ich gerne offen.

[Artikel14]

Einige nützliche Erweiterungen plane ich einzubauen, komme aber alleine nicht so gut voran.

Variante #2 "Profildatei":
Die uhrzeitabhängigen Profile könne man auch einfach in einer Datei hochladen (ähnlich wie bei der Pinbelegung).

Variante #3 "Cloudlösung":
Man könnte dies auch in Google-Tabellen pflegen und über die Google-API einlesen oder abrufen.

Variante #1 "In der OpenDTU"
Pfege in der Weboberfläche der OpenDTU.

Welche Variante davon wäre die beste ohne MQTT?

[stefan123t]

Ich bin für Variante 1 oder 2.
1 ist schön aber aufwendig und 2 einfach aber effektiv.
JSON verwendet OpenDTU beim Pin Mapping und den Settings ja auch.

[resonnbas]

Hallo Artikel14,
für den kleinen Endverbraucher kommt eigentlich nur die Variante #1 in Betracht. Ich warte auch schon sehnsüchtig auf solch eine Lösung. Danke für deinen Einsatz.

[spcqike]

Ggf mal hier anfragen und das Thema pushen.
tbnobody#796
Wenn es im originalen openDTU ist kann es auch hier genutzt werden

[Artikel14]

Im Menü könnte ich mit vorstellen einen Eintrag unter
"Dynamic Power Limiter" mit dem Namen z. B.
"Scheduled Power Limiter" (Zeitlich geplante Leistungssteuerung).

Die Weboberfläche könnte sich sehr stark am Design des Punktes Wechselrichtereinstellungen orientieren.

(1) "Leistungsprofil hinzufügen"
(2) "Leistungsprofil bearbeiten" (Stiftsymbol)
(3) "Leistungsprofil löschen" (Mülleimer-Symbol)

Man könnte als nächstes mal ein Mockup für die neue Seite bauen
(optischer Design-Entwurf auf der Basis "Wechselrichtereinstellungen).

Ein virtuoser Programmierer bin ich eher nicht und müsste mir zwischendrin
jeweils die Zeit nehmen, aber in ein paar Wochen könnte ich das schaffen.
Derzeit setze ich mir eine Entwicklungsumgebung auf
(Notebook plus Visual Code Studio Software)
und habe begonnen den Quelltext zu studieren, um herauszufinden, wo
man die Ergänzungen so vornehmen kann, dass es gut ins Gesamtsystem passt
und keine anderen Funktionen gestört werden. Das Ganze muss beispielsweise
das vorhandene System der Mehrsprachigkeit sauber unterstützen und die
Aufteilungen in Model/View/Controller.

Vielleicht kann ein anderer Entwickler Tipps geben, wie man es angehen sollte
und was man bei der Mehrsprachigkeit und MVC etc. berücksichtigen müsste.

[spcqike]

die Idee finde ich grundsätzlich gut, aber was spricht dagegen, das Ganze im Upstream zu verfolgen?

Wenn ich es könnte, würde ich wohl versuchen, das dort anzubringen.

Wenn die allgemeine zeitabhängige Steuerung in openDTU integriert wäre, könnte man in openDTU-onBattery im Dynamic Power Limiter "einfach" darauf zurückgreifen, und das aktuelle Limit aus deinem vorgeschlagenen Scheduler einfach als weitere Obergrenze betrachten. (an einer Stelle wird ja bereits geprüft, ob das neue, berechnete Limit größer ist, als das, was als oberes Leistungslimit im DPL hinterlegt wurde, an dieser Stelle müsste man dann den DPL erweitern)

[Artikel14]

Klingt sehr gut für mich, aber noch versuche ich die Struktur besser zu verstehen.
Was ist und wo finde ich den "Upstream"?

[spcqike]

der Upstream ist das originale openDTU von tbnobody.tbnobody#796
openDTU-onBattery ist ja ein Fork davon, baut aber weiterhin auf die openDTU auf.

Einfach gesagt: jede Abweichung, die im Fork eingebaut wird, muss nach einem Update im Upstream erneut geprüft werden. Es muss ja sicher gestellt werden, dass dass die Änderungen am "Original" unsere Anpassungen nicht gefährden und das alles weiter läuft, wie es soll.

Das ist auch ein Grund, warum in openDTU vorhandene Funktionen von openDTU-oB nicht angefasst werden, wenn nicht zwingend nötig.

Daher bietet es sich an, solch grundlegenden Änderungen wie das OLED und auch ein Scheduler, der auch in openDTU bereits mehrfach angefragt wurde, in openDTU zu platzieren. Durch kommende Updates seitens openDTU-onBattery, kommen diese Anpassungen dann auch hier im Fork an.

[Artikel14]

Hier mal mein erstes Mockup (Design-Entwurf):

[spcqike]

würdest du nur ein "Tag/Nacht" vorsehen, welches die openDTU(-oB) ja bereits kennt, oder freie Zeiten definieren? bei letzterem wäre es auch gut, würde die Start- und Endzeit in der Übersicht ersichtlich sein.

[Artikel14]

Ja, Tag/Nacht und deutlich mehr.
Weitgehend frei einstellbare Zeiten würde ich dafür ermöglichen wollen.
Diese sollen sich sogar je nach Profilreihenfolge in der Auswertung auch "gezielt überschreiben" können.

Damit realisierbare Beispiele:
{Grundlast/Nachts 62 Watt, aber tagsüber 100 Watt, jedoch am Abend 220 Watt, und montags 13 bis 19 Uhr 400 Watt (weil Wasch- und Putztag).}

Außerdem könnten zwei kleine automatische Optionen für Sonnenaufgang / Sonnenuntergang (mit einem einstellbaren zeitlichen Offset) als dynamisch ermittelte Zeiten berücksichtigt werden.

{20 Min nach Sonnenaufgang 100 Watt, 25 Minuten vor Sonnenuntergang 62 Watt}
Dies würde den Wirkungsgrad meiner selbst-konstruierten hochoptimierten Speicherlösung via indirektem Solar-Paththrough noch etwas weiter erhöhen, weil weniger durch den Akku fließt und direkter an den Wechselrichter. Jeder soll möglichst generisch einstellen können was man braucht.

Start- und Endzeit sollen zukünftig in der Übersicht ersichtlich sein. Vielleicht verbessere das Mockup in Kürze nochmals, damit dies ersichtlich wird.

[spcqike]

klingt alles schön und gut, denk aber auch dabei daran, dass die unterschiedlichen Profile auch an einer Stelle ausgewertet und korrekt berechnet werden müssen :)

Im Upstream bspw. gibt es ja noch gar keinen PowerLimiter. der Scheduler bräuchte also auch einen loop(), ähnlich dem DPL in openDTU-oB, der regelmäßig läuft und das entsprechende Limit an den Wechselrichter überträgt. bzw, da die Info in openDTU-oB ja ebenfalls ankommen muss, vielleicht sollte der loop() das grade aktive profil einfach nur flaggen, ohne es direkt zu setzen.

der Scheduler könnte 2 Toggle haben.

1. zum allgemeinen aktivieren, dass das Menü zum konfigurieren überhaupt sichtbar wird.
2. zum automatischen limitieren des Wechselrichters. (Wie willst du es handhaben, wenn man mehrere Wechselrichter hat? das kann openDTU-oB bisher auch nicht)

Dann würde der Scheduler:loop() regelmäßig das aktive Profil oder Leistungslimit prüfen und flaggen/zwischen speichern. und in openDTU im Anschluss auch an den einen (oder mehrere?) Inverter Übertragen.

openDTU-oB könnte darauf aufbauen, müsste toggle 2. nicht setzen und könnte im vorhandenen dynamic power limiter einfach den aktuellen Leistungdwert vom Scheduler abrufen und entsprechend im DPL berücksichtigen.

so in etwa 😄

[stefan123t]

@spcqike dazu bitte mal den feature request upstream lesen tbnobody#1095
Es wurde vorgeschlagen ein sog. PV-Pool als zusätzliche Abstraktion zwischen WR bzw. MQTT/PV-Panels und dem Globalen Werten einzuführen. Dadurch kann man auch Summen über einen PV-Pool bilden und für den PV-Pool ein gemeinsames Limit entweder über den hier genannten Scheduler oder über MQTT vorgeben.

[resonnbas]

Hallo zusammen, darf ich fragen ob es Fortschritte gibt? Ich könnte die Funktion jetzt sehr gut gebrauchen. DANKE für eure Bemühungen.