76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[hugomckinley]

Das wars!
Da steht gerade 0 (W) drinnen, was false ist.
Unter Tags steht dort aber irgendwas >0 drinnen, was dann natürlich true ist.
Somit vergleiche ich mit unterschiedlichen Werten.

Danke sehr!
Das habe ich zwar gelesen, aber nicht verstanden bzw. hinterfragt, weil es fälschlicherweise funktioniert hat, wenn die Heizung lief!
Ich habe das so interpretiert, dass Device:Reading nur den $VALUE liefert, um damit mit dem Perlcode zu rechnen.
Nachdem ich keinen Wert brauche, war das irgendein dummy-Wert. Jetzt nehme ich einen dummy-Wert der statisch 1 ist.

Gerade korrigiert.
Wie immer im Leben -> Kaum macht man es richtig, funktionierts!

[DS_Starter]

In meinem contrib liegt ein Update der V 1.54.4. Drin ist:

- Attr ConsumerXX hat neuen Key 'aliasshort'

- Deprecated Attribut graphicShowDiff entfernt

- Attr ConsumerXX Key surpmeth=median[_2..20] kann optional die neuesten 2..20 Elemente verwenden

- Attr ConsumerXX Key surpmeth=average[_2..20] anstatt nur 2..20 -> Harmonisierung zur Angabe
                      von surpmeth=median[_2..20] und es werden die neuesten X Elemente verwendet (Korrektur)

- Debug consumerSwitching: Info-Meldung des Vergleichsvorgangs wird ausgegeben

- Speichern des Ergebnisses der surpmeth-Berechnung im neuen Schlüssel surpmethResult im
  Verbraucherstammsatz (get ... valConsumerMaster).
  Den Wert kann man sich mit [FHEM::SolarForecast::]ConsumerVal ('<Name>', '<Nr>', 'surpmethResult', <default>)
  in eigene Programme holen (Wiki)

- Präzisierung der comRef:

Code Auswählen Erweitern

swoncond     Bedingung die zusätzlich erfüllt sein muß um den geplanten Zyklus zu starten und den Verbraucher einzuschalten (optional).
    Device:Reading - die Device/Reading Kombination liefert den Prüfwert $VALUE ('undef' wird ignoriert)
    Die Prüfung kann als regulärer Ausdruck oder als in {..} eingeschlossener Perl-Code formuliert sein:
    Regex - regulärer Ausdruck zur Prüfung von $VALUE der im Erfolgsfall 'wahr' liefern muß
    {Perl-Code} - der in {..} eingeschlossene Perl-Code darf keine Leerzeichen enthalten. Die Variable $VALUE kann vom Code ausgewertet werden.
    Der return Wert muß im Erfolgsfall 'wahr' sein.
   
swoffcond     vorrangige Bedingung um den Verbraucher auszuschalten (optional). Der geplante Zyklus wird gestoppt.
    Device:Reading - die Device/Reading Kombination liefert den Prüfwert $VALUE ('undef' wird ignoriert)
    Die Prüfung kann als regulärer Ausdruck oder als in {..} eingeschlossener Perl-Code formuliert sein:
    Regex - regulärer Ausdruck zur Prüfung von $VALUE der im Erfolgsfall 'wahr' liefern muß
    {Perl-Code} - der in {..} eingeschlossene Perl-Code darf keine Leerzeichen enthalten. Die Variable $VALUE kann vom Code ausgewertet werden.
    Der return Wert muß im Erfolgsfall 'wahr' sein.


LG,
Heiko

[300P]

PS:
Heute wird bei einigen wohl auch ein FTUI-Update manuell mit "get <SF-Devicename> ftuiFramefiles" notwendig 

[Burny4600]

@Heiko

Dann stimmt aber noch etwas im Setup nicht. Die Flüsse der Batterieinverter werden vom Knoten subtrahiert sofern die Laufrichtung (d.h. In/Out) richtig verwendet wird.
Leider sehe ich das Setup der Batterieinverter nicht.

Möglich das ich hier einen Fehler habe.
Meine Batterien sind am Hybridinverter angeschlossen.

Das setupBatteryDev01 lautet

Code Auswählen Erweitern

Deye_12k icon=@dyn:@dyn:@dyn:@dyn show=2:bottom label=beside cap=24000
pin=Akku_Leistung_BMS1__kW:kW pout=-pin charge=Akku_SOC__KAP
intotal=Akku_Energie_Ladung_Gesamt__kWh:kWh outtotal=Akku_Energie_Entladung_Gesamt__kWh:kWh
asynchron=1
Muss ich zusätzlich ein setupInverterDev03 als einen Batterie-Wechselrichter anlegen?

Bei der Erfassung des Verbrauch (Wh) = PV-Erzeugung + sonstige Erzeugung - Netzeinspeisung + Netzbezug - Batterieladung + Batterieentladung.
Sind das die sich stetig erhöhendeen Wh, also die bisherige Summe an Wh der einzelnen Geräten?

[DS_Starter]

Muss ich zusätzlich ein setupInverterDev03 als einen Batterie-Wechselrichter anlegen?

Ja genau. Nativ kann das Modul noch keinen Hybridinverter integrieren. Als Workarund erstellt man einen Standardwechselrichter und dazu einen (virtuellen) Batteriewechselrichter.

Bei der Erfassung des Verbrauch (Wh) = PV-Erzeugung + sonstige Erzeugung - Netzeinspeisung + Netzbezug - Batterieladung + Batterieentladung.
Sind das die sich stetig erhöhendeen Wh, also die bisherige Summe an Wh der einzelnen Geräten?

Wir rechnen auf Stundenbasis. Das Ergebnis Wh bedingt auch dass die Bestandteile in Wh vorliegen müssen. Allerdings wird nur der Stundenanteil jedes Gerätes verwendet und nicht die Summe Wh, aber das macht das Modul intern. Abgeleitet wird es aus den jeweiligen Werten Total Wh.

[Burny4600]

Ja genau. Nativ kann das Modul noch keinen Hybridinverter integrieren. Als Workarund erstellt man einen Standardwechselrichter und dazu einen (virtuellen) Batteriewechselrichter.

Dazu muss ich mir noch etwas berechnen um ac2dc   und dc2ac zu ermitteln.
Nur da müsste ich die Strings der Hybridinverter bei dieser Definition abziehen um es annähernd zu berechnen, denn um die Verluste zu ermitteln muss ich mir noch etwas einfallen lassen.

Wir rechnen auf Stundenbasis. Das Ergebnis Wh bedingt auch dass die Bestandteile in Wh vorliegen müssen. Allerdings wird nur der Stundenanteil jedes Gerätes verwendet und nicht die Summe Wh, aber das macht das Modul intern. Abgeleitet wird es aus den jeweiligen Werten Total Wh.

Gut diese Wh Werte liegen sowohl pro h, pro Tag und als Total vor. Die Totalwerte haben alle gepasst.

[DS_Starter]

@all,
die V 1.54.4 ist eingecheckt und morgen früh im Update enthalten. Details in #3586.

LG,
Heiko

[Burny4600]

@Heiko

Kann man die Farbe je nach Flussrichtung des Beams bei den Batterie-Wechselrichtern so einstellen, dass zB. Laden Rot wäre und Entladen Grün wäre.

[DS_Starter]

Kann man die Farbe je nach Flussrichtung des Beams bei den Batterie-Wechselrichtern so einstellen, dass zB. Laden Rot wäre und Entladen Grün wäre.

Momentan kann man das nicht.

Zur Zeit gibt es, von den Consumern mal abgesehen, diese drei Grundfarben:

Code Auswählen Erweitern

strokecolina     Farbe einer inaktiven Linie
    Wert: Hex (z.B. #cc3300) oder Bezeichnung (z.B. red, blue), default: gray
   
strokecolsig     Farbe einer aktiven Signallinie
    Wert: Hex (z.B. #cc3300) oder Bezeichnung (z.B. red, blue), default: red
   
strokecolstd     Farbe einer aktiven Standardlinie
    Wert: Hex (z.B. #cc3300) oder Bezeichnung (z.B. red, blue), default: darkorange

Dabei ist die Signallinie in rot vorbehalten für einen Zusatnd der i.A. als "unschön" angesehen wird, z.B. den Netzbezug.

Für BatIn/Out trifft das so nicht zu. Es ist nur eine Zwischenspeicherung, die ich persönlich als neutral bewerten würde.
Wenn es den Wunsch nach einer farblichen Unterscheidung gibt, würde ich zwei neue Liniennamen in flowGraphicControl aufnehmen für diesen Zweck und die Farbgebung komplett dem User überlassen wenn er vom Standard abweichen möchte. Das wären dann Linien für BatIn/BatOut.

LG,
Heiko

[Burny4600]

Es muss nicht rot sein, nur einen Unterschied zwischen laden und entladen wäre übersichtlicher bei der Verfolgung des Stromflusses.

Nochmals zurück zu der Leistungsberechnung am Inverter-Knoten in der Graphik.
Verbrauch (W) = Inverter Last Leistung ∑ (W) + sonstige Erzeugung ∑ (W) - Inverter Batterieladung (W) + Inverter Batterieentladung (W)
Die Batterieladung bzw. Batterieentladung berechne ich aus der Akku Leistung, je nach dem ob sie positiv oder negativ ist.

Diese Berechnung kann ich leider bei mir so nicht anwenden.
Die Batterieladung und Batterieentladung dürfen bei mir nicht in die Berechnung des AC-Verbrauchs der Graphik einfließen, sondern werden nur intern im Hybridinverter angezeigt und kann nur als Anzeige in der Graphik verwendet werden.
Würde ich die Batterieladung und Batterieentladung aus dem Verbrauch herausrechnen, passt das mit der Übersicht nicht mehr.

Ich lasse es derzeit wie es ist.

[hugomckinley]

Schön langsam wird es mit meiner Überschussregelung per SF
Wenn ich die letzten Herausforderungen noch schaffe und über keinen Showstopper mehr stolpere, werde ich dann die "Simulation" auf einem Dummy noch ein paar Tage beobachten und dann in den Testbetrieb gehen können.

Aber hier brauche ich Expertenrat:

• Was ist der logical Switchstate und warum und wann unterscheidet er sich vom physical Switchstate?
• 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)
• Was bedeutet: Interrupt Characteristic value: 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.
• 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?
• cycleDayNum: 3 heißt drei mal Ein und drei mal Aus, oder Ein, Aus, Ein?
• Die größte Frage: Warum wird hier nicht ausgeschaltet?

Code Auswählen Erweitern

2025.07.23 20:08:17 1: energy_mgmt DEBUG> ############### consumerSwitching consumer "04" ###############
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - ConsumptionRecommended calc method: median:13, surplus: 0
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - method base: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - additional consumption after switching on (if currently 'off'): 0 W
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - current planning state: planned
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - physical Switchstate before switching: on
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - logical Switchstate before switching: off
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - general switching parameters => auto mode: 1, Current household consumption: 1108 W, nompower: 1800, surplus: 0 W, planstate: replanned: 2025-07-23 19:45:17 - 2025-07-23 20:50:59, starttime: 23.07.2025 19:45:17
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - isInLocktime: 0
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - Check Context 'switch on' => swoncond: 0, on-command: heatpump on
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - isAddSwitchOnCond Info: The value "1" resulted in 'false' after exec "{main::CheckWPOn}"

2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - isAddSwitchOffCond Info: The reference value "1" resulted in 'true' after exec "{main::CheckWPOff}"
-> Check successful -> the effect depends on the switch context
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - device 'dum_valve' is used as switching device
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - Interrupt Info: The reference value "1" resulted in 'false' after exec "{main::CheckWPInterruptable}"
-> the effect depends on the switch context
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - Interrupt Characteristic value: 3
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - Check Context 'switch off' => swoffcond: 1, off-command: heatpump off
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - is Consumption recommended: 0
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - isAddSwitchOffCond Info: The reference value "1" resulted in 'true' after exec "{main::CheckWPOff}"
-> Check successful -> the effect depends on the switch context
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - Interrupt Info: The reference value "1" resulted in 'false' after exec "{main::CheckWPInterruptable}"
-> the effect depends on the switch context
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - current planning state: planned
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - physical Switchstate after switching: on
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - logical Switchstate after switching: off
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - cycleDayNum: 3
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - last cycle start time: 2025-07-23 10:25:14
2025.07.23 20:08:17 1: energy_mgmt DEBUG> consumer "04" - last cycle end time: 2025-07-23 14:44:14
Definition des Consumers:

Code Auswählen Erweitern

Pool_Strom_Heizung:Poolheizung
aliasshort=WP
type=other power=1800 asynchron=0
icon=sani_heating_heatpump
auto=sf_automatic
pcurr=Pool_Pin32_monotonic_count_PowerCurrent:W
switchdev=dum_valve
swstate=heatpump:on:off
mode=can
locktime=600:600
mintime=SunPath
on="heatpump on"
off="heatpump off"
surpmeth=median_13
noshow=0
swoncond=dum_valve:sf_true:{main::CheckWPOn}
interruptable=dum_valve:sf_true:{main::CheckWPInterruptable}
swoffcond=dum_valve:sf_true:{main::CheckWPOff}