IOBroker Anbindung an einen Kostal Plenticore
-
Ich bekomme mit 2.0.1.9 zumindest diese bzgl met.no
2020-03-20 09:57:56.350 warn (11834) Met.no got more than 10 entries in from/to entry. This is bad. Stopping. -
@Diginix Danke, genau das habe ich erwartet. Kannst du mir die debug Meldungen, die davor und danach kommen, noch mitteilen? Das scheint nämlich genau der Punkt zu sein, an dem der Adapter bei euch abgestürzt ist und bei mir nicht.
-
@StrathCole
Da musst du dich mal durchkämpfen:
Ach hab das vor 3 Stunden schon gepostet aber das Log war zu lang und der Post wurde gar nicht gesendet.
Also hier mal das Log in meiner Dropbox:
https://www.dropbox.com/s/w8wouypxj3hi20b/2020-03-19_plenticore.log?dl=0 -
@Diginix Danke sehr. Das genügt mir schon. So etwas hatte ich mir gedacht. Du kannst das Log wieder löschen. Ich denke, mit der neuesten Version ist das Problem behoben.
-
@StrathCole Ok, hab die neue von GIT installiert.
-
Bei mir kommt auch mit der neuen Version noch die Meldung:
plenticore.0 2020-03-20 14:30:31.114 warn (19507) Met.no got more than 10 entries in from/to entry. This is bad. Stopping. -
@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.
