76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Wzut]

ich werde die 11 mal im Icon Thread posten, mal schaun ob Wuppi sie nimmt. Zum spielen hänge ich sie aber schon mal an.
Desweiteren musst du den vorhanden HTML Tag style um zwei Klassen erweitern und dann dann das Bat Image mit $soc zusammenpacken, hier mal die beiden Abschnitte wie ich es gemacht habe :

Code Auswählen Erweitern

$ret .= '<style>TD.solarfc {text-align: center; padding-left:5px; padding-right:5px; margin:0px;}';
$ret .=' .batcontainer {position: relative;}';
$ret .=' .batsoc { position: absolute; top: 50%; left: 50%; transform: translate(-50%, -50%) rotate(-90deg); color:#000; z-index: 2; }';
$ret .='</style>';


  $title   .= defined $currsoc ? "\n".$htitles{socbacur}{$lang}.": ".$currsoc." %" : '';
  my $image = defined $hfcg->{$i}{'rcdchargebat'.$bn} ? FW_makeImage ($bicon) : '';

  $image  = '<div class="batcontainer">'.$image if ($image);
  $image .= '<div class="batsoc">'.int($soc).'</div></div>' if ($image);

  $ret .= "<td title='$title' class='solarfc' width='$width' style='margin:1px; vertical-align:middle align:center; padding-bottom:1px;'>$image</td>";

Dumm ist dabei nur das man nicht weiss welche Hintergrundfarbe gerade aktuell beim User ist. Es wäre toll wenn das auf Modulebene feststellen könnte bevor FHEMWEB das Ding zusammenbaut. In meinem Beispiel z.B. kommt das color:#000 halt nicht so gut an bei einem relativ dunklen Hintergrund. Alternativ kann man natürlich unter dem SoC Wert eine Hintergrundfarbe direkt setzen, hat mir persönlich allerdings nicht so gut gefallen. Anyway, spiel einfach mal etwas damit.     

[DS_Starter]

Dumm ist dabei nur das man nicht weiss welche Hintergrundfarbe gerade aktuell beim User ist.

Wir könnten doch die Schriftfarbe für den Batterieaufdruck konfigurierbar machen? Der User weiß ja welche Farbe an der Stelle am Besten passen würde.

[Max_Meyer]

Leider kommen solche Ausreißer - wahrscheinlich nicht nur bei mir - immer mal wieder vor. Vor diesem Hintergrund möchte ich anregen, dass SF seinen Input etwas mehr prüft. Da Energiezählern stets akkumulierend arbeiten, muss deren Werteverlauf monoton steigend sein 
[/quote]

Hallo zusammen
Ich habe auch solche Ausreißer.
Ursache ist i.d.R. ein Fehlsignal eines Sensors, meist EnOcean oder 433MHz. D.h. ein einmaliger Peak in einer Reihe valider Messwerte. Wenn hier monotonic angewendet wird kommt es zu unrealistisch hohen Differenzwerten. Daher denke ich das einfach monoton steigend nicht die beste Lösung ist
Ein bsp ist hier die grüne Reihe
Gruß Gerd

[Max_Meyer]

Ich sehe zwei Ausreißerprognosen:
...
Einen Grund dafür erkenne ich momentan noch nicht. Da müsste man sich noch die Logausgabe des Debug mit der Herleitung anschauen.

Leider kommen solche Ausreißer - wahrscheinlich nicht nur bei mir - immer mal wieder vor. Vor diesem Hintergrund möchte ich anregen, dass SF seinen Input etwas mehr prüft. Da Energiezählern stets akkumulierend arbeiten, muss deren Werteverlauf monoton steigend sein

Hallo zusammen
Ich habe auch solche Ausreißer.
Ursache ist i.d.R. ein Fehlsignal eines Sensors, meist EnOcean oder 433MHz. D.h. ein einmaliger Peak in einer Reihe valider Messwerte. Wenn hier monotonic angewendet wird kommt es zu unrealistisch hohen Differenzwerten. Daher denke ich das einfach monoton steigend nicht die beste Lösung ist
Ein bsp ist hier die grüne Reihe
Gruß Gerd

[Parallix]

...
Ich habe auch solche Ausreißer.
Ursache ist i.d.R. ein Fehlsignal eines Sensors, meist EnOcean oder 433MHz. D.h. ein einmaliger Peak in einer Reihe valider Messwerte. Wenn hier monotonic angewendet wird kommt es zu unrealistisch hohen Differenzwerten. Daher denke ich das einfach monoton steigend nicht die beste Lösung ist
...

