Autor Thema: Leistungsprognose für Wechselrichter  (Gelesen 65190 mal)

Offline ch.eick

  • Hero Member
  • *****
  • Beiträge: 2002
Leistungsprognose für Wechselrichter
« am: 18 Januar 2021, 08:35:46 »
EDIT: Ich habe noch mal eine sehr schöne Grafik raus gesucht

Hallo zusammen,
ich habe mal diesen Post zum Anlass genommen die Leistungsprognose auch ohne Kostal Plenticore vorzustellen.

Ja, Danke. Das ist sehr umfangreich.
Ich habe das schon mal versucht zu lesen, aber viele Sachen habe ich noch nicht verstanden.
Ich weiß das ich als nächstes mit DBlog anfangen muss.
Ohne zumindest etwas Verständnis was und wie das funktioniert geht es nicht wenn ich es für mich anpassen will.
Du würdest nur die Prognose verwenden.
- DbLog für die große Datenmenge des WR
- DWD_Forecast für das Wetter
- in der 99_myUtils die Solar_* Funktionen
  Diese trägt ebenfalls in DbLog die Prognose Werte ein.
- Anpassung wäre Notwendig, wo die PV_Anlage_1_config bei Dir herkommt, was Du jedoch zu beginn genau so übernehmen könntest
- Zum Testen kannst Du einen Aufruf wie diesen verwenden. Siehe auch einzel Tests im Wiki.
1) LogDB - ist der Name Deines DbLog Devices
2) LogDBRep_delete_PV_Forecast - Ist ein DbRep Device, das alte Forecasts in der DbLog löscht, bevor die neuen geschrieben werden.
3) PV_Anlage_1 ist der Name Deines WR, damit der Forecast in der Datenbank zu diesem Device Werte hinzufügen kann. Das wären readings mit Solar_*
4) Solar_Calculation_fc[0-2] Das wäre der reading name, mit 0 für heute und 1 für morgen
5) DWD_Forecast ist der Name des DWD Device
6) [0-1] 0 für heute und 1 für morgen

{Solar_forecast("LogDB","LogDBRep_delete_PV_Forecast","PV_Anlage_1","Solar_Calculation_fc","DWD_Forecast",0)}
Der Umweg über die DbLog hat den Hintergrund, dass bereits heute, für morgen, die Diagramm Werte des Forecast eingetragen werden.
Im WR wirst Du auch ein reading Solar_Calculation finden, das jeweils den aktuelle Forecast für die Stunde beinhaltet. Dazu muss Solar_forecast() natürlich stündlich aktualisiert werden.


VG
   Christian
« Letzte Änderung: 18 Januar 2021, 08:44:04 von ch.eick »
RPI4; Docker; CUNX; Eltako FSB61NP; 230V zentral verschaltet; SamsungTV H-Serie; DLNARenderer; TV.pl;  Sonos; Vallox; Luxtronik; 2x FB7490; Stromzähler mit DvLIR; wunderground; clever-tanken; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP

Offline sky64

  • New Member
  • *
  • Beiträge: 47
Antw:Leistungsprognose für Wechselrichter
« Antwort #1 am: 18 Januar 2021, 17:33:07 »
Vielen Dank, werde mich mal daran versuchen
Mfg Ron
RaspBerryPi + RFXTRX + GPIO4-1W-Sensoren + EMT7110(Strom/Spannungsmesser) an RF-Soap-Nachbau + 320x240 LowCost LCD-Mudul

Offline ch.eick

  • Hero Member
  • *****
  • Beiträge: 2002
Antw:Leistungsprognose für Wechselrichter
« Antwort #2 am: 18 Januar 2021, 17:48:58 »
Vielen Dank, werde mich mal daran versuchen
Gerne, je mehr es nutzen, umso besser wird es getestet.
Ich denke das Bild spricht für sich, der Tag war jedoch auch ein Volltreffer vom DWD :-)
RPI4; Docker; CUNX; Eltako FSB61NP; 230V zentral verschaltet; SamsungTV H-Serie; DLNARenderer; TV.pl;  Sonos; Vallox; Luxtronik; 2x FB7490; Stromzähler mit DvLIR; wunderground; clever-tanken; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP

Offline sky64

  • New Member
  • *
  • Beiträge: 47
Antw:Leistungsprognose für Wechselrichter
« Antwort #3 am: 21 Januar 2021, 07:24:27 »
Hallo ch.eick

So, die ersten Sachen sind eingestellt. War wie vermutet (befürchtet) natürlich nicht so einfach, da z.B. für das dblog noch einige Sachen beachtet werden müssen und auch nicht 100%ig im Wiki beschrieben ist (z.B. das man ja auch dem MySql auch die Datenbank anlegen muss).
Da mussten erst mal die 15 Jahre alten und nicht mehr verwendeten MySQL-Grundlagen wieder ausgegraben werden ...
Aus diesem Grund heißt mein dblog auch "logdb" und nicht "LogDb" wie bei dir, aber das ist ja nur eine Kleinigkeit.
Außerdem muss man natürlich für alle anderen Devices das Log in die DB abdrehen.
Habe nebenbei eine Menge über "Komfortfunktioen" im FHEM gelernt.
Das Debuging im zentralen fhem.log ist schon wieder schwieriger weil da auch haufen Müll kommt.


Auf jeden Fall habe ich jetzt :

* logdb
* LogDBRep_delete_PV_Forecast
* PV_Anlage_1_config
* DWD_Forecast
* die beiden Funktionen "Solar_forecast" und "Solar_plain" in der "99_myUtils.pm"
In den Readings vom DWD_Forecast  sind Werte drin.
Ein erster Test liefert auch Zahlen:
fhem> {Solar_plain(45,0,"2021-01-19 15:00:00")}
3.60852722543291
fhem> {Solar_plain(45,0,"2021-01-19 18:00:00")}
0.001

Beim nächsten Test hänge ich allerdings, denn ich habe eigentlich kein "PV_Anlage_1 "
Also habe ich eine Dummy "PV_Anlage_1 " erstellt.
Aber hier fehlt vermutlich noch etwas, den mit
fhem> {Solar_forecast("logdb","LogDBRep_delete_PV_Forecast","PV_Anlage_1","Solar_Calculation_fc","DWD_Forecast",1)}
erhalte ich im Log :
2021.01.19 18:29:34 3: DbLog logdb -> added by addCacheLine - TS: 2021-01-20 07:00:00, Device: PV_Anlage_1, Type: addlog, Event: Solar_Calculation_fc1: 0, Reading: Solar_Calculation_fc1, Value: 0, Unit:
2021.01.19 18:29:34 3: DbLog logdb -> added by addCacheLine - TS: 2021-01-20 08:00:00, Device: PV_Anlage_1, Type: addlog, Event: Solar_Calculation_fc1: 0, Reading: Solar_Calculation_fc1, Value: 0, Unit:
2021.01.19 18:29:34 3: DbLog logdb -> added by addCacheLine - TS: 2021-01-20 09:00:00, Device: PV_Anlage_1, Type: addlog, Event: Solar_Calculation_fc1: 0, Reading: Solar_Calculation_fc1, Value: 0, Unit:
2021.01.19 18:29:34 3: DbLog logdb -> added by addCacheLine - TS: 2021-01-20 10:00:00, Device: PV_Anlage_1, Type: addlog, Event: Solar_Calculation_fc1: 0, Reading: Solar_Calculation_fc1, Value: 0, Unit:
2021.01.19 18:29:34 3: DbLog logdb -> added by addCacheLine - TS: 2021-01-20 11:00:00, Device: PV_Anlage_1, Type: addlog, Event: Solar_Calculation_fc1: 0, Reading: Solar_Calculation_fc1, Value: 0, Unit:
2021.01.19 18:29:34 3: DbLog logdb -> added by addCacheLine - TS: 2021-01-20 12:00:00, Device: PV_Anlage_1, Type: addlog, Event: Solar_Calculation_fc1: 0, Reading: Solar_Calculation_fc1, Value: 0, Unit:
2021.01.19 18:29:34 3: DbLog logdb -> added by addCacheLine - TS: 2021-01-20 13:00:00, Device: PV_Anlage_1, Type: addlog, Event: Solar_Calculation_fc1: 0, Reading: Solar_Calculation_fc1, Value: 0, Unit:
2021.01.19 18:29:34 3: DbLog logdb -> added by addCacheLine - TS: 2021-01-20 14:00:00, Device: PV_Anlage_1, Type: addlog, Event: Solar_Calculation_fc1: 0, Reading: Solar_Calculation_fc1, Value: 0, Unit:
2021.01.19 18:29:34 3: DbLog logdb -> added by addCacheLine - TS: 2021-01-20 15:00:00, Device: PV_Anlage_1, Type: addlog, Event: Solar_Calculation_fc1: 0, Reading: Solar_Calculation_fc1, Value: 0, Unit:
2021.01.19 18:29:34 3: DbLog logdb -> added by addCacheLine - TS: 2021-01-20 16:00:00, Device: PV_Anlage_1, Type: addlog, Event: Solar_Calculation_fc1: 0, Reading: Solar_Calculation_fc1, Value: 0, Unit:
2021.01.19 18:29:34 3: DbLog logdb -> added by addCacheLine - TS: 2021-01-20 17:00:00, Device: PV_Anlage_1, Type: addlog, Event: Solar_Calculation_fc1: 0, Reading: Solar_Calculation_fc1, Value: 0, Unit:
2021.01.19 18:29:34 3: DbLog logdb -> added by addCacheLine - TS: 2021-01-20 18:00:00, Device: PV_Anlage_1, Type: addlog, Event: Solar_Calculation_fc1: 0, Reading: Solar_Calculation_fc1, Value: 0, Unit:
2021.01.19 18:29:34 3: DbLog logdb -> added by addCacheLine - TS: 2021-01-20 19:00:00, Device: PV_Anlage_1, Type: addlog, Event: Solar_Calculation_fc1: 0, Reading: Solar_Calculation_fc1, Value: 0, Unit:

