Nulleinspeisung ohne Batterie mit zwei Hoymiles und zwei OpenDTU-onBattery?

[andreash-esp]

Hi,

ich habe zwei Hoymiles und möchte über die OpenDTU-onBattery eine Nulleinspeisung ohne Akku realisieren, entsprechend der Anleitung hier https://github.com/helgeerbe/OpenDTU-OnBattery/wiki/Dynamic-Power-Limiter-%28Nulleinspeisung%29-%E2%80%93-OHNE-BATTERIE
Die Leistungsdaten am Hausanschluss hole ich von einem Shelly 3EM.
Die originale Idee war, den HM-300 einfach laufen zu lassen und den HM-600 zu regeln.

Das Problem dabei ist, dass die OpenDTU-onBattery ja nur einen Wechselrichter regelt. Setze ich den HM-600 auf max. 30W Einspeisung, und der GM-300 speist auch nochmal 100W ein, schaltet die OpenDTU-onBattery den HM-600 ab. Das möchte ich vermeiden.

Da die Hardware ja praktisch nix kostet würde ich einfach eine OpenDTU pro Wechselrichter nehmen, und die zeitversetzt regeln lassen. Also von mir aus einer alle 5 Minuten, einer alle 7. Oder gibt es da eine elegantere Lösung?

Andreas

[spcqike]

warum schaltet er denn ab und warum soll er es nicht?

bei einer Nulleinspeisung, willst du ja eben nichts einspeisen. wenn der HM-300 seine 100W produziert und du damit bereits auf 0W am Shelly kommst, muss / darf der HM-600 ja nicht laufen. soweit stimmt es doch.

reichen die 100W nicht, sollte der HM-600 entsprechend hoch geregelt werden, dass du auf 0W am Zähler kommst.

Zwei openDTU-onBattery können nicht gut aufeinander abgestimmt werden. sie laufen unabhängig voneinander. selbst wenn du die eine aller 20s und die andere aller 23s regeln lässt, kann es passieren, dass einer auf Volllast läuft und der andere gar nicht.

ich würde, wie beschrieben, den kleineren "offen" und "frei" laufen lassen und den größeren den Rest nachregeln. das sollte theoretisch laufen, wie du es oben beschrieben hast.

[andreash-esp]

Wieso er abschaltet, weiss ich nicht. Aber er sollte es nicht, weil das Hochfahren ja sehr lange dauert.

Ziel wäre praktisch irgendwas mit "HM-300 frei plus HM-600 mit Minimum 30W, damit er nicht abschaltet", weil er ja nicht beide parallel regeln kann. Evtl. funktioniert es dann ja sogar, wenn ich den HM-600 auf maximale Einspeisung 330W stelle?

Gerade schlecht zu testen mit dem bisschen Sonne.

EDIT: das funktioniert so nicht.
Stand jetzt habe ich ca. 100W Einspeisung und den HM-600 auf Angestrebter Netzbezug -300W gestellt. D.h. der Limiter am HM-600 dürfte gar nichts machen, da wir ja über dem angestrebten Bezug sind. Tatsächlich regelt er aber zwischen 70% und 100% herum.

[spcqike]

schon recht. er regelt "rum" weil dein Verbrauch unterschiedlich ist. mal regelt er auf 70%, also 420W, damit du auf -300W kommst (sofern denn genug Sonne da ist), mal macht er ihn auf 100% auf, damit du 600W erzeugen würdest.

selbst wenn das Ziel noch nicht ereicht ist, setzt er das Limit neu. Woher soll denn die openDTU wissen, dass die böse Wolke nicht in 0.5s weg ist und dann genug Leistung bereit steht? :)

aktiviere doch in deinem Fall mal das verbose logging und gucke in die Konsole, wenn der Wechselrichter ausgeschalten wird. da steht dann allerhand drin.

und, das "Minimum" ist nicht "produziere mindestens 30W". das bedeutet "produziere erst, wenn du mindestens 30W einspeisen kannst/musst".
heißt: wenn der HM-300 sagen wir 300W produziert, du im Haus 320W verbrauchst (am Shelly also nur 20W importierst), würde die openDTU-onBattery den HM-600 nicht starten, da für eine Nulleinspeisung (eingestelltes Ziel 0W) nur 20W erzeugt werden müssten.
in deinem Fall solltest du also den mindestwert so klein wie möglich setzen, damit der HM-600 auch 10W einspeisen darf, sofern benötigt und Sonne vorhanden.

[Tiese]

Hallo @andreash-esp,

schau dir doch mal mein Projekt: OpenDTU-Client an.
Der regelt einen 2. Wechselrichter unabhängig von OpenDTU-onBattery, Laderegler oder Akkustand (dieser kommt aber bald hinzu - abschaltbar). Und du bekommst sogar noch den Ertrag per Email ;-)

[Tiese]

Hallo @gubbel-alt ,
erst einmal danke für dein Interesse!

Da sich mein OpenDTU-Client mit der OpenDTU verbindet, die Daten per WebAPI abfragt und entsprechend reagiert, läuft es tadellos. 😁
Der Intervall der OpenDTU ist jedenfalls ungenauer, als der vom OpenDTU-Client. Es findet jedoch permanent eine automatische Anpassung statt!