Natürlich müssen Ausreißer nach oben hin anders behandelt werden. Unter Berücksichtigung der Hausanschluss-, Modul- und sonstiger max. Leistungen (P_max) sollten dies aber kein riesiges Problem sein. Werden innerhalb zweier Abfragen, die delta_t Sekunden auseinanderliegen SF zwei Energiewerte angeliefert, die in der Differenz delta_E auseinander liegen und ist delta_E / delta_t > P_max, dann darf der zweite Energiewert von SF nicht verwendet werden (Schwellwertfilterung).

Alternativ kann natürlich ein hoher Energiewert mit einem anschließenden Rücksprung auf eine (längere) Folge wieder kleinerer Enegiewerten identifiziert und eliminiert werden (Breitenfilterung).

Eine weitere Alternative wäre der Einsatz eines Modalfilters, Medianfilters oder getrimmten Mittelwertfilters u.s.w., alle natürlich jeweils gleitend eingerichtet.

[Wzut]

Wir könnten doch die Schriftfarbe für den Batterieaufdruck konfigurierbar machen?

Sicher, aber hat das Muodul nicht schon genug Attribute ?   
Alternativ kannst auch Farben,Font und z-Index innerhalb von .batsoc ganz weglassen und den SoC recht dicht an das Batterie Icon packen. Durch das wesentlich breitere Wettericon darüber, bzw die vierstelligen Werte in den Balken ist in der Spalte genügend Breite vorhanden (in meinem Beispiel bin ich mit top auf 60% und left auf 2%, richtig mittig ist es aber in der Spalte nicht. Habe auf die Schnelle aber nicht gefunden warum. da das TD ja schon align:center hat ) 

[300P]

...
Ich habe auch solche Ausreißer.
Ursache ist i.d.R. ein Fehlsignal eines Sensors, meist EnOcean oder 433MHz. D.h. ein einmaliger Peak in einer Reihe valider Messwerte. Wenn hier monotonic angewendet wird kommt es zu unrealistisch hohen Differenzwerten. Daher denke ich das einfach monoton steigend nicht die beste Lösung ist
...

Natürlich müssen Ausreißer nach oben hin anders behandelt werden. Unter Berücksichtigung der Hausanschluss-, Modul- und sonstiger max. Leistungen (P_max) sollten dies aber kein riesiges Problem sein. Werden innerhalb zweier Abfragen, die delta_t Sekunden auseinanderliegen SF zwei Energiewerte angeliefert, die in der Differenz delta_E auseinander liegen und ist delta_E / delta_t > P_max, dann darf der zweite Energiewert von SF nicht verwendet werden (Schwellwertfilterung).

Alternativ kann natürlich ein hoher Energiewert mit einem anschließenden Rücksprung auf eine (längere) Folge wieder kleinerer Enegiewerten identifiziert und eliminiert werden (Breitenfilterung).

Eine weitere Alternative wäre der Einsatz eines Modalfilters, Medianfilters oder getrimmten Mittelwertfilters u.s.w., alle natürlich jeweils gleitend eingerichtet.

Meine Meinung:
Vielleicht sollte man nicht alle auftretenden Probleme, die irgendwelche unzuverlässige Hardware bzw. irgend ein anderes FHEM-Modul bei der Erfassung macht, hier in SF "maßregeln" wollen.
Es wäre sicherlich besser das man für solche Fehler/Ungenauigkeiten bei der Ursache anpackt und nicht alles in diesem Modul zur Lösung an DS_Starter heranträgt.
Der hat sicherlich schon zeitlich genug allein mit diesem Modul und seine anderen Modulen zu tun / entwickeln / programmieren / regeln.

[bismosa]

Hallo!

Soll ich mein "Problem" vielleicht lieber in einen neuen Thread verschieben?

Ich habe nun ein paar Debug-Zeilen zusammen. Ich selbst werde nicht so ganz schlau daraus. Um 08:00:04 wurde die Pumpe heute gestartet. Um 08:00:47 war dann aber Interrupt gesetzt und die Pumpe wurde wieder abgeschaltet.

Code Auswählen Erweitern

