Steuerungsprojekt für Growatt Noah 2000 und dynamischen Stromtarif Tibber

„Kommuniziert Growatt hier mit dem Shelly über die Cloud?“

Ich würde mal vorsichtig sagen: ja. Ich hatte vor ca. 1–2 Monaten zum Test diesen intelligenten Selbstverbraucher-Modus eingerichtet. Ich selbst hab zwar keinen Shelly im Zählerschrank, den ich hätte hinzufügen können aber Bekannte von mir haben einen. Für den Versuch hab ich dann beide Netzwerke (meins und ihres) per Layer-3-VPN verbunden.

In meinem Test hat der Noah aber zu keiner Zeit mit dem Shelly kommuniziert(er hat sich aber trotzdem an den Stromverbrauch meiner Bekannten angepasst , die Kommunikation mit der Shelly Cloud lief also). Der Shelly war allerdings auch nicht im selben Subnetz ,vielleicht hätte er ja doch kommuniziert, wenn beide im selben Netz gewesen wären.

„Und wie und wo speichern die die Werte?“

Ich würde vermuten, dass die entweder gar nicht gespeichert, sondern im RAM landen und dann direkt umgesetzt werden. Wenn die Verbindung zum Growatt-Server weg ist, fällt der Noah automatisch auf den Standardwert für die Ausgangsleistung zurück (diesen Wert setzt du auch mit deinem Tool). Auch nach einem Neustart springt er erstmal kurz auf diesen Standardwert.

„Alternativ könnte ich mich auch ins MQTT zwischen Noah und Cloud einklinken mit einem MQTT-Proxy.“

Genau das versuch ich grad. Es gibt auch schon ein Projekt für den Noah, mit dem man ihn teilweise lokal auslesen kann (Growatt verwendet da ihr eigenes Protokoll) . Der Noah sendet auch sehr zuverlässig alle 5 Sekunden Daten.
Die Weiterleitung zur Cloud läuft bei mir prinzipiell auch, die Befehle von der Cloud kommen auch beim Akku an. Trotzdem funktioniert das alles nur so halb. Der Akku ist zwischendurch immer wieder mal für 1–2 Minuten in der Cloud online und dann wieder weg.

„Da verursacht das Log vom Noah bestimmt viele Schreibzyklen, oder was denkst du?“

Was der Noah tatsächlich loggt und ob er das alles in den Flash schreibt, wissen wir nicht. Vielleicht loggt er auch nur Fehler? Oder er schickt die Logs direkt per MQTT an Growatt, ohne sie lokal zu speichern? Schwer zu sagen.

Danke für die Infos, ja ich denke hier wäre mal eine Antwort vom Support gut aber bei Growatt ist der Support aktuell beim Party machen mit der Serverinfrastruktur.
Hab in anderen Beiträgen gelesen, das es da zu wilden Orgien kommen soll bei denen aktuell in der Technik.
Auf eine Antwort auf meine Fragen warte ich jetzt seit 6 Wochen.

Ohne genaue Infos ist das wie Kaffesatz lesen. Aber da die API auf 5 Sek. Interwall ausgelegt ist für das setzten den PowerValue denke ich auch das das nicht im Flash landet. Wobei man nie sicher sein kann.

Ich habe mal ausgerechnet wie viele Schreibzyklen in denn 6000 Zyklen des Akkus da ungefähr zusammen kommen und das solle der Flash locker aushalten.

Für mich läuft meine Lösung erst mal, die Nulleinspeise Logik ist ja auch nur ein kleiner Teil.

Hast du mir einen Link zu den anderen Projekten. Das mit dem ESP kenne ich schon und das in GitHub für HomeAssistent die nutzen ja aber auch die API.

Das lokale auslesen wäre super vor allem alle 5 Sekunden Daten wäre nice.

Ich hab denke ich was die Kommunikation angeht, alle Kinderkrankheiten jetzt aus meinem Code raus. Mache jetzt als nächstes den fein Schlief.

Mir geht es hauptsächlich wie bei HomeAssistent um die Programme was wann eingestellt werden soll Aufrund der Tibber Preis Struktur.

Das macht dann schon das meiste an Ersparnis aus die Null Einspeisung zur PrimeTime ist für mich nicht das wichtigste zumal ja eh nur 800W eingespeist werden können.

In was hast du deine Lösung programmiert ?

"Danke für die Infos, ja ich denke hier wäre mal eine Antwort vom Support gut aber bei Growatt ist der Support aktuell beim Party machen mit der Serverinfrastruktur.
Hab in anderen Beiträgen gelesen, das es da zu wilden Orgien kommen soll bei denen aktuell in der Technik."

Tatsächlich lief bei mir bis vor drei Tagen (seitdem lasse ich den Noah auf meinen eigenen MQTT-Server schicken) alles problemlos – obwohl laut anderen Nutzern die Aussetzer da schon richtig übel waren.
Der Akku war bei mir eigentlich immer online (außer nachts, wenn er seine Mindestgrenze erreicht hat) und auch die Growatt-API hat zuverlässig Daten geliefert.
Ich werde ihn am Samstag auch wieder direkt an den Growatt MQTT Server anbinden, um zu gucken, ob es meine aktuelle Probleme an meiner Weiterleitung liegt oder an Growatt.

"Hast du mir einen Link zu den anderen Projekten. Das mit dem ESP kenne ich schon und das in GitHub für HomeAssistent die nutzen ja aber auch die API."'

Welches Projekt mit dem ESp meinst du? OpenDTU?
Dass Projekt mit dem Noah aktuell schon teilweise lokal auslesen kann ist hier.

"Ohne genaue Infos ist das wie Kaffesatz lesen. Aber da die API auf 5 Sek. Interwall ausgelegt ist für das setzten den PowerValue denke ich auch das das nicht im Flash landet. Wobei man nie sicher sein kann."

Meinst du jetzt die API die für uns zugänglich ist oder die die Growatt vermutlich für den Intiligenten Selbstverbrauchermodus nutzt?
Wie kommst du auf die 5 Sekunden?

"Mir geht es hauptsächlich wie bei HomeAssistent um die Programme was wann eingestellt werden soll Aufrund der Tibber Preis Struktur."

Wir haben beide tatsächlich unterscheidliche Ziele. Ich möchte eine Einspeisung um jeden Preis vermeiden(da ich keine Einspeisevergütung zurückbekomme) und mit dem Akku möglichst immer den vollen Stromverbrauch des Hauses abdecken, da ich auch keinen dynamischen Stromtarif habe.

"In was hast du deine Lösung programmiert ?"

Programiert habe ich sie nicht. Ich habe sie nur in HomeAssistant konfiguriert. Es Ist eine relativ einfach Regelung die dauerhaft prüft ob >60 Watt aus dem Netzt kommen oder 15 Watt ins Netzt gehen.
Tagsüber steuere ich dass ganze auch über die growatt API und nachts über meinen Hoymiles WR ( der kann einfach viel schneller Regeln als der Akku + ich belaste den Flash Speicher des Noah nicht, da der WR mir die Möglichkleit bietet die Werte in den Ram zu schreiben).

Ingesamt gesehen habe am Tag ca 70 -100 Akkuanpassungen und 300 - 400 Wechselrichter anpassungen ( wenn ich über den WR steuere reagiere ich aber auch schon bei >15 Watt vom Netzt und < 1 Watt ins Netz).

Meinst du jetzt die API die für uns zugänglich ist oder die die Growatt vermutlich für den Intiligenten Selbstverbrauchermodus nutzt?
Wie kommst du auf die 5 Sekunden?

Na in der Dokumentation der Api von Growatt, wenn mann das Dokumentation nennen will, stehen seit neustem die Intervalle.
Für SetPower 5 Sekunden

"Mir geht es hauptsächlich wie bei HomeAssistent um die Programme was wann eingestellt werden soll Aufrund der Tibber Preis Struktur."

Wir haben beide tatsächlich unterscheidliche Ziele. Ich möchte eine Einspeisung um jeden Preis vermeiden(da ich keine Einspeisevergütung zurückbekomme) und mit dem Akku möglichst immer den vollen Stromverbrauch des Hauses abdecken, da ich auch keinen dynamischen Stromtarif habe.

"In was hast du deine Lösung programmiert ?"

Programiert habe ich sie nicht. Ich habe sie nur in HomeAssistant konfiguriert. Es Ist eine relativ einfach Regelung die dauerhaft prüft ob >60 Watt aus dem Netzt kommen oder 15 Watt ins Netzt gehen.
Tagsüber steuere ich dass ganze auch über die growatt API und nachts über meinen Hoymiles WR ( der kann einfach viel schneller Regeln als der Akku + ich belaste den Flash Speicher des Noah nicht, da der WR mir die Möglichkleit bietet die Werte in den Ram zu schreiben).

Ingesamt gesehen habe am Tag ca 70 -100 Akkuanpassungen und 300 - 400 Wechselrichter anpassungen ( wenn ich über den WR steuere reagiere ich aber auch schon bei >15 Watt vom Netzt und < 1 Watt ins Netz).

Ja definitiv haben wir andere Ziele ich will die Kosten nur minimieren da ich keinen Smartmeter verbauen will.

Neues Logging der Requested und Commited Werte.

Echtzeit Variablen

Neue Tibber Preisübersicht mit Level

Aktuell verwende ich Claculation1 und Adjustment3.

Bei Adjustment 3 habe ich jetzt eine schneller Reaktinszeit und ein Loadbalancing eingebaut.

1 „Gefällt mir“

Entscheidungslogik von TibberRTMAdjustment3

Prüfreihenfolge (von höchster zu niedrigster Priorität)

  1. Automodus-Prüfung

    • Wenn ApiSettingAutoMode = true: Rufe TibberRTMAdjustment3AutoMode(value) auf und beende.
    • Sonst: Fahre mit Schritt 2 fort.
  2. Inaktivitätsprüfung

    • Wenn kein PV-Strom verfügbar UND alle Batterien leer: Keine Aktion, beende.
    • Sonst: Fahre mit Schritt 3 fort.
  3. Betriebsmodus-Ermittlung

    • Wenn ApiSettingExtentionMode = true UND Uhrzeit außerhalb 07:00-18:00 Uhr:
      → ExtensionMode aktiv (Schritt 4)
    • Sonst: Normaler Modus aktiv (Schritt 5)
  4. ExtensionMode-Entscheidungen

    • Strompreisabhängige Prüfung (höchste Priorität):
      • Wenn IsCheapRestrictionMode: Batterie laden
      • Wenn IsExpensiveRestrictionMode: Energiesparmodus aktivieren
    • Wenn keine Preisrestriktion aktiv → Batteriekapazitätsabhängige Prüfung:
      • Hoher Akkustand (>50%): Maximal-Lastbetrieb
      • Mittlerer Akkustand (20-50%): Energiesparmodus
      • Niedriger Akkustand (<20%): Durchschnittslastbetrieb
    • Nach jeder Aktion: Methode beenden.
  5. Normaler Modus-Entscheidungen

    • Preisabhängige Prüfung (höchste Priorität):

      • Wenn IsExpensiveRestrictionMode: Energiesparmodus aktivieren (AutoMode)
      • Aktion: TibberRTMAdjustment3AutoMode(value)
    • Akkuerhaltung bei vollem Akku (zweithöchste Priorität):

      • Wenn CurrentState.IsGrowattBatteryFull: Akku-Ladezustand erhalten
        • Bei hoher Solarleistung: Maximaler Verbrauch für optimale Nutzung
          • Bedingung: effectiveSolarPower > ApiSettingMaxPower * 0.75
          • Aktion: TibberRTMDefaultLoadPriorityMaxAsync(value, GrowattGetDeviceNoahSnList())
        • Standardfall: Nur Überschuss einspeisen
          • Aktion: TibberRTMDefaultBatteryPriorityAsync(value)
    • Standard-Situationen am Tag bei nicht vollem Akku basierend auf Fakten:

      1. Wenn Akku leer ist:

        • Bedingung: Sonder Konstellationen
          • Akkustand leer + normale Preise: !CurrentState.IsBelowAvgPrice && CurrentState.IsBatteryEmpty
        • Aktion: TibberRTMDefaultLoadPriorityAvgAsync(value)
        • Beschreibung: Es wird nur die Grundlast eingespeist um keinen Akkustrom zu verschwenden.
      2. Wenn Akku geladen werden soll (mehrere Bedingungen möglich):

        • Bedingungen: Einer der folgenden Fälle muss zutreffen:
          • Schlechte Wetterprognose (wenig Sonne erwartet): CurrentState.IsCloudy && GetExpectedSolarProductionForNextHours(6) < ApiSettingAvgPower * 2
          • Akkustand niedrig + günstige Preise: GetBatteryLevel() < 30 && CurrentState.IsBelowAvgPrice
          • Akkustand niedrig + schlechte Wetterprognose: GetBatteryLevel() < 80 && (CurrentState.IsCloudy || GetExpectedSolarProductionForNextHours(4) < ApiSettingAvgPower * 2)
          • Akkustand < 80% mit guter Wetterprognose: GetBatteryLevel() < 80 && !CurrentState.IsCloudy
        • Aktion: TibberRTMDefaultBatteryPriorityAsync(value)
        • Beschreibung: Batterie wird priorisiert geladen.
      3. Wenn direkte Solarstromnutzung optimal ist:

        • Bedingung: Nicht billig !IsCheapMode, nur solarstrom verwenden keine batterie
        • Aktion: TibberRTMDefaultLoadPrioritySolarInputAsync(value)
        • Beschreibung: Last priorisiert, um die Solarenergie direkt zu nutzen.
      4. Wenn sonst keine Bedinung greift:

        • Aktion: TibberRTMAdjustment3AutoMode(value)
        • Beschreibung: Optimale Verteilung basierend auf aktuellen Messwerten.

Reserveberechnung basierend auf einem Reorg-Lauf

  • Beschreibung: Die Reserve wird dynamisch auf Grundlage eines Reorg-Laufs berechnet, um die Akkukapazität optimal an die zukünftigen Anforderungen anzupassen.
  • Aktion: Rufe CalculateReserveBasedOnReorg() auf, um die Reserve zu berechnen und anzupassen.
  • Details:
    • Der Reorg-Lauf analysiert historische Daten und zukünftige Anforderungen.
    • Die berechnete Reserve überschreibt ApiSettingExtentionReserveThreshold und ApiSettingExtentionMinimalReserve, falls erforderlich.

Zusätzliche Parameter für den ExtensionMode

  1. ApiSettingExtentionMode

    • Typ: bool
    • Standardwert: true
    • Beschreibung: Aktiviert oder deaktiviert den ExtensionMode. Wenn true, wird der ExtensionMode verwendet.
  2. ApiSettingExtentionExclusionFrom

    • Typ: TimeSpan
    • Standardwert: new TimeSpan(7, 0, 0) (07:00 Uhr)
    • Beschreibung: Gibt die Startzeit des Ausschlusszeitraums an, in dem der ExtensionMode nicht aktiv ist.
  3. ApiSettingExtentionExclusionUntil

    • Typ: TimeSpan
    • Standardwert: new TimeSpan(18, 0, 0) (18:00 Uhr)
    • Beschreibung: Gibt die Endzeit des Ausschlusszeitraums an, in dem der ExtensionMode nicht aktiv ist.
  4. ApiSettingExtentionAvgPower

    • Typ: int
    • Standardwert: 300
    • Beschreibung: Gibt die Menge an Strom (in Watt) an, die im ExtensionMode vom Extension-Akku eingespeist wird.
  5. ApiSettingExtentionReserveThreshold

    • Typ: int
    • Standardwert: 50 (%)
    • Beschreibung: Schwellenwert der Akkukapazität in Prozent, ab dem eine Reserve für teure Preiszeiten eingehalten werden soll.
  6. ApiSettingExtentionMinimalReserve

    • Typ: int
    • Standardwert: 20 (%)
    • Beschreibung: Minimale Akkukapazität in Prozent, die als absolute Reserve beibehalten werden soll.

Zusammenfassung der Hauptfaktoren

  1. Zeit (ExtensionMode oder Normaler Modus):

    • ExtensionMode: Aktiv, wenn ApiSettingExtentionMode == true und die aktuelle Zeit außerhalb des Ausschlusszeitraums liegt.
    • Normaler Modus: Aktiv, wenn der ExtensionMode nicht aktiv ist.
  2. Solarleistung (hoch, mittel, niedrig):

    • Hohe Solarleistung: Priorisiere Batterieladung.
    • Mittlere Solarleistung: Abhängig vom Akkustand.
    • Niedrige Solarleistung: Abhängig von Akkustand und Strompreisen.
  3. Akkustand (voll, leer, teilweise geladen):

    • Voll: Fokus auf Lastpriorisierung.
    • Leer: Fokus auf Batterieladung oder Lastreduktion.
  4. Strompreise (günstig, teuer):

    • Günstig: Priorisiere Batterieladung.
    • Teuer: Aktiviere Energiesparmodus.

Weatherforecast jetzt mit BatteryChargingWindow

So Mqtt ist jetzt auch implementiert.

Man kann jetzt ggf. auch Ohne die Growatt Cloud steuern.

Wahnsinn. Ich werde das nächstes Wochenende gleich ausprobieren. Hast du auch irgendwo deinen HA script/Automation?

Nein für HomeAssistent gibt es das GroBro Projekt auf Github.

Meine Lösung ist StandAlone aktuell nur Growatt und Tibber.

Hey OnkelAlex,
mal ne ganz blöde Frage.. Wie bekomme ich das installiert / zum Laufen?
z.B. auf nem Pi. ?

Hi, ich habe auch schon versucht den Noah so in HA zu bekommen. Leider ohne Erfolg :frowning:

Kannst du mir helfen das einmal einzurichten?

Vielen Dank!

Gruß,

Ja du kannst es mit einem Docker Image ganz einfach auf dem Raspberry Pi laufen lassen oder auch Native mit .net und python.

Ich auf Dockerhub auch ein Image aber noch nicht veröffentlicht.
Meldet euch wenn Ich das veröffentlichen soll.

Was hast du denn für eine Umgebung ?

HomeAssistant auf einem Rasperry Pi