76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Hallo Hugo,

willkommen bei den PV-Propheten. 

gibt es eine Möglichkeit im Flow den Alias der Consumer anzuzeigen. Nicht als Mouseover, sondern als Text über dem Icon o.ä.

Zur Zeit gibt es diese Möglichkeit nicht, vor allem weil die Breite des Alias-Textes unvorhersehbar ist. Alternativ könnte ich die Nummer des Consumers als Andruckmöglichkeit vorsehen.

Muss man das Attribut plantControl->reductionState zusätzlich zu plantControl->feedinPowerLimit angeben, oder ist das alternativ.

Weder noch. Beide Attribute sind optional und steuern verschiedene Aufgaben wie sie in der Commandref beschrieben sind.

Wenn man beides angeben muss, wozu dient dann die Information des reductionStates?

Muß man nicht, aber plantControl->reductionState teilt dem Modul mit dass die Anlage abgeregelt wurde/ist. Es gibt unterschiedliche Gründe dafür. Ein Grund könnte sein, dass das Einspeiselimit der Anlage erreicht ist UND die uberschüssige Energie nicht mehr durch die vorhandenen Batterien aufgenommen werden kann weil diese bereits voll geladen sind.
Also ist plantControl->reductionState für das Modul ein Informationsstatus und es ist davon auszugehen, dass PV-Prognose und reale Erzeugung nicht zusammenpassen werden und somit der Datensatz der betreffenden Stunde nicht für Trainings- un Korrekturzwecke geeignet ist.

LG,
Heiko

[hugomckinley]

Hallo Heiko,
danke für die schnelle Antwort.
Ich muss mich noch an den modularen Aufbau gewöhnen, der solche "Hinweise" braucht. Mein selbst gestrickter, monolithischer Block "weiß" ja alles, ist aber ab dem Speicher der kommen wird nicht mehr sinnvoll wartbar/erweiterbar.

Danke für das tolle Modul.

Zur Zeit gibt es diese Möglichkeit nicht, vor allem weil die Breite des Alias-Textes unvorhersehbar ist. Alternativ könnte ich die Nummer des Consumers als Andruckmöglichkeit vorsehen.

Mein Featurerequests wäre ein zusätzliches Attribut z.B. displayname einzuführen, das auf z.B. 15 Zeichen limitiert ist und über/unter dem Consumer angezeigt wird, wenn es definiert ist. Dann kann man einen sprechenden (langen) Namen vergeben und etwas kurzes, mit dem man den Consumer im Flow schnell identifizieren kann.

Grüße,
Hugo

[Max_Meyer]

Mein Featurerequests wäre ein zusätzliches Attribut z.B. displayname einzuführen, das auf z.B. 15 Zeichen limitiert ist und über/unter dem Consumer angezeigt wird, wenn es definiert ist. Dann kann man einen sprechenden (langen) Namen vergeben und etwas kurzes, mit dem man den Consumer im Flow schnell identifizieren kann.

Hallo Hugo
Ich habe dieses ,Dilemma' mit MQTT- Device gelöst, d.h. SF sieht die,'Original-Device' gar nicht sondern nur MQTT, die sprechende Namen haben, dort hab ich nur die für SF notwendigen topic abonniert und wo notwendig kombiniert
Auf diese Weise sind inzwischen 11 WR und über 70 Consumer an SF angebunden. Ein HybridWR ist als Batterie und als WR mit an Bord. Logik z.B. Ladung Batterie, Prioritäten.... läuft auf den eigentlichen Device und wird von SF mit Signalen versorgt
Vielleicht kein Idealweg,aber mir hat es in einer über Jahre gewachsen Anlage, geholfen gewachsene Logik von neuem zu entkoppeln.
Gruß Gerd

[hugomckinley]

Hallo Gerd,
ich kann mir das jetzt ohne Details nicht vorstellen, wie deine Steuerung funktioniert, aber mein "Problem" ist nur optischer Natur
Dazu würde ich auf keinen Fall MQTT als zusätzlichen Layer einziehen.

