Sammelthema: Erfahrungsaustausch Betreiber Hoymiles Mikrowechselrichter an Akku

Ich verwende OpenDTU schon seit einem guten Jahr. Man hat enorme Verbesserungen vorgenommen und es läuft sehr stabil und unauffällig. Von daher bin ich sehr zufrieden damit.

Wieviel speist Du denn pro Tag ein? Eine Nulleinspeisung wird ja über den Tag gesehen immer ein wenig einspeisen, allein schon der Regelung geschuldet. Oder man setzt den Netzbezug, auf den man regelt, so hoch, dass man aufgrund der Regelung nie zum Einspeisen kommt.

Liest Du deinen 2.8.0er-Zählerstand automatisiert aus und kannst mir hier mal einen Vergleich nennen? Würde mich mal interesseiren.

Den lese ich einmal im Monat manuell ab, da er leider nicht wirklich in der Nähe ist. Den als Referenz für die Funktionsweise zu nehmen bringt aber nichts, da ich absichtlich zu viel ins Netz einspeise, sobald der Akku voll ist :wink:

Die Daten beziehe ich per Shelly 3EM im Sekundentakt und logge sie auch entsprechend häufig mit (in der Regel habe ich zwischen 85500 und 86000 Datenpunkte pro Tag, ab und zu bleibt was auf der Strecke).

Ich hatte es weiter vorn schon geschrieben: aktuell regle ich alle drei Sekunden nach, sofern der Wert am Zähler außerhalb den von mir definierten Bereich verlässt. Da kommt man sogar halbwegs der Waschmaschine hinterher.

Über den Sommer war mein Regelziel auch selten 0 W, sondern irgendwo im negativen Bereich, selbst wenn der Akku nicht voll war (hat also auch begrenzt Aussagekraft).

Beispiele, an denen der Akku nicht oder nur kurz voll war, aber auch nicht leer (also 24 Stunden die Regelung lief):

  • 31.08.2023 14,5 Wh eingespeist (Regelziel war vermutlich etwas oberhalb 0 W +/- 5 W)

  • 03.09.2023 60,2 Wh eingespeist (Regelziel war vermutlich 0 W im Bereich +0/-10 W)

  • 13.09.2023 27,8 Wh eingespeist (Regelziel war vermutlich 0 W im Bereich +/- 5 W)

Sowas will ich aber ohne raspi. Ein esp8266 oder esp32-c3 reicht da völlig aus. Bei mir schaltet ein 8266 die brauchwasser WP je nach solarleistung ein/aus und das läuft seit 2 jahren zuverlässig. Macht auch schöne bilder mit dem internen webserver. Attached rot = shelly3EM momentanleistung, blau gefilterter wert.

Gibt es den hoeymiles nrf2401+ code in C irgendwo schön abgepackt für die esp's?

@eenemeenemuu

Kann man so pauschal nicht sagen. Für mich zeigt der 2.8.0-Wert wie gut die Regelung funktioniert, d.h. wie gut eine Nulleinspeisung umgesetzt ist. Ist meine Abtastrate zu niedrig, erhöht sich der 2.8.0-Wert. Ist die Abtastrate zu hoch, kann es passieren, dass man dem Hoymiles neue Limits setzt und bevor dieser die übernommen und auch am Ausgang sich darauf eingestellt hat, kommt schon das neue Limit. Somit schaukelt sich das Ganze auf. Das sieht man einerseits an ständig neuen Sollwertvorgaben in kurzer Zeit und auch am 2.8.0-Wert (je nachdem wie nahe die Vorgabe am 0-Bezug liegt).

Meine Erfahrungen sind, dass man den Hoymiles überfahren kann, wenn man im 3 sec. Rhythmus neue Limits schickt. Und das hat nichts mit dem System dahinter zu tun, sondern einzig und allein mit dem Regelverhalten des Hoymiles. Er kennt ja das Limit, braucht aber Zeit x um am Ausgang die gewünschte Leistung bereitzustellen. Kann sein, dass das nur auftritt wenn man geringfügige Änderungen macht. Kann aber auch sein, wenn es große Änderungen sind. Da habe ich noch nicht wirklich herausgefunden. Es geht längere Zeit problemlos, aber manchmal tickt der völlig aus. Das Spiel geht dann einige Minuten, dann -aus welchem Grund auch immer- passt alles wieder. Also wäre nichts gewesen. Zeit x kann manchmal 1...2 sek. sein, dann ist alles ok. Manchmal scheint Zeit x eher Richtung 5...6 sek. zu gehen, dann passiert genau das gerade beschriebene.

