Weihnachtsangebot 2025! 🎄

[StrathCole]

@Diginix MinSoC wäre mir nicht wichtig. SoC ist gut.

[Diginix]

@StrathCole minSOC hab ich ja auch nicht aktiv, da gäbe es nur den Dummy.

Hier die letzten 2 Tage, noch ohne intelligente Bat Steuerung.

Die Ladeleistung ist jetzt nicht mehr invertiert und beginnt bei 0W, alles darüber erhöht den SOC. Wie man ja auch gut sehen kann.

[StrathCole]

@Diginix Das festigt zumindest die Vermutung, dass es an der Abregelung liegt, weil die Batterie dann schon voll ist.

[Diginix]

@StrathCole Ok, heute habe ich mal meine Heizpatrone (1,5 kW) vom Warmwasser recht früh hinzugeschaltet damit der Akku langsamer gelanden wird. Das hat das ganze aber auch nur minimal beeinflusst weil einfach zu viel Ertrag vorhanden ist. Zum Glück.

Bisher habe ich die Zuschaltung der Heizpatrone anhand der Ladeleistung bzw der Einspeisung gemacht.
Mit deinem Adapter habe ich ja nun Prognosewerte in kWh für den gesamten Tag. Weiß also ob noch genug Wh zustande kommen.
An welche Objekte hänge ich mich denn am besten mit meiner Logik um einen zusätzlichen Verbraucher zu schalten?

Der hier sagt ja was kommen müsste:
plenticore.0.forecast.day1.power.day
Und die zwei was vermutlich gebraucht wird:
plenticore.0.forecast.consumption.day
plenticore.0.forecast.consumption.night
Darin enthalten ist natürlich der zusätzliche Verbraucher wenn er in den vergangenen Tagen auch eingeschaltet war

Oder reicht nur dieses:
plenticore.0.forecast.day1.power.remaining

Und wie kann ich sicherstellen dass der 6400Wh Akku bei Sonnenuntergang voll ist?

Richtig cool wäre wohl ein boolesches Objekt welches dein Adapter schaltet wenn zusätzliche Last geschaltet werden kann. Dessen Leistung müsste man dann in der Instanz Config hinterlegen.
Aber ich kann das in einem Skript auch selbst bauen, brauche nur mal einen Logikanstoß.

[StrathCole]

@Diginix Also wichtig sind eigentlich nur plenticore.0.forecast.day1.power.remaining und plenticore.0.forecast.consumption.day in diesem Fall.

Mach dir ein Javascript, das beispielsweise auf die plenticore.0.forecast.day1.power.remaining lauscht, dann berechnest du mit dem Astrodate einfach die schon vergangenen Stunden seit Sonnenaufgang und berechnest dir damit dann den voraussichtlichen Restverbrauch des Tages. Mit dem Wert und dem remaining Wert hast du dann in etwa den Überschuss, der zu erwarten ist. Ich nehme den dann x 0.5 zur Sicherheit und schalte zusätzliche Verbraucher (in dem Fall Warmwasser oder Vorlauftemperatur), wenn das Ergebnis immer noch deutlich über der notwendigen Restladung (bis 100%) für die Batterie ist.

[Diginix]

Ich habe mal ein Diagramm des letzten Monats erstellt mit einem Wert pro Tag für den erzielten Ertrag und der Prognose von 0 Uhr für diesen Tag.

Prinzipiell muss man also @StrathCole attestieren dass die Formel mit den Wetterdaten echt brauchbar ist. Zumindest wird an schlechte Tagen die Prognosse von 0 Uhr i.d.R. real übertroffen. Und an guten Tagen ausreichend erreicht, so dass durch auf Grund der Prognose zusätzlich eingeschaltete Lasten kein Nachteil entsteht.
Die Ausreißer vom 29.03. und 03.04. zw. modbus und plenticore dürften an der Batterie liegen, die vom Vortag dann nach Leistung abgab, die in den modbus Wert eingerechnet wurde.

@StrathCole Die intelligente Batteriesteuerung vom Adapter kann ich bei meiner Anlage nicht nutzen.
Die letzten zwei Tage hat sie gegriffen und die Batterie wurde erst verzögert geladen. Mein SOC zum Tagesstart ist aber bei 5%. Und der erste Ertrag ab Sonnenaufgang wurde verbraucht bzw. eingespeist. Problem sind dann Lastspitzen beim Frühstück usw. die dann durch Netzbezug kompensiert wurden weil ja noch nichts in der Batterie gelandet war. Wäre es aber wenn es nicht durch die intell. Steuerung nur eingespeist worden wäre. Evtl. bräuchte ich da noch eine Art Offset mit Uhrzeit. So dass die intelligente Steuerung vor Sonnenaufgang ausgeschaltet wird wenn der SOC <10% ist und dann erst ab einer bestimmten Uhrzeit >10:00 wieder aktiviert wird. Dann würde die Batterie anteilig vorgeladen um Frühstücks Lastspitze zu kompensieren. Danach würde die Batterie aber nicht direkt mit hohem Ladestrom voll geladen.

[Bostil]

Hallo zusammen,

bin immernoch unschlüssig, ob ich in einen KSEM (Smart Energy Meter) für meine neue PV-Anlage (wird in Q3 installiert) investieren soll. Könnte jemand so lieb sein und mal die Datenpunkte, die vom Adapter aus dem Wechselrichter bereitgestellt werden, hier als Screenshot teilen ?

Ich verstehe immernoch nicht, was hinsichtlich Monitoring der KSEM mehr kann und ob die ~ 300 €, die der Installateur dafür berechnet, gerechtfertigt sind.

Danke euch!

[tp1de]

@Bostil sagte in IOBroker Anbindung an einen Kostal Plenticore:

bin immernoch unschlüssig, ob ich in einen KSEM (Smart Energy Meter) für meine neue PV-Anlage (wird in Q3 installiert) investieren soll.

Ohne KSEM kennt der Wechselrichter den Hausverbrauch nicht. D.h. es funktioniert keine dynamische 70% Abregelung und es gibt keine Statistiken zum Hausverbrauch, Eigenverbrauchsquote, Einspeisung etc.

KSEM ist für mich ein Muss !!!

[StrathCole]

@Diginix sagte in IOBroker Anbindung an einen Kostal Plenticore:

Mein SOC zum Tagesstart ist aber bei 5%. Und der erste Ertrag ab Sonnenaufgang wurde verbraucht bzw. eingespeist. Problem sind dann Lastspitzen beim Frühstück usw. die dann durch Netzbezug kompensiert wurden weil ja noch nichts in der Batterie gelandet war.

Ja, korrekt. Da baue ich noch etwas ein, dass man die "Automatik" erst aktivieren kann, wenn mind X% über dem MinSoC geladen sind.

[StrathCole]

@Diginix So, die Einstellung ist jetzt da und steht nach dem Update per Default auf 10%.

[amg_666]

@Diginix Hallo, ich stehe grade etwas auf dem Schlauch wie man die Visualisierung (deine Grafik) hinbekommt. Ich nehme mal an dass das Flot Diagramme sind (?), ich habe den plenticore Adapter heute bei mir installeirt, soweit alles gut, Datenpunkte sind im iobroker vorhanden. Aber wenn ich den Flot Editor starte, kann ich nix auswählen. Bin bzgl Flot totaler Anfänger und nehme mal an dass mir hier noch ein Adapter fehlt. Ich habe ein Flot-Diagramm für Spritpreise laufen (History Adapter) das läuft. Kannst du mir sagen wie ich die Plenticore-Forecasts in Flot anzeigen kann?

[Diginix]

@amg_666 Du musst alle entscheidenden Datenpunkte wie bei deinen Spritpreisen erstmal mit dem History Adapter oder SQL o.ä. erfassen. Nur wenn es historische Werte in einer Datenbank oder Dateien gibt, kann ein Graph gezeichnet werden.
Für die Tageskurven ist das recht einfach. Bei dem letzten Diagramm mit jeweils nur einem Wert pro Tag braucht man noch andere Adapter und Hilftobjekte.
Da ich den ersten Prognosewert pro Tag will und nicht den letzten, der im Laufe des Tages "besser" wird, speichere ich mir den ersten nach 0 Uhr direkt in einen eigenen Objekt, wo er danach 24h nicht mehr verändert wird. Da die realen Erträge aber erst 23:59 Uhr fest stehen, gäbe es einen Versatz im Diagramm von knapp über 23 h. Daher nutze ich noch den statistics Adapter der automatisch 23:59 Uhr Werte in eigene Objekte speichert. Diese muss man dann aber auch wieder mit dem History Adapter protokollieren. Klingt am Ende komplizierter als es ist, aber man muss das Prinzip erstmal verstanden haben.

