76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

Begonnen von DS_Starter, 11 Februar 2024, 14:11:00

Vorheriges Thema - Nächstes Thema

alkazaa

Danke für die Rückmeldung @Parallix!
Zitat von: Parallix am 19 März 2026, 14:11:48Ein 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

#5476
Zitat von: alkazaa am 19 März 2026, 17:55:49Danke für die Rückmeldung @Parallix!
Zitat von: Parallix am 19 März 2026, 14:11:48Ein 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.

ZitatWelches 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.
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.62) und 7591 (8.21) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - Trina TSM 405: (#East, #South, #West) = (12,16,12) - BYD: 2 x HVS 7.7 (BMS V3.31-B, BMU V3.26-B) - EnOcean - Z-Wave - FS20/HMS

Parallix

#5477
Zitat von: DS_Starter am 19 März 2026, 17:36:08@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.
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.62) und 7591 (8.21) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - Trina TSM 405: (#East, #South, #West) = (12,16,12) - BYD: 2 x HVS 7.7 (BMS V3.31-B, BMU V3.26-B) - EnOcean - Z-Wave - FS20/HMS

DS_Starter

ZitatIn 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.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

tomcat.x

Zitat von: DS_Starter am 19 März 2026, 17:43:46
ZitatDie Balken für consumption scheinen nichts mit den Werten im Reading Current_Consumption zu tun zu haben
Stimmt, haben sie nicht. Current_Consumption ist der aktuelle Verbrauch (W/kW). consumption ist der Verbrauch der entsprechenden Stunde (Wh/kWh).

Wenn ich also eine Stunde lang auf Current_Consumption schaue, da um die 500 W angezeigt werden, anhand der eingeschalteten Geräte auch klar ist, dass der Wert in der Stunde nicht viel schwankt, müsste hinterher der consumption Balken für diese Stunde nicht um die 500 Wh anzeigen?
FHEM: 6.4 auf Raspi 4B, Raspbian (noch Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 8.21), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

DS_Starter

ZitatWenn ich also eine Stunde lang auf Current_Consumption schaue, da um die 500 W angezeigt werden, anhand der eingeschalteten Geräte auch klar ist, dass der Wert in der Stunde nicht viel schwankt, müsste hinterher der consumption Balken für diese Stunde nicht um die 500 Wh anzeigen?
Ja, 500 +- X. Wenn es es nicht so ist, liegt es an den gelieferten Energiewerten der beteiligten Geräte. Lies dir dazu diesen Abschnitt im Wiki durch.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

#5481
@all,

Abseits der KI Entwicklung gibt es ein neues Grafikfeature. Mit setupEnvironment können Umgebungskomponenten interiert werden.
Nun ist es auch möglich, Umgebungswerte im Grafikkopf mit anzuzeigen:

graphicControl->headerShowEnv   
Auswahl der anzuzeigenden Umgebungswerte im Grafik Kopfbereich. Die gewählten Optionen werden durch Komma getrennt angegeben.
Die Einrichtung der Umgebungswerte erfolgt mit Attribut setupEnvironment
    outsideTemp - die aktuelle Außentemperatur
    presence - den Anwesenheitsstatus
    windSpeed - die aktuelle Windgeschwindigkeit

Diese Erweiterung bedingt, dass die bisher fix angezeigte Außentemperatur per default nicht mehr angezeigt wird und mit dem Schlüssel graphicControl->headerShowEnv=outsideTemp wieder aktiviert werden muß wenn man es wünscht.

Liegt im contrib.

Edit: Das in #5478 erwähnte Energielimit ist ebenfalls implementiert.

LG,
Heiko
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

grappa24

bei mir sieht das mit diesen Definitionen dann so aus ...

graphicControl headerShowEnv=outsideTemp,presence,windSpeed
setupEnvironment outsideTemp=netatmo_M02_00_00_1b_18_2a:temperature presence=Bewohner:state:home windSpeed=netatmo_M06_00_00_05_03_b6:windstrength_ms
Gebäudesicherheit/-komfort, PV-Prognose/Verbrauchssteuerung, Heizungssteuerung, Multimedia, ...
KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200, Netatmo, Nuki, SolarForecast, HEOS, Alexa-FHEM, ...
FHEM 6.4, 2 x RasPi 3B+, Debian Bullseye

DS_Starter

Ach, da sind Icons nicht ausgeliefert. Ich werde morgen bitten einige neue Icons einzuchecken.
Hier angehängt das fehlende Teil.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Parallix

#5484
Zitat von: DS_Starter am 19 März 2026, 20:19:05
ZitatIn 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.  ;)
Ja, ich weiß worauf Du hinaus willst. Aber ich sehe das Problem nicht, zumindest dann nicht, wenn Du auf Basis von Energiemengen und nicht von Leistungen rechnest.

