UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Schimi]

@mabbi ich sehe die in der App...

ich erlaube meinem den zugangs ins netz und durch das eingebaute Mqtt, kann man gleichzeitig die cloud Verbindung nutzen

[Mabbi]

@schimi

Ah ok, da bin ich auf der neusten Version, letztes Update kam vor ca. 2 Wochen.
Hat Dein AC2400 irgendwo einen Hinweis auf die Hardwarerevision ?
Meine sind vom Juni und von Oktober, nicht das sich da was geändert hat, weil die evtl. neuer sind als Deiner ?

Btw...für alle Interessierten, Zendure verkauft den AC2400 plus 1x AB3000X (2.88 KWh) aktuell für 3 stellig.
Ich war kurz geneigt den 3. zu kaufen, was ich eigentlich erst in 2026 machen wollte.

[Schimi]

@mabbi nicht das ich wüsste...Falls ich dazu komme, schaue ich mal am we ob ich was am Gerät, direkt finde...

hmmmmm

[Mabbi]

Die Dämpfung, die ich eingebaut habe (fast ein Integral :) ) führt im Wechselbetrieb der beiden AC2400 zu einem pumpen, und das nur bei der Enspeisung. Wenn ich die AC2400 synchron laufen lasse, dann ist es weg ... ?

Das wechselseitig ansteuern der AC2400 ist komplexer als ich dachte, vor allem in dem dynamischen Bereich, wenn es gerade um die PV-Ertragsschwelle wo das Haus versorgt ist zwischen Laden und Entladen schwankt.
Dafür war eigentlich die Dämpfung drin.... am WE nochmal an die Tastatur :)

Nicht das ich schon 3 Loadbalancing/Dämpfungs-Funktionen in den letzten Wochen durch hätte...

Nach dem check der Daten von heute habe ich die Nachts-Nicht-Laden Logik erweitert:

Wenn der durchschnittliche PV-Ertrag der letzten 5 Minuten unter 250 W fällt wird Akku-Laden nun auch verhindert.
Diese Abfrage versetzt beide Akkus strikt in den output-Modus(Entladen) solange mindestens eines der beiden Argumente erfüllt ist.

[Schimi]

@mabbi mal ne schnelle Überlegung am Handy...

was ist, wenn du den wert nimmst und durch 2 teilst und jeweils an die beiden 2400AC schickst....

theoretisch sollten die sich gleich ent bzw. beladen

[Mabbi]

@schimi

genau das mache ich auch.
Aber wenn die Akkus nicht synchron sondern im Wechsel angesteuert werden, fängt der 'Regelkreis' manchmal an zu pumpen (nur bei Einspeisung), und das obwohl ich sowohl die Gesamtleistung plus/minus der Akkus heranziehe und auch die Einzelleistung pro Akku vergleiche und Loadbalancing zwischen den beiden mache, und das optional mit IST-Werten oder einem Delta über den Regelzeitraum der Akkus.

Die Problematik ist wohl, dass bei niedrigem PV-Ertrag, wo die Akkus theoretisch zwischen Laden und Entladen schalten würden, je nachdem welcher Verbraucher sich gerade zu oder abschaltet, die ganze Regellung in eine Schwingung versetzt wird, aus der Sie nicht mehr rauskommt.
Rein technisch habe ich die Regelung in .net mit simulierten Daten laufen lassen (ist halt viel einfacher zu debuggen), da bekomme ich ein relativ sauberes Verhalten, Schwingungen werden im Load-Balancing wieder eingefangen.
Aber ich habe hier gerade einen klassischen 'Theorie und Realität' Fall.
Im Augenblick habe ich die Trägheit der Steuerung im Verdacht, ich regel ja nur alle 15 Sekunden und genau an der PV-Ertrags Grenze können in dem Zeitraum auch in den Delta/Zeit Werten schon wilde Sachen passieren.
Ich will das aber nicht mit einer übermässig grossen Totzone erschlagen.

Wenn ich mit exakt der gleichen Steuerung auf die abwechselnde Ansterung der Akkus verzichte

ist alle scool und ich kann ohne Totzone sauber regeln.

Ich werde mal alle relevanten Regel-Daten in Datenpunkte schreiben, die Historie aktivieren und mir das dann per Diagramm anschauen... im zeilenweisen Textdebugging komme ich hier aktuell nicht mehr wirklich weiter.

[Schimi]

@mabbi was wäre wenn du entweder das regeln erst bei z.B. +-50 watt unterschied zum vorherigen wert erlaubst...

oder im bereich bis -+200 Watt nur kleine sprünge erlaubst (z.B. 20 Watt)... würe die Regelung in dem Bereich langsam machen....

hmm, sonst habe ich keine idee gerade..

[lesiflo]

Hallo @Mabbi
ich habe hier mal mitgelesen und einen ähnlichen Aufbau, allerdings mit 2 Hyper und habe das mit Java-Script gelöst.
Die Akkus werden bei mir über die angeschlossenen PV-Panels und externer PV geladen. Ich steuere beide Hyper zusammen. Hier mal ein Auszug wie ich die Leistung ermittle. Bin aber in der Cloud.

const hyper1 = {
    name:           'Hyper1',
    inputLimitDP:   'zendure-solarflow.0.xxxxxx.yyyyyyyy.control.setInputLimit',
    outputLimitDP:  'zendure-solarflow.0.xxxxxx.yyyyyyyy.control.setOutputLimit',
    inputDP:        'zendure-solarflow.0.xxxxxx.yyyyyyyy.gridInputPower',
    outputDP:       'zendure-solarflow.0.xxxxxx.yyyyyyyy.outputHomePower',
    acModeDP:       'zendure-solarflow.0.xxxxxx.yyyyyyyy.control.acMode',
    pvLeistungDP:   'zendure-solarflow.0.xxxxxx.yyyyyyyy.solarInputPower',
    chargePowerDP:  'zendure-solarflow.0.xxxxxx.yyyyyyyy.outputPackPower',
    socDP:          'zendure-solarflow.0.xxxxxx.yyyyyyyy.electricLevel',
    setsocDP:       'zendure-solarflow.0.xxxxxx.yyyyyyyy.control.dischargeLimit',
    ladenGesamtDP:  'zendure-solarflow.0.xxxxxx.yyyyyyyy.calculations.outputPackEnergyTodaykWh',
};

const hyper2 = {
    name:           'Hyper2',
    inputLimitDP:   'zendure-solarflow.0.xxxxxx.zzzzzzzz.control.setInputLimit',
    outputLimitDP:  'zendure-solarflow.0.xxxxxx.zzzzzzzz.control.setOutputLimit',
    inputDP:        'zendure-solarflow.0.xxxxxx.zzzzzzzz.gridInputPower',
    outputDP:       'zendure-solarflow.0.xxxxxx.zzzzzzzz.outputHomePower',
    acModeDP:       'zendure-solarflow.0.xxxxxx.zzzzzzzz.control.acMode',
    pvLeistungDP:   'zendure-solarflow.0.xxxxxx.zzzzzzzz.solarInputPower',
    chargePowerDP:  'zendure-solarflow.0.xxxxxx.zzzzzzzz.outputPackPower',
    socDP:          'zendure-solarflow.0.xxxxxx.zzzzzzzz.electricLevel',
    setsocDP:       'zendure-solarflow.0.xxxxxx.zzzzzzzz.control.dischargeLimit',
    ladenGesamtDP:  'zendure-solarflow.0.xxxxxx.zzzzzzzz.calculations.outputPackEnergyTodaykWh',
};

const evuLeistungDP         = 'mqtt.0.openWB.evu.W';
const aktuelleEinspeisung   = Number(getStateVal(evuLeistungDP, 0));

const hyper1Leistung = Number(getStateVal(hyper1.inputDP, 0)) - Number(getStateVal(hyper1.outputDP, 0));
const hyper2Leistung = Number(getStateVal(hyper2.inputDP, 0)) - Number(getStateVal(hyper2.outputDP, 0));

const leistungAusAkkus = aktuelleEinspeisung - hyper1Leistung - hyper2Leistung; // wie im Original

// PV-Überschuss-Erkennung: negative leistungAusAkkus = Überschuss? (behalte dein Vorzeichenmodell)
if (leistungAusAkkus < -ladenStartSchwelle && speicherMinSOC < zielSOC) {
     ladenErlaubt = true;                
     visLog('☀️ PV-Überschuss → Laden erlaubt', 'ok');
}

Kann gerne mal das gesamte Script posten, ist aber sehr an meine Bedingungen angepasst.

[Unterums]

Hallo,
ich suche jemanden der mir (auch gerne gegen Bezahlung) hilft,

einen Flow einzurichten in IO-Broker. Habe die Zendure Batterie mittels MQTT zum Luafen gebracht und würde nun gerne folgende Werte schreiben können:
1.) Laden über AC Ein / Aus
2.) Entladen über AC Ein / Aus
3.) Die Leistung für 1 oder 2

Ist hier jemand der Lust darauf hat ?

[Schimi]

@unterums wenn ich aus das richtig verstehe, macht mein Javascript genau das... Du musst nur Tibber und evcc auf "false" setzen und deinen Stromzähler angeben (z.B. shelly oder Tibber Pulse.. es gehen auch alle anderen die ein + für bezug und - für einspeisung liefern)

[Uberga]

@schimi Danke, aber wo "baue" ich das Java Script ein ?
Sorry, aber ich bin da absolut unbewandert :-)

[Mabbi]

@uberga

Hi,
das script von @Schimi kommt im Iobroker hier hin, einfach anclicken:

Dann clickst du hier auf das PLUS:

Wählst das hier aus:

Vergibst einen Namen (Verzeichnis würde ich erstmal nicht ändern):

Und fügst den kopierten Text aus dem ersten Post in den Editor ein, dann SPEICHERN

Sollte dann so aussehen (Name kann abweichen)