@StrathCole Danke für die prompte Anpassung. Ich hab die Untergrenze für intell. Bat.Steuerung mal auf 15% gesetzt und beobachte wieder.
Warum ist eigentlich der letzte Wert der day2 Prognose nie der selbe wieder erste von day1?
Also am 12.04. 23:59 ist ja in day2 die Prognose für 13.04. und kurz nach 0 Uhr am 13.04. ist diese in day1 und in day2 dann der 14.04. Zwischen 23:5x und 00:xx Uhr dürften aber die zugrunde liegenden Wetterdaten nicht so dynamisch sein als das der frische day1 Wert so viel anders ist als der letzte day2.

[StrathCole]

@Diginix was verstehst du unter "so viel anders"?

[Bostil]

Könnte denn jemand mal seine Datenpunkte des Kostals hier für einen baldigen Besitzer dieses Gerätes + Adapters veröffentlichen? :-)

[StrathCole]

@Bostil Puh, das sind soooo viele. Ich schaue mal, was ich machen kann :)

[StrathCole]

@Bostil

[Diginix]

@StrathCole
Grundsätzlich war die Frage erst mal ob ich das richtig verstanden habe. Aber da im date Objekt das Datum zum jeweilige day[1|2] forecast steht, denke ich mal, liege ich richtig.
Hier mal paar Werte von Anfang April und von vorgestern. Zum Teil sind es binnen 15min bis zu 50% Wh mehr/weniger beim Sprung von day2 auf day1 für den selben Tag. Da es nicht einfach eine "Übernahme" ist, sondern berechnet, müssen demnach die Quellen (Wetterdienste) da für den nächsten Tag detaillierter sein als kurz vorher für den übernächsten.

day2 2020-04-01 23:48 40645
day1 2020-04-02 00:03 47182

day2 2020-04-02 23:48  6129
day1 2020-04-03 00:03 11449

day2 2020-04-10 23:59 47376
day1 2020-04-11 00:14 42272

day2 2020-04-11 23:59 42825
day1 2020-04-12 00:14 44385

[StrathCole]

@Diginix Die Wetterdaten sind für den aktuellen Tag schon detaillierter und der Wechsel könnte(!) auch gegen 0 Uhr stattfinden. Ich habe manchmal das Phänomen, dass es ca. 4-5 Stunden lang nachts nur "schlechte" Daten gibt und dann alles wieder gut passt.

Habe mir dazu mal einen Graphen gemacht.

Eigentlich passt der Übergang von rot auf grün zum Tageswechsel immer ganz gut.

[Bostil]

@StrathCole Großartig, danke dir! Dann kann ich mal reinschnuppern, was man überhaupt auslesen kann ... danke, danke!

[Diginix]

@StrathCole Ok, verstanden. Ist mir nur aufgefallen als ich den zuletzt geposteten Graphen für Langzeitprognose vs. real gebaut habe. Da nehme ich ja den ersten Wert nach 0 Uhr den du für den aktuellen Tag generierst. Und der war aber eben immer leicht anders als der day2 kurz vor 0 Uhr.
Ich werde mir mal 1h vor Sonnenaufgang noch einen weiteren speichern und vergleichen welcher am Ende vom Tag eher zum realen Ertrag passt. Genauer brauche ich es nicht. Ich will nur sehen wie oft und wie genau die Tagesprognose vor Sonnenaufgang schon passt um damit später eben Dinge automatisieren zu können.
Der letzte Graph sieht ja selbst mit dem 0 Uhr Wert schon vielversprechend aus. Damit kann man auf jeden Fall arbeiten.
Genauer bzw. fein granularer pro Tagesabschnitt/Stunde brauche ich es gar nicht.