76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

@all,

morgen früh wird es ein wichtiges Update für Nutzer von DWD_OpenData geben.

Die letzte Zeit mit fast durchweg optimalen Sonnenschein habe ich beobachtet und mich gefragt, wieso die Prognose bei Verwendung von DWD_OPenData (Device) immer schlechter gegenüber von OpenMeteo DWD ICON wurde.  Es wurden tendienziell überhöhte Werte gegenüber der real erzeugten Energie prognostiziert, sodass die Korrekturfaktoren immer weiter nach unten korrigierten.

Ich habe einen Implementierungsfehler identifiziert, der sich in längeren Phasen mit Bewölkungen <= 10 besonders bemerkbar macht.

Da diese Codekorrektur sehr wichtig für diesen Userkreis ist, habe ich diese Version als Minor Version 1.54.0 und nicht als einfachen Bugfix eingecheckt. Die Version ist auch sofort in meinem contrib zum Download verfügbar.

LG,
Heiko

[DS_Starter]

Ich denke, wenn eine weitere Auffächerung einmal möglich ist wie wir schon einmal angesprochen hatten, dann dürfte es mit der Übersicht kein Problem geben.

Ja, keine Frage. Das ist dann grafisch/programmtechnisch nochmal eine höhere Herausforderung.
Seitens der Priorität würde ich aktuell eher Wert auf eine inhaltliche Weiterentwicklung/Verbesserung der KI Unterstützung im Bereich der Verbrauchsprognose u. ggf. PV-Prognose legen.
20 Consumer könnten wir wahrscheinlich mit der aktuellen Grafikstruktur noch unterbringen. Ich probiere das mal.

LG,
Heiko

[roadghost]

Hallo Ihr Sonnenanbeter.

Ich hab ne Frage, und zwar habe ich seit Sonntag ein Problem mit meinem alexa FHEM, und nach posting im alexa Unterforum !könnte! das SolarForecast mit eine Ursache sein.

Situation:

Nachts, so gegen 00:09 Uhr, stirbt mein alexa FHEm, und meldet: "alexafhem stopped; failed to connect to fhem: error: socket hang up".

Im alexa log ist nichts auffälliges, aber im FHEM log:

2025.07.05 00:09:54.783 3: PV_Prognose - old backup file './FHEM/FhemUtils/PVH_SolarForecast_PV_Prognose_2025_07_02_00_09_03' deleted
2025.07.05 00:09:54.783 3: PV_Prognose - old backup file './FHEM/FhemUtils/PVC_SolarForecast_PV_Prognose_2025_07_02_00_09_03' deleted
2025.07.05 00:09:55.225 1: Wide character in syswrite at FHEM/TcpServerUtils.pm line 563.

Laut @passibe ist in dem log eine Zeile nach diesem Eintrag etwas zu finden, was möglicherweise hier auf dieses Modul hinweist.

Achtung, eintrag hier gekürzt, zu viele Zeichen, Forum-Software macht das nicht mit:

2025.07.05 00:09:55.263 1: txt:72:84:84:80:47:49:46:49:32:50:48:48:32:79:75:13:10:67:111:110:116:101:110:116:45:84:121:112:101:58:32:97:112:112:108:105:99:97:116:105:111:110:47:111:99:116:101:116:45:115:116:114:101:97:109:59:32:99:104:97:114:115:101:116:61:85:84:70:45:56:13:10:13:10:91:34:80:86:95:80,off:0


Kann ich weitere Daten bereitstellen, um das genauer zu analysieren ? Oder ist das SolarForecast hier unschuldig ?

Viele Grüße

[rolf]

Ich werde versuchen die möglichen Consumer auf 20 hochzuziehen. Ist eine schöne runde Zahl  , schauen wir mal wie gut sie sich einfügen lassen.

Hallo Heiko,

super, freut mich - vielen Dank vorab !

Gruß,
Rolf

[DS_Starter]

@roadghost,

Nachts, so gegen 00:09 Uhr, stirbt mein alexa FHEm, und meldet: "alexafhem stopped; failed to connect to fhem: error: socket hang up".

Ein Zusammenhang mit dem SF-Modul ist sehr unwahrscheinlich, weil:

- im SF-Modul TcpServerUtils.pm nicht verwendet wird
- die Funktion TcpServer_WriteBlocking (das ist die Sub in der sich die Fehlerzeile 563 befindet) im Modul nicht verwendet/aufgerufen wird
- ich mir keinen Zusammenhang zwischen dem Löschen von 2 Dateien auf BS Ebene und einem TCP-Aufruf denken kann
- meine Logausgaben grundsätzlich anders aufgebaut sind als:

Code Auswählen Erweitern

