Photovoltaik Eigenverbrauch,Bilanz,Prognose (Kostal Plenticore; KSEM; BYD HV)

Begonnen von ch.eick, 07 Oktober 2020, 16:09:12

Vorheriges Thema - Nächstes Thema

MichaelO

Ok, danke für die Info. Leider muss ich dann für mich persönlich feststellen, dass ich den hier gezeigten Ansatz zwar grundsätzlich gut heiße, aber nicht weiter verfolgen werde, das ist mir zu viel - bitte nicht persönlich nehmen - "Raterei".

Zitat von: ch.eick am 12 Januar 2023, 09:23:27
[...]
Du schießt mit Kanone auf Spatzen :-)
[...]
Ich freue mich aber auf Deine überarbeitete Version.
Das widerspricht sich leider. Der auf wissenschaftlich fundierten Erkenntnissen basierte vorgestellte Ansatz der Ermittlung der Modultemperatur mit einer einfachen Formel und einem vom vorhandenen Dienst bereitgestellten weiteren Wert wird als "auf Spatzen schießen" bezeichnet, während Du dich ansonsten auf meine überarbeitete Version freust. Einen Vergleich der Prognosen zwischen den unterschiedlichen Temperaturermittlungen werde ich nicht anstellen, da der Rest der Berechnungen aus meiner Sicht zu vage ist und somit keine Grundlage für Vergleiche bildet.

Aber wie gesagt, ist nicht persönlich, es geht um die Sache. Wenn genug Teilnehmer des Forums mit dem bisherigen Ansatz zufrieden sind, dann erfüllt er ja seinen Zweck. Sollte dennoch irgend jemand wissen, wie man aus dem Rad1h-Wert des DWD für den jeweiligen Ort auf die darin enthaltenen Anteile der Direkt- und Diffusstrahlung kommt, wäre ich dankbar, wenn dieses Wissen hier geteilt wird.

Mumpitz

Zitat von: MichaelO am 12 Januar 2023, 09:45:41

Aber wie gesagt, ist nicht persönlich, es geht um die Sache. Wenn genug Teilnehmer des Forums mit dem bisherigen Ansatz zufrieden sind, dann erfüllt er ja seinen Zweck. Sollte dennoch irgend jemand wissen, wie man aus dem Rad1h-Wert des DWD für den jeweiligen Ort auf die darin enthaltenen Anteile der Direkt- und Diffusstrahlung kommt, wäre ich dankbar, wenn dieses Wissen hier geteilt wird.

Ich arbeite seit bald 1.5 Jahren mit dem Ansatz von Christian und bin mehr als zufrieden damit. Die Prognose stimmt in den meisten Fällen sehr genau. Ich wüsste nicht warum die Werte genauer sein sollten, da ich damit ja keine direkten Schaltungen ausführe sondern nur entscheide, wie viel der Speicher geladen wird oder ähnliches.

Gruss aus der Schweiz :-)

ch.eick

Zitat von: Mumpitz am 12 Januar 2023, 11:52:46
Ich arbeite seit bald 1.5 Jahren mit dem Ansatz von Christian und bin mehr als zufrieden damit. Die Prognose stimmt in den meisten Fällen sehr genau. Ich wüsste nicht warum die Werte genauer sein sollten, da ich damit ja keine direkten Schaltungen ausführe sondern nur entscheide, wie viel der Speicher geladen wird oder ähnliches.

Gruss aus der Schweiz :-)
Hallo Reto,
ich schreibe noch offline mit Michael und möchte seine Korrekturen alle mit einarbeiten. Formel sind besser als Konfigurationsparameter, egal, ob das Ergebnis dadurch mehr an die realität kommt oder nicht. ich finde die Ideen grundlegend sehr gut und inovativ. Es wird also weiterhin noch viele Verbesserungen geben.
Ich entschuldige mich auch nochmal, wenn meine Anmerkungen abweisend gewirkt haben. Es war sehr stressig in der letzten Zeit, da viele Fragen über PN gekommen sind und ziemlich individuell waren.

VG   Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

MichaelO

Zitat von: ch.eick am 12 Januar 2023, 13:08:01
Ich entschuldige mich auch nochmal, wenn meine Anmerkungen abweisend gewirkt haben. Es war sehr stressig in der letzten Zeit, da viele Fragen über PN gekommen sind und ziemlich individuell waren.

Alles kein Problem, ich schrieb ja, das es nichts Persönliches ist. Vielleicht liege ich ja auch falsch, deswegen stellen wir ja hier unsere Ideen und Erkenntnisse zur Diskussion. Wenn es dann hinterher besser wird, ist doch jede Diskussion lohnenswert gewesen. Und wenn nicht, sind alle schlauer für die Zukunft  8)

ch.eick

Zitat von: kaiman am 11 Januar 2023, 07:54:42
Hier die Zeilen im StateFormat:

my $YearBefore      = "LogDBRep_Statistic_previous_Year";
my $YearPrevious    = POSIX::strftime("%Y",localtime(time_str2num(ReadingsTimestamp("$YearBefore","SW_Statistic_Yield_Year","null"))));

Im Bild die Daten aus der LogDBRep_Statistic_previous_Year

Okay, somit ist SW_Statistic_Yield_Year im LogDBRep_Statistic_previous_Year Device vorhanden und es sollte im stateFormat entsprechend berücksichtigt werden. Schick mir doch mal des stateFormat, ober besser ein komplettes List von dem WR_1_API Device als PN. Eventuell machst Du vorher noch einen Vergleich mit dem Wiki.

EDIT: Übrigens haben sich die reading Namen auf SW_* geändert.

VG  Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

MichaelO

Kurz zur Info. Nach langer Recherche habe ich tatsächlich eine Seite gefunden, die den Weg der Berechnung des Ertrags einer PV-Anlage aus der Globalstrahlung aufzeigt:

https://www.homerenergy.com/products/pro/docs/3.9/how_homer_calculates_the_pv_array_power_output.html

in Verbindung mit

https://www.homerenergy.com/products/pro/docs/3.9/how_homer_calculates_the_radiation_incident_on_the_pv_array.html

Nach Rücksprache mit Christian werde ich versuchen, das in die Prognose-Routine zu bringen, so dass man dann testen kann, ob dieser wissenschaftliche Ansatz genauere Werte liefert, als die bisherigen Versuche basierend auf empirischer Beobachtung. Falls ja, wäre es schön, falls nein zumindest eine gute Programmierübung gepaart mit Wissenszuwachs zum Thema Meteorologie  8)

kaiman

Zitat von: ch.eick am 12 Januar 2023, 13:18:49
Okay, somit ist SW_Statistic_Yield_Year im LogDBRep_Statistic_previous_Year Device vorhanden und es sollte im stateFormat entsprechend berücksichtigt werden. Schick mir doch mal des stateFormat, ober besser ein komplettes List von dem WR_1_API Device als PN. Eventuell machst Du vorher noch einen Vergleich mit dem Wiki.

EDIT: Übrigens haben sich die reading Namen auf SW_* geändert.

VG  Christian

Hast du meine PN mit dem List bekommen?

LG

ch.eick

RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

kaiman

oh sry, übersehen.

Gibt es eine "einfache" Möglichkeit, die reading im Namen auf SW_* umzubauen?

LG

jnewton957

Zitat von: ch.eick am 14 Januar 2022, 10:38:50

Bitte achtet darauf, dass die splitReading() Funktion in 99_myUtils aktualisiert wurde.


Ich lese mich gerade durch die ganzen Beiträge durch und wollte das LogDBRep_Statistic_previous_Quarter implementieren.

Aber ich finde im fhem die splitReading() Funktion für die 99_myUtils nicht.

Was habe ich übersehen?

Grüße
Jörg
FHEM6.2 auf Pi5
V 1.66 nanoCUL 433 (IT)
V 1.66 nanoCUL868 (HM)
sqlite3 LogDb
ELRO AB440, DECT200,  TFA30.3125, esp8266, HM, TabletUI, IR-Schreiblesekopf (Udo),tibber Pulse, Kostal Pico, cfos Wallbox, Modbus TCP

ch.eick

Zitat von: jnewton957 am 19 Januar 2023, 20:26:46
Ich lese mich gerade durch die ganzen Beiträge durch und wollte das LogDBRep_Statistic_previous_Quarter implementieren.

Aber ich finde im fhem die splitReading() Funktion für die 99_myUtils nicht.
Hallo Jörg,
die ist in diesem Post enthalten.

VG  Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Zitat von: kaiman am 19 Januar 2023, 18:59:07
Gibt es eine "einfache" Möglichkeit, die reading im Namen auf SW_* umzubauen?
Leider nein, eventuell hilft im UNIX ein diff von den beiden stateFormat, dann werden alle Zeilen angezeigt.
Oder Du sicherst Dir Dein altes stateFormat und verwendest dann das aktuelle.

Solltet Ihr im Device noch die alten readings verwenden, dann müssen die neuen erzeugt werden und im Anschluss in der Datenbank alles alte auf das neue geändert werden.
Dazu gibt es bereits im Thread und auch im Wiki eine Hilfestellung.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

jnewton957

Zitat von: ch.eick am 20 Januar 2023, 07:48:17
Hallo Jörg,
die ist in diesem Post enthalten.

VG  Christian

gefunden, eingebaut und Fehlermeldung: DBD::SQLite::db prepare failed: no such function: CONCAT at ./FHEM/93_DbRep.pm line 11129.

