76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

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

Vorheriges Thema - Nächstes Thema

DS_Starter

#1395
Hallo zusammen,

in meinem contrib liegt die V 1.40.0 zunächst zum Test wegen der Feiertage.

Der zum Schalten der Consumer ermittelte PV-Überschuß (Surplus) kann nun nach verschiedenen Methoden ermittelt und für jeden Consumer individuell eingestellt werden.
Dazu gibt es den optionalen Key "surpmeth" im Consumer-Attribut:

surpmeth   
Die möglichen Optionen legen das Verfahren zur Ermittlung des PV-Überschusses fest. (optional)
    default - der PV-Überschuß wird aus dem Reading 'Current_Surplus' direkt ausgelesen. (default)
    median - es wird der Median der letzten PV-Überschuß Messungen (max. 20) verwendet.
    2 .. 20 - der verwendete PV-Überschuß wird als Durchschnitt der angegebenen Anzahl Meßwerte gebildet.
    Device:Reading - Device/Reading-Kombination die einen vom Nutzer bestimmten bzw. berechneten numerischen PV-Überschuß in Watt liefert.

Damit kann der User eigene Überschuß-Berechnungen in das Consumer-Schaltmodul integrieren.

Nach dem Download der Version aus dem contrib Restart nicht vergessen!

Edit: gerade (23.12, 08:50) das Modul im contrib nochmal upgedated.

LG und schöne Feiertage,
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

TheTrumpeter

Zitat von: DS_Starter am 22 Dezember 2024, 10:57:58Nach dem Download der Version aus dem contrib Restart nicht vergessen!
Ich hab's mal geladen und den neuen Schlüssel für 2 Verbraucher gesetzt. Aufgrund der schwachen PV-Prognose für die nächsten Tage wird's aber vermutlich ein paar Tage dauern, bis ich dazu was sagen kann.

Danke für die rasche und flexible Umsetzung.
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

DS_Starter

#1397
Zitat... wird's aber vermutlich ein paar Tage dauern, bis ich dazu was sagen kann.
Naja, jetzt stehen bei mir auch erstmal andere Aktivitäten als FHEM-Entwicklung auf dem Plan.  ;)

Bin gespannt auf deine Rückmeldung.

Falls du Fehler / Ungereimtheiten suchen willst oder musst -> ctrDebug=consumerSwitchingXX einschalten.

LG
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

rolf

Hallo,

ich bin gerade am einrichten des SolarForecast-Moduls. Leider stürzt mir mein komplettes FHEM ab, sobald ich mit "attr xxx setupWeatherDev1 OpenMeteoWorld-API" den Wetterdienst definiere. Es erscheint noch die Meldung "SolarForecast wartet auf Solarvorhersagedaten " - aber nach ca. einer Minute stürzt FHEM ab - im Eventlog finde ich folgende Fehlermeldungen:

2024.12.23 11:24:20 3: SolarForecast - all registered consumers collected
The following parameter was passed in the call to DateTime::Format::Strptime::new but was not listed in the validation options: strict
 at /usr/share/perl5/DateTime/Format/Strptime.pm line 58.
   DateTime::Format::Strptime::new(undef, "pattern", "%Y-%m-%dT%H:%M", "strict", 0, "time_zone", "UTC") called at lib/FHEM/Utility/CTZ.pm line 110
   FHEM::Utility::CTZ::convertTimeZone(HASH(0x5e142c76e580)) called at ./FHEM/76_SolarForecast.pm line 17883
   FHEM::SolarForecast::timestringUTCtoLocal("SolarForecast", "2024-12-23T10:15", "%Y-%m-%dT%H:%M") called at ./FHEM/76_SolarForecast.pm line 4214
   FHEM::SolarForecast::__openMeteoDWD_ApiResponse(HASH(0x5e142b15e088), "", "{\"latitude\":48.34,\"longitude\":8.5,\"generationtime_ms\":0.16999"...) called at FHEM/HttpUtils.pm line 755
   main::__ANON__(HASH(0x5e142b15e088)) called at fhem.pl line 786
2024.12.23 11:26:44 1: HMCCURPCPROC [d_rpc001004BidCos_RF] RPC server CB2001001002001004 stopped handling connections. PID=1972 run=-1
2024.12.23 11:26:44 1: HMCCURPCPROC [d_rpc001004BidCos_RF] Parent process (FHEM,PID=1724) not running. Shutting down RPC server process CB2001001002001004.
2024.12.23 11:26:44 1: HMCCURPCPROC [d_rpc001004BidCos_RF] Deregistering RPC server http://192.168.1.2:7411/fh2001 with ID CB2001001002001004 at http://192.168.1.4:2001
2024.12.23 11:26:44 1: HMCCURPCPROC [d_rpc001004BidCos_RF] FHEM will be restarted automatically if restart is enabled in system.d configuration.

Hat mir bitte jemand einen Tip was ich falsch mache - vielen Dank vorab !!
Schöne Feiertage,
Gruß,
Rolf
System 1: Intel NUC (ubuntu 18.04.1 lts) mit diversen Homematic-Komponenten + CUNO mit Uniroll/Hoermann + RFXTRX mit TFA + EnOcean mit Eltako + Alexa + Harmony + per HMCCU gekoppelter PI3-Raspberrymatic mit HM-IP-Komponenten
System 2: PI2-Raspberry (Jessie) + Signalduino mit Somfy/RTS

DS_Starter

Hallo Rolf,
Bin unterwegs, deshalb nur kurz.
Glaube nicht dass du etwas falsch gemacht hast.
Kann das Problem noch nicht genau identifizieren, denke aber es liegt im Umfeld der Perl oder der usr/share/perl5/DateTime/Format/Strptime.pm Version. Kannst du mir die Versionen dieser Komponenten mitteilen?
Unsere Community kann dich sicher dabei unterstützen.
Nach den Feiertagen kann ich mir das anschauen.

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

rolf

Zitat von: DS_Starter am 23 Dezember 2024, 13:10:20... Kannst du mir die Versionen dieser Komponenten mitteilen?
Unsere Community kann dich sicher dabei unterstützen.
Nach den Feiertagen kann ich mir das anschauen.

LG Heiko

Hallo Heiko,
danke für die schnelle Reaktion - es eilt nicht, ich freue mich wenn mich irgendwann nach den Feiertagen jemand unterstützt.
Als Betriebssystem arbeite ich mit einem Ubuntu 24.04.1 LTS (GNU/Linux 6.8.0-51) - perl ist laut apt install auf der neuesten Version 5.38.2-3.2build2 - aber die Datei usr/share/perl5/DateTime/Format/Strptime.pm ist vom 21.05.2021 und drin steht was von Version 1.79. Vermutlich also recht alt die usr/share/perl5/DateTime/Format/Strptime.pm - muss mich mal schlau machen wie man die aktualisieren kann...

Schöne Feiertage !,
Gruß,
Rolf
System 1: Intel NUC (ubuntu 18.04.1 lts) mit diversen Homematic-Komponenten + CUNO mit Uniroll/Hoermann + RFXTRX mit TFA + EnOcean mit Eltako + Alexa + Harmony + per HMCCU gekoppelter PI3-Raspberrymatic mit HM-IP-Komponenten
System 2: PI2-Raspberry (Jessie) + Signalduino mit Somfy/RTS

rolf

Zitat von: rolf am 23 Dezember 2024, 13:51:38
Zitat von: DS_Starter am 23 Dezember 2024, 13:10:20... Kannst du mir die Versionen dieser Komponenten mitteilen?
Unsere Community kann dich sicher dabei unterstützen.
Nach den Feiertagen kann ich mir das anschauen.

LG Heiko

Hallo Heiko,
und gerade eben konnte ich das Problem lösen - dein Modul läuft jetzt.
Das Problem war tatsächlich ein "Mischmasch" der CPAN-Module - nachdem das korrigiert war, läuft das Ganze.
Danke nochmal für den entscheidenden Tip mit der strptime.pm !

Gruß,
Rolf
System 1: Intel NUC (ubuntu 18.04.1 lts) mit diversen Homematic-Komponenten + CUNO mit Uniroll/Hoermann + RFXTRX mit TFA + EnOcean mit Eltako + Alexa + Harmony + per HMCCU gekoppelter PI3-Raspberrymatic mit HM-IP-Komponenten
System 2: PI2-Raspberry (Jessie) + Signalduino mit Somfy/RTS

Tomk

Hallo Heiko, besten Dank für dein Engagement hier. Ich schaue mir das Modul jeden Tag mehrmals an und es macht großen Spaß zu optimieren...
Eine Frage habe ich jedoch zum Battery_OptimumTargetSoC: wenn ich es richtig verstanden habe, ist das Ziel die Batterie optimal zu laden um das Batterie Management zu unterstützen. Mein Anwendungsfall wäre ein anderer, da ich gerne den Batterie Soc zwecks Ersatzstromversorgung so hoch wie möglich halten möchte. Kann man den optimalen Min soc auf Basis der Prognose für Ertrag und Verbrauch zu einem Zeitpunkt errechnen, sodass ich damit den Wechselrichter (Batterie-Entladungsgrenze) dynamisch konfigurieren kann. Also z.b.: Ertrag morgen 20Kwh, Verbrauch 10kwh, Batterie 10kwh = dann MinSoc auf 10% da die Batterie wieder geladen werden sollte. Wenn nur 10kwh Ertrag prognostiziert werden sollte der soc auf zb. 80% bleiben. Damit hätte man etwas Luft zum Puffern aber die max Ersatzstrom Kapazität. Das timing der Berechnung wäre zu wählen das auch entsprechend ausreichend Ladung in der Batterie ist, also nicht zu früh bzw. zu spät.

Oder ist das schon so ähnlich über Battery_OptimumTargetSoC abgedeckt?
Nochmals besten dank und weiter so 👍
Gruß Tom

rolf

Hallo Heiko,
hab mich mit deinem Modul beschäftigt - bin begeistert - wirklich super !
Bin am Definieren meiner "consumer" die bei PV-Überschuss geschaltet werden sollen und bräuchte da einen Denkanstoss. Bei mir steht ein E3DC-Speicher mit einer ACTHOR-Heizstabsteuerung die so funktioniert das jeglicher potentieller PV-Überschuss stufenlos geregelt in Heizstäbe geleitet wird, eben exakt so gesteuert das Netzeinspeisung unterbunden wird. Das führt aus Sicht vom Modul natürlich dazu das nie PV-Überschuss existiert - geht ja sofort in die Heizstäbe. Meine anderen "consumer" sollten aber Vorrang vor den Heizstäben haben. Die ACTHOR-Heizstabsteuerung liefert Werte - ist es der richtige Ansatz den ACTHOR im Modul als nicht schaltbaren Verbraucher zu definieren und falls irgendwie möglich mit niederer Priorität als die anderen consumer.
Danke vorab für einen Tip !
Gruß,
Rolf
System 1: Intel NUC (ubuntu 18.04.1 lts) mit diversen Homematic-Komponenten + CUNO mit Uniroll/Hoermann + RFXTRX mit TFA + EnOcean mit Eltako + Alexa + Harmony + per HMCCU gekoppelter PI3-Raspberrymatic mit HM-IP-Komponenten
System 2: PI2-Raspberry (Jessie) + Signalduino mit Somfy/RTS

DS_Starter

Guten Morgen,

Bin noch unterwegs, deswegen kurz.

@Tom,
das kannst du mit dem upSoC regeln. Wenn du den Schlüssel z.B. auf 80 setzt, wird das Modul den Min SoC stark angelehnt an die Prognose bestimmen. Bei sehr wenig Erzeugungungsprognose, d.h. wenn der berechnete Min SoC sich oberhalb von upSoC bewegt, wird upSoC eingestellt. Landet die Berechnung unterhalb von upSoC (und werden weitere Bedingungen nicht verletzt) wird der berechnete SOC im Reading eingestellt. Werde ich im Wiki noch ergänzen.

@Rolf,
da muß ich erstmal drüber nachdenken.
Welche Werte liefert denn der Heizstab?

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

rolf

Zitat von: DS_Starter am 26 Dezember 2024, 09:38:32@Rolf,
da muß ich erstmal drüber nachdenken.
Welche Werte liefert denn der Heizstab?

LG,
Heiko

Hallo Heiko,
ebenfalls guten Morgen !
An den ACTHOR9S (so heist das Steuergerät von myPV) sind bei mir 2 stufenlos regelbare Heizstäbe mit jeweils bis zu 3KW Leistungsaufnahme angeschlossen. Die Information welchen Überschuss es gerade gibt holt er sich direkt per MODBUS-Verbindung von meiner E3DC und regelt entsprechend die Heizstäbe hoch. Das Gerät unterstützt bis zu 3 Heizstäbe. Auslesen der Werte läuft bei mir per HTTPMOD - neben vielen anderen Infos liefert der ACTHOR:
- die aktuelle Leistung pro Heizstab in W
- die Energie pro Heizstab in W
- die Leistung für alle Heizstäbe in W
- die Energie für alle Heizstäbe in W
und und und....
Gerne liefere ich Dir auch die komplette Device....
Gruß,
Rolf
System 1: Intel NUC (ubuntu 18.04.1 lts) mit diversen Homematic-Komponenten + CUNO mit Uniroll/Hoermann + RFXTRX mit TFA + EnOcean mit Eltako + Alexa + Harmony + per HMCCU gekoppelter PI3-Raspberrymatic mit HM-IP-Komponenten
System 2: PI2-Raspberry (Jessie) + Signalduino mit Somfy/RTS

DS_Starter

Das heißt die E3DC ermittelt ihrerseits permanent den Hausverbrauch und dementsprechend den kalkulierten Überschuß?
Kannst du diesen Überschuß mit FHEM auslesen?
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

rolf

Zitat von: DS_Starter am 26 Dezember 2024, 10:06:48Das heißt die E3DC ermittelt ihrerseits permanent den Hausverbrauch und dementsprechend den kalkulierten Überschuß?
Kannst du diesen Überschuß mit FHEM auslesen?
Ja, das ist kein Thema - ich lese die E3DC mit Modbus aus und bekomme so tausende von Infos, auch den Wert was se einspeisen will - zählt man den Wert und den aktuellen Wert den der ACTHOR9S abnimmt zusammen, dann hat man den kompletten Überschuss.
System 1: Intel NUC (ubuntu 18.04.1 lts) mit diversen Homematic-Komponenten + CUNO mit Uniroll/Hoermann + RFXTRX mit TFA + EnOcean mit Eltako + Alexa + Harmony + per HMCCU gekoppelter PI3-Raspberrymatic mit HM-IP-Komponenten
System 2: PI2-Raspberry (Jessie) + Signalduino mit Somfy/RTS

DS_Starter

@Rolf, das sieht doch gut aus.
Problem ist, dass wir in deinem Fall 2 Regelkreise haben die nichts voneinander wissen.
Die noch nicht veröffentlichte Weiterentwicklung in #1395 könnte hier helfen.
Im Prinzip den Überschuß der E3DC zzgl. Des Wertes der ACTHOR9S zzgl. Eines evtl. Sicherheitszuschlags in ein Userreading bringen und dieses Userreading dem Verbraucherattribut im SF Schlüssel surpmeth mitteilen.

Bin jetzt ein paar Stunden unterwegs. Kannst ja mal drüber nachdenken. Ggf. hat TheTrumpeter schon erste Erfahrungen damit gesammelt.

LG
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

rolf

Zitat von: DS_Starter am 26 Dezember 2024, 11:35:04@Rolf, das sieht doch gut aus.
Problem ist, dass wir in deinem Fall 2 Regelkreise haben die nichts voneinander wissen.
Die noch nicht veröffentlichte Weiterentwicklung in #1395 könnte hier helfen.
Im Prinzip den Überschuß der E3DC zzgl. Des Wertes der ACTHOR9S zzgl. Eines evtl. Sicherheitszuschlags in ein Userreading bringen und dieses Userreading dem Verbraucherattribut im SF Schlüssel surpmeth mitteilen.

Bin jetzt ein paar Stunden unterwegs. Kannst ja mal drüber nachdenken. Ggf. hat TheTrumpeter schon erste Erfahrungen damit gesammelt.

LG

Hallo, danke erst Mal für den Tip - hab deine aktuelle Version aus dem contrib in mein FHEM geholt, neu gestartet, das entsprechende Reading generiert und jetzt mal einen "consumer" so definiert. Jetzt mal schauen was passiert, wenn das Wetter so bleibt dann könnte es eventuell sogar tatsächlich noch mit PV-Überschuss was werden ;-)
Gruß,
Rolf

So - hab jetzt einiges getestet und dein o.g. Tip scheint recht gut zu funktionieren - vielen Dank !
System 1: Intel NUC (ubuntu 18.04.1 lts) mit diversen Homematic-Komponenten + CUNO mit Uniroll/Hoermann + RFXTRX mit TFA + EnOcean mit Eltako + Alexa + Harmony + per HMCCU gekoppelter PI3-Raspberrymatic mit HM-IP-Komponenten
System 2: PI2-Raspberry (Jessie) + Signalduino mit Somfy/RTS