Es werden aber keine Solar-Readings erstellt.
Muss ich die vorher noch anlegen? Im Wiki habe ich für die Kostal-Anlage PV_Anlage_1 aber auch nicht gefunden.
Nur den Verweis im DbLogInclude.
Und das immer Value: 0 kommt ist sicher auch nicht richtig.

Mit global verbose 4  steht sowas im Log:
2021.01.19 18:39:12 4: DbRep LogDBRep_delete_PV_Forecast - -------- New selection ---------
2021.01.19 18:39:12 4: DbRep LogDBRep_delete_PV_Forecast - Command: sqlCmd DELETE FROM history WHERE DEVICE='PV_Anlage_1' AND READING='Solar_Calculation_fc1' AND TIMESTAMP>='2021-01-20 07:00:00'
2021.01.19 18:39:12 4: DbRep LogDBRep_delete_PV_Forecast - Timestamp begin human readable: not set
2021.01.19 18:39:12 4: DbRep LogDBRep_delete_PV_Forecast - Timestamp end human readable: not set
2021.01.19 18:39:12 4: BlockingCall (sqlCmd_DoParse): created child (22554), uses telnetPort to connect back
2021.01.19 18:39:12 4: Solar_SolarRadiation   :  0 0
2021.01.19 18:39:12 3: get Astro text SunAz 2021-01-20 07:00:00 : 109.6
2021.01.19 18:39:12 3: get Astro text SunAlt 2021-01-20 07:00:00 : -10
2021.01.19 18:39:12 3: Solar_plain: azimuth = 109.6, orientation=-1.22870706506562, elevation=-0.174532253560458, angle=0.733035464953923
2021.01.19 18:39:12 3: Solar_plain: factor = 0.001
2021.01.19 18:39:12 4: plain/direction        :  42/0 >>> 0.001
2021.01.19 18:39:12 3: DbLog logdb -> added by addCacheLine - TS: 2021-01-20 07:00:00, Device: PV_Anlage_1, Type: addlog, Event: Solar_Calculation_fc1: 0, Reading: Solar_Calculation_fc1, Value: 0, Unit:
2021.01.19 18:39:12 4: Solar_Plain            : 0.001
2021.01.19 18:39:12 4: Solar_SolarRadiation   : 0
2021.01.19 18:39:12 4: Solar_Cloud            : 77
2021.01.19 18:39:12 4: cloudk                 : -0.2 0
2021.01.19 18:39:12 4: Solar_Correction_Cloud : 0.846
2021.01.19 18:39:12 4: Solar_Rain             : 12
2021.01.19 18:39:12 4: raink                  : -0.2 0
2021.01.19 18:39:12 4: Solar_Correction_Rain  : 0.976
2021.01.19 18:39:12 4: Solar_Temp             : 14.6
2021.01.19 18:39:12 4: tempk                  : -0.39 25
2021.01.19 18:39:12 4: Solar_Correction_Temp  : 1.041
2021.01.19 18:39:12 4: 1 7 0 0
2021.01.19 18:39:12 4: Solar_SolarRadiation   :  0 0
2021.01.19 18:39:12 3: get Astro text SunAz 2021-01-20 08:00:00 : 120.9
2021.01.19 18:39:12 3: get Astro text SunAlt 2021-01-20 08:00:00 : -1.1
2021.01.19 18:39:12 3: Solar_plain: azimuth = 120.9, orientation=-1.03148561854231, elevation=-0.0191985478916504, angle=0.733035464953923
2021.01.19 18:39:12 3: Solar_plain: factor = 0.001
2021.01.19 18:39:12 4: plain/direction        :  42/0 >>> 0.001
2021.01.19 18:39:12 3: DbLog logdb -> added by addCacheLine - TS: 2021-01-20 08:00:00, Device: PV_Anlage_1, Type: addlog, Event: Solar_Calculation_fc1: 0, Reading: Solar_Calculation_fc1, Value: 0, Unit:
2021.01.19 18:39:12 4: Solar_Plain            : 0.001
2021.01.19 18:39:12 4: Solar_SolarRadiation   : 0
2021.01.19 18:39:12 4: Solar_Cloud            : 77
2021.01.19 18:39:12 4: cloudk                 : -0.2 0
2021.01.19 18:39:12 4: Solar_Correction_Cloud : 0.846
2021.01.19 18:39:12 4: Solar_Rain             : 12
2021.01.19 18:39:12 4: raink                  : -0.2 0
2021.01.19 18:39:12 4: Solar_Correction_Rain  : 0.976
2021.01.19 18:39:12 4: Solar_Temp             : 15
2021.01.19 18:39:12 4: tempk                  : -0.39 25
2021.01.19 18:39:12 4: Solar_Correction_Temp  : 1.039
2021.01.19 18:39:12 4: 1 8 0 0
2021.01.19 18:39:12 4: Solar_SolarRadiation   :  0 0
2021.01.19 18:39:12 3: get Astro text SunAz 2021-01-20 09:00:00 : 132.9
2021.01.19 18:39:12 3: get Astro text SunAlt 2021-01-20 09:00:00 : 6.3
2021.01.19 18:39:12 3: Solar_plain: azimuth = 132.9, orientation=-0.822046914269757, elevation=0.109955319743089, angle=0.733035464953923
2021.01.19 18:39:12 3: Solar_plain: factor = 0.001
2021.01.19 18:39:12 4: plain/direction        :  42/0 >>> 0.001
2021.01.19 18:39:12 3: DbLog logdb -> added by addCacheLine - TS: 2021-01-20 09:00:00, Device: PV_Anlage_1, Type: addlog, Event: Solar_Calculation_fc1: 0, Reading: Solar_Calculation_fc1, Value: 0, Unit:
2021.01.19 18:39:12 4: Solar_Plain            : 0.001
2021.01.19 18:39:12 4: Solar_SolarRadiation   : 0
2021.01.19 18:39:12 4: Solar_Cloud            : 78
2021.01.19 18:39:12 4: cloudk                 : -0.2 0
2021.01.19 18:39:12 4: Solar_Correction_Cloud : 0.844
2021.01.19 18:39:12 4: Solar_Rain             : 12
2021.01.19 18:39:12 4: raink                  : -0.2 0
2021.01.19 18:39:12 4: Solar_Correction_Rain  : 0.976
2021.01.19 18:39:12 4: Solar_Temp             : 15.6
2021.01.19 18:39:12 4: tempk                  : -0.39 25
2021.01.19 18:39:12 4: Solar_Correction_Temp  : 1.037
2021.01.19 18:39:12 4: 1 9 0 0
2021.01.19 18:39:12 4: Solar_SolarRadiation   :  0 0
2021.01.19 18:39:12 3: get Astro text SunAz 2021-01-20 10:00:00 : 145.7
2021.01.19 18:39:12 3: get Astro text SunAlt 2021-01-20 10:00:00 : 12.3
2021.01.19 18:39:12 3: Solar_plain: azimuth = 145.7, orientation=-0.598645629712371, elevation=0.214674671879363, angle=0.733035464953923
2021.01.19 18:39:12 3: Solar_plain: factor = 3.2783741916608
2021.01.19 18:39:12 4: plain/direction        :  42/0 >>> 3.278
2021.01.19 18:39:12 3: DbLog logdb -> added by addCacheLine - TS: 2021-01-20 10:00:00, Device: PV_Anlage_1, Type: addlog, Event: Solar_Calculation_fc1: 0, Reading: Solar_Calculation_fc1, Value: 0, Unit:
2021.01.19 18:39:12 4: Solar_Plain            : 3.278
2021.01.19 18:39:12 4: Solar_SolarRadiation   : 0
2021.01.19 18:39:12 4: Solar_Cloud            : 78
2021.01.19 18:39:12 4: cloudk                 : -0.2 0
2021.01.19 18:39:12 4: Solar_Correction_Cloud : 0.844
2021.01.19 18:39:12 4: Solar_Rain             : 12
2021.01.19 18:39:12 4: raink                  : -0.2 0
2021.01.19 18:39:12 4: Solar_Correction_Rain  : 0.976
2021.01.19 18:39:12 4: Solar_Temp             : 16.1
2021.01.19 18:39:12 4: tempk                  : -0.39 25
2021.01.19 18:39:12 4: Solar_Correction_Temp  : 1.035
2021.01.19 18:39:12 4: 1 10 0 0
2021.01.19 18:39:12 4: Solar_SolarRadiation   :  0 0
2021.01.19 18:39:12 3: get Astro text SunAz 2021-01-20 11:00:00 : 159.6
2021.01.19 18:39:12 3: get Astro text SunAlt 2021-01-20 11:00:00 : 16.3
2021.01.19 18:39:12 3: Solar_plain: azimuth = 159.6, orientation=-0.356045797263334, elevation=0.284487573303547, angle=0.733035464953923
2021.01.19 18:39:12 3: Solar_plain: factor = 2.88788364649468
2021.01.19 18:39:12 4: plain/direction        :  42/0 >>> 2.888
2021.01.19 18:39:12 3: DbLog logdb -> added by addCacheLine - TS: 2021-01-20 11:00:00, Device: PV_Anlage_1, Type: addlog, Event: Solar_Calculation_fc1: 0, Reading: Solar_Calculation_fc1, Value: 0, Unit:
2021.01.19 18:39:12 4: Solar_Plain            : 2.888
2021.01.19 18:39:12 4: Solar_SolarRadiation   : 0
2021.01.19 18:39:12 4: Solar_Cloud            : 81
2021.01.19 18:39:12 4: cloudk                 : -0.2 0
2021.01.19 18:39:12 4: Solar_Correction_Cloud : 0.838
2021.01.19 18:39:12 4: Solar_Rain             : 12
2021.01.19 18:39:12 4: raink                  : -0.2 0
2021.01.19 18:39:12 4: Solar_Correction_Rain  : 0.976
2021.01.19 18:39:12 4: Solar_Temp             : 16.8
2021.01.19 18:39:12 4: tempk                  : -0.39 25
2021.01.19 18:39:12 4: Solar_Correction_Temp  : 1.032
2021.01.19 18:39:12 4: 1 11 0 0
2021.01.19 18:39:12 4: Solar_SolarRadiation   :  0 0
2021.01.19 18:39:12 3: get Astro text SunAz 2021-01-20 12:00:00 : 174.2
2021.01.19 18:39:12 3: get Astro text SunAlt 2021-01-20 12:00:00 : 18.4
2021.01.19 18:39:12 3: Solar_plain: azimuth = 174.2, orientation=-0.101228707065066, elevation=0.321139346551243, angle=0.733035464953923
2021.01.19 18:39:12 3: Solar_plain: factor = 2.74433223543208
2021.01.19 18:39:12 4: plain/direction        :  42/0 >>> 2.744
2021.01.19 18:39:12 3: DbLog logdb -> added by addCacheLine - TS: 2021-01-20 12:00:00, Device: PV_Anlage_1, Type: addlog, Event: Solar_Calculation_fc1: 0, Reading: Solar_Calculation_fc1, Value: 0, Unit:
2021.01.19 18:39:12 4: Solar_Plain            : 2.744
2021.01.19 18:39:12 4: Solar_SolarRadiation   : 0
2021.01.19 18:39:12 4: Solar_Cloud            : 80
2021.01.19 18:39:12 4: cloudk                 : -0.2 0
2021.01.19 18:39:12 4: Solar_Correction_Cloud : 0.840
2021.01.19 18:39:12 4: Solar_Rain             : 12
2021.01.19 18:39:12 4: raink                  : -0.2 0
2021.01.19 18:39:12 4: Solar_Correction_Rain  : 0.976
2021.01.19 18:39:12 4: Solar_Temp             : 17.5
2021.01.19 18:39:12 4: tempk                  : -0.39 25
2021.01.19 18:39:12 4: Solar_Correction_Temp  : 1.029
2021.01.19 18:39:12 4: 1 12 0 0
2021.01.19 18:39:12 4: Solar_SolarRadiation   :  0 0
2021.01.19 18:39:12 3: get Astro text SunAz 2021-01-20 13:00:00 : 189
2021.01.19 18:39:12 3: get Astro text SunAlt 2021-01-20 13:00:00 : 18.1
2021.01.19 18:39:12 3: Solar_plain: azimuth = 189, orientation=0.157079028204412, elevation=0.315903378944429, angle=0.733035464953923
2021.01.19 18:39:12 3: Solar_plain: factor = 2.76515203658699
2021.01.19 18:39:12 4: plain/direction        :  42/0 >>> 2.765
2021.01.19 18:39:12 3: DbLog logdb -> added by addCacheLine - TS: 2021-01-20 13:00:00, Device: PV_Anlage_1, Type: addlog, Event: Solar_Calculation_fc1: 0, Reading: Solar_Calculation_fc1, Value: 0, Unit:
2021.01.19 18:39:12 4: Solar_Plain            : 2.765
2021.01.19 18:39:12 4: Solar_SolarRadiation   : 0
2021.01.19 18:39:12 4: Solar_Cloud            : 80
2021.01.19 18:39:12 4: cloudk                 : -0.2 0
2021.01.19 18:39:12 4: Solar_Correction_Cloud : 0.840
2021.01.19 18:39:12 4: Solar_Rain             : 12
2021.01.19 18:39:12 4: raink                  : -0.2 0
2021.01.19 18:39:12 4: Solar_Correction_Rain  : 0.976
2021.01.19 18:39:12 4: Solar_Temp             : 17.8
2021.01.19 18:39:12 4: tempk                  : -0.39 25
2021.01.19 18:39:12 4: Solar_Correction_Temp  : 1.028
2021.01.19 18:39:12 4: 1 13 0 0
:
:
2021.01.19 18:39:12 4: Connection accepted from telnetPort_127.0.0.1_59734
2021.01.19 18:39:12 4: DbRep LogDBRep_delete_PV_Forecast - database user for operation: fhemuser
2021.01.19 18:39:12 4: DbRep LogDBRep_delete_PV_Forecast - SQL execute: DELETE FROM history WHERE DEVICE='PV_Anlage_1' AND READING='Solar_Calculation_fc1' AND TIMESTAMP>='2021-01-20 07:00:00';
2021.01.19 18:39:12 3: DbRep LogDBRep_delete_PV_Forecast - Number of entries processed in db fhem: 13 by DELETE