Nachdem ich die Leistung direkt vom Stromzähler nehme, kenne ich auch 1.8.0 und 2.8.0. Deshalb die Frage an Dich.

@s-b-2 Zum Verständnis für mich und damit wir nicht aneinander vorbei reden: 1.8.0 ist für mich der Bezug in kWh und 2.8.0 die Einspeisung in kWh. Mein Zähler gibt mir das am Display jeweils in ganzen kWh aus. Zusätzlich kann ich am Display die aktuelle Leistung ablesen, die positiv oder negativ sein kann.
Zum Thema "braucht einige Zeit bis die Leistung eingestellt ist". Ich habe bisher HM-300/400/600 getestet. Jeder davon setzt das Limit meiner Erfahrung nach innerhalb einer Sekunde um (öfter bekomme ich keine Daten vom Shelly). Manchmal beobachte ich auch dieses Schwingen. Ich habe das bisher auf nicht empfangene Pakete beim Hoymiles geschoben, daher schicke ich mittlerweile in der "Wartezeit" sicherheitshalber jede Sekunde denselben Wert noch einmal raus. Daher regle ich auch alle drei Sekunden und nicht alle zwei. Davon erhoffe ich mir weniger Schwingerei, falls doch mal mehrere Pakete nicht ankommen :wink:

Ja genau. Nachdem ich den Zähler optisch auslese und diesen Leistungswert verwende, bekomme ich die beiden Zählerstände 1.8.0 und 2.8.0 mit 7 Nachkommastellen sowieso. Von daher ist das für ein ganz guter Hinweis, wie schnell und genau meine Regelung in Richtung Nulleinspeisung geht.

Meine Beobachtung ging eher in die Richtung: Das neue Limit hat der Hoymiles empfangen (zu sehen an der OpenDTU-Weboberfläche und über MQTT), kriegts aber manchmal nicht hin, schnell zu regeln. Meistens klappts aber ganz gut.

Mit den Hoymiles mit mehreren Eingängen scheint es etwas tricky zu sein, wie ich hier im Topic gelesen hatte. Deshalb wollte ich bewusst bei denen mit einem Anschluss bleiben und kann zum HM-600 nichts sagen. Das DC-DC ist einerseits um auf 48V hochzukommen, denn damit laufen die HM-400 bei mir tadellos im gesamten Leistungsbereich oberhalb von 25W. Außerdem sind die DC-DC gleichzeitig mein Einschaltstrombegrenzer und galvanische Trennung zwischen Hoymiles und Batterien.

Danke für den Hinweis. Ich habe das im Posting oben gerade noch eingefügt. Grundsätzlich kann man mit den Shellys schön IST-Werte und Statistiken in der Shelly App anschauen. Ich mag sowas sehr. :slight_smile:

Die 8x Shelly für die Blue Smart Charger brauche ich zwingend, um die Charger per MQTT ein- und auszuschalten.

Die 4x Shelly an den Hoymiles sind mehr informativ für die Statistiken und Werte. Aber gleichzeitig auch Überwachung und ein AC-seitiges Not-Aus aus der Ferne per App, wenn der Entlade-Algorithmus oder OpenDTU mal groben Unsinn machen würde.

Ja, dankeschön. Läuft wirklich sehr stabil und fein. Ich bin glücklich. :slight_smile:

Ja, da stimme ich zu 100% zu. Ich habe im Posting nochmal meine Gedanken zu 24V bzw. 48V eingefügt. Grundsätzlich hätte ich auch gern ein 48V System gewählt, da es da auch mittlerweile viele schöne Batterien zum guten Preis gibt. Aber das Thema Einschaltströme wollte ich mit einer "fertigen" Lösung erschlagen und ich mag die AC-Charger von Victron wirklich sehr. Und da gibt es leider noch keine native 48V Lösung von Victron, weil das vermutlich auch kein relevanter Markt ist.

Nein, sehe ich auch nicht als Schlechtreden. Alles gut. Du hast ja Recht und völlig korrekte Argumente. Für meine Situation war es für mich die zweckmäßigste Lösung, die lediglich unnötig viel gekostet hat.

Das klingt interessant, danke. Ich habe OpenDTU eingesetzt und nicht -onBattery. Wobei ich OpenDTU mittlerweile über meine Steuerung so nutze, dass das mit der Queue und einem möglichen "Verstopfen der Pipeline" nicht mehr relevant ist. Ich werde es mir bei Gelegenheit aber mal anschauen.

Dazu eine Frage - mit welcher Firmware arbeitest Du beim 3EM?

Bei mir hat der Shelly Pro 3EM mit der 0.14.x Firmware auch fleißig im 3s-Takt in der App sowie über MQTT die Werte geliefert. Damit habe ich immer 5 Pakete über den Mittelwert geglättet und somit alle 15s geregelt, aber alle 3s den aktuellen Wert gesehen. Seit dem neuesten Update auf 1.0.3 war damit leider Schluss und die Werte kommen über MQTT und App nur noch alle 15 Sekunden. Damit musste ich natürlich das Glätten weglassen und mit dem aktuellen Wert arbeiten. Hat mich anfangs geärgert, dass ich nur noch 15 Sekunden einen Wert bekomme, aber mittlerweile bin ich damit auch ganz zufrieden, weil ich dann direkt auf den aktuellen Ist-Wert regele und nicht mehr über den Mittelwert glätte. Damit verschärft sich für mich lediglich das "Mikrowellen"-Problem. :wink: Aktuell gibt es schon wieder eine 1.0.6-beta1, aber die habe ich noch nicht gesetzt und hoffe einfach mal, dass die Update-Frequenz des Pro 3EM wieder verbessert wird.

Ich hab die 1.0.6-beta1 auf meinem Pro 3EM laufen, funktioniert gut und die Werte kommen wieder fix (lokal und auch in die Cloud)

1 „Gefällt mir“

Ich weiß nicht wie OpenDTU das handhabt und von MQTT habe ich mich auch schnell wieder verabschiedet. Meine Beobachtung mit AhoyDTU ist jedenfalls folgende: setze ich das Limit nicht mit der AhoyDTU, sondern anderweitig (bspw. mit meinem Script), zeigt AhoyDTU immer das ihm letzt bekannte Limit an. AhoyDTU nutze ich rein informativ und obwohl meine Nulleinspeisung ja den ganzen Tag lang verschiedene Limits setzt, zeigt AhoyDTU den ganzen Tag fröhlich 50% an. Was ich damit sagen möchte: nur weil *DTU anzeigt, dass das Limit gesetzt wurde, würde ich nicht meine Hand dafür ins Feuer legen, dass es auch tatsächlich beim Hoymiles angekommen ist. Wie gesagt, das mag bei OpenDTU ggf. anders funktionieren. Kannst dir ja mal den Spaß machen und eine zweite OpenDTU auf denselben Wechselrichter aufschalten und schauen, ob das Limit sich dort auch anpasst, oder wie bei mir den ganzen Tag auf demselben Wert sitzt.

Edit: Was ich geschrieben habe muss ich etwas korrigieren. Während ich hier geantwortet habe hat sich das in AhoyDTU angezeigte Limit tatsächlich von 50% auf 70% geändert. Offenbar fragt AhoyDTU doch in gewissen Zeiträumen das Limit ab (keine Ahnung ob das durch ein Firmwareupdate kam). Wirklich zeitnah scheint das aber nicht zu sein. Gerade läuft die Waschmaschine, da hab ich alle paar Sekunden komplett andere Limits.

20220415-105853/v1.11.7-25-gb3b096857-v1.11.7-3em

Da der 3EM so wie er ist für mich funktioniert und ich die Shelly-Cloud nicht nutze, hab ich die Firmware höchstens nach der erstmaligen Inbetriebnahme auf den damals aktuellsten Stand gebracht. Ich nutze allerdings auch nicht MQTT, da die Werte (zumindest damals) unzuverlässig übermittelt wurden. Ich frage den 3EM daher per HTTP ab, da bekomme ich seit jeher auch direkt den saldierten Wert.

1 „Gefällt mir“

@pepeboo der HM600 läuft problemlos mit 24V, zieht aber max. 10A, also limit auf 2x240W=480W. Da potentiell Dauerbetrieb ist das gut, dann wird er auch nicht zu warm. Das Einschaltstromproblem gibt es nur 1x, nämlich bei Montage. Für mich macht der ol.a. Aufbau wenig Sinn. Bei dem Aufwand hätte man gleich nen Victron multiplus nehmen können!

1 „Gefällt mir“

Ich mach das auch einfacher. Geladen wird mit 28V 15A max, das teil ist $40 bei ali. Stufen mach ich nicht, zu aufwendig. WR nehm ich entweder den regelbaren soyosource 24V oder den hoymiles 600 wenn ich mit dem opendtu zeugs zurechtkomme. Regeln und schalten soll das ein esp8266 auf einem relais-board. Der macht auch die shelly abfrage, batteriespannung messen und max werte dem soyosource oder dem hoymiles senden.

Der saldierte http wert ist in einem riesen-datensatz versteckt. Oder gibts da auch was kurzes? Ich frag die 3 einzelleistungen ab und summier das dann weil der esp8266 hat nicht viel ram und ich brauch das meiste zum datensätze abspeichern.

Nabend,

(hab über MyDealz hier zu dem Thread gefunden, natürlich die SuFu genutzt aber nix zum Thema gefunden.)

Hat mal jemand den Aufbau Hoymiles+OpenDTU mit einem SunnyHomeManger2 statt eines Shelly3EM als Nulleinspeisung realisiert? Hätte schon irgendwie Lust mir das mal nach zu basteln, aber iwie finde ich nichts zu dieser Konstellation.

Hallo zusammen,

ich bin zwar nicht neu hier im Forum und habe schon einiges realisiert. Jetzt geht das Projekt in die nächste Phase-> DIY Speicher 6kWh

und daraus eine Grundlasteinspeisung per HM-300, alles gesteuert von OpenDTU on batterry.

Hab mir schon diesen Thread durchgelesen und das meiste ist mir geläufig, einiges ist für mich Neuland.

Genauer werde ich mein Projekt vorstellen, wenn der theoetische Aufbau steht. Im Moment bin ich in der Erprobung, da einige Komponenten noch nicht final fest stehen.

Kurzum: Hardware ist mein Ding, da kann ich vielleicht auch einiges beitragen und helfen, mit Software stehe ich auf Kriegsfuß.

Dank der tollen Vorarbeit hier im Forum, vielen Dank dafür, hab ich schon einiges gechafft und es läuft seit über Oktober 2022 stabil.

Kurze Zusammenfassung:

Das ist vorhanden:

2,8kWp Dachanlge an Growatt MIC 3000, seit 1,5 Jahren angemeldet mit Einspeisevergütung usw

Raspi4 mit ioBroker, einige ESP8266 mit Tasmota drauf (Stromzähler per IR auslesen), Heizungssteuerung, Garagentor Steuerung und und und

Alles soweit im ioBroker integriert, der Wechselrichter, Stromzähler usw werden in eine DB geschrieben, per Grafana visualisiert usw...

Es war ein langer Kampf bis zu diesem Punkt. Wie gesagt Softwaare ist nicht meins, aber ich hab mich durchgekämpft. {green}:grinning:

Mein Vorhaben:

Aufgrund der Gegebenheiten AC Ladung des Speichers (24V, 230Ah), das Ladegerät ist noch nicht final festgelegt. Da bastele ich noch.

Aufgrund der im Überfluß vorhandenen PV-Leistung ist der Wirkungsgrat nicht unbedingt Prio 1 (Haushalt mit nur ca. 1000kWh/a Strombezug, fast 1800kWh eingespeist).

Ich möchte aber meinem Netzbetreiber nicht so viel Strom schenken, von den 1000kWh sind bei uns ca. 500kWh nur die Grundlast (ca. 60-100W).

Aufgrund von vielen und guten Erfahrungen wird es wohl ein Victron MPPT Laderegler an Meanwell Industrienetzteil. Diese Kombi biete sehr viele Vorteile und ziemlich

guten Wirkungsgrad sogar. Zu diesem Punkt später mehr. Einspeisung per HM-300, gesteuert soll das ganze werden per OpenDTU on battery.

Heute hab ich den ESP32 schon gesflasht und soweit eingerichtet, aber am ersten Punkt, den Stromzähler einbinden, scheitere ich schon.

Der Stromzähler wird wird wie gesagt per IR-Kopf an ESP8266 und Tasmota ausgelesen und per MQTT an ioBroker gesendet.

Als MQTT-Broker läuft der Sonoff Adapter, der hat einige Vorteile gegenüber dem MQTT-Adapter, z.b. wird der String vom Stromzähler direkt geparst usw...

Jetzt möchte ich den Stromzähler in penDTU unter Power Meter einbinden, egal was ich dort eintrage, ich scheitere kläglich.

Verbindung von OpenDTU zu Sonoff Adapter ist da, der sendet fleißig "alive" Pakete, diese werden auch empfangen.

Anbei 2 Screenhots vom Sonoff-Adapter mit den entsprechen Abschnitten des Stromzählers.

sonoff.0.MT175.MT175_Psonoff.0.MT175.MT175_Psonoff.0.MT175.MT175

Als "Adresse" oder wie auch immer das heißt für die Momentanleistung wird mir das angezeigt: sonoff.0.MT175.MT175_P

Was muß ich in OpenDTU eintagen, damit dem Gerät die Momentanleistung am Stromzähler bekannt ist?

Mein Dank im Voraus und ein schönes Wochenende

Gestern stand ich am Abgrund, heute bin ich einen Schritt weiter.

Mittlerweile weiß ich, dass es wohl besser ist den Zähler per HTTP + JSON abzufragen.

Nachdem ist diverse Dokus 2 Tage lang studiert habe, kann ich dne Zähler immer noch nicht abfragen.

Soweit bin ich schon:

Wieso schluckt er nicht den JSON Pfad: StatusSNS.MT175.P ??

Der Doku nach müsste es richtig sein. Aber egal was ich probiere, es kommt immer eine Fehlermeldung.

Frage ich Tasmota direkt über den Browser auf der Adresse http://192.168.199.130/cm?cmnd=status%208 ab, bekomme ich folgende Antwort:

Dem nach müsste der Pfad StatusSNS.MT175.P richtig sein.

Einer eine Idee?

ICh werde noch bekloppt hier, das ganze Wochenende versaut wegen so einer vermentlichen Kleinigkeit.

Grüße

@hoschiking Ist denn der Punkt das richtige Zeichen um im Pfad zu navigieren?
Ansonsten könntest Du auch noch probieren anstatt "status%208" "status 8" bei der URL einzugeben.

@hoschiking

Probier's mal mit / anstatt .

Bei mir funktioniert es wie folgt: http://192.168.170.25/cm?cmnd=Status%208

Im Browser :

Unter "OpenDTU-onBattery" -> Einstellungen -> Powermeter:

Und wie Du unter "Success" erkennen kannst, kommt der Leistungswert zurück.

Viel Erfolg!

Das war es! StatusSNS/MT175/P eingetippt und schon geht es.

Ich hätte schwören können, ich habe es mit / probiert, ohne Erfolg.

Nun läuft es. Was mich aber bei dem OpenDTU onBattery Projekt jetzt schon nervt, ist die teiilweise sehr mangelhafte Dokumentation.

Wenn man nicht täglich mit den Geräten spielt, ist man sehr oft bei einfachsten Dingen aufgeschmissen.

Beispiel:

Auf der Projektseite wird schön erklärt, wie das Funkmodul verdrahtet und konfiguriert wird, aber dass genau

das Portmapping in der Firmware garnicht existiert und jegliche angeschlossene Hardware nicht funktioniert, das wird nicht erklärt.

Dabei kann man in der Config sogar das Profil "Standard" auswählen, mit einer Warnung, dass wenn man was anderes wählt, die Hardware

nicht mehr funktionieren wird. Es funktioniert ohnehin nix. Also das geht besser.

Habe auch 2 Tage benötigt bis das Funkmodul lief.

Vielen Dank für euren Support

Bitte, gern geschehen

Euch vielen Dank für den Support, der erste Versuchsaufbau steht und funktioniert soweit.

Ganz kurz, was ich bisher realisiert habe:

2x 400W Module in Serie -> Victron MPPT 100/20 -> 8x CALB 230Ah (5,9kWh) -> Hoymiles HM-300

Die Komponenten per Funk und VE.Direkt an OpenDTU onBattery eingebunden.

JK-BMS kommt die Tage, wird dann per UART an OpenDTU angeschlossen,

Den Stromzähler lese ich per Optokopf am ESP8266-> Raspi4 mit ioBroker

Dazu 3x AC-Netzteil Meanwell 24W-150W in Reihe (72V 450W) -> Victron MPPT 100/20 -> Batterie

Der wird dazugeschaltet, wenn genug Leistung vom Dach kommt (2,8kWp an Growatt MIC-3000), gesteuert per Script im ioBroker.

Beide Victrons sind per VE.Smart Network synchronisiert, klappt wunderbar.

2 offen Fragen hab ich da noch:

Kann man an die OpdenDTU beide Victrons per VE-Direkt anschliessen? Falls ja wie? Wie ist es zu konfigurieren?

Ich hab gesehen, dass einige hier in diesem Thread auch mehrere Victrons in ihrem Setup verbaut haben.

Konfiguration des Dynamic Power Limiter:

Ich möchte, dass der HM-300 nur nachts einspeist, aber egal was ich einstelle, speist der immer ein, sobald ich Strom vom Netz beziehen muß.

Solar-Passtrough AN/AUS, Nur Nachts oder wenn Batterie voll ist egal. Er speist fleißig ein.

Ich wollte eigentlich verhindern, dass ich den HM-300 AC-seitig tagsüber vom Netz trennen muss und es OpenDTU machen lassen,

aber irgendwie scheint OpenDTU nach mir noch nicht bekannten Kriterien einzuspeisen.

Wie habt ihr es gelöst?

Vielen Dank und schönes Wochenende