Mein Ziel ist es derzeit, dass ich jetzt die "wenigen" Geräte, die meine eigene Logik steuert, in SF zu überführen und dort zu schalten.
Dazu muss ich mir, soweit ich das bis jetzt verstanden habe, die passenden swoncond und swoffcond basteln um die entsprechenden Randbedingungen zu berücksichtigen.
Auch die locktime werde ich verwenden, da ich bisher alles mit DOIF und wait-timern gelöst habe.

Könntest du mir beispielhaft die notwendigen Definitionen eines deiner Geräte zukommen lassen, vielleicht kan ich ja was abkucken?
Danke!

Grüße,
Hugo

[hugomckinley]

Da hätte ich auch noch gleich eine Frage dazu, wo ich keine Antwort gefunden habe:

Ist es möglich als PerlCode bei swoncond eine Funktion aus der 99_myUtils.pm zu verwenden.
Ein erster Versuch führt leider nur zu:

Code Auswählen Erweitern

ERROR in interruptable or swoffcond Code execution: Undefined subroutine &FHEM::SolarForecast::CheckWPOff called at (eval 170417) line 1.Die Funktion lässt sich aber in der Befehlszeile von FHEM aufrufen und funktioniert.

Grüße,
Hugo

[DS_Starter]

Hallo Hugo,

wenn du eine Funktion außerhalb des SolarForecast-Packages im "main" aufrufen willst, mußt du die Funktion mit zwei führenden Doppelpunkten schreiben, also z.B.:

Code Auswählen Erweitern

{::CheckWPOff}

Funktionen in der 99_myUtils.pm liegen im "main" Package, welches man damit erreicht. Auch "main::CheckWPOff" wäre möglich.

LG,
Heiko

[hugomckinley]

Sehe ich das richtig, dass man bei der surpmeth "median" oder "avg" nicht sagen kann, ob das der Median oder der Durchschnitt der letzten 5sec oder der letzten 5 Minuten ist, sobald man einen oder mehrere Consumer/Inverter mit asynchron=1 hat? In diesem Fall ist ja plantControl->cycleInterval eigentlich nicht mehr relevant bei vielen Events, da ja jeder eine Neuberechnung auslöst.
Sehe ich das richtig?

Hintergrund: Bisher prüfe ich, ob der Überschuss für eine gewisse Zeit (einige Minuten, kommt auf den Verbraucher an) über seiner Leistung + Zuschlag liegt. Das führt dazu, dass ein kurzes Aufreißen der Wolkendecke, nicht zu einem Einschalten führt. Ebenso in umgekehrter Richtung, dass eine Wolke die 2 Minuten die PV-Leistung senkt nicht zum Ausschalten des Verbrauchers führt.
Dieses Verhalten könnte ich mit dem Median oder dem Durchschnitt wahrscheinlich auch abbilden, aber nur wenn das der Wert in einem gewissen (einstellbaren) Zeitraum ist und nicht über eine gewisse Anzahl von Werten, da ich ja nicht sagen kann, ob das der Median/Durchschnitt von 30 Sekunden oder 5 Minuten ist.

Nebeneffekt ist, dass ich bei mir über die Wartezeiten die Verbraucher priorisieren kann. z.B. erhöht die Poolpumpe die Leistung nach 3 Minuten, die Wärmepumpe schaltet aber erst nach 6 Minuten ein, um ein Takten möglichst zu vermeiden. Das führt auch dazu, dass die WP nur dann aktiv wird, wenn der Überschuss für beide reicht. Wenn der Überschuss zwar für die Poolpumpe oder die Wärmepumpe reicht, aber nach dem Hochschalten der Poolpumpe sich die WP nicht mehr ausgeht, wird dieser Timer in den folgenden Minuten nach dem Hochschalten der Poolpumpe zurück gesetzt und die Wärmepumpe muss (weiter) warten, oder es geht sich gar nicht mehr aus.

d.h. über das unterschiedlich verzögerte Einschalten kann ich die Verbraucher priorisieren und die waittimer sorgen für ein stabiles und schwankungstolerantes Schaltverhalten.
So schaltet die WP als erstes aus, denn ohne kann die Pumpe wahrscheinlich weiter laufen. Damit die WP nicht zu oft taktet, aber erst nach z.B. 7 Minuten und die Pumpe nach 9 Minuten usw.

Das alles hat jetzt noch nichts mit einem Forecast zu tun, denn das ist nur das Folgen der Überschussleistung und da brauche ich keine Vorhersage, da dieses Verhalten von Sonneaufgang bis Sonnenuntergang gilt.

Die Verbesserung/Erweiterung, die ich mir durch SF erhoffe ist, dass ich mit der Vorhersage dann die Wärmepumpe fürs Haus, Batterieladung und E-Auto in Abhängigkeit der Prognose zum passenden Zeitpunkt "einzwicken" kann, damit es im Haus warm ist und das Auto voll (genug) wird usw.
In dieser Zeit können dann andere (niederpriorisierte) "Überschussverbraucher" ausgeschaltet, bzw. runter geregelt werden. z.B. muss das Auto geladen werden, auch wenn der Pool noch keine Badewanne ist
Dieses Verhalten sollte auch möglich sein, wenn diese hochpriorsierten Verbraucher (WP-Haus, e-Auto, Batterieladung) über die Prognose von SF gesteuert werden und die "Überschussvernichter" extern, wie bisher. Vom Gefühl her ist das besser zu kontrollieren, wenn alles über SF läuft.
Ausserdem wäre es leichter beherschbar, wenn das ganze Strommanagement an einer Stelle passiert und nicht vom Zusammenspiel von zwei Systemen, die nur indirekt üner den Überschuss kommunizieren, abhängt. 

Ich weiß nicht, ob das hier die richtige Stelle ist, aber das sind so meine Überlegungen und mir will nicht einfallen, wie ich das mit SF abbilden kann, ohne etwas mit den waittimern von DOIF vergleichbarem.

Bitte um Korrektur, oder Hinweise, ob ich da auf dem Holzweg bin, oder ob ich nur nicht sehe, wie das funktionieren kann.

Grüße,
Hugo

[DS_Starter]

Sehe ich das richtig, dass man bei der surpmeth "median" oder "avg" nicht sagen kann, ob das der Median oder der Durchschnitt der letzten 5sec oder der letzten 5 Minuten ist, sobald man einen oder mehrere Consumer/Inverter mit asynchron=1 hat?  In diesem Fall ist ja plantControl->cycleInterval eigentlich nicht mehr relevant bei vielen Events, da ja jeder eine Neuberechnung auslöst.
Sehe ich das richtig?

Ja, das siehst du richtig.

Dieses Verhalten könnte ich mit dem Median oder dem Durchschnitt wahrscheinlich auch abbilden, aber nur wenn das der Wert in einem gewissen (einstellbaren) Zeitraum ist und nicht über eine gewisse Anzahl von Werten, da ich ja nicht sagen kann, ob das der Median/Durchschnitt von 30 Sekunden oder 5 Minuten ist.

Ja richtig. Die asynch-Einstellung ist in diesem Kontext nicht hilfreich.

Wenn man eine regelmäßige Bezugsgröße bzgl. der Zyklusabarbeitung braucht, sollte asynch nicht gesetzt werden.
Evtl. kann man mit "locktime" ergänzend auf das Schaltverhalten Einfluß nehmen. 

LG,
Heiko

[Max_Meyer]

Könntest du mir beispielhaft die notwendigen Definitionen eines deiner Geräte zukommen lassen, vielleicht kan ich ja was abkucken?

Hallo Hugo,
Das mach ich gerne - wird aber bisschen dauern da ich derzeit nur mit dem Handy unterwegs bin und so das kopieren von Code fehlerträchtig ist. Ich hoffe das passt?
Ich habe die Lösung gewählt weil die eigentlichen Device auf unterschiedlicher Hardware laufen so bleib ich flexibel.
Gruß Gerd

[Burny4600]

@Heiko

Ich habe eine Bitte betreffend der Batterieanzeige.
Derzeit sind meine zwei unabhängigen Batterieeinheiten in der Anzeige vermischt. Ich vermute das auch daraus der Stromfluss, egal in welche Richtung, immer grün angezeigt wird.
Derzeit habe ich noch keine Idee wie ich die Visualisierung entsprechend umstellen kann.
Wenn du einmal an den Hybridinvertern arbeitest, wäre eine Änderung der Batterieeinheiten hilfreich.

Zur Erinnerung:
Ich habe zwei unabhängige Hybridinverter.
Jeder Hybridinverter hat mehrere ihm zugeteilte Batterieinheiten die als gesamte Einheit zu betrachten sind (Batteriekaskade pro Hybridinverter).
Darum müssten eine Zuteilung bei den Hybridinverter erfolgen, wo jeder Hybridinverter seine eigene Batterie hat.

Wie gesagt, wenn du einmal mit den Hybridinvertern anfängst.

[300P]

Kleine Codeschnipsel für diejenigen die immer wieder die Contrib-Versionen zum Testen laden (FHEM auf RPI)

A - >>Userattribut anlegen (hinzufügen)

Code Auswählen Erweitern

attr Forecast userattr userFn_LoadContribcUpdate:1,0
B - >>ctrlUserExitFn anlegen (oder ergänzen)

Code Auswählen Erweitern

{
# BEGIN ######## Load_Contrib_Update #######
#
# Wenn attr userFn_LoadContribcUpdate = 1 dann ...
# lade das aktuelle nur 1 x das Solarforecast Update ...
# aus dem Contrib von DS_Starter.

  my $updatefromcontrib = AttrVal ($name, 'userFn_LoadContribcUpdate', "0");

  if ($updatefromcontrib eq "1") {

  # lade die aktuelle Dateiversion vom Contrib DS_Starter
  Log3 ($name, 2, qq{$name - start download Update Solarforecast from Contrib   ====>>> wird gestartet});
  fhem ('"wget -qO ./FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm"');

  # setze aber sofort wieder zurück auf 0 (= nicht weiter laden >> 1 x reicht)
  Log3 ($name, 2, qq{$name - end download Update Solarforecast from Contrib});
  fhem (" attr $name userFn_LoadContribcUpdate 0");
  Log3 ($name, 2, qq{$name - attr $name userFn_LoadContribcUpdate 0             ====>>> wurde ausgeführt});
  }
#
#
# ENDE ######## Load_Contrib_Update #######
}

C - >>Anzeige im Bereich graphicHeaderOwnspec irgendwo einfügen:

Code Auswählen Erweitern

ContribUpdate:userFn_LoadContribcUpdate

Im graphicHeaderOwnspec setzt man dann o.g. von 0 auf 1. Als Ergebnis wird einmalig die aktuelle Version aus dem Contrib von DS_Starter geladen.

Nicht vergessen !!!
Manuelles "shutdown & restart" aktiviert erst die frisch geladene Testversion !!!

[grappa24]

@Burny4600, bin nicht sicher, ob es dir hilft:

Ich hab zwar nur einen Hybridinverter, habe aber für diesen im Modul zwei Inverter angelegt, wobei der eine den Fluß von/zur Batterie darstellt.
Hier seine Definition (mit strings=none und ac2dc bzw. dc2ac):

Code Auswählen Erweitern

SymGen24 icon=inverter@#ff8c00:inverter@grey strings=none ac2dc=PowerFlow_Site_P_DC_OUT:W dc2ac=PowerFlow_Site_P_DC_IN:W capacity=7680 asynchron=1

[DS_Starter]

Hallo zusammen,

nur zur Info, morgen ist ein Update verfügbar welches aber nur mehr Debug Infos liefert -> https://forum.fhem.de/index.php?msg=1344951.

LG,
Heiko