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

#600
@All,

in meinem contrib liegt eine neue V 1.21.0.
Ich habe die Anregung von pah umgesetzt, dass der Energy Meter (currentMeterDev) bezüglich der Schüssel contotal und feedtotal einen Tageszähler anbieten kann.
Das bedeutet das Modul behandelt einen Reset dieser Readings am Tagesanfang zu "0" entsprechend.

Auszug aus der ComRef:

currentMeterDev <Meter Device Name> gcon=<Readingname>:<Einheit> contotal=<Readingname>:<Einheit> gfeedin=<Readingname>:<Einheit> feedtotal=<Readingname>:<Einheit> [conprice=<Feld>] [feedprice=<Feld>]

Legt ein beliebiges Device und seine Readings zur Energiemessung fest. Das Modul geht davon aus, dass der numerische Wert der Readings positiv ist. Es kann auch ein Dummy Device mit entsprechenden Readings sein. Die Bedeutung des jeweiligen "Readingname" ist:

    gcon    Reading welches die aktuell aus dem Netz bezogene Leistung liefert
    contotal    Reading welches die Summe der aus dem Netz bezogenen Energie liefert (ein sich stetig erhöhender Zähler)
                    Wird der Zähler zu Beginn des Tages auf '0' zurückgesetzt (Tageszähler), kann dieses Reading verwendet werden.
                    In diesem Fall erfolgt eine Meldung im Log mit verbose 3.
    gfeedin    Reading welches die aktuell in das Netz eingespeiste Leistung liefert
    feedtotal    Reading welches die Summe der in das Netz eingespeisten Energie liefert (ein sich stetig erhöhender Zähler)
                    Wird der Zähler zu Beginn des Tages auf '0' zurückgesetzt (Tageszähler), kann dieses Reading verwendet werden.
                    In diesem Fall erfolgt eine Meldung im Log mit verbose 3.
.....

Die Version soll erst noch ein wenig im Test laufen bevor sie ins Repo wandert um sicher zu gehen keine Nebenwirkungen eingefangen zu haben. Bis jetzt läuft sie bei mir einwandfrei.

LG

ESXi@NUC+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 15 Mai 2024, 10:47:30Naja, mit wollen hat es nichts zu tun. Die nachgerüstete Victron-Anlage bzw. das Meßkonzept ist beim Netzbetreiber als Nulleinspeiseanlage registriert. Dadurch bleibt meine (parallele) Altanlage mit Überschußeinspeisung bzw. deren noch gute Einspeisevergütung unberührt.
Wie wird das technisch realisiert? Hat die Victron-Anlage einen eigenen (Sub-) Zähler, an dem der Netzbetreiber feststellen kann woher der eingespeiste Strom kommt?
Wenn beides hinter dem gleichen Hausstromzähler hängt, kann man ja unmöglich nachvollziehen von welcher Anlage der eingespeiste Strom erzeugt wurde. (Natürlich nur in einem physikalisch nachvollziehbaren Rahmen... wenn Du mehr einspeist als die Altanlage insgesamt bringt, wird's unplausibel.)
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

ZitatWie wird das technisch realisiert? Hat die Victron-Anlage einen eigenen (Sub-) Zähler, an dem der Netzbetreiber feststellen kann woher der eingespeiste Strom kommt?
Die Victron-Anlage hat einen eigenen Zähler. Sobald dieser Zähler eine Einspeisung misst, regelt Victron ab. D.h. das Hausnetz wird versorgt, das öffentliche Netz nicht. Victron hat dafür einen eigenen Steuerungssatz (ESS) der in das Controlgerät (CerboGX) geladen wird.
ESXi@NUC+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 15 Mai 2024, 12:56:08Die Victron-Anlage hat einen eigenen Zähler. Sobald dieser Zähler eine Einspeisung misst, regelt Victron ab. D.h. das Hausnetz wird versorgt, das öffentliche Netz nicht. Victron hat dafür einen eigenen Steuerungssatz (ESS) der in das Controlgerät (CerboGX) geladen wird.
Mit sowas habe ich gerechnet, aber das spielt sich doch alles hinter dem offiziellen Zähler statt, oder?
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

ESXi@NUC+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

@pah, zu deinem zweiten Anstrich:

Zitat2. Waschmaschinen sind durchaus Großverbraucher, und die meisten laufen inzwischen ziemlich lange. Ein weiterer wichtiger Faktor
ist die Wäschetrockung (nicht im Trockner, sondern auf der Leine). Es nutzt zwar möglicherweise der Stromrechnung, wenn die
Waschmaschine nachmittags um 17:00 fertig ist - aber trocken wird das dann nicht mehr. Ich habe keine Möglichkeit gefunden,
eine "Fertig-Zeitangabe" für einen Consumer festzulegen.
Im Prinzip kann man eine definierte Endezeit bereits jetzt indirekt festlegen durch eine Kombination aus power, mintime, notafter.

Also z.B.:
attr ... consumerXX <Device Name> type=washingmachine power=0 mintime=120 notafter=10:00 ...


Bei der Definition würde die Waschaschine spätestens 10:00 für max. 2h loslaufen. Sie wäre also spätestens 12:00 fertig.
Das ist doch was du haben wolltest oder doch noch etwas anders?

LG,
Heiko
ESXi@NUC+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

Die neue Version ist eingecheckt. Ich habe keine unerwünschten Nebenwirkungen festgestellt.
ESXi@NUC+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

Hallo zusammen,

ich habe die aktuelle Entwicklungsversion von DWD_OpenData in mein contrib geladen. Wer dieses Wettermodul benutzt kann/sollte diese V nutzen. Mumpitzstuff hat den Speicherverbrauch optimiert.
Siehe dazu den DWD-Thread: https://forum.fhem.de/index.php?msg=1313448

schöne Pfingsten,

LG,
Heiko
ESXi@NUC+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

kask

Ist das gewollt das der Link oben auf deinen Post abfeuert? Du erwähnst Mumpitzstuff aber ich habe jetzt mal gesucht und ich finde nix über die Speicheroptimierung da von Ihm.
Oder habt Ihr das privat geklärt?

Hätte mich schon interressiert was da optimiert wurde und wie. Könnte ja auch für andere Sachen für mich interessant sein.

DS_Starter

Mumpitzstuff hat es in dem Thread nicht genau beschrieben was er alles geändert hat. Ich habe mir die Details auch nicht angeschaut.
Seinen Originalpost findest du hier:
https://forum.fhem.de/index.php?msg=1307533

Um die Änderungen nachzuvollziehen, kannst du dir die Unterschiede zwischen den DWD Versionen in meinem contrib genauer anschauen.
ESXi@NUC+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

kask

Ich sollte mal mit dem optimieren der Anlagen aufhören.
Wenn das so weiter geht verdient ja keiner mehr geld an mir ;)

