76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[stefanru]

Hi Tobias, Hi Heiko,

das Thema Wallbox hatten wir schonmal.

Damals hatten die meisten gesagt sie verwenden dafür EVCC.
Ich benutze es auch selbst in Verbindung mit deinem Modul.

Ich denke EVCC ist hier die richtige Lösung, da dort sehr viel Aufwand betrieben wird für die Ladesteuerung und die Integration von Wallboxen und Autos.
Es läuft auch super parallel zu deinem Modul.

Also meine Meinung ist man sollte sich einfach noch EVCC parallel auf dem Server installieren.

@Tobias: Hast du dir schonmal EVCC angeschaut?

Gruß,
Stefan

[cbl]

Ist eigentlich eine "Smarte" E-Auto Ladefunktion geplant?

Also quasi:
(08:00) Auto wird angesteckt
(08:00) Laden wird gestoppt da aktuell zu wenig V vorhanden und um 11:00 genug vorhanden ist
(11:00) Laden wird aufgrund von genügend PV gestartet


Lg
Tobias

Ich habe noch keine Wallbox und lade übergangsweise über eine Steckdose (mit 6A, also sehr gemächlich). Die hängt als Consumer auch am Modul und das macht genau das, was du oben beschreibst.

Wenn man die Wallbox aus FHEM ansteuern kann, sollte die Einbindung als Consumer schon heute mit diesem großartigen Modul gelingen.

Gruß
Christian

[tupol]

Hallo Heiko,

ich habe es eingebunden. Weiß aber nicht, wie man kontrolliert, ob es tut was es tun soll.

Das mit der Wallbox ist recht kompliziert. Ich habe mich entschieden, es selber über ein Perl-Script zu programmieren. Dadurch kann ich Sachen berücksichtigen wie:

• PV-Durchschnittswert mit schleichender oder schneller Anpassung der Ladeleistung
• Komplexe Bedienung/Ansteuerung der Wallbox
• Ladestand E-Auto (da mein E-Auto und meine Wallbox nicht ausreichend smart sind, geht es nur über einen CAN-Adapter, MQTT-Server, FHEM-MQTT-Client)
• Gestufte Prio des Aufladung je nach Batteriestand Solar und E-Auto, z. B. Schnellladen bis mindestens 30%, danach Prio-Laden bis 40%, Anpassen der Ladeleistung an Füllstand-Solarbatterie bis 60%, Berücksichtigung Restverbrauch Haus ab 40%, etc.)
• Vorbereitung der Solarbatterie (85%->100%) auf Rückkehr des Autos
• Solarbooster der Wärmepumpe nur bei geladenem oder nicht angeschlossenem E-Auto
• Verschiedene Lade-Modi wie PV-Laden, PV-Laden mit Solarbatterie, Minimal- und Maximalladen, Zielzeitpunkt-Laden etc.

Gruß
tupol

[DS_Starter]

@Tupol,

h habe es eingebunden. Weiß aber nicht, wie man kontrolliert, ob es tut was es tun soll.

Ah ja, guter Hinweis. Ich baue noch eine Debug Logmeldung mit ein damit man die Berücksichtigung des Keys nachverfolgen kann.

@Thema Wallbox,
stimmt Stefan hatten wir schonmal. Für eine einfache Anwendung (wie bei Christian beschreibt) reicht offensichtlich die aktuelle Consumer Einbindung.
Die komplexen Steuerungsaufgaben, wie Tupol sie beschreibt, sind natürlich nochmal eine andere Hausnummer.
Tupol, möglicherweise könnte ich deine Algos im Modul mit verankern/adaptieren falls gewünscht. Es liest sich schon sehr ausgefeilt was du entwickelt hast.

LG

[DS_Starter]

@Tupol, habe eine Debugmeldung für ctrlDebug=consumtion eingebaut. Sie zeigt die Berücksichtigung:

Code Auswählen Erweitern