Das PV_Anlage_1_config hat (ich habe nur eine Ausrichtung):
   TYPE       dummy
   READINGS:
     2021-01-19 17:31:17   Battery_Total_Power 5200
     2020-09-11 07:36:39   Forecast_Station Zscherben
     2021-01-19 17:33:14   forecast_cloudk 20
     2021-01-19 17:33:21   forecast_cloudk_base 0
     2021-01-19 17:32:56   forecast_factor 1
     2021-01-19 17:34:07   forecast_raink  20
     2021-01-19 17:34:19   forecast_raink_base 0
     2021-01-19 17:34:34   forecast_tempk  39
     2021-01-19 17:34:53   forecast_tempk_base 25
     2021-01-19 17:32:02   module_1_count  22
     2021-01-19 17:31:04   module_1_direction 0
     2021-01-19 17:31:29   module_1_name   South
     2021-01-19 17:32:37   module_1_plain  42
     2021-01-19 17:32:23   module_1_power  305

Ich hoffe du kannst mit den Logs etwas anfangen.

Gruß Ron


RaspBerryPi + RFXTRX + GPIO4-1W-Sensoren + EMT7110(Strom/Spannungsmesser) an RF-Soap-Nachbau + 320x240 LowCost LCD-Mudul

Offline ch.eick

  • Hero Member
  • *****
  • Beiträge: 2002