Inzwischen gibt es die V2...

Schöne Grüße
Tiese

[Keule31]

Hallo Tiese, ich hätte großes Interesse an deinen Client, würde das Projekt gerne begleiten und testen, ich betreibe 2 HWR und würde die gerne auf Nulleinspeisung fahren, was mit der OpenDTU oB leider nur mit einem WR möglich ist, aber mit deinem Client tatsächlich funktioniert. Hat man irgendwie eine Chance an den Client ranzukommen? BG

[Tiese]

Hallo @Keule31,
ja, eine "nahezu" 0-Einspeisung ist möglich. 😃

Den OpenDTU-Client V1 hätte ich da, muss die Software aber noch an die neue Web-API-Version von OpenDTU anpassen.
Würde nur 60,-€ kosten (plus Versand) - und falls du nicht zufrieden sein solltest - es ist ein nRF24L01+ Chip, für die HM-Serie, integriert! Somit kann die OpenDTU-Software geflasht werden!
Ausstattung V1: 1,3" Display (weiß), ESP32, internes WLAN, nRF24L01+ Chip mit externer Antenne.

Der OpenDTU-V2 (wie hier oben abgebildet) würde 70,-€ kosten (zzgl. Versand), muss dafür aber erst die Teile bestellen (will meinen nicht hergeben).
Ausstattung V2: 1,54" Farbdisplay, ESP32, externe WLAN-Antenne.

Schöne Grüße
Tiese

PS: Bei Interesse setzte ich den OpenDTU-Client (entsprechende Version) auf kleinanzeigen.de rein!

[Keule31]

Hallo Tiese,
klasse ich freu mich riesig und ich nehme gerne den V1, wie kommen wir zusammen?
BG
Peter

[Tiese]

Hallo Peter,

hier die Anzeige auf Kleinanzeigen

Schöne Grüße
Tiese

[andreash-esp]

schon recht. er regelt "rum" weil dein Verbrauch unterschiedlich ist. mal regelt er auf 70%, also 420W, damit du auf -300W kommst (sofern denn genug Sonne da ist), mal macht er ihn auf 100% auf, damit du 600W erzeugen würdest.

selbst wenn das Ziel noch nicht ereicht ist, setzt er das Limit neu. Woher soll denn die openDTU wissen, dass die böse Wolke nicht in 0.5s weg ist und dann genug Leistung bereit steht? :)

aktiviere doch in deinem Fall mal das verbose logging und gucke in die Konsole, wenn der Wechselrichter ausgeschalten wird. da steht dann allerhand drin.

und, das "Minimum" ist nicht "produziere mindestens 30W". das bedeutet "produziere erst, wenn du mindestens 30W einspeisen kannst/musst". heißt: wenn der HM-300 sagen wir 300W produziert, du im Haus 320W verbrauchst (am Shelly also nur 20W importierst), würde die openDTU-onBattery den HM-600 nicht starten, da für eine Nulleinspeisung (eingestelltes Ziel 0W) nur 20W erzeugt werden müssten. in deinem Fall solltest du also den mindestwert so klein wie möglich setzen, damit der HM-600 auch 10W einspeisen darf, sofern benötigt und Sonne vorhanden.

Ich habe es ja so eingestellt:
HM-600 Angestrebter Netzbezug -300W, also sollte der HM-600 doch soviel produzieren, dass insgesamt 300W eingespeist werden.
Von dem HM-300 weiss er ja nichts.
Bei der heutigen Einstrahlung komme ich insgesamt aber nur auf ca. 240W, also 80W vom HM-300 und 240W vom HM-600.
Daher verstehe ich nicht, wieso der HM-600 von den 100% herunterregelt. Ich habe ja permanent Netzbezug bei meiner Grundlast von ~300W tagsüber

[spcqike]

Wenn du 80W am HM-300 und 240W am HM-600 produzierst, ~300W benötigst, fehlen dir nur noch 280W zu deinen -300W. Also muss der HM-600 ja nur 580W erzeugen. Dann wärst du bei -300W. Ergo stellt die openDTU das Limit auf 97%.

Produziert der HM-300 mal ne Minute mehr oder geht der Kühlschrank zu Hause aus und du brauchst weniger als 300W, muss noch weniger vom HM-600 produziert werden. Also fällt das Limit weiter runter.

[andreash-esp]

Ah, da habe ich wohl einen Denkfehler. Wenn der HM-600 auf 90% Limit steht, dann limitiert er nicht die eingehende DC-Leistung auf 90%, sondern die Maximalleistung.
Sinnvoll ist das wohl nur zu testen, wenn genügend von der Sonne kommt.

Danke für den Austausch!

[genmad]

@andreash-esp
Für dieses Problem gäbe es hier eine Lösung:
https://github.com/genmad/shellyAPIGen2AndAboveScripts/blob/master/src/openDTUonBattery/virtualPowerMeters_oDoB.js

Was man dazu braucht ist ein Shelly mit Api 2+.

In diesem Skript wird ein Virtueller Leistungsmesser je odob Controller erstellt. Ausserdem kann man eine minimale Leistung je Wr anheben, so dass diese immer laufen.

Es wird mindestens immer die minimale Leistung der Wrs ins Heimnetz eingespeist, solange Sonne und Batterie das zulassen.