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

[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".

[...]
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]

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]

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

[MichaelO]

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 

[ch.eick]

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

[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 

[kaiman]

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]

Hast du meine PN mit dem List bekommen?

Ich hatte doch bereits alles beantwortet.

[kaiman]

oh sry, übersehen.

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

LG

[jnewton957]

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

[ch.eick]

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

[ch.eick]

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.

[jnewton957]

Hallo Jörg,
die ist in diesem Post enthalten.

VG  Christian

gefunden, eingebaut und Fehlermeldung:

Code Auswählen Erweitern

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.

[DS_Starter]

Kleiner Zwischenruf...

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/

[ch.eick]

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/

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.

Code Auswählen Erweitern


## 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()

Code Auswählen Erweitern


## 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