Antw:Leistungsprognose für Wechselrichter
« Antwort #4 am: 21 Januar 2021, 09:37:00 »
Hallo Ron

da z.B. für das dblog noch einige Sachen beachtet werden müssen und auch nicht 100%ig im Wiki beschrieben ist (z.B. das man ja auch dem MySql auch die Datenbank anlegen muss).
Da mussten erst mal die 15 Jahre alten und nicht mehr verwendeten MySQL-Grundlagen wieder ausgegraben werden ...
Aus diesem Grund heißt mein dblog auch "logdb" und nicht "LogDb" wie bei dir, aber das ist ja nur eine Kleinigkeit.
Außerdem muss man natürlich für alle anderen Devices das Log in die DB abdrehen.
Okay, ich stimme zu, dass das recht komplex werden kann. Deshalb habe ich mich da auch weitestgehend raus gehalten und mich auf die Unterstützung im Forum verlassen.

Zitat
Auf jeden Fall habe ich jetzt :

* logdb
* LogDBRep_delete_PV_Forecast
* PV_Anlage_1_config
* DWD_Forecast
* die beiden Funktionen "Solar_forecast" und "Solar_plain" in der "99_myUtils.pm"
In den Readings vom DWD_Forecast  sind Werte drin.
Wenn Dein Wechselrichter anders als PV_Anlage_1 heißt, muss der Name natürlich überall geändert werden.
Durch die Funktionen werden mit setreading dann die berechneten Werte dort hinein geschrieben, also sollte es auch ein Dummy tun. Das habe ich so gemacht, damit bei jedem WR der Forecast direkt zugeordnet wird und auch in der Datenbank der selbe Devicename eingetragen wird. Das erleichtert das Abrufen des Forecast zusammen mit anderen readings des WR.

Zitat
Ein erster Test liefert auch Zahlen:
fhem> {Solar_plain(45,0,"2021-01-19 15:00:00")}
3.60852722543291
fhem> {Solar_plain(45,0,"2021-01-19 18:00:00")}
0.001
Das sieht schon mal sehr gut aus, um 18:00 Uhr ist die Sonne bereits untergegangen und die Funktion liefert ein 0.001 zurück, wodurch die Solar_Calculation quasi Null wird.

Zitat
Beim nächsten Test hänge ich allerdings, denn ich habe eigentlich kein "PV_Anlage_1 "
Also habe ich eine Dummy "PV_Anlage_1 " erstellt.       <<<<< Da gehen die setreading dann rein (s.o.)
Aber hier fehlt vermutlich noch etwas, den mit
fhem> {Solar_forecast("logdb","LogDBRep_delete_PV_Forecast","PV_Anlage_1","Solar_Calculation_fc","DWD_Forecast",1)}
erhalte ich im Log :
2021.01.19 18:29:34 3: DbLog logdb -> added by addCacheLine - TS: 2021-01-20 07:00:00, Device: PV_Anlage_1, Type: addlog, Event: Solar_Calculation_fc1: 0, Reading: Solar_Calculation_fc1, Value: 0, Unit:
2021.01.19 18:29:34 3: DbLog logdb -> added by addCacheLine - TS: 2021-01-20 08:00:00, Device: PV_Anlage_1, Type: addlog, Event: Solar_Calculation_fc1: 0, Reading: Solar_Calculation_fc1, Value: 0, Unit:
Zitat
Nur den Verweis im DbLogInclude.
Und das immer Value: 0 kommt ist sicher auch nicht richtig.
Ohne DbLogInclude werden nur die Solar_Calculation_fc* Werte in die Datenbank geschrieben.
Schau bitte mal nach, ob Du im DWD_Forecast Device auch für fc[0|1] die rad1h Werte hast.
Nicht alle Stationen liefern diesen Wert.

Zitat
Es werden aber keine Solar-Readings erstellt.
Muss ich die vorher noch anlegen? Im Wiki habe ich für die Kostal-Anlage PV_Anlage_1 aber auch nicht gefunden.
{ fhem "setreading PV_Anlage_1 Solar_SolarRadiation  0"}
Das sollte ein reading anlegen und wird so auch im Solar_forecast() als Kommando abgesetzt.


Ich schreibe mal einige Bemerkungen zwischen die Log Zeilen

Mit global verbose 4  steht sowas im Log:
2021.01.19 18:39:12 4: DbRep LogDBRep_delete_PV_Forecast - -------- New selection ---------
2021.01.19 18:39:12 4: DbRep LogDBRep_delete_PV_Forecast - Command: sqlCmd DELETE FROM history WHERE DEVICE='PV_Anlage_1' AND READING='Solar_Calculation_fc1' AND TIMESTAMP>='2021-01-20 07:00:00'
2021.01.19 18:39:12 4: DbRep LogDBRep_delete_PV_Forecast - Timestamp begin human readable: not set
2021.01.19 18:39:12 4: DbRep LogDBRep_delete_PV_Forecast - Timestamp end human readable: not set
2021.01.19 18:39:12 4: BlockingCall (sqlCmd_DoParse): created child (22554), uses telnetPort to connect back
>>>Das löschen der Vorherigen Forecasts für heute und morgen sollte somit klappen.

2021.01.19 18:39:12 4: Solar_SolarRadiation   :  0 0
>>>Aus dem DWD Device ist um 8:00 Uhr rad1h auf 0

2021.01.19 18:39:12 3: get Astro text SunAz 2021-01-20 07:00:00 : 109.6
2021.01.19 18:39:12 3: get Astro text SunAlt 2021-01-20 07:00:00 : -10
>>>Das ist die Sonnenposition vom Astro Device

2021.01.19 18:39:12 3: Solar_plain: azimuth = 109.6, orientation=-1.22870706506562, elevation=-0.174532253560458, angle=0.733035464953923
2021.01.19 18:39:12 3: Solar_plain: factor = 0.001
>>>Die Winkelkorrektur ist bei dem tiefen Sonnenstand noch in einem ungültigen Bereich und gibt als Faktor 0.001 zurück.

2021.01.19 18:39:12 4: plain/direction        :  42/0 >>> 0.001
Das ist die Dachneigung und Ausrichtung, die bei dem Sonnenstand zum Faktor 0.001 führt und somit kein Ertrag zu erwarten ist.

2021.01.19 18:39:12 3: DbLog logdb -> added by addCacheLine - TS: 2021-01-20 07:00:00, Device: PV_Anlage_1, Type: addlog, Event: Solar_Calculation_fc1: 0, Reading: Solar_Calculation_fc1, Value: 0, Unit:
>>> Für 7:00 Uhr Null Ertrag in die Datenbank schreiben
# Jetzt kommen noch die Detail
2021.01.19 18:39:12 4: Solar_Plain            : 0.001
2021.01.19 18:39:12 4: Solar_SolarRadiation   : 0
2021.01.19 18:39:12 4: Solar_Cloud            : 77
2021.01.19 18:39:12 4: cloudk                 : -0.2 0
2021.01.19 18:39:12 4: Solar_Correction_Cloud : 0.846
2021.01.19 18:39:12 4: Solar_Rain             : 12
2021.01.19 18:39:12 4: raink                  : -0.2 0
2021.01.19 18:39:12 4: Solar_Correction_Rain  : 0.976
2021.01.19 18:39:12 4: Solar_Temp             : 14.6
2021.01.19 18:39:12 4: tempk                  : -0.39 25
2021.01.19 18:39:12 4: Solar_Correction_Temp  : 1.041
2021.01.19 18:39:12 4: 1 7 0 0
>>> 1 ist Deine Ausrichtung, da Du nur eine Hst, bleibt es hier immer bei 1
>>> 7 => 07:00 Uhr
>>> 0 ist der SolarRadiation Wert
>>> 0 ist die Summe der SolarCalculation

>>> Das PV_Anlage_1 Device erhält nur readings für die aktuelle Stunde des Forecast, alle anderen Werte stehen in der Datenbank

# Nun kommt der Lauf für 8:00 Uhr
2021.01.19 18:39:12 4: Solar_SolarRadiation   :  0 0
2021.01.19 18:39:12 3: get Astro text SunAz 2021-01-20 08:00:00 : 120.9
2021.01.19 18:39:12 3: get Astro text SunAlt 2021-01-20 08:00:00 : -1.1
2021.01.19 18:39:12 3: Solar_plain: azimuth = 120.9, orientation=-1.03148561854231, elevation=-0.0191985478916504, angle=0.733035464953923
2021.01.19 18:39:12 3: Solar_plain: factor = 0.001
2021.01.19 18:39:12 4: plain/direction        :  42/0 >>> 0.001
2021.01.19 18:39:12 3: DbLog logdb -> added by addCacheLine - TS: 2021-01-20 08:00:00, Device: PV_Anlage_1, Type: addlog, Event: Solar_Calculation_fc1: 0, Reading: Solar_Calculation_fc1, Value: 0, Unit:
2021.01.19 18:39:12 4: Solar_Plain            : 0.001
2021.01.19 18:39:12 4: Solar_SolarRadiation   : 0
2021.01.19 18:39:12 4: Solar_Cloud            : 77
2021.01.19 18:39:12 4: cloudk                 : -0.2 0
2021.01.19 18:39:12 4: Solar_Correction_Cloud : 0.846
2021.01.19 18:39:12 4: Solar_Rain             : 12
2021.01.19 18:39:12 4: raink                  : -0.2 0
2021.01.19 18:39:12 4: Solar_Correction_Rain  : 0.976
2021.01.19 18:39:12 4: Solar_Temp             : 15
2021.01.19 18:39:12 4: tempk                  : -0.39 25
2021.01.19 18:39:12 4: Solar_Correction_Temp  : 1.039
2021.01.19 18:39:12 4: 1 8 0 0

2021.01.19 18:39:12 4: Solar_SolarRadiation   :  0 0
2021.01.19 18:39:12 3: get Astro text SunAz 2021-01-20 09:00:00 : 132.9
2021.01.19 18:39:12 3: get Astro text SunAlt 2021-01-20 09:00:00 : 6.3
2021.01.19 18:39:12 3: Solar_plain: azimuth = 132.9, orientation=-0.822046914269757, elevation=0.109955319743089, angle=0.733035464953923
2021.01.19 18:39:12 3: Solar_plain: factor = 0.001
2021.01.19 18:39:12 4: plain/direction        :  42/0 >>> 0.001
2021.01.19 18:39:12 3: DbLog logdb -> added by addCacheLine - TS: 2021-01-20 09:00:00, Device: PV_Anlage_1, Type: addlog, Event: Solar_Calculation_fc1: 0, Reading: Solar_Calculation_fc1, Value: 0, Unit:
2021.01.19 18:39:12 4: Solar_Plain            : 0.001
2021.01.19 18:39:12 4: Solar_SolarRadiation   : 0
2021.01.19 18:39:12 4: Solar_Cloud            : 78
2021.01.19 18:39:12 4: cloudk                 : -0.2 0
2021.01.19 18:39:12 4: Solar_Correction_Cloud : 0.844
2021.01.19 18:39:12 4: Solar_Rain             : 12
2021.01.19 18:39:12 4: raink                  : -0.2 0
2021.01.19 18:39:12 4: Solar_Correction_Rain  : 0.976
2021.01.19 18:39:12 4: Solar_Temp             : 15.6
2021.01.19 18:39:12 4: tempk                  : -0.39 25
2021.01.19 18:39:12 4: Solar_Correction_Temp  : 1.037
2021.01.19 18:39:12 4: 1 9 0 0
[/quote]

>>> Meine Vermutung ist, das im DWD Device keine rad1h Werte geliefert wurden.

VG
   Christian
RPI4; Docker; CUNX; Eltako FSB61NP; 230V zentral verschaltet; SamsungTV H-Serie; DLNARenderer; TV.pl;  Sonos; Vallox; Luxtronik; 2x FB7490; Stromzähler mit DvLIR; wunderground; clever-tanken; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP

Offline EinEinfach

  • Full Member
  • ***
  • Beiträge: 330
Antw:Leistungsprognose für Wechselrichter
« Antwort #5 am: 21 Januar 2021, 09:44:45 »
Hallo Christian,

ich habe ein sehr großes Interesse an der Prognose zum Solarertrag. Ich habe einen SolarEdge Wechselrichter, aber wie ich es verstanden habe, das ist im Prinzip egal.

Meine Frage lautet, ich habe gesehen, dass du dich in einem anderen Thread mit dem Thema im Zusammenhang mit dem 76_Solarforecast-Modul auch auseinandersetzt. Vom Aufwand erscheint mir die andere Lösung einfacher umzusetzen, aber die Genauigkeit ist in deinem Ansatz besser. Da du deine Erfahrungen in den anderen Modul miteinbrigen willst, soll langfristig diese Lösung hier entfallen?

Gruß
Alex
fhem auf Intel NUC6CAYH mit Proxmox im LXC (Debian 10), KNX mit knxd über MDT SCN-IP000.02, Buderus GB192-15i über KM100, Solaredge WR SE9K über Modbus-TCP

Offline ch.eick

  • Hero Member
  • *****
  • Beiträge: 2002
Antw:Leistungsprognose für Wechselrichter
« Antwort #6 am: 21 Januar 2021, 10:06:42 »
ich habe ein sehr großes Interesse an der Prognose zum Solarertrag. Ich habe einen SolarEdge Wechselrichter, aber wie ich es verstanden habe, das ist im Prinzip egal.

Meine Frage lautet, ich habe gesehen, dass du dich in einem anderen Thread mit dem Thema im Zusammenhang mit dem 76_Solarforecast-Modul auch auseinandersetzt. Vom Aufwand erscheint mir die andere Lösung einfacher umzusetzen, aber die Genauigkeit ist in deinem Ansatz besser. Da du deine Erfahrungen in den anderen Modul miteinbringen willst, soll langfristig diese Lösung hier entfallen?
Hallo Alex,
Heiko und ich arbeiten wahrscheinlich näher zusammen, alles andere macht ja auch keinen Sinn und der Kontakt unter uns steht ja auch bereits.

Mein Forecast ist eigentlich recht simpel aufgebaut und hat ziemlich gute Ergebnisse, deshalb werde ich das auch so erstmal belassen.
Aus meinem Forecast kommt sofort eine Prognose, die man dann auch noch etwas anpassen kann, was ich jedoch bisher nicht benötigt habe, nachdem die Defaults gestanden haben.

Das 76_Solarforecast ist noch in der Entwicklung und da wird sicherlich noch einiges kommen.
Was mir bei diesem Modul noch fehlt ist halt der Eintrag in die DB und es macht bisher nur einen Forecast von 24 Stunden, wobei ja momentan 16 Stunden Nacht sind :-)
Heiko wird sich jetzt auch noch mit Regen und Wolken befassen, wo wir dann im Gespräch sind.
Ich glaube seine Autokorrektur lernt das dann auch, jedoch wird es dann wie beim Kostal Plenticore sein, dass ein schneller Wechsel von Hochsommer zu einem Regentag erst tage später erkannt wird. Das ist ein bekanntes Problem beim Plenticor, was bei der "intelligenten" Batteriesteuerung ziemlich störend ist.

Eine Mischung aus beiden Forecast, also meine Prognose mit Heikos Autokorrektur wäre echt die Krönung. Plin hat heute auch noch KI mit ins Spiel gebracht, was ich sehr spannend finde.
Eventuell baut Heiko ja auch meine Funktionen für Teilbereiche mit ein, ich habe da schon Ideen, die man über Attribute gestalten könnte.

Das neue Modul hat für mich den Charm, dass der Maintainer es dann ja auch pflegen und weiterentwickeln wird, da ich kein Softwareentwickler bin wäre das ein Grund für mich zu wechseln.
Meine Lösung werde ich jedoch nicht so bald abschaffen, da sie halt sehr simpel und ohne Schnickschnak ist. Wer ein wenig Perl lesen kann, findet auch die Stellen, wo eventuell Spezialanpassungen notwendig sind.
Eventuell baue ich noch kleine Erweiterungen ein, die dann aber auch an das Modul anlehne (Copy/Paste :-) )

Es kann ja auch beides parallel laufen, was einen Vergleich ermöglicht und dann hat jeder die freie Wahl.

VG
   Christian
RPI4; Docker; CUNX; Eltako FSB61NP; 230V zentral verschaltet; SamsungTV H-Serie; DLNARenderer; TV.pl;  Sonos; Vallox; Luxtronik; 2x FB7490; Stromzähler mit DvLIR; wunderground; clever-tanken; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP

Offline ch.eick

  • Hero Member
  • *****
  • Beiträge: 2002
Antw:Leistungsprognose für Wechselrichter
« Antwort #7 am: 21 Januar 2021, 22:25:51 »
Hallo zusammen, damit der andere Thread wieder sauber wird können wir hier gerne mit WR Leistungs Prognose und Solar_Forecast weiter machen. Wenn Ihr Eure relevanten Posts aus dem anderen Thread hier nochmals zusammenfasst, dann geht nichts verloren. Ich beginne dann meine störenden Posts dort wieder raus zu löscht.

