76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Was ist der logical Switchstate und warum und wann unterscheidet er sich vom physical Switchstate?

Der logische Switchstate berücksichtigt ein Standby bzw. den Threshhold der bei pcurr angegeben wurde. Beispiel ein Schaltdose mit Meßfunktion. Angeschlossen ist ein TV. Die Dose ist "on", dh. der Verbraucher ist physich "on". Der Verbraucher (TV) ist aber im Standby und verbraucht nur 0,5W. DAmit ist der Verbrauch < Threshhold und der Verbraucher ist logisch "off".

Gibt es außer den Vorgaben im Consumer für das Einplanen, einem Klick auf das Uhrensymbol und einem set consumerNewPlanning weitere Gründe warum ein Consumer neu geplant wird? (hier 19:45, aus irgendeinem Grund, den ich noch nicht weiß, wird hier neu geplant und anscheinend sofort gestartet)

Ja.
Sofern ein Consumer nicht im Planungszeitraum gestartet werden konnte (weil z.B. kein Überschuß oder andere Verhinderungsgründe), versucht das Modul ein Replanning in einem folgenden passenden Zeitraum:

Code Auswählen Erweitern

planstate: replanned: 2025-07-23 19:45:17 - 2025-07-23 20:50:59, starttime: 23.07.2025 19:45:17
Ein Start erfolgt aber hier nicht, sondern nur die neue Einplanung.

Was bedeutet: Interrupt Characteristic value: 3

Das ist ein Interrupt Typ -> für interne Programmierung.
Interruptable 0/1 -> Typ 0/1, Code return "true" -> 2, Code return "false" -> 3

Gehe ich recht in der Annahme, dass ein swoffcond=1 stärker wiegt, als ein interruptable=0? Denn dann müsste hier ja ausgeschaltet werden.

Das sind zwei unterschiedliche Sachverhalte. interruptable=0 besagt der Verbraucher ist nicht temporär unterbrechbar. swoffcond=1 besagt, wenn die Bedingung zutrifft, wird der gesamte aktive Lauf beendet. D.h. der Consumer ist dann "finished".

last cycle start time: 2025-07-23 10:25:14 und last cycle start time: 2025-07-23 10:25:14 sind die Ein- und Ausschaltzeiten des Consumers?

Ja

cycleDayNum: 3 heißt drei mal Ein und drei mal Aus, oder Ein, Aus, Ein?

Das erstere.

Die größte Frage: Warum wird hier nicht ausgeschaltet?

Ich sehe zwei Gründe.
1. es liegt kein PV Überschuß vor

Code Auswählen Erweitern

Current household consumption: 1108 W, nompower: 1800, surplus: 0 W ....

2. die swoncond: 0, d.h. die zusätzliche Bedingung für Start des Zyklus ist "false" geliefert von {main::CheckWPOn}. Gleichzeitig wird 'true' after exec "{main::CheckWPOff} geliefert, d.h. swoffcond=1 und somit wird Einschalten ebenfalls verhindert.

