76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

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

Vorheriges Thema - Nächstes Thema

TheTrumpeter

Wäre es möglich die optionalen Verbraucher und ev. auch die mit Unterbrechungsmöglichkeit so umzustellen, dass anstelle des momentanen Überschusses ein gemittelter Wert für Start/Abbruch/Unterbrechung verwendet wird? (Den Mittelwert könnte man dann im MeterDev selbst bilden, ich habe z.B. 2- und 5-min Mittelwerte, die ich für das Beenden der WW-Erzeugung abhängig von der Speichertemperatur oder der Kühlung verwende.)

Wenn beispielsweise ein ständig taktender Verbraucher läuft (z.B. Backrohr), führt die aktuelle Implementierung zu einem eher zufälligen Ein- und Ausschalten von optionalen Verbrauchern. Ähnliches passiert durch kurze Verbrauchsspitzen.

(Mittels swoncond könnte das auch umgangen werden, aber nur bei solchen Verbrauchern, wo die swoncond ansonsten nicht benötigt wird.)
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

ZitatWäre es möglich die optionalen Verbraucher und ev. auch die mit Unterbrechungsmöglichkeit so umzustellen, dass anstelle des momentanen Überschusses ein gemittelter Wert für Start/Abbruch/Unterbrechung verwendet wird?
Ich verstehe das Problem. Für andere Zwecke führe ich im Modul (valCurrent -> genslidereg  bzw. h4fcslidereg) Register mit die jeweils den Wert der letzten 3 Messungen PV-Erzeugung bzw. 4h PV Forecast für eine Durchschnittsberechnung beinhalten.

Ein solches Register könnte ich auch für den PV-Überschuß führen. Dann könnte die Schaltbedingung für Start/Abbruch/Unterbrechung etc. abgeleitet werden, wenn der Durchschnitt der letzten 3 Ermittlungen über oder unter einem Schwellenwert liegt.
Einziges Manko was ich momentan sehe ist, dass die Abstände der Ermittlungen abhängig sind vom eingestellten ctrlInterval, wobei der Meter/Inverter in der aktuellen Modulversion auch asynchron eingestellt werden kann und dadurch der Zyklus, sowie die Berechnung, bei jedem Meter/Inverter-Event durchlaufen wird. Die Anzahl der Messungen für den Durchschnitt kann ich frei festlegen, tendiere so zwischen 3 und 6. Sie sind dann aber fest und nicht für jeden Consumer individuell festlegbar, wobei mit etwas weiteren Aufwand auch das umsetzbar wäre. Ich würde aber erstmal nur den Standard nehmen.

Die Unterscheidung, ob der Verbraucher über einen Durchschnittswert oder wie bisher durch direkte Messung geschaltet werden soll, könnte der User per Verbraucher-type steuern. Dazu müsste ich nur einen weiteren Typ, z.B. Pacemaker (Schrittmacher), einführen.

Das würde doch deinen Use Case abbilden wenn dich richtig verstanden habe?
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 16 Dezember 2024, 20:07:26Durchschnitt der letzten 3 Ermittlungen
Zitat von: DS_Starter am 16 Dezember 2024, 20:07:26Die Anzahl der Messungen für den Durchschnitt kann ich frei festlegen, tendiere so zwischen 3 und 6.
Zitat von: DS_Starter am 16 Dezember 2024, 20:07:26fest und nicht für jeden Consumer individuell festlegbar
Damit hätte ich nix gewonnen, wenn ich bei "asynchron=1" für Inverter- und MeterDev bleibe. Das Abfrageintervall beträgt 5 Sekunden. (Events treten zwar wg. event-on-change-reading-Einstellungen nur bei dynamischen Änderungen auf, aber genau das wäre in dem betrachteten Anwendungsfall auch gegeben.)
Damit würde beispielsweise das Öffnen/Schließen des Garagentors den ggf. laufenden Luftentfeuchter bereits unterbrechen.


Zitat von: DS_Starter am 16 Dezember 2024, 20:07:26Das würde doch deinen Use Case abbilden wenn dich richtig verstanden habe?
Vielleicht stelle ich es mir zu einfach vor, aber könnte nicht beispielsweise im MeterDev ein zusätzlicher Parameter eingeführt werden, mit dem ein (vom User beliebig konfigurierter) Durchschnittswert eingelesen wird, beispielsweise "gconavrg=[reading]" (z.B. gconavrg=activepoweroffset_5min:W) und "gfeedavrg=-gconavrg".
Im ConsumerDev kann dann mittels zusätzlichem Schalter ausgewählt werden, ob auf den aktuellen oder Durchschnittswert reagiert wird, beispielsweise "swtavrg" mit "0" für "aktuelle Logik" und "1" für Durchschnittswert.

