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