Neh, mal im ernst wie kann ich eine negative Consumption haben?
Vermutlich ist da in der Historie letzten Monat mal was schief gelaufen. Sollte vieleicht abgefragt werden das es nicht kleiner 0 sein kann.
Das ist doch was seit dem 14ten nicht i.O immer zur 16ten Stunde. Ich bin ratlos. Einer eine Idee?

Edit: die -923/-935 sind unterschiedlich weil es zwei verschiedene Instancen sind.
Ich habe 7 instancen (SolarForecast Devices) und alle haben das Problem um 16Uhr


kask

Danke für die Hilfe und das Grübeln ;)
Ich hatte letzte Woche Montag einen Umzug vom Raspberry auf einen amd64 system mit proxmox und debian.
Da hatte ich das Backup vom 12ten..also 13ten um 00:XX eingespielt.
Mittags gegen 16Uhr kamen dann wieder Werte rein im Zuge des portierens.
Beim nächsten mal sollte ich, wenn alles geht, wieder mit dem Backup starten.
Doof gelaufen!


DS_Starter

Boah, jetzt hatte ich mich schon angestrengt. Dann schreibe ich es jetzt auch noch ;)


Die Consumption (der jeweiligen Stunde) errechnet sich aus:

Hausverbrauch = Erzeugung - Einspeisung + Netzbezug - Bat-In + Bat-Out

Der Forecast ist dann der Durchschnitt der jeweiligen Stunde über die vorhandenen Tage.
An der obigen Formel siehst du, falls z.B. für Bat-In ein unverhältnismäßiger (zu großer/falscher) Wert gemessen bzw. übermittelt wurde, kann der Hausverbrauch negativ werden.

Ich könnte natürlich auf 0 begrenzen. Allerdings sieht man dann nicht mehr falls etwas falsch gelaufen ist.
Und da es die Ausnahme ist bzw. sein sollte, ist es wohl besser ihn zu sehen.
ESXi@NUC+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

kask

Jepp, ist besser es zu sehen um Unstimmigkeiten eventuell bei großer abweichung schneller detektieren zu können.
Gefunden wo es klemmt hatte ich es mit dem ctrldebug "consumption" das war schon einmal sehr gut.
 

TheTrumpeter

Gibt es irgendeine Limitierung der Prognosewerte bei z.B. unplausibler/fehlender Vorhersage?

Mir fällt sporadisch auf, dass es in der Prognose einzelne Stunden mit Ertragsprognose "15 kW" gibt, die definitiv nicht erreicht werden können, weil meist eher am späteren Nachmittag gelegen. Die WR-Leistung ist auch mit 15 kW angegeben, daher sieht das für mich nach irgendeinem Ersatzwert aus. Oft "verschwinden" diese Unplausibilitäten nach einigen weiteren zyklischen Datenabrufen wieder und manchmal kommen sie auch plötzlich rein.

Ich hab' grad keinen Screenshot davon bzw. auch keine Daten, werd' aber versuchen es in den nächsten Tagen nachzureichen sobald ich es wieder sehe.
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