(Die Ausgabe "isAddSwitchOnCond Info: The value "1" resulted in 'false' after exec "{main::CheckWPOn}" muß ich nochmal ändern -> die 1 ist nicht der return von main::CheckWPOn), ist aber nur der Log)

Hier das Problem mit dem nicht Schalten in umgekehrter Richtung:
Warum wird hier nicht geschaltet?

Bei interuptable ist ein Code angegeben, das bedeutet der Verbraucher wird unterbrochen wenn {} = "true" liefert. Und das macht er:

Code Auswählen Erweitern

2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - Interrupt Info: The reference value "1" resulted in 'true' after exec "{main::Check_Pump_High_Interruptable}"
-> Check successful -> the effect depends on the switch context

Commandref:
Device:Reading:{Perl-Code} - Verbraucher wird temporär unterbrochen, wenn der Perl-Code 'wahr' zurückgibt oder unzureichender
    PV Überschuß (wenn power ungleich 0) vorliegt und wird wieder eingeschaltet, wenn der Perl-Code 'falsch' zurückgibt und PV Überschuß
    (wenn power ungleich 0) vorliegt.


Ich hoffe nichts vergessen zu haben...

LG,
Heiko

[DS_Starter]

Version mit den Debug Info Changes ist eingecheckt.

[hugomckinley]

@Heiko
Danke für deine Erklärungen.

Ich habe den Begriff interruptable falsch verstanden und die commandref daher nicht so interpretiert.
Ich dachte, dass interruptable=1 die Freigabe für das Schalten durch den Überschuss ist, dabei ist es ein zusätzliches Kriterium.
Einmal mit UND und einmal mit ODER. Wie bei swoncond und swoffcond.
Ich dachte:
* interuptable=1 -> Regelung durch Überschuss freigegeben
* interruptable=0 -> Überschussregelung aus -> immer ein, wenn geplant

aber es ist so:
* interruptable=1: Verbraucher aus, trotz Überschuss (surplus=0 ODER interruptable = 1)
* interruptable=0: Verbraucher ein, wenn Überschuss vorhanden (surplus >0 UND interruptable = 0)

Habe ich das richtig Verstanden, dass bei interruptable der Perlcode oder die Regex für sich true ergeben müssen?

Ist das dann nicht anders, wie bei swoncond und swoffond? Da muss doch der Vergleich Decvice:Reading mit dem Ergebnis des Perlcode true ergeben, oder?

Es wird ja

swoffcond=<Device>:<Reading>:<Bedingung>

angegeben. Das Device/Reading muß den Vergleichswert liefern der mit der Bedingung verglichen wird.
Dabei kann Bedingung ein Regex oder, wie bei dir, eine Funktion sein.

(Was bei mir egal ist, da mein sf_true Reading fix auf 1 steht. Aber evtl. verwende ich es ja mal anders.)

--> Sollte ich jetzt verstanden haben. Danke!
 
Ich glaube bei einer Frage haben wir aneinander vorbei geredet:

Code Auswählen Erweitern

Gehe ich recht in der Annahme, dass ein swoffcond=1 stärker wiegt, als ein interruptable=0? Denn dann müsste hier ja ausgeschaltet werden.Hier ist swoncond=false, interruptable=false und swoffcond=true
Meine Frage war, warum hier nicht ausgeschaltet wird?
Wird hier der physische Schalter nicht ausgeschaltet, weil der logische Zustand schon aus ist?
(Kommt bei mir derzeit noch vor, da noch meine Regelung den Verbraucher steuert. Leistung ist schon 0, aber physical Switchstate ist noch "on")

[DS_Starter]

Ich dachte:
* interuptable=1 -> Regelung durch Überschuss freigegeben
* interruptable=0 -> Überschussregelung aus -> immer ein, wenn geplant

Das ist nicht ganz richtig. Richtig ist:

* interuptable=1 -> Ein gestarteter Verbraucher kann bei fehlendem Überschuß unterbrochen und später fortgesetzt werden
* interruptable=0 -> Ein einmal gestarteter Verbraucher darf nicht unterbrochen werden wenn später Überschuß fehlen sollte

Aber das Verhalten ist unterschiedlich ob man interuptable=1/0 setzt oder ob man interuptable=Device:Reading:{Perl-Code} verwendet -> ComRef

Habe ich das richtig Verstanden, dass bei interruptable der Perlcode oder die Regex für sich true ergeben müssen?

Ist angegeben: interuptable=Device:Reading:{Perl-Code} -> bei return "true" wird direkt unterbrochen, bei "false" forstgesetzt.  $VALUE aus
               Device:Reading kann im Code ausgewertet werden.

               Bei swoncond und swoffond ist es genauso, nur das bei swoncond der Verbraucher überhaupt erst gestartet wird wenn "true" und bei
               swoffond der Consumer auf "finished" gesetzt wird, d.h. er wird beendet und nicht nur unterbrochen.

ist angegeben: Device:Reading:Regex -> der Regex wird auf den Wert von Device:Reading angewendet -> bei "true" direkte Uterbrechung, bei "fals." Forstzung.

[DS_Starter]

Meine Frage war, warum hier nicht ausgeschaltet wird?
Wird hier der physische Schalter nicht ausgeschaltet, weil der logische Zustand schon aus ist?

Die swoffcond ist "false" ->

Code Auswählen Erweitern

2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - Check Context 'switch off' => swoffcond: 0, off-command: pump_high off
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - is Consumption recommended: 1
2025.07.24 09:00:18 1: energy_mgmt DEBUG> consumer "07" - isAddSwitchOffCond Info: The reference value "1" resulted in 'false' after exec "{main::Check_Pump_High_Off}"
-> the effect depends on the switch context

Da swoffcond nicht true ist, weiterhin PV da ist (is Consumption recommended: 1) wird nicht ausgeschaltet.

[hugomckinley]

Meine Frage hat sich auf den Beitrag davor bezogen. Hier war die Frage, warum nicht eingeschaltet wurde.


Hier war die Frage warum nicht ausgeschaltet wurde.
https://forum.fhem.de/index.php?msg=1345175

[DS_Starter]

Ah ok, Mißverständnis.

Wird hier der physische Schalter nicht ausgeschaltet, weil der logische Zustand schon aus ist?

Ja, richtig.

Du kannst z.B. bei pcurr den :<Schwellenwert> ergänze und ihn recht hoch setzen, z.B 500 (W). Dann ist der Consumer erst dann aktiv gewertet wenn er > 500 W verbraucht.