2025.07.05 00:09:55.263 1: txt:72:84:84:80:47:49:46:49:32:50:48:48:32:79:75:13:10:67:111:110:116:101:110:116:45:84:121:112:101:58:32:97:112:112:108:105:99:97:116:105:111:110:47:111:99:116:101:116:45:115:116:114:101:97:109:59:32:99:104:97:114:115:101:116:61:85:84:70:45:56:13:10:13:10:91:34:80:86:95:80,off:0

Du kannst allerdings probehalber die Erstellung und Bereinigung der Backup-Files im SF-Device einfach mal als Negativtest ausschalten indem du im Attr plantControl explizit backupFilesKeep=0 setzt.

LG,
Heiko

[Burny4600]

Hallo Heiko,

ich habe ein Problem mit dem Consumer 07. Dieser Consumer verursacht eine ständige Wiederholung unter Event monitor.

Code Auswählen Erweitern

2025-07-05 15:40:18.116 Global global ATTR AB_WS_SS consumer07 AB_POOLD:Aussenbereich Pool auto=automatic etotal=Active_Energy_Day__kWh:kWh icon=scene_pool interruptable=0 mintime=240 mode=must notafter=21 off=AUS on=EIN pcurr=Active_Power__W:W:2 power=0 swoffcond=AB_POOLD:SF_Abort:1 swstate=state:EIN:AUS type=other
Wenn ich die Definition ändern möchte, wird diese Änderung nicht übernommen.
Die SolarForcast Version ist V1.53.3. Mit der V1.53.0 ist mir das noch nicht aufgefallen.

Es kommt auch ständig immer wieder Connention lost.
Auch im Log sind ständige Einträge vorhanden.

Code Auswählen Erweitern

2025.07.05 15:19:54.519 3: [Freezemon] myFreezemon: possible freeze starting at 15:19:52, delay is 2.518 tmr-CODE(0x3658698)(ProcessRequestQueue) tmr-CODE(0x3658698)(ProcessRequestQueue) tmr-FHEM::SolarForecast::centralTask(N/A)
2025.07.05 15:19:57.236 3: [Freezemon] myFreezemon: possible freeze starting at 15:19:55, delay is 2.235 possibly caused by: tmr-FHEM::SolarForecast::singleUpdateState(N/A) tmr-CODE(0x3658698)(ProcessRequestQueue) tmr-CODE(0x3699788)(GetUpdate) tmr-CODE(0x36bc650)(ResponseTimeout) tmr-FHEM::SolarForecast::releaseCentralTask(AB_WS_SS) tmr-FHEM::SolarForecast::createAssociatedWith(AB_WS_SS) tmr-CODE(0x36bc650)(ResponseTimeout) tmr-CODE(0x3699788)(GetUpdate) tmr-CODE(0x3699788)(GetUpdate) tmr-CODE(0x3699788)(GetUpdate) tmr-STELLMOTOR_GetUpdate(AB_FR_HZG_R2H)
2025.07.05 15:20:03.327 3: [Freezemon] myFreezemon: possible freeze starting at 15:20:02, delay is 1.326 possibly caused by: tmr-CODE(0x3658698)(ProcessRequestQueue) tmr-FHEM::SolarForecast::singleUpdateState(N/A) tmr-CODE(0x3658698)(ProcessRequestQueue) tmr-CODE(0x36bc650)(ResponseTimeout) tmr-CODE(0x3658698)(ProcessRequestQueue) tmr-CODE(0x3658698)(ProcessRequestQueue) tmr-FHEM::SolarForecast::releaseCentralTask(AB_WS_SS) tmr-CODE(0x3699788)(GetUpdate) tmr-CODE(0x3658698)(ProcessRequestQueue)
2025.07.05 15:20:46.259 3: [Freezemon] myFreezemon: possible freeze starting at 15:20:45, delay is 1.258 possibly caused by: tmr-FHEM::SolarForecast::centralTask(N/A) tmr-CODE(0x36bc650)(ResponseTimeout) tmr-CODE(0x3658698)(ProcessRequestQueue) tmr-SYSMON_Update(sysmon) tmr-FHEM::SolarForecast::singleUpdateState(N/A) tmr-FHEM::SolarForecast::releaseCentralTask(AB_WS_SS) tmr-PID20_Calc(N/A) tmr-PID20_Calc(N/A) tmr-FHEM::SolarForecast::createAssociatedWith(AB_WS_SS) tmr-CODE(0x3658698)(ProcessRequestQueue)
2025.07.05 15:20:48.961 3: [Freezemon] myFreezemon: possible freeze starting at 15:20:47, delay is 1.96 possibly caused by: (GetUpdate) tmr-CODE(0x3658698)(ProcessRequestQueue) tmr-CODE(0x3658698)(ProcessRequestQueue) tmr-CODE(0x3699788)(GetUpdate) tmr-FHEM::SolarForecast::centralTask(N/A) tmr-CODE(0x36bc650)(ResponseTimeout)
2025.07.05 15:20:50.911 3: [Freezemon] myFreezemon: possible freeze starting at 15:20:49, delay is 1.91 possibly caused by: tmr-FHEM::SolarForecast::singleUpdateState(N/A) tmr-CODE(0x3658698)(ProcessRequestQueue) tmr-CODE(0x3658698)(ProcessRequestQueue) tmr-CODE(0x3658698)(ProcessRequestQueue) tmr-FHEM::SolarForecast::releaseCentralTask(AB_WS_SS) tmr-FHEM::SolarForecast::createAssociatedWith(AB_WS_SS) tmr-CODE(0x3699788)(GetUpdate) tmr-CODE(0x3658698)(ProcessRequestQueue)