RPI4; Docker; CUNX; Eltako FSB61NP; 230V zentral verschaltet; SamsungTV H-Serie; DLNARenderer; TV.pl;  Sonos; Vallox; Luxtronik; 2x FB7490; Stromzähler mit DvLIR; wunderground; clever-tanken; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP

Offline ch.eick

  • Hero Member
  • *****
  • Beiträge: 2002
Antw:Leistungsprognose für Wechselrichter
« Antwort #8 am: 21 Januar 2021, 22:35:32 »
Mit folgendem wget in der Fhem Kommandozeile bekommt man Heikos aktuellste Version
"wget -qO ./FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"
Meine Implementierung steht mit Beschreibung im Wiki
Wetter- / Leistungs-Prognose


==========================================================================================
Ich habe übrigens bei mir noch eine Verschiebung der Werte vom DWD um 1 Stunde eingebaut, dadurch passten die Werte besser mit der Realität überein.
Da fällt mir gerade ein, dass ich das auch noch in die *_config reinbauen wollte, gut dass wir drüber gesprochen haben.

==========================================================================================
nur für den Solarforecast extra ein SQL Datenbank anzulegen, begeistert mich wenig
das Modul arbeitet ohne DbLog.

Nur meine Implementierung verwendet DbLog, um bereits heute die Kurve für morgen einzutragen.
Ich überlege jedoch, ob ich auch die readings für fc[0|1] einfach mit ins Device schreibe, damit man es ohne DbLog verwenden kann, dann ist es halt nicht mehr so schön ;-)
EDIT: Das sähe dann so aus
Solar_Calculation_fc0_10 662 2021-01-21 17:32:43
Solar_Calculation_fc0_11 692 2021-01-21 17:32:43
Solar_Calculation_fc0_12 639 2021-01-21 17:32:43
Solar_Calculation_fc0_13 837 2021-01-21 17:32:43
Solar_Calculation_fc0_14 615 2021-01-21 17:32:43
Solar_Calculation_fc0_15 476 2021-01-21 17:32:43
alle anderen sind auf 0 und hier weg gelassen
Wenn das wirklch gebraucht würde, dann bitte bei mir melden, ich mache es dann mit einem Parameter konfigurierbar, damit die Datenbank dann wegfallen kann.
Somit würde dann aber auch Grafana nicht mehr diese Werte aus der Datenbank bekommen.

Ich habe halt auch festgestellt, dass es schon besser ist die Vielzahl der PV Werte in einer Datenbank zu haben. Mit FileLog war ich da sehr schnell am Ende, insbesondere
wenn es um Aggregierund der Daten geht, aber jeder wie er mag.
Grafana ist ja auch sehr schön mit einer Datenbank zu nutzen. Das gibt es alles auch schon vorgefertigt in Docker Containern.

============================================================================================
Meinst du mit  "Heizungskurve" tatsächlich die im Heizungsbau üblichen Kurven zur Einstellung der Vorlauftemp. abhängig von Außentemp und Steilheit ? Oder ist es ein Synonym für eine andere Kurve ?
Genau die :-) , ich bin da ziemlich pragmatisch, die Code Zeilen hatte ich ja schon hier rein gestellt.
Es hatte auch einen verblüffend einfachen und guten Effect ;-)

============================================================================================
@papaFinde ich einen guten und vermutlich hinreichenden Ansatz. Zumal wir diese Grunddaten bereits im Modul haben über die ww-Id's. Das werde ich mal einbauen. Frage nur wie hoch ich die Korrekturen ansetze, mal schauen ...
Aus meiner Erfahrung reicht ein Faktor aus Regen und einer aus Wolken, wie gesagt die Stärke der Dämpfung beeinflusse ich über die "Heizungskurve".
Den Ansatz mit den Wetter IDs hatte ich bereits verworfen, da es einfach viel zu viel ist und es dann noch Dämpfungsfaktoren geben müsste.

============================================================================================
Im reading steht jeweils die Einheit dabei, somit auch als VALUE in der Datenbank, was sich in Grafana mit meinem Kenntnisstand nicht anzeigen lässt.
Es wäre schön, wenn dort nur der Wert und nicht die Einheit mit drin stände. Oder gibt es da einen Trick?

time                            Today_Hour_PVforecast
2021-01-20 14:56:39 269 Wh
2021-01-20 14:56:39 264 Wh

Unschön ist auch, das die readings eine Stundennummerierung haben und somit in der Datenbank als einzelne readings erscheinen und nicht der Wert mit dem korrekten TIMESTAMP.

============================================================================================
Edit:
Jetzt wo du mich darauf aufmerksam gemacht hast, habe ich mir nochmal die rad1h Daten des DWD angeschaut. Die Werte folgen über den Tag einer relativ gleichförmigen Kurve - mal höher mal tiefer - wie das sehe. Da können eigentlich keine Bedingungen wie Regen, Wolken etc. enthalten sein.
Das muss noch mit rein. Mal gucken ob ich die Stelle bei dir finden zum Spicken.  :)
Ich habe einfach auf die Prozentuale Wahrscheinlichkeit für Wolken und Regen die "Heizungskurve" angewendet. Die hat jeweils einen Basiswert und einen Wert für die Steilheit.

Der Basiswert legt fest, bei welchem Eingangswert quasi der Faktor 1 zurück kommt und die Steigung legt die Aggressivität fest, wie stark auf eine Änderung des Eingangswertes reagiert werden soll.
Die Defaults findest Du im Wiki beim Device PV_Anlage_1_config

        $cloudk = ReadingsVal($logdevice."_config","forecast_cloudk",0) * -0.01 ;    <<< die -0.01 brauchte ich, weil es beim DUMMY keinen Picker für solche Werte gibt.
        if ($cloudk ne 0) {
          $cloudk_base = ReadingsVal($logdevice."_config","forecast_cloudk_base",0) ;
          $Solar_Correction_Cloud = round((1 + ($Solar_Cloud - $cloudk_base) * $cloudk / 100),3) ;
        };

============================================================================================
Das wäre mein momentanes DWD Device, wenn Du auch beide Forecasts parallel testen möchtest.
defmod DWD_Forecast DWD_OpenData
attr DWD_Forecast DbLogExclude .*
attr DWD_Forecast comment Version 2020.10.19 18:28
attr DWD_Forecast event-on-change-reading Rad1h,TTT,Neff,R600
attr DWD_Forecast forecastDays 1
attr DWD_Forecast forecastProperties Rad1h,TTT,Neff,R600,RRS1c,SunUp,SunRise,SunSet
attr DWD_Forecast forecastResolution 1
attr DWD_Forecast forecastStation P0178
attr DWD_Forecast group PV Eigenverbrauch
attr DWD_Forecast icon weather_rain_fog
attr DWD_Forecast room Informationen->Wetter,Strom->Photovoltaik
attr DWD_Forecast sortby 06
attr DWD_Forecast verbose 0

============================================================================================
@Heiko  im Photovoltaikforum wird für die Prognose auch irgend eine pvlib verwendet. Kilian ist da unterwegs. Was ich so gesehen habe werden in der pvlib direkt verschiedene Hersteller Module unterstützt, was wohl mit dem Wirkungsgrad und den Einbußen bei steigenden Temperaturen zu tun hat. Da war ich vor einem Jahr auch aktiv, jedoch hatte ich mich dann für den etwas simpleren Weg entschieden und mit plin auch das damals verwendete Python eliminiert. Nochmals vielen Dank an plin :-)

============================================================================================
Zitat von: DS_Starter
Wolken und Regen sind momentan noch nicht mit drin.
War der Auffassung dass der DWD es bereits in den Strahlungsdaten für den Standort berücksichtigt.
Liege ich da falsch ? Wenn ja, wie beziehst du diese Werte mit ein ?

Edit:
Jetzt wo du mich darauf aufmerksam gemacht hast, habe ich mir nochmal die rad1h Daten des DWD angeschaut. Die Werte folgen über den Tag einer relativ gleichförmigen Kurve - mal höher mal tiefer - wie das sehe. Da können eigentlich keine Bedingungen wie Regen, Wolken etc. enthalten sein.
Das muss noch mit rein. Mal gucken ob ich die Stelle bei dir finden zum Spicken.  :)

Ansonsten braucht das Modul im AutoMode eine gewisse Einschwingphase von ein paar Tagen. Dann sollten die Werte plausibel sein. Und ich feile ja weiter ...  ;)
[/quote]


============================================================================================
Ich habe zwei Anlagen. Also zwei Wechselrichter und 5 Strings. Dann unterschiedliche Ausrichten (Ost oder West) und unterschiedliche Dachneigungen (45 oder 20) Wenn ich dich richtig verstanden habe sind das nun 5 Devices. Womit ich ja noch klar kommen würde. Aber wenn ich die Wetterprognose pro String errechne muss ich ja bestimmt auch pro String die Erzeugung als Device angeben. Das kann ich soweit aber dann werden noch "Energieerzeugung pro Tag" und "aktueller Netzbezug" benötigt. Diese beiden Werte sind aber ja immer auf die ganze Anlage summiert. Wie funktioniert dann die  Berechnung bzw. was muss ich da tun damit es richtig berechet wird?
Das wäre eine super Vergleichsanlage für Wetter / Leistungs-Prognose
Auf Wunsch könnte ich recht schnell noch mehr als 3 Ausrichtungen ermöglichen.
EDIT: Der Wunsch ist schon umgesetzt, die Schleife läuft einfach jetzt bis kleiner gleich 5 .

Ich habe jedoch keine Autokorrektur vorgesehen, weil das bei Kostal im WR nicht so richtig funktioniert. Dort wird es zur "inteligenten Ladesteuerung" des Speichers eingesetzt.


============================================================================================
Zitat von: DS_Starter
@Christian,
Zitat
Wo bekommst Du denn die Nennleistung des Moduls her, die variiert schon ziemlich?
Die Globalstrahlung kJ/m2 wird in kWh umgerechnet und mit der Anlagengröße in m² multipliziert. Dieser Wert wird mit dem Wirkungsgrad der gesamten Anlage (Wirkungsgrad Module & Wirkungsgrad WR) und einem Faktor der Neigung multipliziert.
Multipliziert wird der Rohwert mit einem Korrekturfaktor der die sonstigen physikalischen Merkmale der Anlage wie Ausrichtung der Module für jede einzelne Stunde anpasst. Das kann man manuell machen (fix) oder die Autokorrektur einschalten welche die Soll/Ist-Werte ständig miteinander vergleicht und anpasst. Die max. Anpassung kann man über Attribut maxVariancePerDay einstellen.

An der Automatik baue ich gerade weiter.


============================================================================================
Der Standort ist ja bereits in der Definition/Konfiguration des DWD_OpenData hinterlegt.
Welchen Einfluß bzw. Faktoren sollte man denn zusätzlich einbeziehen die eine erneute Angabe des Standortes im Modul notwendig machen ?

Ja, solche individuellen Anlagenfaktoren werden durch die manuelle/automatische Angabe eines Korrekturfaktors neutralisiert.
Beim DWD liefert nicht jede Station den rad1h Wert, wodurch man unter Umständen einige viele Kilometer weg ist.
Ich wohne im Rhein Tal und da wäre der Höhenunterschied zum Odenwald doch schon über 550 Meter und die nächste DWD Station wäre Bensheim für beides :-)
Unsere Mitstreiter in der Schweiz haben da auf 5 Km Entfernung noch krassere Höhenunterschiede. Das ist also doch ziemlich wichtig.

Zitat
So etwas gibt es nicht. Man legt sich z.B. mehrere Devices an wenn man z.B. mehrere unterschiedlich ausgerichtete Anlagen/Strings hat.
Für das jeweilige Device kann man wieder manuell/automatisch eine Ergebniskorrektur ableiten (lassen) die sich aus den vorhergesagten Strahlungswerten und den tatsächlich erreichten Ergebnissen ergibt.
Puh, dann würde ich für meine Anlage schon drei Devices haben. Ein anderer Anwender in Norddeutschland hat 3 Ausrichtungen und 2 weitere Gebäude mit ziemlich starken Unterschieden, das sind dann 5 Devices :-(

Zitat
Später soll noch die SolCast API als mögliche Quelle eingebunden werden. Dort muss man sich bezüglich Lage ebenfalls festlegen. Im kostenfreien Abruf geht m.W. nur eine.
Bei drei Ausrichtungen mit drei Devices häufen sich dann auch noch die Abfragen, ich glaube 20 sind frei.

Zitat
Nein, das ist der Wirkungsgrad den der Hersteller für die Module angibt.
Da schau ich mal ins Datenblatt.

Zitat
Hast du eine Temperaturabhängigkeit mit eingebaut ? Wen ja, gib mir mal einen Tipp für das mathmatische Schema dafür. Dann würde ich es mit integrieren.
Ja, ist drin, mit einer Temperaturkurve von den Heizungsbauern :-)
Klappt gut, sogar mit einer geschätzten Temperatur. Ich nehme die TTT vom DWD +10° als Schätzwert. Am besten wäre jeweils ein Sensor pro Ausrichtung direkt unter den Modulen, aber ich stehe auf less Hardware.
Für den fc_0_aktuell wäre auch der Messfühler der Wärmepumpe am Lufteinlass gut. Die LWP steht bei mir im Süden in der prallen Sonne, da habe ich die +10° abgeleitet ;-)

Zitat
Wird in der sub calcPVforecast ab Zeile  2144 gemacht.
Wo bekommst Du denn die Nennleistung des Moduls her, die variiert schon ziemlich?

Zitat
Dann liefert dein DWD Device diese Daten nicht. Schau mal ob du dort im Attribut forecastProperties    SunUp,SunRise,SunSet mit gesetzt hast.
Okay, ich hatte da auf die nötigsten readings minimiert, das sollte dann ins Wiki rein.

Zitat
Man trägt ja nichts ein. Die Informationen laufen Stunde um Stunde vorwärts. Das sieht man auch an der Grafik. Sie zeigt immer einen Slot von 24h ab aktueller Zeit. Man kann es per Attr verringern wenn man mag.
Müsste ich mal überdenken. Ich frage am aktuellen Tag bereits die Forecast Werte vom nächsten Tag ab, um meine Entscheidungen noch am aktuellen Tag mit einfließen zu lassen. Wäre der nächste Tag schlecht, und heute noch Top, dann könnte ich die LWP im PV Modus überheizen lassen und hätte schon WW für den nächsten Tag. Auch der Pool ließe sich anders heizen. Beim BEV könnte man dann auch schon heute voll aufladen und bräuchte nicht morgen zu tanken.

Zitat
Wird alles automatisch bestimmt aus den DWD Daten.
Aber guter Hinweis dass der DWD im Tag fc0_* nochmal korrigiert. Das muss ich noch mit berücksichtigen denke ich.
Ich glaube der DWD liefert alle drei Stunden neue Daten, dann lösche ich in der DbLog den Forecast für heute und für morgen und schreibe die aktualisierten Werte wieder rein. Das war mit ein Grund die DbLog zu verwenden. Die Kurve von morgen kann dann auch schon angeschaut werden. Wenn der heutige Tag dann zu nächsten tag wechselt, bleibt die Kurve in der Datenbank stehen und man sieht direkt den Vergleich, was der DWD am Vortag prognostiziert hat und wie jetzt der aktuelle Tag aussieht. ... das war ganz schön wirr jetzt :-)

Ich habe nochmal ein Grafana Diagramm eines Top Prognose Tages angehängt.
Die rote Linie ist bereits am Vortag in die Datenbank geschrieben worden. An der hell-grünen Solar_Calculation_fc0 Linie sieht man, dass der DWD die Prognose nach oben korrigiert hat.


============================================================================================
Ja, hab ich und habe mir Anregungen geholt. Ich entnehme auch einiges aus dem Wiki des Projekts.
Unser Modul ist nicht auf eine Datenbank angewiesen und es ist ja jetzt schon durch die generische Wahl des Inverterdevices (z.B.) unabhängig vom Hersteller. Muß ja kein SMA-Inverter sein.
Das bringt mich auf die Idee dass ein User des Projektes bzw. ch.eick auch dieses Modul parallel installieren könnte und aus den Differenzen zwischen beiden evtl. Verbesserungen ableiten lassen.
Hallo zusammen,
wie gewünscht habe ich es jetzt parallel konfiguriert und mal ein List gemacht.
Das sieht schon mal echt monströs aus. Tolle Aufbereitung und die Konfigurationsführung gefällt mir echt gut.

My5cent:
1. Ich war erschlagen von dem vielen Code :-) , da sollte das Ergebnis ja auch besser werden :-)
2. HTMP Darstellung sieht schon mal gut aus, wobei ich normalerweise nur auf die Kurve schau

3. Noch habe ich nicht verstanden:
  - Warum der Standort nicht benötigt wird
  - Mit dem Standort ist auch eine Höhe über NN verbunden
  - Die Gebäudehöhe hat einen kleinen Einfluss auf die Winkel
  - Wo finde ich die Ausrichtung der Module, eventuell Gebäudenamen Ost, Süd, West, Garage, Scheune
    So könnte man sehen, welche Ausrichtung für die Leistung sorgt
  - moduleEfficiency ist das die Veränderung mit der Temperatur?
  - Wie wird die Leistung pro qm berücksichtigt?

  - SunRise und SunSet ist bisher auf 00:00 <<< Das lag an den fehlenden readings im DWD Device

4. Es wird keine DbLog benötigt, wie kann ich dann die Kurve für morgen eintragen?

5. Beim DWD wird fc0_10_* verwendet, das fände ich besser als NextHour

6. Wo kann ich den Forecast für morgen einstellen? Der DWD hat oft Abweichungen zwischen dem fc1_* und korrigiert das dann nochmal am entsprechenden Tag im fc0_*
« Letzte Änderung: 21 Januar 2021, 23:13:10 von ch.eick »
RPI4; Docker; CUNX; Eltako FSB61NP; 230V zentral verschaltet; SamsungTV H-Serie; DLNARenderer; TV.pl;  Sonos; Vallox; Luxtronik; 2x FB7490; Stromzähler mit DvLIR; wunderground; clever-tanken; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP

Offline plin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 812
    • FHEM-Landschaft von plin
Antw:Leistungsprognose für Wechselrichter
« Antwort #9 am: 22 Januar 2021, 07:26:47 »
Aus einem anderen Thread übernommen (weil vielleicht auch hier interessant):

Kennt sich jemand mit KI aus? Wenn man auf Basis der eigenen Aufzeichnungen (Forecast Rad1h, Sonne, Bedeckung, ... , Ist-Werte) die KI die Abhängigkeiten und Faktoren ermitteln lässt wäre das die Gold-Lösung.

Ich habe mich etwas schlau gemacht und gebastelt.  Aktuell lasse ich die DWD-Forcast-Werte 'Rad1h','Neff','R600','Azimuth','Altitude','SunD1','VV' sowie den Durchschnitt der erzeugten Leistung in das Modell einfließen.

In den Grafiken seht Ihr
- die erzeugte Leistung (Total_AC_active_power mit hoher zeitlcher Auflösung, gelbe Linie)
- den Mittelwert der verstrichenen Stunde dieser Leistung (yield, orangefarbene Linie)
- die Vorhersage des Modells (Forecast, Stundenbasis, blaue Linie)

Jetzt heißt es abwarten, denn meine Anlage ist erste Ende Oktober live gegangen und ich habe ca. 1.700 Datensätze als Basis für die Analyse. Aktuell kann die PV-Erzeung bei schlechtem Wetter schon recht gut vorhergesagt werden. Sommer muss noch trainiert werden  :).

VG plin
FHEM1 (Main) Raspi3b mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline eurofinder

  • Full Member
  • ***
  • Beiträge: 454
Antw:Leistungsprognose für Wechselrichter
« Antwort #10 am: 22 Januar 2021, 09:19:02 »
Gibt es einen Grund, warum "moduleTiltAngle" nur 3 fest definierte Werte annehmen kann? Über einen Schieberegler könnte das doch sonst auch stufenlos zwischen 0 - 90 Grad einstellbar gemacht werden.

Gruß
eurofinder
RPI3+; Raspbian Buster Lite; RPI-RF-MOD; piVCCU3, HMIP-eTRV-2, HmIP-SWDO, HmIP-SRH, HmIP-STHO, HmIP-SLO

Offline ch.eick

  • Hero Member
  • *****
  • Beiträge: 2002
Antw:Leistungsprognose für Wechselrichter
« Antwort #11 am: 22 Januar 2021, 15:11:35 »
Hallo zusammen,
für die Verwender von PV_Anlage_1_config
Ich habe die Defaults für Bewölkung und Regen man etwas angepasst, da dort noch alte Werte aus der Erprobungszeit im Wiki standen.
Gruß
   Christian
« Letzte Änderung: 22 Januar 2021, 17:03:56 von ch.eick »
RPI4; Docker; CUNX; Eltako FSB61NP; 230V zentral verschaltet; SamsungTV H-Serie; DLNARenderer; TV.pl;  Sonos; Vallox; Luxtronik; 2x FB7490; Stromzähler mit DvLIR; wunderground; clever-tanken; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP

Offline ch.eick

  • Hero Member
  • *****
  • Beiträge: 2002
Antw:Leistungsprognose für Wechselrichter
« Antwort #12 am: 22 Januar 2021, 19:11:38 »
So, ich habe heute ausgiebig mit Heiko telefoniert und unsere Zusammenarbeit in die Wege geleitet. Danke an Heiko für das Gespräch.

Natürlich wird das alles noch viel Zeit in Anspruch nehmen und noch mehr Tests.
Deshalb habe ich in meine Solar_forecast() Funktion noch einiges eingebaut
- Es werden nun 5 Ausrichtungen unterstützt, z.B. Ost, Sued, West, Schuppen, Garage, Carport, die Namen sind ja frei wählbar, wobei ich Umlaute eher meiden würde :-)
- Wenn man beim Aufruf die DbLog und das DBRep Device mit "none" angibt, wird nichts in die Datenbank geschrieben, oder auch nur bei DbRep ein "none" löscht halt nichts.
  Das ist dann für die Anwender, die keine Datenbank haben (wollen)
- Es gibt jetzt mehr readings, die in das Wechselrichter Device geschrieben werden
  - Solar_Calculation_fc[0|1]_hh   die Kalkulation für die jeweilige Stunde
  - Solar_Calculation_fc[0|1]_day   die Summe für den gesamten Tag
  - Solar_Calculation_fc0_4h    die Summe der nächsten 4 Stunden des aktuellen Tages
- Wer den Forecast nicht in seinem Wechselrichter Device haben möchte kann natürlich auch beim Aufruf jedes andere Device angeben

Einige Aufrufbeispiele
{Solar_forecast("LogDB","LogDBRep_delete_PV_Forecast","PV_Anlage_1","Solar_Calculation_fc","DWD_Forecast",0)}
{Solar_forecast("LogDB","none","PV_Anlage_1","Solar_Calculation_fc","DWD_Forecast",0)}
{Solar_forecast("none","none","PV_Anlage_1","Solar_Calculation_fc","DWD_Forecast",0)}
{Solar_forecast("LogDB","LogDBRep_delete_PV_Forecast","Ein_eigenes_Device","Ein_eigener_reading_Stamm","DWD_Forecast",0)}

Somit ist es nun einfacher die Einzelwerte beider Prognosevarianten zu vergleichen.
Heiko bildet im Modul ja ebenfalls diese Werte, auf die ich wegen der Datenbankmöglichkeiten verzichtet hatte.
Durch die Flexibilität beim Aufruf von Solar_forecast() kann Heiko jetzt sogar die Funktion testweise aus seinem Modul verwenden, ohne alles direkt einzubauen.
@Heiko, Du kannst Dich dazu gerne nochmal melden.

Dann sind auch noch einige Kommentare im Code eingefügt, damit man sich besser orientieren kann.

Diesen Code werde ich dann nach einigen Tests auch ins Wiki übertragen, jedoch wollte ich zumindest noch alles etwas beobachten.
EDIT: Der Code war bereits veraltet und steht nun im Wiki
« Letzte Änderung: 23 Januar 2021, 10:23:15 von ch.eick »
RPI4; Docker; CUNX; Eltako FSB61NP; 230V zentral verschaltet; SamsungTV H-Serie; DLNARenderer; TV.pl;  Sonos; Vallox; Luxtronik; 2x FB7490; Stromzähler mit DvLIR; wunderground; clever-tanken; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP

Offline Mumpitz

  • Full Member
  • ***
  • Beiträge: 370
Antw:Leistungsprognose für Wechselrichter
« Antwort #13 am: 22 Januar 2021, 19:56:00 »
Hallo zusammen

Muss man etwas beachten um das Chache File zu nutzen?
Wenn ich
get SolarForecast pvhistory aufrufe erhalte ich die Meldung:
PV cache is empty.obwohl dort bereits 3 Tage drinn sein müssten!

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7496
Antw:Leistungsprognose für Wechselrichter
« Antwort #14 am: 22 Januar 2021, 20:09:28 »
Zitat
Muss man etwas beachten um das Chache File zu nutzen?
Nein, das wird automatisch genutzt.

Schau mal ob du bei dir dieses File findest:

.../FHEM/FhemUtils/PVH_SolarForecast_<dein Devicename>

Dieses File wird bei einem stop/start geschrieben und wieder eingelesen. Wenn du das File nicht findest schau mal ins Log ob es beim Stop/start Fehlerausschriften gibt.
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf VM
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter