76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[alkazaa]

Danke für die Rückmeldung @Parallix!

Ein Einbau in SF ist grundsätzlich denkbar, widerspricht meines Erachtens aber dem Ansatz von SF, was perfekt zu Steuerung geeignet ist, ggf. auch zur Regelung, dann aber mit einer sehr geringen Abtastfrequenz.

Sehe ich auch so. Das Super-Tool SF ist so mächtig, dass man aufpassen muss, dass es nicht zu fett wird.
Eigentlich sollte sowas wie Dein controller ja sogar in die firmware der Batterie. Aber da sind andere zuständig.

Welches Modul nutzt Du denn für die Kommunikation mit der Box?
Ich nutze das hier vorgestellte ModbusAttr Modul. Das 23_BYDBox.pm Modul habe ich auch ausprobiert, schlummert in meinem FHEM setup als deaktiviertes Modul noch herum. Bin noch in der Experimentierphase, hab die Box (in einem Fronius System) erst seit Ende letzten Jahres.
 

[Parallix]

Danke für die Rückmeldung @Parallix!

Ein Einbau in SF ist grundsätzlich denkbar, widerspricht meines Erachtens aber dem Ansatz von SF, was perfekt zu Steuerung geeignet ist, ggf. auch zur Regelung, dann aber mit einer sehr geringen Abtastfrequenz.

Sehe ich auch so. Das Super-Tool SF ist so mächtig, dass man aufpassen muss, dass es nicht zu fett wird.
Eigentlich sollte sowas wie Dein controller ja sogar in die firmware der Batterie. Aber da sind andere zuständig.

In die Firmware eines BAT-Systems lässt es sich nicht integrieren, da der Hersteller die spezifischen Nutzeranforderungen nicht kennt.

Welches Modul nutzt Du denn für die Kommunikation mit der Box?
Ich nutze das hier vorgestellte ModbusAttr Modul. Das 23_BYDBox.pm Modul habe ich auch ausprobiert, schlummert in meinem FHEM setup als deaktiviertes Modul noch herum. Bin noch in der Experimentierphase, hab die Box (in einem Fronius System) erst seit Ende letzten Jahres.

Meinerseits nutze das BYDBox-Modul, da ich nur so via FHEM an die einzelnen Zellspannungen komme.

[Parallix]

@Parallix,

was evtl. ein Weg sein könnte, wäre die Verwendung eines Percentils (z.B. 99.5 % oder 99.9 %). Das wäre eine Maßnahme die z.B.einmal im Monat als Nachtverarbeitung laufen könnte und würde außergewöhnlich starke Ausreißer elimenieren können. Jeden Tag wäre kontraproduktiv weil nicht erkannt würde ob es ein einmaliger Ausreißer ist oder dieser Wert sich zukünftig wiederholt.

In dem ursprünglichen Beitrag ging es um einen Energiemenge im mehrstelligen MWh-Bereich und ich finde, dass solche physikalisch nicht möglichen Werte zeitnah herausgefiltert werden sollten, um die schon hohe Qualität von SF weiter zu verbessern. Das Filtern sollte auf Basis von Plausibilitätsprüfungen (Monotonie und Leistungsgrenzen) auch möglich sein.

Wenn nur ein angelieferter Wert fehlerhaft zu sein scheint, dann lässt sich dieser in vielen hier bereits diskutierten Fällen auf Basis von Leistungsgrenzen eliminieren.

Komplizierter wird es, einen Fehlerburst mit mehreren hintereinander liegenden fehlerhaften Werten zu identifizieren und zu eliminieren. Die Strategie ist aber auch hier die gleiche, da der erste fehlerhafte/unplausible Wert den Beginn des Burst anzeigt und der letzte vor dem Rücksprung auf niedrigere Werte das Ende des Bursts.

Von meiner Seite spricht auch nichts dagegen, jede Elimination fehlerhafter/unplausibler Werte über ein Reading bekannt zu machen.

[DS_Starter]

In dem ursprünglichen Beitrag ging es um einen Energiemenge im mehrstelligen MWh-Bereich

Ja sicher. Und was ist mit dem einstelligen MWh-Bereich? Oder vllt. doch knapp unterhalb 1MWh?
Aber warum dann 800-900kWh durchlassen?
Das ließe sich endlos weiterführen ... du weißt worauf ich hinaus will. 

Um es sich nicht so schwer zu machen, lege ich für den Verbrauch einen Grenzwert von 100000 Wh fest.
Bei 64A Haussicherung x 3 Phasen sind wir bei max. 46080 Wh (1h). Den Wert verdopple ich und runde ihn auf 100000.
Sollte die Begrenzung anschlagen, gibt es eine WARNING im Log. Dadurch wird man darauf aufmerksam und kann sich Gedanken dazu machen.