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.....

[Burny4600]

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.

AB, EG, OG1, OG2 sind eigene Energiezähler. Auch die Verbraucher haben einen eigenen Energiezähler.
Die zugehörigen Verbraucher zu den Bereichen (AB, EG, OG1, OG2) werden aber in den Bereichen abgezogen, und somit stimmt die Summe der Verbraucher und Energiezähler der Bereiche annähernd, weil in der Anzeige auf und abgerundet wird. ~ +/-5W
Es stimmen auch alle Verbrauchs- und Produktions-Werte wie man auf meinen Shreenshots sehen kann. Nur der Dummy-Verbraucher hat ein Problem mit den ermittelten Werten.

consumer02

Code Auswählen Erweitern

EG_KUE_GSD:EG-Küche+Geschirrspüler
aliasshort=EG-KUE-GS
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
off=AUS
on=EIN
pcurr=Active_Power__W:W:2
power=2350
swstate=state:EIN:AUS
type=dishwasher
consumer11

Code Auswählen Erweitern

EG_SDM630M_01D:EG+gesamt
aliasshort=EG
etotal=Active_Energy__kWh:kWh
exconfc=2
icon=control_building_modern_s_eg
noshow=2
pcurr=Active_Power__W:W
power=0
type=other

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

Wenn das keinen Einfluss auf den SF mit den Vorhersagen hat kann ich diesen weglassen.

Du kannst ctrlDebug=collectData setzen.

Code Auswählen Erweitern

2025.07.28 10:44:08.422 1: AB_WS_SS DEBUG> collect Producer 01 data - device: AB_WG2KWD =>
2025.07.28 10:44:08.423 1: AB_WS_SS DEBUG> pcurr: 0 W, etotal: 0 Wh
2025.07.28 10:44:08.423 1: AB_WS_SS DEBUG> collect Producer 02 data - device: AB_NS6KWD =>
2025.07.28 10:44:08.424 1: AB_WS_SS DEBUG> pcurr: 0 W, etotal: 0 Wh
2025.07.28 10:44:08.424 1: AB_WS_SS DEBUG> collect Meter data - device: HTZ_SDM630M_01 =>
2025.07.28 10:44:08.424 1: AB_WS_SS DEBUG> gcon: 1083.8 W, gfeedin: 0 W, contotal: 22209830 Wh, feedtotal: 769902 Wh
2025.07.28 10:44:08.425 1: AB_WS_SS DEBUG> write to pvHistory - day: 28, hod: 11, GridConsumption (gcons): 601 Wh
2025.07.28 10:44:08.426 1: AB_WS_SS DEBUG> collect Battery Readings data: device=Deye_12k =>
2025.07.28 10:44:08.426 1: AB_WS_SS DEBUG> pin: 0 W, pout: 0 W, totalin: 2695.5 Wh, totalout: 2387.1 Wh, soc: 40
2025.07.28 10:44:08.427 1: AB_WS_SS DEBUG> collect Battery Readings data: device=Deye_15k =>
2025.07.28 10:44:08.427 1: AB_WS_SS DEBUG> pin: 0 W, pout: 0 W, totalin: 2499.1 Wh, totalout: 2313.5 Wh, soc: 20
2025.07.28 10:44:08.526 1: AB_WS_SS DEBUG> EnergyConsumption input -> PV: 600 Wh, PP: 0 Wh, GridIn: 0 Wh, GridCon: 601 Wh, BatIn: 0 Wh, BatOut: 0 Wh
2025.07.28 10:44:08.526 1: AB_WS_SS DEBUG> EnergyConsumption result -> 1201 Wh
2025.07.28 10:44:08.530 1: AB_WS_SS DEBUG> current Power values -> PV2Node: 490 W, PV2Grid: 0, Other: 0 W, GridIn: 0 W, GridCon: 1083 W, BatIn: 0 W, BatOut: 0 W
2025.07.28 10:44:08.530 1: AB_WS_SS DEBUG> current Consumption result -> 1573 W
2025.07.28 10:44:10.543 1: AB_WS_SS DEBUG> collect Inverter 01 data - device: Deye_12k_SFD, source: pv, delivery: default =>
2025.07.28 10:44:10.543 1: AB_WS_SS DEBUG> pvOut: 0 W, pvIn: 180 W, AC->DC: 0 W, DC->AC: 0 W, etotal: 2723300 Wh
2025.07.28 10:44:10.544 1: AB_WS_SS DEBUG> collect Inverter 02 data - device: Deye_15k_SFD, source: pv, delivery: default =>
2025.07.28 10:44:10.544 1: AB_WS_SS DEBUG> pvOut: 490 W, pvIn: 690 W, AC->DC: 0 W, DC->AC: 0 W, etotal: 2718800 Wh
2025.07.28 10:44:10.545 1: AB_WS_SS DEBUG> collect Inverter 03 data - device: Deye_12k_SFD, source: bat, delivery: default =>
2025.07.28 10:44:10.545 1: AB_WS_SS DEBUG> pvOut: 0 W, pvIn: 0 W, AC->DC: 0 W, DC->AC: 0 W, etotal: 0 Wh
2025.07.28 10:44:10.546 1: AB_WS_SS DEBUG> collect Inverter 04 data - device: Deye_15k_SFD, source: bat, delivery: default =>
2025.07.28 10:44:10.546 1: AB_WS_SS DEBUG> pvOut: 0 W, pvIn: 0 W, AC->DC: 0 W, DC->AC: 0 W, etotal: 0 Wh
2025.07.28 10:44:10.546 1: AB_WS_SS DEBUG> summary data of all Inverters - pv: 490 W, this hour Generation: 600 Wh
2025.07.28 10:44:10.546 1: AB_WS_SS DEBUG> State of Plant derating: 0, info: reductionState not set
2025.07.28 10:44:10.546 1: AB_WS_SS DEBUG> currently saved 'pvrlvd' value: 1
2025.07.28 10:44:10.546 1: AB_WS_SS DEBUG> current percentage pvrl/pvapifc deviation of hod 11: 960.0 % -> pvrlvd: 1
2025.07.28 10:44:10.790 1: AB_WS_SS DEBUG> collect Producer 01 data - device: AB_WG2KWD =>
2025.07.28 10:44:10.791 1: AB_WS_SS DEBUG> pcurr: 0 W, etotal: 0 Wh
2025.07.28 10:44:10.791 1: AB_WS_SS DEBUG> collect Producer 02 data - device: AB_NS6KWD =>
2025.07.28 10:44:10.792 1: AB_WS_SS DEBUG> pcurr: 0 W, etotal: 0 Wh
2025.07.28 10:44:10.792 1: AB_WS_SS DEBUG> collect Meter data - device: HTZ_SDM630M_01 =>
2025.07.28 10:44:10.792 1: AB_WS_SS DEBUG> gcon: 1024.7 W, gfeedin: 0 W, contotal: 22209830 Wh, feedtotal: 769902 Wh
2025.07.28 10:44:10.793 1: AB_WS_SS DEBUG> write to pvHistory - day: 28, hod: 11, GridConsumption (gcons): 601 Wh
2025.07.28 10:44:10.794 1: AB_WS_SS DEBUG> collect Battery Readings data: device=Deye_12k =>
2025.07.28 10:44:10.794 1: AB_WS_SS DEBUG> pin: 0 W, pout: 0 W, totalin: 2695.5 Wh, totalout: 2387.1 Wh, soc: 40
2025.07.28 10:44:10.795 1: AB_WS_SS DEBUG> collect Battery Readings data: device=Deye_15k =>
2025.07.28 10:44:10.795 1: AB_WS_SS DEBUG> pin: 0 W, pout: 0 W, totalin: 2499.1 Wh, totalout: 2313.5 Wh, soc: 20
2025.07.28 10:44:10.895 1: AB_WS_SS DEBUG> EnergyConsumption input -> PV: 600 Wh, PP: 0 Wh, GridIn: 0 Wh, GridCon: 601 Wh, BatIn: 0 Wh, BatOut: 0 Wh
2025.07.28 10:44:10.895 1: AB_WS_SS DEBUG> EnergyConsumption result -> 1201 Wh
2025.07.28 10:44:10.898 1: AB_WS_SS DEBUG> current Power values -> PV2Node: 490 W, PV2Grid: 0, Other: 0 W, GridIn: 0 W, GridCon: 1024 W, BatIn: 0 W, BatOut: 0 W
2025.07.28 10:44:10.898 1: AB_WS_SS DEBUG> current Consumption result -> 1514 W


Schau dir die nachfolgenden Screenshots mal an.

Ich finde bei deinen Screenshots keinen Fehler. Da passt immer alles zusammen, auch wenn dein Heater manchmal nicht erfasst wurde.

Der einzige Unterschied deines Screenshots zu meinem ist die Einbindung der Batterie. Bei dir ist es der klassische Aufbau.
Bei mir ist die Batterie mit einem eigenen Inverter eingebunden. Die Energie des Batterieinverters wird beim PV-Inverter bei mir abgezogen oder dazugezählt, je nachdem, ob die Batterie geladen oder entladen wird. Damit passt die Summe am Inverter-Konten. Grüne Markierung.

Was mir aber jetzt aufgefallen ist, dürfte das genau das Problem für den Dummy-Verbraucher sein.
Das ist mir speziell an meinem ersten Shreenshot aufgefallen. Hier liefert der Hybrid-Inverter-1 81W und der Hybrid-Inverter-2 1019W und der Pseudo-Batterie-Inverter-2 des Hybrid-Iverter-2 2320W. Siehe grüne Markierungen die den Leistungswert am Inverter-Knoten 3240W ergibt.
Diese Werte stimmen mit denen meiner Hybrid-Inverter zusammen, was ich aber mit einer internen Berechnung im Vorfeld mache. Nur SF ist dafür nicht ausgelegt.
Es hängt wahrscheinlich auch damit zusammen.
Betrachtet man den Batterie-Inverter-2, wird hier der fast gleiche Wert angezeigt wie es beim Dummy-Verbraucher der Fall ist. Siehe rote Markierungen.

Was mir dazu noch aufgefallen ist, ist die Batterie die trotz Batterie-Inverter Konfiguration (ac2dc/dc2ac) zusätzlich die Einbindung am Inverter- und Haus-Knoten hat, die eigentlich nicht mehr benötigt werden.

Wenn sich diese Konfiguration nicht auf das SF auswirkt, kann ich den Dummy-Verbraucher weglassen und es passt soweit alles.

@Heiko
In meinem Post befindet sich die Datei energiemanagement.pm die meine SF Konfiguration beinhaltet.
Vielleicht fällt dir noch etwas auf.

Ich denke ich habe somit mein Dummy-Verbraucher Problem gefunden.