Ein Löschen des Consumer 07 mit Neustart löst das Problem zwar, aber wenn ich den Consumer 07 neu definiere wird der alte Eintrag wieder übernommen.
Wie kann ich die alte Definition entfernen?

Eines habe ich noch herausgefunden.
Der Consumer 07 lässt sich ändern, wenn ich den Eintrag für Consumer 07 unter ctrlUserExitFn entferne. Dann bleibt auch die Definition von Consumer 07 nach einem Neustart von FHEM vorhanden.

Mache ich den Eintrag unter ctrlUserExitFn

Code Auswählen Erweitern

{ 
  ::pumpPoControl ($name, '07', 180);
}wird unter Consumer 07 die alte Konfiguration eingetragen.

Warum ist das nur bei Consumer 07?

[DS_Starter]

Warum ist das nur bei Consumer 07?

Keine Ahnung 

Wie sieht die sub pumpPoControl denn genau aus? Poste mal bitte den kompletten Code.

[DS_Starter]

@Chris,

ich sehe gerade, du hast den Alias falsch angegeben. Er darf keine Leerzeichen enthalten.

Lt Commandref:

Im optionalen Alias sind Leerzeichen durch '+' zu ersetzen (z.B. 'Ein+toller+Alias').

Also

Code Auswählen Erweitern

... AB_POOLD:Aussenbereich+Pool auto=automatic


[Burny4600]

Ich habe den Alias in der üblichen Form mit &nbsp; definiert. Wurde jetzt auf AB_POOLD:Aussenbereich+Pool geändert.

Consumer 07

Code Auswählen Erweitern

AB_POOLD:Aussenbereich+Pool
icon=scene_pool
type=other
asynchron=1
power=0 pcurr=Active_Power__W:W:2 etotal=Active_Energy_Day__kWh:kWh
on=EIN off=AUS swstate=state:EIN:AUS auto=automatic mode=must
interruptable=1 swoffcond=AB_POOLD:SF_Abort:1
mintime=240 notbefore=03:00 notafter=21:00
Eintrag in der 99_mySolarForecastUtils.pm

Code Auswählen Erweitern

############################################################################
#   Pumpensteuerung AB-Pool
############################################################################
sub pumpPoControl {
  my $name  = shift;
  my $c     = shift;                                                              # Nummer des Verbrauchers, z.B. 07
  my $mneed = shift;                                                              # Soll-Pumpenzeit, z.B. 300 (Minuten)
 
  $c            = sprintf "%02d", $c;                                             # falls führende 0 vergessen wird
  my $pump      = FHEM::SolarForecast::ConsumerVal ($name, $c, 'name', '');       # Devicename der Pumpe
  my $plstate   = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planstate', '');
  my $simpCstat = FHEM::SolarForecast::simplifyCstate ($plstate);                 # akt. Status des Consumers
  my $dhash     = $defs{$pump};

  readingsSingleUpdate ($dhash, 'SF_Abort', 0, 0);                                # default keine Zyklusbeendigung

  if ($simpCstat =~ /started|interrupt|continu/xs) {                              # Vorgang ist gestartet
      my $t       = time;
      my $startts = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchon',  '');
      my $stopts  = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planswitchoff', '');
      return if(!$startts || !$stopts);
     
      my $mrest = sprintf '%.0f', (($stopts - $t) / 60);                          # Restlaufzeit (Minuten)     
      my $dt     = FHEM::SolarForecast::timestringsFromOffset ($startts, 0);
      my $day    = $dt->{day};
      my $hstart = int $dt->{hour} + 1;                                           # lfd. Stunde bei Pumpen Start
      my $msum   = 0;
     
      for my $hod (1..24) {                                                       # bisherige Laufzeit der Pumpe
          next if($hod < $hstart);
          $hod = sprintf "%02d", $hod;
          $msum += FHEM::SolarForecast::HistoryVal ($name, $day, $hod, "minutescsm${c}", 0);
      }
    
      if ($msum >= $mneed) {
          readingsSingleUpdate ($dhash, 'SF_Abort', 1, 0);                        # vorfristige Zyklusbeendigung
          return;
      }

      if ($mrest >= ($mneed - $msum)) {                       
          fhem ("set $name attrKeyVal consumer$c interruptable=1");               # Interrupt-Freigabe
      }
      else {                       
          fhem ("set $name attrKeyVal consumer$c interruptable=0");               # keine Interrupt-Freigabe
      }
  }
 
return;
}
Jedenfalls liegt es nicht an dem Pseudo Leerzeichen.
Sowie ich wieder das Attribut ctrlUserExitFn ergänze

Code Auswählen Erweitern

{ 
  ::pumpPoControl ($name, '07', 180);
}
steht sofort wieder der alte Eintrag im Consumer 07

Alte Consumer 07 Definition

Code Auswählen Erweitern

AB_POOLD:Aussenbereich Pool
asynchron=1
auto=automatic
etotal=Active_Energy_Day__kWh:kWh
icon=scene_pool
interruptable=0
mintime=240
mode=must
notafter=21:00
notbefore=03:00
off=AUS
on=EIN
pcurr=Active_Power__W:W:2
power=0
swoffcond=AB_POOLD:SF_Abort:1
swstate=state:EIN:AUS
type=other
Eigenartig.

[DS_Starter]

Das ist in der Tat eigenartig. Poste mal bitte wie der "alte" Eintrag aussieht, auf den der consumer gesetzt wird.

[Burny4600]

Das ist der alte Eintrag.

Code Auswählen Erweitern

AB_POOLD:Aussenbereich Pool
asynchron=1
auto=automatic
etotal=Active_Energy_Day__kWh:kWh
icon=scene_pool
interruptable=0
mintime=240
mode=must
notafter=21:00
notbefore=03:00
off=AUS
on=EIN
pcurr=Active_Power__W:W:2
power=0
swoffcond=AB_POOLD:SF_Abort:1
swstate=state:EIN:AUS
type=other

[DS_Starter]

Also ist es tatsächlich nur die Änderung von interruptable=0/1.
Hast du global autosave=1 gesetzt oder nicht gesetzt, jedenfalls nicht explizit 0?

Was passiert, wenn du:

Code Auswählen Erweitern

set ... attrKeyVal consumer07 interruptable=1   bzw.
set ... attrKeyVal consumer07 interruptable=0

manuell ausführst?

[roadghost]

@roadghost,

Nachts, so gegen 00:09 Uhr, stirbt mein alexa FHEm, und meldet: "alexafhem stopped; failed to connect to fhem: error: socket hang up".

Ein Zusammenhang mit dem SF-Modul ist sehr unwahrscheinlich, weil:

- im SF-Modul TcpServerUtils.pm nicht verwendet wird
- die Funktion TcpServer_WriteBlocking (das ist die Sub in der sich die Fehlerzeile 563 befindet) im Modul nicht verwendet/aufgerufen wird
- ich mir keinen Zusammenhang zwischen dem Löschen von 2 Dateien auf BS Ebene und einem TCP-Aufruf denken kann
- meine Logausgaben grundsätzlich anders aufgebaut sind als:

Code Auswählen Erweitern

2025.07.05 00:09:55.263 1: txt:72:84:84:80:47:49:46:49:32:50:48:48:32:79:75:13:10:67:111:110:116:101:110:116:45:84:121:112:101:58:32:97:112:112:108:105:99:97:116:105:111:110:47:111:99:116:101:116:45:115:116:114:101:97:109:59:32:99:104:97:114:115:101:116:61:85:84:70:45:56:13:10:13:10:91:34:80:86:95:80,off:0

Du kannst allerdings probehalber die Erstellung und Bereinigung der Backup-Files im SF-Device einfach mal als Negativtest ausschalten indem du im Attr plantControl explizit backupFilesKeep=0 setzt.

LG,
Heiko

Hi,

da Du Millionenmal mehr Ahnung von der Materie hast, als ich, möchte ich Dir da nicht widersprechen, aaber:

Wenn ich die 76_SolarForecast aus dem restoreDir vom 02.07.25 wiederherstelle, taucht der Fehler nicht mehr im FHEM log auf.

Möglicherweise besteht dort nur ein gewisser Zusammenhang, oder soetwas wie ein Querverweis ??

[Burny4600]

global autosave=0 ist definiert.

Sobald ich set AB_WS_SS attrKeyVal consumer07 interruptable=1 eingebe, kommt zwar keine Fehlermeldung, aber die Consumer 07 Definition wird auf die alte Definition zurückgesetzt.

[DS_Starter]

Wenn global autosave=0 definiert ist, wird das automatische Sichern verhindert.
Will man attrKeyVal nutzen, sollte autosave=1 gesetzt bzw. garnicht gesetzt sein. autosave=1 ist der FHEM Standard. Ich schreibe es in die Commandref noch rein.