2025.06.18 07:59:49 1: SF DEBUG> ############### consumerSwitching consumer "02" ###############
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - ConsumptionRecommended calc method: default, value: 493
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - additional consumption after switching on (if currently 'off'): 500 W
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - current planning state: planned
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - physical Switchstate before switching: off
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - logical Switchstate before switching: off
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - general switching parameters => auto mode: 1, Current household consumption: 294 W, nompower: 500, surplus: 493 W, planstate: planned: 2025-06-18 08:00:00 - 2025-06-18 16:00:00, starttime: 18.06.2025 08:00:00
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - isInLocktime: 0
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - device 'Firmata_Aussensteckdose' is used as switching device
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - Interrupt Info: value "0" doesn't match the Regex "1"
-> the effect depends on the switch context
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - Interrupt Characteristic value: 3
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - Interrupt Info: value "0" doesn't match the Regex "1"
-> the effect depends on the switch context
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - current planning state: planned
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - physical Switchstate after switching: off
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - logical Switchstate after switching: off
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - cycleDayNum: 0
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - last cycle start time: 2025-06-17 20:07:57
2025.06.18 07:59:49 1: SF DEBUG> consumer "02" - last cycle end time: 2025-06-17 20:15:03

2025.06.18 08:00:04 1: SF DEBUG> ############### consumerSwitching consumer "02" ###############
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - ConsumptionRecommended calc method: default, value: 495
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - additional consumption after switching on (if currently 'off'): 500 W
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - current planning state: planned
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - physical Switchstate before switching: off
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - logical Switchstate before switching: off
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - general switching parameters => auto mode: 1, Current household consumption: 291 W, nompower: 500, surplus: 495 W, planstate: planned: 2025-06-18 08:00:00 - 2025-06-18 16:00:00, starttime: 18.06.2025 08:00:00
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - isInLocktime: 0
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - device 'Firmata_Aussensteckdose' is used as switching device
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - Interrupt Info: value "0" doesn't match the Regex "1"
-> the effect depends on the switch context
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - Interrupt Characteristic value: 3
2025.06.18 08:00:04 1: SF DEBUG> Consumer switch enable by battery state: 1
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - send switch command now: "set Firmata_Aussensteckdose on"
2025.06.18 08:00:04 3: MQTT2_DEVICE set Firmata_Aussensteckdose on
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - Interrupt Info: value "0" doesn't match the Regex "1"
-> the effect depends on the switch context
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - current planning state: starting
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - physical Switchstate after switching: on
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - logical Switchstate after switching: on
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - cycleDayNum: 1
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - last cycle start time: 2025-06-18 08:00:04
2025.06.18 08:00:04 1: SF DEBUG> consumer "02" - last cycle end time: still running

2025.06.18 08:00:09 1: SMAInverter - Inverter answer does not match our parameters.
2025.06.18 08:00:38 1: SMAInverter SMAInverter -> BlockingCall SMAInverter_getstatusDoParse Timeout: process terminated
2025.06.18 08:00:47 1: SF DEBUG> ############### consumerSwitching consumer "02" ###############
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - ConsumptionRecommended calc method: default, value: 498
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - additional consumption after switching on (if currently 'off'): 0 W
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - current planning state: started
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - physical Switchstate before switching: on
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - logical Switchstate before switching: on
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - general switching parameters => auto mode: 1, Current household consumption: 291 W, nompower: 500, surplus: 498 W, planstate: switched on: 2025-06-18 08:00:04 - 2025-06-18 16:00:04, starttime: 18.06.2025 08:00:04
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - isInLocktime: 0
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - device 'Firmata_Aussensteckdose' is used as switching device
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - Interrupt Info: value "1" matches the Regex "1"
-> Check successful -> the effect depends on the switch context
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - Interrupt Characteristic value: 2
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - Interrupt Info: value "1" matches the Regex "1"
-> Check successful -> the effect depends on the switch context
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - send switch command now: "set Firmata_Aussensteckdose off"
2025.06.18 08:00:47 3: MQTT2_DEVICE set Firmata_Aussensteckdose off
2025.06.18 08:00:47 3: MQTT2_DEVICE set Firmata_Aussensteckdose off
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - current planning state: interrupting
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - physical Switchstate after switching: off
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - logical Switchstate after switching: off
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - cycleDayNum: 1
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - last cycle start time: 2025-06-18 08:00:04
2025.06.18 08:00:47 1: SF DEBUG> consumer "02" - last cycle end time: -
Kann es sein, das hier ein Fehler im Wiki (oder in der Zwischenzeit eine Änderung) war?

Code Auswählen Erweitern

if ($mrest >= ($mneed - $msum)) {
          readingsSingleUpdate ($dhash, 'SF_Int', 1, 0);                        # Interrupt-Freigabe
      }
      else {
          readingsSingleUpdate ($dhash, 'SF_Int', 0, 0);                        # keine Interrupt-Freigabe
 
      }
Freigabe müsste doch (wenn ich das richtig verstanden habe) 0 sein?
Da aber keine Laufzeit hinzugekommen ist, warum sollte dann durch das Script SF_Int geändert worden sein?

Um 13:01:47 wurde dann die Pumpe eingeschaltet. Da war Interrupt auf "0".
Alle anderen Schaltzeiten waren dann heute wegen zu starker Bewölkung und nicht vorhandenem PV-Überschuss völlig in Ordnung.

Gruß
Bismosa

[Shadow3561]

Ich muss mal kurz dazwischen grätschen, sorry.
Wir sanieren gerade unser Dach und mussten einen String runternehmen.
Ich habe jetzt das Attribut "pvCorrectionFactor_Auto" auf "noLearning" gesetzt. Wenn alles wieder montiert ist gehe ich zurück auf "on_complex....".
Ist dieser Weg der richtige oder verhagelt ich mir damit die gesammelten Daten für die KI?

Mit freundlichen Grüßen

[DS_Starter]

Nabend zusammen,

@Shadow3561,

Ist dieser Weg der richtige oder verhagelt ich mir damit die gesammelten Daten für die KI?

Das ist genau richtig, passt.

@bismosa,
bei dir bewegen wir uns wahrscheinlich in einem Grenzbereich wo Überschuß und nominale Leistungsaufnahme der Pumpe nah beisammen liegen.

... nompower: 500, surplus: 493 W,...

Ich würde dir raten den Überschuß im Consumer entweder über einen Median oder den Durchschnitt mehrerer Messungen zu verwenden:

  surpmeth=median  oder    surpmeth=5 (z.B.)

Im nächsten Release kommt an dieser Stelle noch eine Debugausgabe hinzu.
Zu Testzwecken kannst du auch vorübergehend power=350 setzen um eine evtl. Änderung des Verhaltens zu provozieren.


@all,

Es wäre sicherlich besser das man für solche Fehler/Ungenauigkeiten bei der Ursache anpackt ...

Der Meinung von 300P schließe ich mich absolut an. Weniger aus "Eigennutz" sondern auf Grund der Überlegung, dass SF nur ein Konsument der Werte z.B. eines Zählerdevices ist. Vermutlich werden diese Werte auch an anderer Stelle verarbeitet, geloggt, in SVG's gezaubert und vllt. auch zu Berechnungen genutzt.
Selbst wenn SF die Probleme durch diverse Maßnahmen neutralisiert, bleibt das Grundproblem bestehen und verschlechtert insgesamt die Qualität der FHEM Installation.

Ich plädiere dafür, wenn wir/ihr solche Dinge bei Gerätemodulen bemerkt auf jeden Fall auch die Entwickler dieser Module anzusprechen um eine Verbesserung der Datenlieferung zu erreichen wenn möglich. Dann haben alle etwas davon. Ungeachtet dessen werden ich meinen Teil in SF auch leisten.

[Parallix]

...
Meine Meinung:
Vielleicht sollte man nicht alle auftretenden Probleme, die irgendwelche unzuverlässige Hardware bzw. irgend ein anderes FHEM-Modul bei der Erfassung macht, hier in SF "maßregeln" wollen.
Es wäre sicherlich besser das man für solche Fehler/Ungenauigkeiten bei der Ursache anpackt und nicht alles in diesem Modul zur Lösung an DS_Starter heranträgt.
Der hat sicherlich schon zeitlich genug allein mit diesem Modul und seine anderen Modulen zu tun / entwickeln / programmieren / regeln.

In Teilen gebe ich 300P recht. Da es aber eine schier unglaubliche Anzahl an zuliefernden Modulen gibt, könnte eine Konzentration der Problemlösung (in SF) zielführender, schneller und damit vielleicht auch sinnvoller sein, als eine eine große Anzahl dezentraler Lösungen, oder?

