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.

[Burny4600]

Ich habe eine Frage zum Dummy-Verbraucher.
Woraus wird der Wert beim Dummy-Verbraucher ermittelt?

Eigentlich kann dieser Wert nur positiv sein, denn dieser Wert ergibt sich aus dem Wert des Hausknotens und der Verbraucher. Zumindest habe ich das so verstanden.
Laut SF Graphik ist dieser Wert ungefähr -6. Das kann sich aus Verzögerungen der Energieauswertung ergeben.
Aber der Wert -2327 beim Dummy-Verbraucher kann nicht stimmen.

Fällt ein Verbraucher mit hohem Verbrauch weg, ist der Dummy-Verbraucher zwar positiv, kann aber auch nicht stimmen.
Irgendwo muss ich einen Fehler verursacht haben.

[300P]

Ja - solche Situationen habe ich manchmal auch.

Bei mir "schläft" der Messwert im zuständigen Mess-Device in solchen Fällen manchmal minutenlang ehe wieder ein aktualisierter Wert kommt, obwohl der Abfragezylus im Device extra klein (15 sec) eingestellt ist.
Andere Reading aus dem gleichen Gerät werden zwar immer wieder neu aktualisiert - aber der Wert vom aktuellem Verbrauch eben manchmal (noch) nicht.

Liegt also bei mir meist eindeutig an der eingesetzten Hardware die nicht "zeitnah" die "richtigen" Werte im entsprechenden Device zur Verfügung stellt.


Meine Waschmaschine und meine PV-WW-ZusatzHeater sind solche Kandidaten (==>> Fritz-Geräte)

[Burny4600]

Ja - solche Situationen habe ich manchmal auch.

Das stört mich jetzt nicht mehr, denn ich synchronisierte nun die Energiewerte mit dem Hauptzähler der alle 15 Sek. einen Event auslöst.
Das wäre für SF nicht schlecht den Trigger auf den Hauptzähler (Grid) zu definieren, um unrealistische Werte in der Grafikansicht einzudämmen.

Das mich stört ist der ermittelte Dummy-Wert beim Hausknoten der bei mir nicht stimmt. Ich finde den Fehler einfach nicht den ich irgendwo verursacht habe.

[300P]

Am Ende wirst du merken das es ein ,,Zeitverzug sein wird der halt passiert".

Bei deinen Screenshots scheint hier die Ursache der Consumer zu sein, der einmal ON und danach ,,fast" AUS ist.

[Burny4600]

Bei deinen Screenshots scheint hier die Ursache der Consumer zu sein, der einmal ON und danach ,,fast" AUS ist.

Meinst du den Consumer 02 von links. Das passt vom Consumer. Der Geschirrspüler hat einmal die Heizung an und dann wieder aus. Wenn alle Verbraucher zusammengerechnet werden, kommst du auf 3356 kW. 3350 kW werden am Hauskonten angezeigt. Nur wenn du auf den Dummy-Verbraucher schaust siehst du einen Verbrauch von -2327 kW.

Beim anderen Screenshot wird am Dummy-Verbraucher zu viel angezeigt. Die Berechnung des Dummy-Verbrauchers weicht bei mir permanent zu viel ab. Und das sowohl viel zu viel ins Negative und zu viel ins Positive.
Wobei alle anderen Werte zusammenpassen.

Irgendwo ist bei mir ein Fehler vorhanden, der aber nach meinen Beobachtungen nichts mit einem Zeitverzug zu tun hat. Da müsste bei relativ konstantem Verbrauch sich der Dummy-Verbrauch anpassen. Das tut er aber nicht.
Der Zeitversatz müsste nach 20 Sek. behoben sein. Die Verbraucherwerte werden zwischen 10 und 15 Sek ermittelt und an SF übergeben.

[DS_Starter]

Hallo Chris,

eine kurze Erläuterung zu dem Consumer Dummy.
Der Wert für diesen Dummy wird berechnet, indem von dem ermittelten Hausverbrauch (Wiki) die gemessenen/gelieferten Anteile der registrierten Verbraucher abgezogen wird. Der verbleibende Rest ist der nicht zuordenbare Dummy-Verbrauch.

Du kannst ctrlDebug=collectData setzen. Am Ende des Log siehst du:

2025.07.27 18:15:08.453 1: SolCast DEBUG> current Power values -> PV2Node: 438 W, PV2Grid: 0, Other: 0 W, GridIn: 0 W, GridCon: 45 W, BatIn: 0 W, BatOut: 126 W
2025.07.27 18:15:08.453 1: SolCast DEBUG> current Consumption result -> 609 W

den Hausverbrauch.

Wenn ich mir deine Screenshots anschaue, fällt mir auch EG-KUE-GS auf der ein Großverbraucher ist. Du hast EG, OG1, OG2 integriert, die vermutlich keine echten Verbraucher sind, sondern nur Summenzähler oder Summendummies. Allerdings gehen sie als Verbraucher ein, wenn sie so definiert sind und werden gemäß der oben gezeigten Berechnung berücksichtigt was zwangsläufig zu Fehlern im Dummy in die eine oder andere Richtung führt.

Im einfachsten Fall blendest du dir den Consumer-Dummy nicht ein, denn es ist m.M. nach dadurch lediglich ein Schönheitsfehler wenn du EG, OG1, OG2 für dich richtig einordnen kannst.

LG,
Heiko 


 

[300P]

Schau dir die nachfolgenden  Screenshots mal an.
Mein Device ,,Heater" reagiert einfach nicht zeitnah mit den richtigen Verbrauchswerten.
Daher ergibt sich die negative Summierung.....