Damit könnte alles wie bisher bleiben, nur bei den consumer-abhängigen Berechnungen wird auf einen anderen Verbrauchswert geschaut.
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

#1383
ZitatDamit hätte ich nix gewonnen, wenn ich bei "asynchron=1" für Inverter- und MeterDev bleibe. Das Abfrageintervall beträgt 5 Sekunden. (Events treten zwar wg. event-on-change-reading-Einstellungen nur bei dynamischen Änderungen auf, aber genau das wäre in dem betrachteten Anwendungsfall auch gegeben.)
Für mein/unser Verständnis.
Wenn das MeterDev alle 5 Sec Werte liefert und der Durchschnitt des Überschusses über z.B. 10 Messungen gemittelt werden soll, dann würde der Grenzwert mindestens 50 Sec lang unter/überschritten sein müssen um eine Reaktion hervorzurufen. Ist das nicht ausreichend?

Wenn nötig könnte ich wie beschrieben mit entsprechenden Aufwand die Avg-Möglichkeit für jeden Consumer einzeln einstellbar gestalten und über einen Schlüssel im Consumerdev festlegen lassen, wieviele Messwerte eingehen sollen. Zum Beispiel avg=1 (bzw. nicht gesetzt) für den aktuellen Wert (wie jetzt) oder avg=2..10 für X Messwerte. 10 wäre max. oder ein anderer zentral festgelegter Wert.

Es geht dabei übrigens nicht nur um die Werte des MeterDev (Einspeisung/Verbrauch) sondern um den Überschuß, es gehen also auch noch Werte der PV-Erzeugung, anderer Erzeuger und der zuvor berechnete aktuelle Verbrauch unter Berücksichtigung von Batterie-In/Out ein.
All das zusammen UND zusätzlich der Auswertung im Consumer gesetzter Parameter bezüglich der evtl. Ignorierung des Überschusses erfolgt die Generierung des valConsumerMaster->isConsumptionRecommended.

Dieser Wert ist für die Entscheidung der Consumeraktivitäten zuständig, ganz so einfach ist es also nicht.
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 17 Dezember 2024, 10:41:2810 Messungen
Ja das geht dann schon eher in die Richtung... mit den ursprünglich genannten 3-6 wär's definitiv zu wenig gewesen.

Trotzdem würd' ein kurzer hoher Peak zum Ausschalten führen, und zwar zu einem Zeitpunkt, wo der Peak schon wieder vorbei ist. Es gibt wohl keine allgemein gültige Lösung für das Problem, drum würd' mir persönlich ein "individueller Mittelwert" besser gefallen als etwas, das im Modul vorgegeben ist.
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

Die Anzahl der Messungen war erstmal eine Arbeitsgröße. Ich kann den möglichen Bereich auch bis 20 ziehen.
Irgendwo muß halt der Max sein.

ZitatEs gibt wohl keine allgemein gültige Lösung für das Problem, drum würd' mir persönlich ein "individueller Mittelwert" besser gefallen
Allerdings ermittelst du nicht den Überschuß, sondern nur den Meter In/Out.

Wie dem auch sei, du könntest neben dem Key swoncond/swoffcond (wenn die schon benutzt sind) auch den Key auto verwenden und bei Vorliegen einer Verbrauchsspitze in deinem Meterdev oder dem Reading Current_Consumption das automatische Schalten verbieten respektive wieder freigeben.

Auch eine Möglichkeit.

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

tobi01001

Zitat von: TheTrumpeter am 17 Dezember 2024, 12:15:18Es gibt wohl keine allgemein gültige Lösung für das Problem, drum würd' mir persönlich ein "individueller Mittelwert" besser gefallen als etwas, das im Modul vorgegeben ist.
Ich habe bei der Wärmepumpe ein ähnliches Problem. Das mache ich auch individuell, weil das Modul nicht alle Eventualitäten abdecken kann.

Aktuell schalte ich die nicht von Solarforecast aus sondern berechne mir den Überschuss und Schaltpunkte selbst.
Dafür summiere ich z.B. "secondary" consumers (unwichtige Verbraucher) auf und errechne einen gleitenden/gewichteten Mittelwert über 15 Werte.

Das Buget für die Wäremepumpe errechnet sich dann aus
"Momentanleistung PV" - ("Momentanleistung Verbrauch Haus" - ("Momentanleistung Wärmepumpe" + "Momentanleistung Secondary Consumers"))

Wenn das Budget einen gewissen Grenzwert (aktuell 500 W - auch gemittelt) überschreitet (und ein paar andere Bedingugnen zutreffen), wird der PV-Start der Wärmepumpe aktiviert.

