NEWS
IOBroker Anbindung an einen Kostal Plenticore
-
@tom57 Ist bei mir auch so, aber ich vermute dass es @StrathCole ja dann intern zu handeln weiß.
-
@tom57 @Diginix das wird in der nächsten Version verschwinden. Ich habe den Grund für das Problem gefunden.
Für alle, die ein bisschen Javascript können oder Programmierung mögen:
toTime -> Date Sun Mar 29 2020 03:00:00 GMT+0200 (Mitteleuropäische Sommerzeit) toTime.setHours(toTime.getHours()-1) toTime -> Date Sun Mar 29 2020 03:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)
Das Problem war, dass eure Server in deutscher Zeit laufen und er bei Zeitberechnungen da ein Problem kriegt (3 Uhr am 29.3. minus eine Stunde ist wieder 3 Uhr am 29.3.) und in eine Endlosschleife läuft. Darum trat es jetzt auch plötzlich auf, weil die Wetterdaten jetzt bis zu dem Datum gingen.
Ich muss stattdessen komplett in UTC Zeitzone rechnen, also:
toTime -> Date Sun Mar 29 2020 03:00:00 GMT+0200 (Mitteleuropäische Sommerzeit) toTime.setUTCHours(toTime.getUTCHours()-1) toTime -> Date Sun Mar 29 2020 01:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)
Damit verschwindet dann auch diese Warnmeldung.
-
@StrathCole Danke für die Info.
@DiginixIch war übrigens erstaunt, dass seit gestern Abend der WU-Adapter mit Koordinaten auf einmal keine Daten und Fehlermeldungen produzierte. Warum auch immer so plötzlich. Der Plenticore Adapter bekam dann Null-Werte und produzierte Fehler.
Nach Eingabe des Ortsnamens geht der WU-Adapter dann wieder. Hattet Ihr das auch?
-
@tom57 Nein, hatte ich nicht.
-
@tom57 sagte in IOBroker Anbindung an einen Kostal Plenticore:
seit gestern Abend der WU-Adapter mit Koordinaten auf einmal keine Daten und Fehlermeldungen produzierte
Ich habe schwach in Erinnerung, dass das passieren kann, wenn sich der öffentliche API-Key auf der WU Webseite ändert und der alte nicht mehr funktioniert. Dann muss man einmal den Adapter neu starten und vorher ggf. den Key entfernen.
-
@StrathCole sagte in IOBroker Anbindung an einen Kostal Plenticore:
Ich habe schwach in Erinnerung, dass das passieren kann, wenn sich der öffentliche API-Key auf der WU Webseite ändert und der alte nicht mehr funktioniert. Dann muss man einmal den Adapter neu starten und vorher ggf. den Key entfernen.
Hatte den API-Key nicht ausgefüllt. Nach der Fehlermeldung habe ich meinen eigenen API-Key eingefügt. Mit Koordinaten kam aber immer noch der Fehler. Nur mit Ortseingabe als Text lief der Adapter.
Egal, aber ich war schon erstaunt, über die "plötzliche" Änderung gestern Abend - analog zum Plenticore Adapter.Corona scheint schon weiter vorgedrungen sein als bisher bekannt ......
-
Ich nutze nur daswetter als Adapter, kein WU.
-
Ich nutze alle, die aktuell unterstützt werden, also daswetter, WU und darksky. Bei WU muss man glaub ich den Datenpunkt einmal löschen, in dem der API-Key gespeichert wird, der bei "nicht ausgefüllt" von der Webseite extrahiert wird. Dann holt sich der Adapter beim nächsten Neustart einen aktuellen.
-
Die aktuelle Version im Git hat nun nicht mehr die Warnung bezüglich met.no
-
Wie sehen bei euch denn die Werte in den letzten Tagen aus? Bei mir ist die Kurve sehr, sehr nah an der Realität, da die Tage jetzt natürlich wolkenlos waren und entsprechend die Prognose fast gleich Maximum war.
-
@StrathCole
Bei mir auch. Ich habe aber noch 10% mehr Fläche (Leistung) für die beiden Strings angegeben. Insofern erreichen die Ist-Werte aktuell nicht ganz die Prognose. Da ich bis 8:30 Uhr die SO-Fläche teilverschattet habe, ist der Ertrag bis dahin natürlich auch niedriger.Ansonsten ist der Ertrag im Vergleich zur Prognose im Verlauf fast identisch. Bei wolkenlosen bzw. heiterem Wetter stimmt die Prognose sehr gut überein.
Nur bei 90-100% bedecktem Himmel sind die Werte in der Regel um den Faktor 2 bis 5 zu niedrig.
Irgendwie geben die Wetteradapter nicht genügend Infos zur Dicke der Wolkendecke bzw. zur Stärke der difusen Strahlung her.D.h. z.B. laut Adpater 100% Bewölkung - ist auch so - dann als Resultat sehr geringe Prognose (6.25%) aber in Realität doch viel difuse Strahlung mit Ertrag von 30-35% vom Maximum.
-
@tom57 Seit du auf die neue Git-Version aktualisiert hast, gab es glaub ich noch keine volle Bewölkung, da müssen wir jetzt noch mal abwarten, da die Version eine ganz andere Berechnung hat als vorher.
Ich habe bei meiner Anlage keine Anpassungen gemacht, die Wirkung steht auf 19,4%. Das passt so weit trotzdem gut.
-
@StrathCole
Ja warten wir mal ein paar Tage. Zum Wochenende hin kommt ja wieder mehr Bewölkung. Ich bin gespannt.
Ansonsten funktioniert die Prognose ja so sehr gut. -
@tom57 Ich habe bei mir auch die dynamische Aktivierung und Deaktivierung der intelligenten Steuerung aktiviert. Das hilft tatsächlich. Durch das gute Wetter in den letzten Tagen hat die intelligente Steuerung nun zumindest am Vormittag nur geringe Batterieladung vorgenommen, sodass nur eine kurze Zeit am Mittag ein wenig der Leistung durch die 70%-Grenze verloren geht. Sobald die Prognose wieder schlechter wird, schaltet der Adapter die Einstellung wieder ab.
-
@StrathCole sagte in IOBroker Anbindung an einen Kostal Plenticore:
Ich habe bei mir auch die dynamische Aktivierung und Deaktivierung der intelligenten Steuerung aktiviert.
Ist bei Dir die 70% Begrenzung fest eingestellt? Wenn ja wo? Im KSEM oder im Plenticore?
Bei mir ist die 70%-Grenze ja durch die String-Anordnung gegeben, d.h. es ist nicht vorgegeben.
Irgendwie macht die intelligente Steuerung dann auch nichts ....??? -
@tom57 Bei mir ist die 70% im Plenticore eingestellt. Der Plenti zieht dann den Verbrauch (gemessen vom KSEM) und die Batterieladung von der Leistung ab. Insofern ist die Grenze dynamisch, aber die maximale Einspeisung ist als W im Plenticore hinterlegt.
-
@StrathCole sagte in IOBroker Anbindung an einen Kostal Plenticore:
Bei mir ist die 70% im Plenticore eingestellt.
Bei mir ist im Plenticore keine Begrenzung eingestellt.
Im KSEM hatte ich mal versuchsweise die 50% Begrenzung für die Batterieförderung aktiviert.
Das funktioniert dann auch - die Einspeisung wird begrenzt. Das soll auch bei 2 Wechselrichtern funktionieren.Ich habe aber den Eindruck, dass mit KSEM-Begrenzung die intelligente Batteriesteuerung nicht richtig funktioniert.
Ich sehe keinen Effekt in der zeitverzögerten Batterieladung. -
@tom57 Okay, das war vom Solateur so vorgegeben, der hat die 70% eingetragen. Im KSEM ist nichts eingestellt, der ist nur für die Messungen zuständig. Das mit der verzögerten Ladung ist bei mir sehr sinnvoll, sonst wäre in diesen Tagen die Batterie schon gegen 10 Uhr voll und dann würde ich zwischen 10 und 14 Uhr ca. häufig Leistung verschwenden, denn ich erreiche derzeit mittags einen Peak von 9,1-9,2kW, Verbrauch liegt da meist zwischen 400 und 1000W, Einspeiselimit bei ca. 6900W. Durch die verzögerte Ladung erreiche ich dieses Limit kaum.
Ich muss sie halt wieder abschalten, wenn das Wetter schlechter wird, sonst lädt die dumme Intelligenz nämlich am ersten und zweiten schlechten Tag morgens ebenfalls nicht, sondern speist ein.
-
Hier mal ein tolles Beispiel, dass die "intelligente" Batteriesteuerung selbst unter diesen Bedingungen nicht vernünftig arbeitet:
Die grüne Linie knickt am ersten Tag ganz leicht ab, am zweiten und dritten Tag ganz deutlich. Das ist der Moment, wo die Anlage auf 70% begrenzt. Die Batterie wird also immer noch zu schnell geladen am Vormittag. Dadurch sind es schon jetzt 2-3 Stunden, in denen etwa 1-2,5kW verloren gehen. Im Sommer wird das noch extremer sein, wenn die Batterie in der Nacht nicht bis 5% entladen wird. Ich hoffe wirklich, dass die das endlich gebacken kriegen, den Ladestrom manuell einstellbar zu machen.
Hier die dazugehörige Ladekurve der Batterie. Viel zu steil, viel zu früh.
-
@StrathCole sagte in IOBroker Anbindung an einen Kostal Plenticore:
Wie sehen bei euch denn die Werte in den letzten Tagen aus? Bei mir ist die Kurve sehr, sehr nah an der Realität, da die Tage jetzt natürlich wolkenlos waren und entsprechend die Prognose fast gleich Maximum war.
Bei mir läuft alles auf Max. Also Prognose = Max und Anlage schießt zT darüber hinaus und wird dann technisch bei 5,5 kW gedeckelt. Alle anderen Graphen habe ich in die Dropbox. Bei diesen Bedingungen ist es also recht einfach die Kurven gleich zu haben.