Vielleicht könnte man dem SF-User aber auch eine Handvoll an sinnvollen Maßnahmen/Vorschläge an die Hand geben, mit denen er sich einfach selber um die Problemlösung kümmern kann. Ein solcher Vorschlag wäre vielleicht, die Modul-Instanzen, die SF Daten anliefern, um geeigneten UserReadings zu erweitern. Hierbei könnten die Methoden, die  event-aggregator zur Verfügung stellt, zum Einsatz kommen. Schade ist nur, dass dort einige hilfreiche Filter noch fehlen, insb. solche, die sporadisch auftauchende Ausreißer unberücksichtigt lassen. Vlt. gibt es ja an anderer Stelle in FHEM eine Toolbox, in der die für unseren Anwendungszweck benötigten gleitenden Filter bereits existieren oder leicht erweitert werden können. Ist Euch so eine Toolbox bekannt?

PS: Meinerseits schreibe ich in diesen Thread hier meine Vorschläge rein, da er "Ideen zu Weiterentwicklung" heißt. Vielleicht gibt es hierbei auch mal die ein oder andere schlechte Idee, die dann natürlich nicht in SF aufgenommen werden sollte.

[Wzut]

@Heiko ich habe die Icons unter https://forum.fhem.de/index.php?msg=1343459 gepostet,
Allerdings unter den Namen battery_0-100 statt einfach nur bat_0-100

[bismosa]

Hallo!

Danke für den Versuch mir hier zu helfen!
Ich versuche ja erstmal nur das Schaltverhalten zu verstehen. Sorry, wenn ich damit nerve. Ich habe das wohl immer noch nicht kapiert 
Ich habe das Modul so verstanden, das es gerade (auch) dafür gemacht ist um Verbraucher gezielt zu steuern. Ich denke die Steuerung der Poolpumpe sollte ein häufiger Anwendungsfall sein. Dann stelle ich mich vermutlich nur dämlich an 
Bisher habe ich noch nichts verändert. da ich erstmal die jetzige Situation verstehen möchte.

bei dir bewegen wir uns wahrscheinlich in einem Grenzbereich wo Überschuß und nominale Leistungsaufnahme der Pumpe nah beisammen liegen.

Das war gestern so. Angegeben habe ich die Pumpe mit 500W (da existiert keine Verbrauchsmessung). Das sind aber nur ca. 250-300W realer Verbrauch.
Heute war auch genug Überschuss vorhanden:

Code Auswählen Erweitern

2025.06.19 10:00:04 1: SF DEBUG> ############### consumerSwitching consumer "02" ###############
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - ConsumptionRecommended calc method: default, value: 1297
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - additional consumption after switching on (if currently 'off'): 500 W
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - current planning state: planned
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - physical Switchstate before switching: off
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - logical Switchstate before switching: off
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - general switching parameters => auto mode: 1, Current household consumption: 375 W, nompower: 500, surplus: 1297 W, planstate: planned: 2025-06-19 10:00:00 - 2025-06-19 18:00:00, starttime: 19.06.2025 10:00:00
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - isInLocktime: 0
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - device 'Firmata_Aussensteckdose' is used as switching device
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - Interrupt Info: value "0" doesn't match the Regex "1"
-> the effect depends on the switch context
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - Interrupt Characteristic value: 3
2025.06.19 10:00:04 1: SF DEBUG> Consumer switch enable by battery state: 1
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - send switch command now: "set Firmata_Aussensteckdose on"
2025.06.19 10:00:04 3: MQTT2_DEVICE set Firmata_Aussensteckdose on
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - Interrupt Info: value "0" doesn't match the Regex "1"
-> the effect depends on the switch context
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - current planning state: starting
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - physical Switchstate after switching: on
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - logical Switchstate after switching: on
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - cycleDayNum: 1
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - last cycle start time: 2025-06-19 10:00:04
2025.06.19 10:00:04 1: SF DEBUG> consumer "02" - last cycle end time: still running

2025.06.19 10:00:37 1: SF DEBUG> ############### consumerSwitching consumer "02" ###############
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - ConsumptionRecommended calc method: default, value: 1420
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - additional consumption after switching on (if currently 'off'): 0 W
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - current planning state: started
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - physical Switchstate before switching: on
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - logical Switchstate before switching: on
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - general switching parameters => auto mode: 1, Current household consumption: 2248 W, nompower: 500, surplus: 1420 W, planstate: switched on: 2025-06-19 10:00:04 - 2025-06-19 18:00:04, starttime: 19.06.2025 10:00:04
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - isInLocktime: 0
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - Check Context 'switch on' => swoncond: 1, on-command: on
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - isAddSwitchOnCond Info: value "" matches the Regex ""
-> Check successful
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - device 'Firmata_Aussensteckdose' is used as switching device
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - Interrupt Info: value "1" matches the Regex "1"
-> Check successful -> the effect depends on the switch context
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - Interrupt Characteristic value: 2
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - Check Context 'switch off' => swoffcond: 0, off-command: off
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - Interrupt Info: value "1" matches the Regex "1"
-> Check successful -> the effect depends on the switch context
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - send switch command now: "set Firmata_Aussensteckdose off"
2025.06.19 10:00:37 3: MQTT2_DEVICE set Firmata_Aussensteckdose off
2025.06.19 10:00:37 3: MQTT2_DEVICE set Firmata_Aussensteckdose off
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - current planning state: interrupting
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - physical Switchstate after switching: off
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - logical Switchstate after switching: off
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - cycleDayNum: 1
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - last cycle start time: 2025-06-19 10:00:04
2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - last cycle end time: -
Warum beginnt der Zyklus heute wieder um 10Uhr? Mit der Einstellung: notafter=10:00 könnte er doch auch früher starten, wenn genug Überschuss vorhanden ist?
Der Überschuss war auch beim abschalten groß genug. Auch jetzt habe ich aktuell 2kW Überschuss. Da könnte die Pumpe ruhig laufen.

Oder wird durch die Kombination von

Code Auswählen Erweitern

mintime=480
notafter=10:00
Der gesamte Tag betrachtet? Da z.B. um 14Uhr der meiste Überschuss vorhanden ist, wird erst dann die Pumpe geschaltet? Die 480 Minuten würde er dann ja auch noch bis Sonnenuntergang erreichen.
Mein Ziel war es durch diese Einstellung zu erreichen, das die Pumpe um 10Uhr (wenn genug Überschuss vorhanden) beginnt. Aber nach 18Uhr dann nicht mehr läuft.

Gruß
Bismosa

[DS_Starter]

@Wzut,

prima. Das schaue ich mir dann kurzfristig auch an.

[DS_Starter]

@Bismosa,

kein Thema 

Ich habe das Modul so verstanden, das es gerade (auch) dafür gemacht ist um Verbraucher gezielt zu steuern. Ich denke die Steuerung der Poolpumpe sollte ein häufiger Anwendungsfall sein.

Ja, genau richtig.

Ich denke ich weiß jetzt warum deine Pumpe ausschaltet. Du hast das Beispiel im Wiki angwendet

Code Auswählen Erweitern

interruptable=Firmata_Aussensteckdose:SF_Int:1
Das bedeutet, sobald der Regex "1" im Device:Reading Firmata_Aussensteckdose:SF_Int matcht, schaltet die Pumpe ab, egal ob noch Überschuß da ist oder nicht.

Und der Regex matched, da das Reading über dein Skript auf 1 gesetzt wurde:

Code Auswählen Erweitern

2025.06.19 10:00:37 1: SF DEBUG> consumer "02" - Interrupt Info: value "1" matches the Regex "1"

Zur Lösung definierst du interruptable im Consumer einfach so:

Code Auswählen Erweitern

interruptable=1

Dann reagiert das Modul bei der Steuerung nur auf das Vorhandensein eines Überschusses mit "on" bzw. "off".
(Das Beispiel im Wiki schaue ich mir nochmal an ob es da einen Fehler gibt. Es ist aber für einen speziellen Steuerungsfall aufgebaut).

Warum beginnt der Zyklus heute wieder um 10Uhr? Mit der Einstellung: notafter=10:00 könnte er doch auch früher starten, wenn genug Überschuss vorhanden ist?

Das Modul versucht die angegebene Soll-Laufzeit von 480 Minuten unter Berücksichtigung der PV-Prognose, der Verbrauchsprognose und der Laufprognose anderer Verbraucher möglichst optimal in den Tag hinzuplanen. Wenn man sich die Logik der Planung näher anschauen will -> ctrlDebug->consumerPlanning einschalten.

Mit der Einstellung notafter=10:00 greift man praktisch in den Planungsprozess ein und sagt dem Modul dass man ab 10:00 die Einplanung starten möchte auch wenn das Modul vllt. intern erst 10:30 die Einplanung setze würde.

LG,
Heiko