2024.06.15 22:02:11.168 1: SolCast DEBUG> ################### Consumption forecast for the next hours ###################
2024.06.15 22:02:11.168 1: SolCast DEBUG> Consumer '04' values excluded from forecast calc by 'exconfc' - day: 01, hour: 23, csme: 72.8999999999069
2024.06.15 22:02:11.169 1: SolCast DEBUG> Consumer '04' values excluded from forecast calc by 'exconfc' - day: 08, hour: 23, csme: 72.9000000001397
2024.06.15 22:02:11.169 1: SolCast DEBUG> Consumer '04' values excluded from forecast calc by 'exconfc' - day: 18, hour: 23, csme: 73.5
2024.06.15 22:02:11.170 1: SolCast DEBUG> Consumer '04' values excluded from forecast calc by 'exconfc' - day: 25, hour: 23, csme: 74.1000000000931
2024.06.15 22:02:11.170 1: SolCast DEBUG> estimated Consumption for Sa -> starttime: 2024-06-15 22:00:00, confc: 530, days for avg: 4, hist. consumption registered consumers: 213.85

Ist eingecheckt und auch im contrib verfügbar.

[DS_Starter]

Zur Info...

Bezüglich der Umstellung Readings -> Attribute bin ich soweit durch.
Lediglich die Attribute ctrlWeatherDevX stelle ich noch nach setupWeatherDevX um da diese Einstellungen auch direkt zum Setup des Devices gehören.

Die Konfigurations-Readings moduleAzimuth und moduleDeclination bleiben erhalten damit sie bei Nachführanlagen dynamisch von extern verändert werden können. Ich überlege allerdings noch ob ich sie in setupStringAzimuth bzw. setupStringDeclination umsetze damit sie im Wording zu den Setup-Attributen passen.

[tupol]

Tupol, möglicherweise könnte ich deine Algos im Modul mit verankern/adaptieren falls gewünscht. Es liest sich schon sehr ausgefeilt was du entwickelt hast.

Ich glaube, da ist eher Dein Ansatz mit einer möglichst flexiblen Schnittstelle sinnvoller. Meine Anwendungen ist ja nur für unser Nutzungsverhalten programmiert. Ich bin da noch am Beobachten von PV, Haus-Verbrauch und E-Auto-Nutzung und bessere immer wieder was nach, wenn mir eine mögliche Logik auffällt. Bei einem anderen Nutzungsverhalten muss die Logik sicher anders aussehen. Ich kann aber gerne etwas detaillierter schildern, was ich bisher umgesetzt habe.

[TechnoTron]

@Stefan

Nein, aktuell nutze ich die Modbusverbindung des Ladegeräts.

Hier stelle ich auch die Ladeleistung in Abhängigkeit von Verbrauch und Batteriespeicher-Stand rauf und runter.
Das habe ich über ein paar Scripte etc. gelöst.

EVCC kenne ich nicht, werde ich mir gleich mal ansehen.

Ich bin aber ein Fan von Aio (All in one) Lösungen deswegen wollte ich fragen ob da etwas geplant ist.

[DS_Starter]

Moin Tobias,

du kannst mir deine Scripte (gerne auch als PM) übermitteln.
Daran sehe ich vermutlich deine Vorgehensweise und könnte sie ggf. in die Consumer Konfiguration matchen.
Vllt. kann man dann bereits einige (einfachere) Fälle abbilden.

LG

[kask]

Zur Info...

Bezüglich der Umstellung Readings -> Attribute bin ich soweit durch.
Lediglich die Attribute ctrlWeatherDevX stelle ich noch nach setupWeatherDevX um da diese Einstellungen auch direkt zum Setup des Devices gehören.

Die Konfigurations-Readings moduleAzimuth und moduleDeclination bleiben erhalten damit sie bei Nachführanlagen dynamisch von extern verändert werden können. Ich überlege allerdings noch ob ich sie in setupStringAzimuth bzw. setupStringDeclination umsetze damit sie im Wording zu den Setup-Attributen passen.

Ich habe noch nie wirklich verstanden warum sämtliche Anlagen Parameter als Readings ausgeführt wurden bzw. noch werden.
Eigentlich benutzen sämtliche Module die Ich so kenne und benutze Readings als ändernde Werte des Moduls und Attribute als statische.
In dem SolarForecast Modul ist es ja anfangs anders gewesen. Da waren eigentlich alle statischen Paramater zur Anlage als Reading ausgeführt.
Wo war da der Grund? Bzw. Ist da der Grund? Man kann doch auch auf Attribut änderungen intern im Modul drauf reagieren.
Oder gibt es da was das als Attribute nicht möglich ist aber als Reading?
Attribute kann ich doch auch so ändern ob ich jetzt "set","setreading" oder "attr" nehme zum anpassen.

[DS_Starter]

Hallo kask,

am Anfang der Entwicklungen bestand die Idee darin, die vielfältigen Einstellmöglichkeiten der Darstellung und sonstigen Verhaltens inhaltlich von den Core-Einstellungen des Moduls zu trennen sowie sich dynamisch änderende Settings zu ermöglichen. Dadurch konnte ich die Anzahl der Attribute managen.
Später hatte ich mit der Einführung der Klassifikationen ctrl.*. flow.*, graphic.*, setup.* die Möglichkeit die Attribute zu strukturieren, was dem User ermöglicht trotz der vielen Attribute sich gut zu orientieren wenn man die Struktur verinnerlicht hat.

Einige der Einstellungen wie z.B. Azimuth oder Declination sind ganz praktisch wenn man sie dynamisch ändern kann (Nachführanlagen) ohne diese Parameteränderung explizit speichern zu müssen. Erstens hat man ständig das rote Fragezeichen im System stehen und außerdem wird ein nicht gespeichertes Attribut beim Restart immer mit dem letzten persistierten Wert wiederhergestellt. Das ist nicht gewünscht in diesen Fällen. Ein ähnliches Verfahren gibt es im notify Modul mit dem Setter active/inactive versus disable. Beide Dinge wirken im Prinzip identisch mit dem oben beschriebenen Unterschied.

Aus diesem Grund ist zum Beispiel auch pvCorrectionFactor_Auto als Setter ausgeführt. So kann z.B. der User in Abhängigkeit bestimmter Umstände in den noLearning Modus wechseln und zurück. Gängiges Beispiel ist des Vorhandensein einer Schneedecke auf den Modulen oder Umbauarbeiten. Die Schneedecke kennt das Modul nicht, aber die Abweichungen wären extrem und würden über längere Zeit die gelernten Werte stark verfälschen. So kann der User manuell oder automatisiert über den Set-Befehl zwischen den Modi wechseln ohne sich um eine Speicherung der Strukturänderung Gedanken machen zu müssen.

 
 

[tupol]

Das mit dem Schnee war mir gar nicht bewusst. Könnte man das auch automatisch abfangen, so dass große Ausreiser nicht berücksichtigt werden?
Ich strebe ja immer danach, dass FHEM ohne irgendwelche händische Einstellungen läuft und man höchstens mal einen Knopf drückt, wenn man in den Urlaub fährt.

[DS_Starter]

Könnte man das auch automatisch abfangen, so dass große Ausreiser nicht berücksichtigt werden?

Zum Beispiel mit einem entsprechend angebrachten "Schneesensor". Es könnte ein Belichtungssensor sein, der während der Tagzeit ausgewertet wird. Fällt sein Wert unter X wird von einer Scheedecke ausgegangen und per notify etc. ein "set ... pvCorrectionFactor_Auto noLearning" ausgelöst.
Man kann sich da sicher noch mehr einfallen lassen.

[tupol]

Hallo Heiko,

Ein Hinweis für die Wallboxsteuerung. Für die Entscheidung mit dem Laden zu starten, verwende ich unter anderem die verfügbare Differenz des Tages aus "PV-Forecast" - "Consumer-Forecast bis Sonnenuntergang" - "Nötige Solar-Batterieladung bis 100%". Dahinter steht die Vorgabe, dass die Solar-Batterie bei Sonnenuntergang voll sein soll. Man muss dabei aber zwischen Brutto- und Netto-SoC unterscheiden. Prinzipiell versuche ich immer so schnell wie möglich die Autobatterie zu laden, da ich da nix mehr rein schieben kann, wenn es unterwegs ist.

Gruß
tupol

[tupol]

Zum Beispiel mit einem entsprechend angebrachten "Schneesensor". Es könnte ein Belichtungssensor sein, der während der Tagzeit ausgewertet wird. Fällt sein Wert unter X wird von einer Scheedecke ausgegangen und per notify etc. ein "set ... pvCorrectionFactor_Auto noLearning" ausgelöst.
Man kann sich da sicher noch mehr einfallen lassen.

Nein. Ich meinte über die AI. In der Statistik werden ja große Ausreiser auch aussortiert und entweder mit dem Median gearbeitet oder mit der 2. und 3. Quartil.