Die Secondary Consumers haben somit keinen Einfluss auf das Budget der Wärmepumpe. Im Gegenteil, teilweise sind sie als "can" in Solarforecast bzw nutze ich das Reading pvStartRecommended um die dann noch wegzuschalten.

Durch die Mittelwerte (und wait timer) wird auch ein nicht gemessenes Gerät wie ein Wasserkocher den PV-Start nicht deaktivieren (zumal da noch mehr Bedingungen dran hängen).

Wird halt schnell etwas komplexer...
FHEM@UbuntuServer on Lenovo ThinkCentre M900 [i5-6500T / 8GB RAM] MySQL-DbLog, Grafana, FTUI3 / HmIP incl. CCU3 / LGESS / Wärempumpe über TA CMI und CANoE / Shellies u.v.m.

kask

ZitatWenn das MeterDev alle 5 Sec Werte liefert und der Durchschnitt des Überschusses über z.B. 10 Messungen gemittelt werden soll, dann würde der Grenzwert mindestens 50 Sec lang unter/überschritten sein müssen um eine Reaktion hervorzurufen. Ist das nicht ausreichend?

Das ist so aber nicht ganz richtig. Wir nehmen an das wir 10 als trigger nehmen. Wenn 9mal eine 9 drin ist und dann eine 19 kommt. Dann hätte ich in diesen Moment 10 als Durchschnitt.
Und im nächsten Zug kommt eine 8 dann wäre ich nach 5sec. auf <10. Und nicht nach 50. Ganz so einfach ist es ja nun doch nicht. Das kann aber bei jedem Durschnitt passieren. Es sei denn man aktualisiert denn Wert nur nach z.b. 50sec. Dann wäre es aber nicht fliessend.

Dann würde es aber auch nicht mehr passen bei erste Wert gebildet aus: 9,9,9,9,9,9,9,9,9,18 = <10, nachfolgende Werte: 18,17,16,4,5,3,2,1,8,7 = <10. Hätte man das jetzt zeitlich um 3 messwerte später gestartet wäre der Triggerpunkt erreicht gewesen. 9,9,9,9,9,9,18,18,17,16 =  > 10.

Einen selbst gebauten Wert bzw. auswähbaren Wert halte ich da auch wirklich für Sinnvoller. Vieleicht will man einen richtigen Fliesswert/gleitenden Mittelwert bilden.

DS_Starter

@kask, da hast du natürlich Recht.  :)

ZitatEinen selbst gebauten Wert bzw. auswähbaren Wert halte ich da auch wirklich für Sinnvoller. Vieleicht will man einen richtigen Fliesswert/gleitenden Mittelwert bilden.
Ja, kann man machen und in den Schlüsseln swoncond, swoffcond oder auto anwenden.
Wären aus deiner/eurer Sicht noch weitere Möglichkeiten nötig bzw. sinnvoll?
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

@TheTrumpeter,
ich habe über diese These nochmal nachgedacht:
ZitatTrotzdem würd' ein kurzer hoher Peak zum Ausschalten führen, und zwar zu einem Zeitpunkt, wo der Peak schon wieder vorbei ist.
Ich würde das nicht pauschal unterschreiben. Als Beispiel gäbe es 10 Ermittlungen des Überschusses. 9 mal wäre der Überschuß 1500 W. Einmal kommt ein gemessener Peak von 4000W Verbrauch vor was zu einem ermittelten Überschuß von 0 führen würde.

Bei einer Durchschnittsermittlung des Überschusses im Schieberegister würde es sich so darstellen:

( 1500 + 1500 + 1500 + 1500 + 1500 + 0 + 1500 + 1500 + 1500 + 1500 ) = 13500 / 10 = 1350 W


Beim Peak ist der Überschuß = 0.

Hat der zu schaltende Verbraucher eine nominale Leistungsaufnahme von < 1350 W wäre die Überschußbedingung weiterhin erfüllt und würde keine Ausschaltaktion bedingen. Auch ein Peak von z.B. 10000W Verbrauch würde in dem Beispiel auch nur ein Überschuß 0 ergeben.
Das nur zur Erläuterung.
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

#1390
Noch etwas weiter gedacht ...

Die Consumer könnten einen optionalen Key zur Bestimmung des PV-Überschusses mit folgenden Optionen bekommen:

surplus=1..20
surplus=<Device>:<Reading>

surplus=1..20 -> die interne PV-Überschußrechnung wird verwendet, 1 - Verwendung aktuell gemessener Überschuß, 2..20 - der Durchschnitt der letzten 2 .. 20 Ermittlungen wird verwendet

surplus=<Device>:<Reading> -> die angegebene Device/Reading Kombi stellt den PV-Überschuß zur Verfügung (kann eine User-Berechnung des PVÜ enthalten)

Damit hätte der User alle Freiheiten. Er müsste natürlich an dieser Stelle einen Wert des PV-Überschusses zur Verfügung stellen. Die relevanten Aktivitäten der Consumer werden vom PV-Überschuß und angrenzenden Bedingungen abgeleitet.   

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 17 Dezember 2024, 21:41:08surplus=<Device>:<Reading> -> die angegebene Device/Reading Kombi stellt den PV-Überschuß zur Verfügung (kann eine User-Berechnung des PVÜ enthalten)
Ja das geht im Prinzip genau in die Richtung, die mir vorschwebt. Wie muss das Reading aussehen? Kann da eine vorzeichenbehaftete Größe verwendet werden? ("activepoweroffset" stellen meines Wissens nach alle in Österreich gebräuchlichen SmartMeter direkt zur Verfügung, der Wert ist negativ bei Einspeisung und positiv bei Netzbezug.) Falls der Wert immer >= 0 sein muss, kann ich den Mittelwert einfach per Userreading noch entsprechend formatieren.



Zitat von: tobi01001 am 17 Dezember 2024, 16:23:33Aktuell schalte ich die nicht von Solarforecast aus sondern berechne mir den Überschuss und Schaltpunkte selbst.
Das mache ich für die WW-Bereitung und Kühlung ähnlich. Allerdings verwende ich nur den Mittelwert des Netzbezugs als Schaltgröße. WW wird ab einer bestimmten Speichertemperatur abgebrochen, sobald der gemittelte Netzbezug der letzten 5 Minuten einen bestimmten Wert überschreitet. Bei der Kühlfunktion mache ich es ähnlich, wobei da auch die erneute Freigabe abhängig vom gemittelten Netzbezug (bzw. Einspeisung) erteilt wird.
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

Guten Morgen,

ZitatWie muss das Reading aussehen? Kann da eine vorzeichenbehaftete Größe verwendet werden?
Das Reading muß den (realen, Mittelwert oder anders geglätteten) PV-Überschuß darstellen. Alle numerischen Werte >0 würde ich als Überschuß interpretieren, alles <=0 als kein Überschuß bzw. Überschuß=0.

Insofern kann das Reading auch negative Werte enthalten, der PVÜ wäre in diesen Fällen immer 0.

Dein Meter stellt ja nur In/Out zur Verfügung. Dabei kann die Einspeisung mit einem aktuellen Überschuß unter Umständen gleichgesetzt werden. Hast du noch eine Batterie die geladen wird, dann "sieht" der Meter diesen Anteil nicht denn der Überschuß geht ja als Ladeenergie in die Batterie.
Muß man also konkret schauen wie die Dinge bei dir liegen.
Aber da du ohnehin Mittelwerte berechnen willst, kannst du das Userreading wie dann in der Hilfe vorgegeben erstellen.
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 17 Dezember 2024, 20:20:04@kask, da hast du natürlich Recht.  :)

ZitatEinen selbst gebauten Wert bzw. auswähbaren Wert halte ich da auch wirklich für Sinnvoller. Vieleicht will man einen richtigen Fliesswert/gleitenden Mittelwert bilden.
Ja, kann man machen und in den Schlüsseln swoncond, swoffcond oder auto anwenden.
Wären aus deiner/eurer Sicht noch weitere Möglichkeiten nötig bzw. sinnvoll?

Meinerseits bin ich auch der Meinung, dass Mittelwerte (besser wäre aber wahrscheinlich ein Median) via User-Readings einfließen sollten, da das Modul andernfalls immer komplexer und damit auch immer schwerer zu warten wird.

Andere Dinge hingegen, wie z.B. die Integration von mehr als einem Speicher, lassen sich nicht extern erledigen und sollten sinnvollerweise in das Modul einfließen.
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.59) und 7591 (8.02) - Goodwe: GW25K-ET (DSP V8 / ARM V9) - BYD: 2 x HVS 5.1 (BMS V3.29-A, BMU V3.23-A) - EnOcean - Z-Wave - FS20/HMS

DS_Starter

Der von mir in #1390 skizzierte Ansatz würde dem User die gewünschte Freiheit bieten und den würde ich auch einbauen.
Modulintern bleibt es dann bei der einfachen PVÜ Nutzung bzw. dem einfachen Durchschnitt über X Werte oder vllt. auch Median wie von dir vorgeschlagen was auch recht einfach intern umsetzbar wäre.
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