Leider keine Info zum Fehler hier im Forum gefunden.
FHEM6.2 auf Pi5
V 1.66 nanoCUL 433 (IT)
V 1.66 nanoCUL868 (HM)
sqlite3 LogDb
ELRO AB440, DECT200,  TFA30.3125, esp8266, HM, TabletUI, IR-Schreiblesekopf (Udo),tibber Pulse, Kostal Pico, cfos Wallbox, Modbus TCP

DS_Starter

Kleiner Zwischenruf...

Zitat
Fehlermeldung:
Code: [Auswählen]

DBD::SQLite::db prepare failed: no such function: CONCAT at ./FHEM/93_DbRep.pm line 11129.

Leider keine Info zum Fehler hier im Forum gefunden.


The SQL standard provides the CONCAT() function to concatenate two strings into a single string.

SQLite, however, does not support the CONCAT() function. Instead, it uses the concatenate operator (||) to join two strings into one.

-> https://www.sqlitetutorial.net/sqlite-string-functions/sqlite-concat/
ESXi 6.5 @NUC6i5SYH+FHEM auf Debian, DbLog/DbRep MariaDB
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

ch.eick

Zitat von: DS_Starter am 20 Januar 2023, 16:33:44
The SQL standard provides the CONCAT() function to concatenate two strings into a single string.

SQLite, however, does not support the CONCAT() function. Instead, it uses the concatenate operator (||) to join two strings into one.

-> https://www.sqlitetutorial.net/sqlite-string-functions/sqlite-concat/

Okay, ich schau mir das mal an.
https://database.guide/how-to-enable-the-pipe-concatenation-operator-in-mysql/
Zitat
MySQL supports the use of the pipe concatenation operator (||) for concatenating its operands. However, you need to enable it first.

By default, MySQL treats || as a logical OR operator (although this treatment is currently deprecated). However, the ANSI standard requires that || is a concatenation operator. Perhaps you have code that already uses the pipe concatenation operator, and you would rather not go through and change the code to use the CONCAT() function.

Fortunately, MySQL provides us with the ability to specify whether to treat it as a logical OR operator or a concatenation operator.
Wenn ich das jetzt richtig verstehe, wird dann als Folge das || nicht mehr als logisches OR verwendet, was auch probleme machen könnte.


Momentan habe ich folgendes gefunden, um MySQL da kompatiebler zu bekommen, sodass es auch bei Oracle MySQL laufen würde.

## so kann man den sql_mode abfragen, der gerade gesetzt ist
mysql> SELECT @@sql_mode;
+----------------------------------------------------------------------------------------------------------------------+
| @@sql_mode                                                                                                                           |
+----------------------------------------------------------------------------------------------------------------------+
| ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION |
+----------------------------------------------------------------------------------------------------------------------+

## Nun kann man im Oracle MySQL PIPES_AS_CONCAT hinzufügen
mysql> SET sql_mode=(SELECT CONCAT(@@sql_mode,',PIPES_AS_CONCAT'));

## Danach nochmal nachschauen
mysql> SELECT @@sql_mode;
+--------------------------------------------------------------------------------------------------------------------------------------+
| @@sql_mode                                                                                                            |
+--------------------------------------------------------------------------------------------------------------------------------------+
|PIPES_AS_CONCAT,ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION|
+--------------------------------------------------------------------------------------------------------------------------------------+

## Und hier ein Test
mysql> SELECT 'Homer' || 'Symptom';
+----------------------+
| 'Homer' || 'Symptom' |
+----------------------+
| HomerSymptom         |
+----------------------+

mysql> SELECT concat('Homer','Symptom');
+---------------------------+
| concat('Homer','Symptom') |
+---------------------------+
| HomerSymptom              |
+---------------------------+


Anscheinend verwenden hier im Thread alle anderen kein SQLite, also entweder MySQL oder MariaDB .
Nun bin ich mir nicht wirklich sicher, was das noch für weitere Konsquenzen haben wird.

Da es sich bisher um einen Einzelfall zu handeln scheint, bitte ich momentan darum in dem LogDBRep_Statistic_previous_Quarter Device das SQL SELECT aus dem Wiki lokal zu ändern.
Beispiel für die 4 SELECT mit je 2 CONCAT()

## aus einem
CONCAT('Q', CAST(MONTH(TIMESTAMP)/3 AS DECIMAL(1)))
## würde dann ein
'Q'||CAST(MONTH(TIMESTAMP)/3 AS DECIMAL(1))

## aus einem
CONCAT('Q', CAST(MONTH(TIMESTAMP)/3 AS DECIMAL(1)), '_', REPLACE(READING, '_Year', '')))
## würde dann ein
'Q'||CAST(MONTH(TIMESTAMP)/3 AS DECIMAL(1))||'_'|| REPLACE(READING, '_Year', ''))


Ich hoffe das kann jetzt weiter helfen.

VG   Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick