Leistungsprognose für Wechselrichter

Begonnen von ch.eick, 18 Januar 2021, 08:35:46

Vorheriges Thema - Nächstes Thema

Wzut

Sorry aber das ist eine schlechte Liste ! Das sind in Wahrheit etliche mehr, so fehlen da z.B. alle die ich erfolgreich getestet hatte in meinem Umkreis.
Daher besser die MOSMIX Karte verwenden und vom Wohnort aus in alle Richtungen immer weiter weg testen.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

ioT4db

#271
ok, dann werd ichs wieder rausnehmen. aber irgendwo muss es doch ne Liste mit Rad1h geben, echt zum verzweifeln...
FHEM auf Synology mittels Docker,  Jeelink-Clone 1x für PCA301 und 1x für Lacrosse, THZ304SOL, Homematic: CUL_HM / M-MOD-RPI-PCB, Pushover, Xiaomi s50

dk3572

#272
Zitat von: DS_Starter am 09 März 2021, 22:11:53
Nabend Dieter,

klappt bei mir tadellos mit der SMAInverter Version

FVERSION 76_SMAInverter.pm:v2.14.1-s23909/2021-03-07

und ohne dem Workaround mit dem userreading. Ich benutze jetzt wieder

currentInverterDev MySTP_5000 pv=total_pac:kW etoday=etoday:kWh

Das sind Beispiel History-Werte von gestern und heute:


09 => 00 => pvreal: 0, pvforecast: 0
      01 => pvreal: 0, pvforecast: 0
      02 => pvreal: 0, pvforecast: 0
      03 => pvreal: 0, pvforecast: 0
      04 => pvreal: 0, pvforecast: 0
      05 => pvreal: 0, pvforecast: 0
      06 => pvreal: 2, pvforecast: 0
      07 => pvreal: 304, pvforecast: 23
      08 => pvreal: 1541, pvforecast: 351
      09 => pvreal: 1941, pvforecast: 635
      10 => pvreal: 3142, pvforecast: 703
      11 => pvreal: 3871, pvforecast: 1484
      12 => pvreal: 4519, pvforecast: 1769
      13 => pvreal: 4140, pvforecast: 1365
      14 => pvreal: 1773, pvforecast: 1374
      15 => pvreal: 922, pvforecast: 1232
      16 => pvreal: 531, pvforecast: 892
      17 => pvreal: 131, pvforecast: 203
      18 => pvreal: 1, pvforecast: 86
      19 => pvreal: 0, pvforecast: 0
      20 => pvreal: 0, pvforecast: 0
      21 => pvreal: 0, pvforecast: 0
      22 => pvreal: 0, pvforecast: 0
      23 => pvreal: 0, pvforecast: 0
08 => 00 => pvreal: 0, pvforecast: 0
      01 => pvreal: 0, pvforecast: 0
      02 => pvreal: 0, pvforecast: 0
      03 => pvreal: 0, pvforecast: 0
      04 => pvreal: 0, pvforecast: 0
      05 => pvreal: 0, pvforecast: 0
      06 => pvreal: 0, pvforecast: 0
      07 => pvreal: 21, pvforecast: 0
      08 => pvreal: 637, pvforecast: 240
      09 => pvreal: 777, pvforecast: 563
      10 => pvreal: 796, pvforecast: 869
      11 => pvreal: 3034, pvforecast: 1607
      12 => pvreal: 4314, pvforecast: 2313
      13 => pvreal: 3566, pvforecast: 2952
      14 => pvreal: 3091, pvforecast: 2167
      15 => pvreal: 3122, pvforecast: 1600
      16 => pvreal: 1606, pvforecast: 693
      17 => pvreal: 284, pvforecast: 432
      18 => pvreal: 0, pvforecast: 143
      19 => pvreal: 0, pvforecast: 0
      20 => pvreal: 0, pvforecast: 0
      21 => pvreal: 0, pvforecast: 0
      22 => pvreal: 0, pvforecast: 0
      23 => pvreal: 0, pvforecast: 0


Komisch ... wenn es bei dir nicht klappt kannst du das userreading weiterhin verwenden. Verstehe es allerdings nicht wenn es doch bei mir funktioniert.

Grüße,
Heiko

Hallo Heiko,

warum auch immer, aber nun funktioniert es bei mir auch ohne das userReading.

Was noch unklar ist, sind die Werte fast immer um 01

11 => 00 => pvreal: 0, pvforecast: 0
      01 => pvreal: 12056, pvforecast: 0
      02 => pvreal: 0, pvforecast: 0


Es ist auf jeden Fall nicht wie von friesenjung vermutet die Summe aller Werte vom Vortag.

Evtl. erinnerst du dich noch an deinen Vorschlag in meiner DBLog valueFn.

{
   if ($DEVICE eq "SMA_Wechselrichter") {
     if( ($READING eq "etoday" || $READING eq "etotal") && $VALUE > 4000000 ) {
       Log3 ($DEVICE, 1, "Reading: $READING with Value: $VALUE was ignored and not logged. ");
       $IGNORE = 1;
     }
   }
}


Ist das in meiner pvHistory immer um 01 ein ähnliches Problem?

VG Dieter

Edit:

Das glaub ich jetzt nicht.
Kaum hab ich das geschrieben und guck eben in die pvHistory, Werte pvreal = 0
Erst nach einem setreading SolarForecast Today_Hour01_PVreal 0 Wh werden wieder Werte geschrieben.

ioT4db

Zitat von: dk3572 am 11 März 2021, 07:01:23
...
Es ist auf jeden Fall nicht wie von friesenjung vermutet die Summe aller Werte vom Vortag.
...
Moin,
dann ist es wohl noch ein anderes Verhalten. Bei mir ist es definitiv bis auf die letzte Stelle identisch mit dem PV-Ertrag aus dem Inverter-Modul vom Vortag (hab in etwa die letzten 10 Tage überprüft).

VG
FHEM auf Synology mittels Docker,  Jeelink-Clone 1x für PCA301 und 1x für Lacrosse, THZ304SOL, Homematic: CUL_HM / M-MOD-RPI-PCB, Pushover, Xiaomi s50

thobo

Hallo Dieter,

der Wert in der ersten Stunde entspricht nicht der Summe in SolarForecast aufgelisteten Werte des Vortages, sondern dem gesamt Ertrag des Vortages deines Inverters.

Fakt ist, wenn immer noch die Stunde 1 einen Wert ungleich 0 hat, dann funktioniert das immer noch nicht bei dir! Das einzige was das heißt, ist, dass dein Vortag weit weniger Strom geliefert hat, als der aktuelle Tag. Denn sobald der Ertrag des Vortages (der in Stunde 1 steht) beim aktuellen Tag überschritten wird, gibt es auch wieder korrekte Werte in den einzelnen Stunden des laufenden Tages. Das kann natürlich ein paar Stunden dauern.

Viele Grüße
Thomas

Wzut

Hier mein erster Vorschlag für eine geänderte HTML Grafik.
Benötigt werden drei neue Attribute :
history_hour:slider,-12,-1,0 ".
"Val1:forecast,real,consumption ".
"Val2:forecast,real,consumption ".

history_hour bestimmt wie weit die Startstunde in die Vergangenheit verschoben werden soll.
0 = Start aktuelle Stunde , wie bisher
Val1 muss vorbesetzt werden , Val2 wird benötigt wenn ein Ausgabetyp gewählt wurde der zwei Werte erfordert -> pvco & diff
So kann der User selbst bestimmen welche Werte wie angezeigt werden sollen, die Farben sind wie bisher zu wählen.
Allerdings könnte man die Farb Attribute auch umbennen um einen direkten Bezug zu Val1 & Val2 herzustellen.
Wird der Layout Typ  pvco oder diff ausgewählt und Val1 und Val2 auf den geleichen Wertetyp (z.b. beide forcast) wird automatisch wieder der typ pv verwendet da es keinen Sinn macht zweimal den gleichen Typ zu nutzen. consumption ist z.Z. noch nicht in Funktion (siehe meinen anderen Post , Thema neuer hash) , ebenso wird für Stunden in der Vergangenheit kein Wetter Icon angezeigt.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Wzut

#276
Leider ist mir gestern ein kleiner Fehler durchgegangen, er betrifft vier Code Zeilen in denen die Variable $future verwendet wird.
Richtig berechnet und abgefragt ist :
$future = 1 if ($i >= abs($offset));

        $val1   = (!$future) ? $val1 : ReadingsNum($name, 'NextHour'.$nh.'_PVforecast',  0);
        $val2   = (!$future) ? $val2 : 0;
        $we{$i} = (!$future) ? -1    : $hash->{HELPER}{'NextHour'.$nh.'_WeatherId'} if($weather);

danach kann man auch den Bereich von history_hour von nur -12 problemlos bis auf -23 erhöhen.

Edit : noch ein Vorschlag für die heutigen vier Layout Typen :
single, double, diff
single = nur ein Wert -> war pv & co
double = zwei Werte im direkten Vergleich -> pvcn
diff = auch zwei Werte , aber andere Darstellung

die Farbnamen sollten zu den Werten passen , z.B. Val1 und Val1Color - Val2 und Val2Color
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Wzut

@Heiko, da ist ein kleines Problem das ich noch nicht so ganz verstehe : Wann werden die Berechnungen ausgeführt ?
Ich hatte erwartet das mit jedem Event eines der Geräte in Notifydev komplett durchgerechnet wird, aber so kurz wie die sub Notify ist kann das ja nicht sein.
Ich sehe das die aktuellen Werte des HM und des WR sich nicht mit den Ausgabe im Header decken, bzw. der Zeitpunkt Stand fast immer um einige Minuten hinter her hinkt.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

eurofinder

Wäre so etwas nicht noch eine schöne Ergänzung: https://forum.fhem.de/index.php/topic,119440.msg1138772.html#msg1138772
Die Richtungsströme optisch darzustellen von PV-Anlage, Verbrauch, Einspeisung und Speicher?

Ansonsten tolle Arbeit, die ihr hier leistet.

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

DS_Starter

Moin zusammen,

@thobo
Zitat
Allerdings habe ich hier das Phänomen, dass meine Vorhersage immer genau eine Stunde später anfängt, als mein Inverter schon Strom produziert. Gleiches nur umgekehrt habe ich am Abend. Während SolarForecast noch Erträge voraussagt, ist im realen Leben die Sonne schon lange untergegangen.
Ja, ich erinnere mich dunkel dass ch.eick davon sprach dass er in seiner Lösung den Wert für die Forecast um eine Stunde vorgezogen hat. Wenn man genau hinschaut passen die Werte insgesamt besser zueinander wenn man diese Verschiebung gedanklich vornimmt.

Ich werde das mal programmtechnisch vornehmen.

@Wzut:
Zitat
@Heiko, das mit den beiden neuen hashes unter $data ist super, die elende Rechnerei hat sich stark vereinfacht. Mein einer Fehler an dem ich so festhing hat sich damit auch erschlagen. Und du kennst ja den Spruch mit dem kleinen Finger und der ganzen Hand :
Bitte noch zwei hashes in dieser Art :
Nr 1 müsste die Wetterdaten aufnehmen, denn z.Z. kann ich für Vergangenheit kein Icon anzeigen da ich keine Wetter History habe.
Nr. 2 den tatsächlichen Verbrauch
Klar, mach ich.  :)

Zitat
Dann noch eine Frage dazu : der(die) neue hash ist ja ein 24 Stunden Ringpuffer, wie schaut das aus mit den Werten der aktuellen Stunde,
wird dieser Wert immer aktuell frisch gehalten oder ist er der alte Wert von gestern und wird erst mit Ablauf der aktuellen Stunde überschrieben ? 
Ist aktuell.

Zitat
@Heiko, da ist ein kleines Problem das ich noch nicht so ganz verstehe : Wann werden die Berechnungen ausgeführt ?
Die Werte werden in Abständen des Attribut interval durchgerechnet. Anfangs habe ich über Notifydev mit Events gearbeitet, habe aber festgestellt dass als Reaktion darauf zuviele Events durch Solarforecast generiert werden. Habe aber Notifydev noch drin weil ich vermute es an der einen oder anderen Stelle noch zu brauchen. Momentan liegt nichts dahinter, d.h. die sub Notify ist de facto leer.

@dk3572
Zitat
01 => pvreal: 12056, pvforecast: 0
Wie friesenjung schon schrieb ist es der Wert von etoday aus Inverter-Modul vom Vortag. Es steht dort zu lange drin und müsste um 1 Uhr des aktuellen Tages 0 sein. Deswegen die Verwendung des Userreadings um diesen Fehler zu umgehen. Mit der aktuellen Version des SMAInverter (76_SMAInverter.pm:v2.14.1-s23909/2021-03-07) ist dieser Fehler bei meinem STP5000 allerdings behoben.


Werde mich jetzt mal wieder mit etwas Weiterentwicklung befassen...  :)

Grüße,
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

@eurofinder,

also das finde ich eine super Idee und schöne Ergängung 8)
@Wzut, dass wäre doch was für dich !?   :D

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

DS_Starter

@Wzut

Zitat
Nr 1 müsste die Wetterdaten aufnehmen, denn z.Z. kann ich für Vergangenheit kein Icon anzeigen da ich keine Wetter History habe.
Brauchst du alles, also WeatherId, WeatherTxt, CloudCover, RainProb, oder nur ein Teil davon ?
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

ch.eick

Zitat von: DS_Starter am 13 März 2021, 09:20:43
@thoboJa, ich erinnere mich dunkel dass ch.eick davon sprach dass er in seiner Lösung den Wert für die Forecast um eine Stunde vorgezogen hat. Wenn man genau hinschaut passen die Werte insgesamt besser zueinander wenn man diese Verschiebung gedanklich vornimmt.

Ich werde das mal programmtechnisch vornehmen.
Der DWD gibt den Wert der Stunde erst am Ende der Stunde an, also muss man es 1 Stunde nach vorne holen.

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

Wzut

Zitat@Wzut, dass wäre doch was für dich !?
Brauchst du alles, also WeatherId, WeatherTxt, CloudCover, RainProb, oder nur ein Teil davon ?
a. jaja der papa ist schon ein Fuchs und hat oft gute Ideen :) Das Bsp ist aber für TabletUI, aus dem Stand habe ich noch keinen Plan das so in FHEMWEB darzustellen, aber ich werde es mir die Tage mal in Ruhe anschauen wenn die anderen Fehler gefixt sind (habe ich doch heute morgen schon wieder einen gefunden :(  )

b. für die reine Icon Anzeige mit Hoover reicht WeatherId und WeatherTxt völlig aus.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

DS_Starter

@Wzut, in meinm contrib liegt eine Version mit zusätzlichen Hashes:

$data{$hash->{TYPE}}{$name}{weather} - Wetterdaten (hab alles eingefügt, vllt. kann man das noch brauchen)


2021.03.13 13:21:32.434 1: SolCast2 - Weather forecast Hash: {
  '14' => {
            'id' => '80',
            'rainprob' => '33.00',
            'txt' => 'leichter Regenschauer',
            'cloudcover' => '82'
          },
  '07' => {
            'id' => '3',
            'rainprob' => '16.00',
            'txt' => 'Bewölkung zunehmend',
            'cloudcover' => '81'
          },
  '16' => {
            'id' => '80',
            'txt' => 'leichter Regenschauer',
            'cloudcover' => '72',
            'rainprob' => '27.00'
          },
  '23' => {
            'txt' => 'Bewölkung unverändert',
            'cloudcover' => '68',
            'rainprob' => '12.00',
            'id' => 102
          },
  '02' => {
            'id' => 102,
            'cloudcover' => '63',
            'txt' => 'Bewölkung unverändert',
            'rainprob' => '3.00'
          },
  '10' => {
            'cloudcover' => '87',
            'txt' => 'durchgehend leichter Regen',
            'rainprob' => '27.00',
            'id' => '61'
          },
  '18' => {
            'id' => '80',
            'rainprob' => '17.00',
            'cloudcover' => '66',
            'txt' => 'leichter Regenschauer'
          },
  '01' => {
            'rainprob' => '2.00',
            'cloudcover' => '63',
            'txt' => 'Bewölkung unverändert',
            'id' => 102
          },
  '09' => {
            'id' => '80',
            'cloudcover' => '87',
            'txt' => 'leichter Regenschauer',
            'rainprob' => '23.00'
          },
  '05' => {
            'id' => '2',
            'rainprob' => '6.00',
            'txt' => 'Bewölkung unverändert',
            'cloudcover' => '70'
          },
  '20' => {
            'txt' => 'Bewölkung unverändert',
            'cloudcover' => '68',
            'rainprob' => '8.00',
            'id' => 102
          },
  '13' => {
            'id' => '80',
            'rainprob' => '31.00',
            'cloudcover' => '85',
            'txt' => 'leichter Regenschauer'
          },
  '11' => {
            'id' => '80',
            'rainprob' => '30.00',
            'cloudcover' => '85',
            'txt' => 'leichter Regenschauer'
          },
  '15' => {
            'rainprob' => '32.00',
            'cloudcover' => '75',
            'txt' => 'leichter Regenschauer',
            'id' => '80'
          },
  '19' => {
            'cloudcover' => '68',
            'txt' => 'Bewölkung unverändert',
            'rainprob' => '12.00',
            'id' => '2'
          },
  '22' => {
            'rainprob' => '14.00',
            'txt' => 'Bewölkung unverändert',
            'cloudcover' => '69',
            'id' => 102
          },
  '03' => {
            'id' => 102,
            'txt' => 'Bewölkung unverändert',
            'cloudcover' => '63',
            'rainprob' => '4.00'
          },
  '17' => {
            'cloudcover' => '68',
            'txt' => 'leichter Regenschauer',
            'rainprob' => '23.00',
            'id' => '80'
          },
  '21' => {
            'id' => 102,
            'rainprob' => '11.00',
            'txt' => 'Bewölkung unverändert',
            'cloudcover' => '68'
          },
  '04' => {
            'txt' => 'Bewölkung unverändert',
            'cloudcover' => '68',
            'rainprob' => '5.00',
            'id' => 102
          },
  '08' => {
            'rainprob' => '26.00',
            'cloudcover' => '82',
            'txt' => 'durchgehend leichter Regen',
            'id' => '61'
          },
  '06' => {
            'rainprob' => '10.00',
            'cloudcover' => '77',
            'txt' => 'Bewölkung unverändert',
            'id' => '2'
          },
  '00' => {
            'txt' => 'Bewölkung unverändert',
            'cloudcover' => '64',
            'rainprob' => '3.00',
            'id' => 102
          },
  '12' => {
            'txt' => 'leichter Regenschauer',
            'cloudcover' => '86',
            'rainprob' => '33.00',
            'id' => '80'
          }
}


$data{$hash->{TYPE}}{$name}{current} - enthält aktuellen Verbrauch und auch PV Generation


2021.03.13 13:21:32.435 1: SolCast2 - current values Hash: {
  'generation' => '2056',
  'consumption' => '0'
}
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