ZitatUm 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.
Sorry, aber ich Du setzt hier einen viel zu hohen Wert an. Selbst wenn wir mal von 64A-Sicherungen im HAK ausgehen, dann wird der dahinter liegende SLS nur noch maximal 50A haben, was zu einer max. Leistung in Höhe von 3 x 230V x 50 A = 34,5 kW von/zum Grid führt.

Gucken wir uns jetzt typische Setups im Privatbereich an: Wallbox (11 kW), eine Wärmepumpe (5 kW) und der in Ihr verbaute Heizstab für die kalte Jahreszeit (9 kW). Diese (Dauer-)Verbraucher würden, wenn Sie alle gleichzeitig eingeschaltet sind, max. 11kW + 5kW + 9kW = 25kW zum Arbeiten benötigen. Rechnen wir jetzt noch einen vollbelegten Herd mit eingeschaltetem Backofen, alles auf höchster Stufe und einem (praxisfremden) Duty Cycle von 100%, hinzu (10 kW), dann kommen wir mit 35 kW fast punktgenau auf o.g. Maximalwert von 34,5 kW.

Da jeder hier wahrscheinlich die Maximallast seines Setups abschätzen kann, könnte und sollte man diese vielleicht individuell in SF konfigurierbar gestalten, oder?
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.62) und 7591 (8.21) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - Trina TSM 405: (#East, #South, #West) = (12,16,12) - BYD: 2 x HVS 7.7 (BMS V3.31-B, BMU V3.26-B) - EnOcean - Z-Wave - FS20/HMS

DS_Starter

#5485
Moin,

ZitatSorry, aber ich Du setzt hier einen viel zu hohen Wert an.
Gestern ging es noch um Ausreißer im MW Bereich und heute sind 100000 zu viel.  ;)
Genau deswegen schrieb ich gestern "Das ließe sich endlos weiterführen ...".

Mir ist schon klar, dass man diesen Wert unter normalen Umständen nicht erreicht. Darum geht es nicht, sondern um offensichtiliche Fehlerzustände außerhalb der Normalitäten.
Natürlich kann man typische Setups ausrechnen wie du es getan hast. Ich muß aber auch an untypische Varianten denken.

ZitatSelbst wenn wir mal von 64A-Sicherungen im HAK ausgehen, dann wird der dahinter liegende SLS nur noch maximal 50A haben, was zu einer max. Leistung in Höhe von 3 x 230V x 50 A = 34,5 kW von/zum Grid führt.
Wer sagt denn, dass die maximale Leistung im Haushalt bzw. SF durch den HAK bzw. die Haussicherungen begrenzt ist? Stelle dir eine leistungsfähige Batterieanlage vor an der ebenso leistungsfähige WR mit Ersatzstromanschluß vorhanden sind die das Haus versorgen. Die WB zur Ladung der EV wird mit 22kW + 11kW Wallboxen über den HA versorgt, weitere WR der Batterieanlage können auch noch Anteile dazuliefern. Der User betreibt als Hobby eine kleine Farm und hat zusätzliche PV und Leistungsabnahmen im Betrieb mit Null-Einspeisung, wobei die Anteile auch in SF eingehen.

Unter diesen Gesichtspunkten glaube ich auch nicht, dass JEDER! die Maximallast seines Setups berechnen kann.

Das Beispiel ist sicherlich etwas konstruiert, jedoch nicht unmöglich und soll auch nur zeigen was abseits des "typischen Setups" möglich wäre.

LG,
Heiko

Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Parallix

#5486
Zitat von: DS_Starter am 20 März 2026, 08:57:15...
Das Beispiel ist sicherlich etwas konstruiert, jedoch nicht unmöglich und soll auch nur zeigen was abseits des "typischen Setups" möglich wäre.
...
Natürlich ist neben Deinem 64A- und meinem 50A-Setup einiges möglich! Und genau deshalb hatte ich ja auch geschrieben/angeregt:

ZitatDa jeder hier wahrscheinlich die Maximallast seines Setups abschätzen kann, könnte und sollte man diese vielleicht individuell in SF konfigurierbar gestalten, oder?
Bei o.g. Annahme bleibe ich, da ich "jeder hier" und nicht "JEDER" geschrieben hatte. Aber selbst wenn es hier jemand nicht schafft, seine Maximallast im Haus abzuschätzen, so könnte man diesen Fall durch einen Default-Wert für einen ansonsten frei konfigurierbaren Höchstwert abfangen.

Sehr hoffe ich, dass Du meine Anregung auch nicht als unproduktive Kritik an Deinem wirklich tollen SF verstehst. Meinerseits sehe ich nur, dass nicht nur ich, sondern auch viele andere immer mal wieder Probleme mit unplausiblen (da physikalisch nicht  möglichen) Werten haben. Das fühlt sich irgendwie so an, als würde ich in einem modernen Luxuswagen sitzen, bei dem jede kleine Schneeflocke vor der Kamera zu einer überzogenen Reaktion führt. 
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.62) und 7591 (8.21) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - Trina TSM 405: (#East, #South, #West) = (12,16,12) - BYD: 2 x HVS 7.7 (BMS V3.31-B, BMU V3.26-B) - EnOcean - Z-Wave - FS20/HMS

DS_Starter

Kein Problem, man muß sich dazu ja mal bzgl. der Standpunkte austauschen können.  :)

Ich habe auch garnichts dagegen eine Einstellmöglichkeit vorzusehen, die ich in plantControl einbauen kann. Dann kann jeder bei Bedarf nachsteuern.
Nur das Grundsetup sollte nicht zu einengend sein.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Parallix

Zitat von: DS_Starter am 20 März 2026, 09:42:24Kein Problem, man muß sich dazu ja mal bzgl. der Standpunkte austauschen können.  :)
Toll, dass Du das so siehst!

ZitatIch habe auch garnichts dagegen eine Einstellmöglichkeit vorzusehen, die ich in plantControl einbauen kann. Dann kann jeder bei Bedarf nachsteuern.
Nur das Grundsetup sollte nicht zu einengend sein.

Unlängst hatten wir uns ja auch einmal über in SF ausgewiesene und nicht ausgewiesene Verbraucher unterhalten. Insb. bei den ausgewiesenen Verbrauchern könnte man ja auch eine Maximalleistung hinterlegen, die bei Wallbox, Wärmepumpe und anderen Dauerlasten ja anhand des Typenschildes leicht zu ermitteln ist. Bei allen Verbrauch messenden Steckdosen & Co. sollte das eigentlich auch gelingen. Wahrscheinlich ist es für künftige Zwecke (z.B. Dimmung seitens des Netzbetreibers und/oder unzureichendem PV-Überschuss sowie der Planung in SF) sinnvoll, statt der maximalen Last gleich die aller ggf. vorhandenen Leistungsstufen anzugeben.

Übrig bleiben dann "nur" noch die in SF nicht explizit ausgewiesenen Verbraucher bzw. deren maximale Summenlast, die jeder dann abzuschätzen hat, wenn er nicht den voreingestellten Default zufrieden ist.
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.62) und 7591 (8.21) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - Trina TSM 405: (#East, #South, #West) = (12,16,12) - BYD: 2 x HVS 7.7 (BMS V3.31-B, BMU V3.26-B) - EnOcean - Z-Wave - FS20/HMS

DS_Starter

Im contrib liegt ein Update der V2.4.0.

plantControl->conEnergyHourLimit    
 Limitierung des maximal möglichen Energieverbrauches im Hausnetz pro Stunde (Wh).
 Werte oberhalb des Limits werden durch SolarForecast als ungültig bewertet und nicht gespeichert.
 Wert: Ganzzahl, default: 100000


Wird die Grenze erreicht/verletzt gibt es eine Warnung im Log.

Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter