76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

@all,

ich habe die max. möglichen Consumer im Modul auf 20 erhöht.
Es lässt auch noch mit etwas guten Willen in der Flowgrafik unterbringen. In dem Screenshot habe ich dazu eingestellt:

Code Auswählen Erweitern

consumerdist=90
size=600
h2consumerdist=190
showconsumerdummy=0

Das Update befindet sich im contrib.

LG,
Heiko

[Gisbert]

Hallo Heiko,

ich war die letzten Tage auf der Suche nach der Ursache für die fehlerhafte Darstellung von Umlauten und Sonderzeichen wie in °C u.a.

Rudi hatte sich der Sache angenommen und Module identifiziert, die zwischen dem 28.6. und 5.7. (Zeitpunkte meiner Fhem-Updates) geändert wurden, siehe dazu auch den verlinkten Beitrag:
https://forum.fhem.de/index.php?topic=142010.msg1344512#msg1344512
Ab dem 5.7. sehe ich die falsche Darstellung der Umlaute und von Sonderzeichen.

Um es kurz zu machen, ein Update deines Moduls im Zeitraum 28.6. bis 5.7. scheint sich als Ursache herauszukristallisieren. Wenn ich dein Modul disable, wird alles richtig angezeigt, wenn ich das disable-Attribut lösche, werden die Umlaute etc. wieder sehr komisch dargestellt.
Da ich dein Modul und dein enormes Engagement sehr schätze und respektiere und ich sehr gerne dein Modul weiter nutzen möchte, wollte ich dich bitten in dieses Problem reinzuschauen.

Beschreibung und Darstellung des Fehlers sind hier dokumentiert:
https://forum.fhem.de/index.php?topic=142010.0

Viele Grüße Gisbert

[DS_Starter]

Hallo Gisbert,

lade die V aus meinem contrib. Wir hatten kürzlich erst einen Fehler behoben mit typografischen Anführungszeichen der sich bei alexa mit englischer Einstellung gezeigt hatte. Der fix ist noch nicht eingecheckt.
Vllt. hast du auch engl. eingestellt. Wenn das nicht hilft brauche ich ein konkretes Beispiel denn bei mir werden Umlaute korrekt dargestellt.

LG,
Heiko

[Burny4600]

Das interpretierst du evtl. falsch:
notbefore =>>> starte die "Einplanung" nicht vor dieser Zeit
notafter  =>>> starte die "Einplanung" nicht nach dieser Zeit

Das habe ich richtig verstanden.

(bedeutet NICHT schalte mich an und aus innerhalb dieser Zeit  )

Für was definiere ich für den Consumer ein notbefore und ein notafter, wenn die Planung das ohnehin nicht berücksicht?

Code Auswählen Erweitern

EG_KUE_GSD:EG-Küche+Geschirrspüler
auto=automatic
etotal=Active_Energy_Day__kWh:kWh
exconfc=2
icon=scene_dishwasher
interruptable=EG_KUE_GSD:SF_Int:1
mintime=180
mode=must
notafter=19:00
notbefore=06:30
.....
Im Zeitraum 06:30 bis 19:00 ist die Einplanung mit einer Mindestzeit von 180 min möglich.

Die Verbraucherplanung gibt aber vor, EIN um 17:00 und AUS um 20:00.

Anscheinend verstehe ich hier immer nich etwas falsch.

[DS_Starter]

Guten Morgen,

Für was definiere ich für den Consumer ein notbefore und ein notafter, wenn die Planung das ohnehin nicht berücksicht?

Doch, die Planung berücksichtigt es ja. Wie 300P schon schrieb passiert mit dieser Angabe:

notbefore=06:30
notafter=19:00

Die Einplanung des Starts des Consumerzyklus erfolgt nicht vor 06:30 und nicht nach 19:00. Das heißt der geplante Start des Consumers erfolgt optimiert irgendwo zwischen 06:30 und 19:00. Das ist aber der Start des Zyklus. D.h. im Extremfall startet der Consumer 19:00 und läuft dann die eingegebene mintime, hier mintime=180 Minuten.

Die Verbraucherplanung gibt aber vor, EIN um 17:00 und AUS um 20:00.

In deinem konkreten Fall wird der Start um 17:00 eingelant (im Zeitfenster 06:30 bis 19:00) und läuft dann 180 Minuten = 3h bis 20:00.

Alles richtig wie definiert.

[tomcat.x]

Vielleicht sind hier die Begriffe missverständlich. (Nur) der "Start" wird in diese Zeitspanne gelegt. Wenn man "Einplanung" als den Slot versteht, in dem das Gerät laufen wird, ist es nicht richtig. Ich war da auch drüber gestolpert und hatte die Zeiten nachträglich angepasst.

[DS_Starter]

Ja wahrscheinlich. In der ComRef habe ich aktuell stehen:

notbefore    Startzeitpunkt Verbraucher nicht vor angegebener Zeit 'Stunde[:Minute]' einplanen (optional)
   Der <Ausdruck> hat das Format hh[:mm] oder ist in {...} eingeschlossener Perl-Code der hh[:mm] zurückgibt.
   
notafter    Startzeitpunkt Verbraucher nicht nach angegebener Zeit 'Stunde[:Minute]' einplanen (optional)
   Der <Ausdruck> hat das Format hh[:mm] oder ist in {...} eingeschlossener Perl-Code der hh[:mm] zurückgibt.

Hier steht ausdrücklich Startzeitpunkt drin. Vllt. muß ich das noch eindringlicher schreiben?

[300P]

Schreibe evtl. einfach dazu:

notafter    Startzeitpunkt Verbraucher nicht nach angegebener Zeit 'Stunde[:Minute]' einplanen (optional)
   Der <Ausdruck> hat das Format hh[:mm] oder ist in {...} eingeschlossener Perl-Code der hh[:mm] zurückgibt.

Achtung:
Der sich ergebende Schaltzeitpunkt zum Beenden (off) kann in beiden Fällen jedoch weit über den gewählten Zeitpunkt "notafter" hinausgehen. Hierdurch wird lediglich der mögliche Startzeitpunkt eingeschränkt, jedoch in keinem Fall die eingeplante Laufzeit.

[tomcat.x]

Hier steht ausdrücklich Startzeitpunkt drin. Vllt. muß ich das noch eindringlicher schreiben?

Also das finde ich schon eindeutig. War das mal anders beschrieben? Weiß auch nicht, wo ich das mir der "Einplanung" in diesem Zeitraum her habe. Vermutlich die allgemeine Verwirrung

[DS_Starter]

War das mal anders beschrieben?

_Irgendwann_ vielleicht ... steht aber schon sehr lange so drin. 

[Burny4600]

Die Einplanung des Starts des Consumerzyklus erfolgt nicht vor 06:30 und nicht nach 19:00. Das heißt der geplante Start des Consumers erfolgt optimiert irgendwo zwischen 06:30 und 19:00. Das ist aber der Start des Zyklus. D.h. im Extremfall startet der Consumer 19:00 und läuft dann die eingegebene mintime, hier mintime=180 Minuten.

Die Verbraucherplanung gibt aber vor, EIN um 17:00 und AUS um 20:00.

In deinem konkreten Fall wird der Start um 17:00 eingelant (im Zeitfenster 06:30 bis 19:00) und läuft dann 180 Minuten = 3h bis 20:00.

Ok.
Jetzt habe ich es verstanden, dass durch die mintime die Planungszeit von 19:00 überschritten werdem kann.
Ich nahm an, dass ein Betrieb nur in diesem Zeitfenster erfolgt, auch wenn die mintime noch nicht erreicht wurde.
Da muss ich dann einige Zeiten bei den Consumern ändern.


Aber zurück zur ständigen Wiederholung von Connection lost, trying a reconnect every 5 seconds..
Verursacht von consumer 07, wenn ein aktives Planungsfenster vorhanden ist.
Entferne ich unter dem Attribut ctrlUserExitFn die Zeile ::pumpControl ($name, '07', 180); ist sofort keine Wiederholung von Connection lost.... ersichtlich.
Irgendwie habe ich in der 99_mySolarForecastUtils.pm pumpControl anscheinend einen Fehler.

Code Auswählen Erweitern

############################################################################
#   Pumpensteuerung
############################################################################
sub pumpControl {
  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;
}

[DS_Starter]

Fehler ist da nicht drin. Allerdings wird bei den Statements:

* fhem ("set $name attrKeyVal consumer$c interruptable=1");
* fhem ("set $name attrKeyVal consumer$c interruptable=0");

jedesmal ein Aktualisierungszyklus durchlaufen weil das Consumerattribut geändert wird. Das hat Auswirkung auf ein Eventaufkommen und Systemlast (wie weiter vorn diskutiert) je nachdem wie häufig der Zyklus passiert. 

Hilfreich könnte folgende Ergänzung sein. Oben nach "my $plstate":

Code Auswählen Erweitern

my $plstate   = FHEM::SolarForecast::ConsumerVal ($name, $c, 'planstate', '');       # die nächste Zeile ergänzen ->
my $intbl     = FHEM::SolarForecast::ConsumerVal ($name, $c, 'interruptable', 1);


Und dann innerhalb der if-Bedingung diese Statements verwenden:

Code Auswählen Erweitern

      if ($mrest >= ($mneed - $msum)) {                       
          fhem ("set $name attrKeyVal consumer$c interruptable=1") if(!$intbl);               # Interrupt-Freigabe
      }
      else {                       
          fhem ("set $name attrKeyVal consumer$c interruptable=0") if($intbl);                # keine Interrupt-Freigabe
      }

Dadurch werden die Befehle nur einmalig ausgeführt wenn die jeweilige $intbl-Zusatzbedingung erfüllt ist und dürfte die Systemlast deutlich reduzieren.
Probier das mal aus.

[Gisbert]

Hallo Gisbert,

lade die V aus meinem contrib. Wir hatten kürzlich erst einen Fehler behoben mit typografischen Anführungszeichen der sich bei alexa mit englischer Einstellung gezeigt hatte. Der fix ist noch nicht eingecheckt.
Vllt. hast du auch engl. eingestellt. Wenn das nicht hilft brauche ich ein konkretes Beispiel denn bei mir werden Umlaute korrekt dargestellt.

LG,
Heiko

Hallo Heiko,

das war es tatsächlich - mit der neuen Version aus deinen contrib sieht jetzt wieder alles gut aus. In Debian, auf dem mein Fhem läuft, habe ich US-englische Sprache eingestellt.

Du bist der beste, vielen, lieben Dank.
Gisbert

[DS_Starter]

Freut mich dass dein Problem dadurch auch gelöst werden konnte. 
Ich werde die Version aus dem contrib heute einchecken. Dann ist der Fix morgen früh offiziell verfügbar.

LG,
Heiko

[Burny4600]

@Heiko

jedesmal ein Aktualisierungszyklus durchlaufen weil das Consumerattribut geändert wird. Das hat Auswirkung auf ein Eventaufkommen und Systemlast (wie weiter vorn diskutiert) je nachdem wie häufig der Zyklus passiert. 

Das sieht jetzt anders aus. Und die Systemlast hat sich beim Pi4 auch reduziert.

Danke für den Tipp.