Mit dem Play/Pause startet das script bzw stoppt.

ABER.... ich würde Dir nicht empfehlen als Anfänger gleich mit Javascripten zu arbeiten.
Ehrlich, schreib ein paar kleine Blocklys, verstehe wie Datenpunkte angelegt, angesprochen und manipuliert werden und dann kannst du auch Deinen Akku selber steuern mit einem kleinen script und Erfahrung.
Die Akkus sind keine Spielzeuge. Du solltest wirklich verstehen wie du die scripte überwachst und dann reagierst.

Schau mal, ich arbeite seit Wochen an einem Akku-Script... es gibt idz. X-Versionen und ganz glücklich bin ich aktuell immer noch nicht mit dem Ergebnis (wobei das nun eher Schönbauerei ist als reale technische Verbesserung idZ.)

[Schimi]

es kann definitiv nicht schaden sich mal mit blockly auseinander zu setzen...

Mein Skript braucht zwar nur konfiguriert werden und sollte funktionieren... aber ein grundverständnis schadet nie :-)

PS: es gab wieder ein Update (siehe ersten post)

[lesiflo]

Hi, noch ein Tip von mir:
Du solltest, falls du den Wert hast, deinen Rest-Tagesverbrauch in kW/h welcher durch PV gedeckt wird, noch von deinem Tages Rest-PV abziehen. Dann bekommst du einen noch besseren Restwert zum Laden deiner Akkus. Ich verwendet zusätzlich noch den Genauigkeitsfaktor aus PV-Prognose und tatsächlicher PV Energie, den ich dann mit in die Berechnung der restliche PV Leistung mit einfließen lasse. Wenn dann PV nicht reicht wird über Tibber geladen (aber nur falls das wirtschaftlich Sinn macht)

So z.B.: pvRest_Real = (pvRest - verbrauchRest) * Faktor

Gerade was die teilweise sehr ungenaue PV-Prognose angeht solltest du den Genauigkeitsfaktor mit einbauen. Hier mal ein Beispiel von heute wie ungenau die Vorhersage ist. War aber auch nur sehr wenig Sonne.

Ich nutze übrigens für die PV-Vorhersage solarprognose.de. Der errechnet die Genauigkeit gleich mit. Gibt auch einen Adapter dafür.

[Schimi]

Danke für den Tipp... mit der Genauigkeit habe ich auch so "meine probleme"...

das mit dem Resttagesverbrauch ist aber schwer vorauszusehen...

aber ich mach mir da nochmal gedanken... das mit dem Genauigkeitsfaktor ist definitiv ein guter Tipp

[lesiflo]

Ich speichere mir den Tagesverbrauch in einer influxDB ab. Daraus errechne ich mir den durchschnittlichen Restverbrauch bis Sonnenuntergang der letzten 5 Tage und ziehe diesen dann von der Rest PV-Leistung ab. Mit Hilfe von ChatGPT war das relativ einfach umzusetzen.

[Schimi]

update auf 2.8

@lesiflo habe da mal was (auf deinen Hinweis hin) mit de Prognose umgestrickt...

Leider ist zur Zeit ja nicht soviel "PV", deshalb dauern die feldtests was länger...
Das mit dem Tagesverbrauche schaue ich mir noch an.... das will ich aber ne Zeitlang testen...

[Mabbi]

Ich denke der Ertrag und somit die Gnauigkeit variieren stark.
Unterm Strich kann man die Werte von solarprognose schon gut nehmen, ich teste aber seit einiger Zeit daran, wie umstehende Objekte wie Bäume etc. Einfluss auf die real produzierte Leistung haben.
Ist deutlich kniffeliger als ich dachte, bei Bewölkung sind die Bäume in der Auswirkung eher geringer im Effekt als bei klarem Himmel.
Mit fehlen im Augenblick noch Testdaten für einen groben Überblick.
Da sich die Verschattung ja auch noch im Jahresverlauf deutlich ändert ist das sehr schwer zu interpolieren.
Einen festen Faktor je Tagestunde zu finden ist nicht der richtige Weg, eher anhand von Sonnen-Auf- und Untergang eine mögliche Ertragskurve für die eigene Anlage zu generieren, stundeweise aufzusplitten und in die Solarprognose einzurechnen.

Bevor es verwirrend wird... insgesamt ein spannendes Thema.

[Schimi]

ich bin gerade komplett im flow und habe jetzt eine Prognose auf basis der letzten 14 tage (taggenau)... wonach entschieden wird ob aus dem netz geladen wird oder nicht....

Um das aber nun zu testen, muss ich erstmal daten sammeln ;-)
also denke ich, nen update wird nicht vor Weihnachten kommen.... (aktuell Version 2.22)

Ich habe langsam die "angst" das es zuviel ist.... als Backup habe ich ja das Script vor der PV-Prognose... damit war ich eigentlich schon sehr zufrieden

[lesiflo]

Der solarprognose Adapter rechnet falsch wenn der aktuelle Wert größer ist als die Prognose.