Leistungsprognose für Wechselrichter

[DS_Starter]

Hallo Stephan,

die Erstellung der Readings statistic_todayGridFeedIn, statistic_todayGridConsumption können schon über das Attr ctrlStatisticReadings (todayGridConsumption, todayGridFeedIn) zugeschaltet werden.
Die Batteriereadings füge ich noch hinzu.

Die Readingserstellung muß etwas sparsam bleiben sonst läuft es aus dem Ruder. Nicht jeder braucht alle Readings.

Grüße,
Heiko 

[CaptainHook]

Hallo Heiko, Hallo Dracolein

super, vielen Dank für das schnelle Feedback. Der Schalter "ctrlStatisticReadings" ist mir beim lesen der Hilfe durchgerutscht.

Gibt einfach das zu steuernde Gerät als Consumer an und passe bei Bedarf mittels vorhandener SolarForeCast-Parameter diverse Ein- / Ausschaltbedingungen an.

Mein Problem ist, das der Consumer quasi aus zwei Geräten besteht, einmal die Energiemessdose und das eigentliche Gerät.
Man könnte einen Dummy anlegen um beide Geräte zu vereinen und dann entsprechen ansteuern.
Meine Frage war eher ob man beim Consumer bei on und off eine FHEM Befehl nutzen kann

Beispiel / Idee:

Code Auswählen Erweitern

Revolt_3d47 type=dishwasher power=1800 icon=scene_dishwasher pcurr=power:W:1 etotal=energy on={set steckdose_1 on} off={set steckdose_1 off}

Grüße Stephan

[DS_Starter]

Mein Problem ist, das der Consumer quasi aus zwei Geräten besteht, einmal die Energiemessdose und das eigentliche Gerät.
Man könnte einen Dummy anlegen um beide Geräte zu vereinen und dann entsprechen ansteuern.
Meine Frage war eher ob man beim Consumer bei on und off eine FHEM Befehl nutzen kann

Ja, das kommt vor (Homematic z.B). Zur Zeit bezieht sich on/off nur auf das angegebene Consumerdevice.
Dummy braucht  man nicht.
Du gibst als Consumer das schaltbare Device an.
Die noch erfragten Energiereadings etc. "spiegelst" du dir per userReadings aus dem Meßdevice in dein Schalterdevice.   

Zum Beispiel so:

Code Auswählen Erweitern

consumption_total:<Triggerreading>.* {ReadingsVal(<Energeiemeßdevice>, "Consumption_Total", 0)}

consumption_total kannst du dann bei dem Schlüssel etotal im Consumerdevice angeben.

Vllt. erweitere ich on/off noch. Mal schauen.

[Dracolein]

@DS_Starter, sorry ich hab mein Posting zulange editiert, während Du bereits geantwortet hattest.

Unhöflich wie ich bin, möchte ich zur Sicherheit nochmal auf mein Posting hinweisen, falls es Dir durchgerutscht sein sollte
https://forum.fhem.de/index.php?topic=117864.msg1281165#msg1281165

 

[DS_Starter]

Gerne erinnern.
Ich verliere durchaus mal bei den vielen Dingen die von verschiedenen Seiten einwirken den Überblick was ich mir noch anschauen wollte.

LG

[DS_Starter]

In meinem contrib liegt die neue Version 0.80.8.

Was ist neu ?

- Model SolCastAPI: Datenabfruf für 72h statt 48h
- über das Attr ctrlStatisticReadings kann das Reading statistic_dayAfterTomorrowPVforecast erzeugt werden (sofern Daten vorhanden sind)
- über das Attr ctrlStatisticReadings können die Readings statistic_todayBatIn und statistic_todayBatOut erzeugt werden.

LG

[Dracolein]

Short notice, habe meinen FHEM-Server grade neugestartet - mit von Dir o.g. v 0.80.8. und erhielt im Log einen Eintrag:

Code Auswählen Erweitern

PERL WARNING: Use of uninitialized value in string eq at ./FHEM/76_SolarForecast.pm line 3698.

[DS_Starter]

Moin,

danke für die Info. Habe es beseitigt und liegt im contrib.

[DS_Starter]

In meinem contrib liegt die neue Version 0.80.10.

Was ist neu ?

- die Berechnung für die Vorhersage/Ergebnisqualität richtet sich nun nach dem tatsächlich erreichten Abweichungswert der jeweiligen Stunde in der Durchschnittsbetrachtung.
  Mit get ... forecastQualities sieht man die erreichten Werte (1 ist das erreichbare Maximum):

....
starttime: 2023-07-14 11:00:00, wcc: 51, crange: -, quality: 0.13, used factor: 1.16
starttime: 2023-07-14 12:00:00, wcc: 55, crange: -, quality: 0.10, used factor: 1.11
starttime: 2023-07-14 13:00:00, wcc: 61, crange: -, quality: 0.82, used factor: 1.22
starttime: 2023-07-14 14:00:00, wcc: 61, crange: -, quality: 0.83, used factor: 1.21
starttime: 2023-07-14 15:00:00, wcc: 63, crange: -, quality: 0.9, used factor: 1.11
starttime: 2023-07-14 16:00:00, wcc: 61, crange: -, quality: 0.85, used factor: 1.18
starttime: 2023-07-14 17:00:00, wcc: 59, crange: -, quality: 0.71, used factor: 1.31
starttime: 2023-07-14 18:00:00, wcc: 57, crange: -, quality: 0.67, used factor: 1.36
starttime: 2023-07-14 19:00:00, wcc: 51, crange: -, quality: 0.65, used factor: 1.53
starttime: 2023-07-14 20:00:00, wcc: 51, crange: -, quality: 0.62, used factor: 1.61
starttime: 2023-07-14 21:00:00, wcc: 43, crange: -, quality: 0.89, used factor: 1.12

Die starttime ist der kommende Tag, die dann verwendeten Faktoren und angezeigten Qualitäten sind verzeichnet. Es hat mich schon lange gestört, dass die Qualitäten sich immer nur auf die Anzahl der berücksichtigten Tage bezog.

- die Consumer haben einen neuen Schlüssel spignorecond (surplus ignore condition) der die von Dracolein angeregte Funktion abdeckt. Aus der Hilfe:

spignorecond    
   Bedingung um einen PV Überschuß zu ignorieren (optional). Bei erfüllter Bedingung wird der Verbraucher entsprechend der Planung eingeschaltet
   auch wenn zu dem Zeitpunkt kein PV Überschuß vorliegt.
   ACHTUNG: Die Verwendung beider Schlüssel spignorecond und interruptable kann zu einem unerwünschten Verhalten führen!
   Device - Device zur Lieferung der Bedingung
   Reading - Reading welches die Bedingung enthält
   Regex - regulärer Ausdruck der für eine 'wahre' Bedingung erfüllt sein muß

Wichtig ist sich Gedanken darüber zu machen ob die Angaben in den Schlüssel spignorecond und interruptable sich widersprechen. Es wird nun bereits etwas komplex aber das Thema ist nunmal nicht ganz so trivial und man muß ein paar Überlegungen anstellen.

Ich konnte den neuen Schlüssel noch nicht so ganz ausgiebig testen ... das überlasse ich Dracolein. 

[Dracolein]

Ja geil, dann muss ich mich damit am Wochenende beschäftigen 
Stand up paddel
Radtour
Joggingrunde
Grillen & Bier

Korrektur
Grillen & Bier bleibt!


edit:
vorbereitende Rückfrage meinerseits zur richtigen Syntax mit der Bitte um Korrektur

Code Auswählen Erweitern

spignorecond=<Device>:<Reading>:<Regex>Kann man dort auch eine If-Abfrage als Bedingung formulieren und falls ja, wie wäre die zu formulieren? (Falls zu komplex, umgehe ich dies mittels eines userreadings) Ginge beispielhaft sowas?:

Code Auswählen Erweitern

spignorecond={ReadingsVal("Wallboxdevice","state",0) eq "loading" and ReadingsNum("SMAgateway","pvueberschuss",0) = 1}
(FHEM-Code wie in DOIFs möglich klappt vermutlich nicht ([Device:Reading] eq "loading").... usw):


by the way angemerkt: Du hast echt einen Nagel im Kopf!
13.000 Zeilen Code, in Worten dreizehnTAUSEND Zeilen Code hat das Modul inzwischen       

[DS_Starter]

Moin,

... ja, es verursacht manchmal schon Schmerzen. 

Kann man dort auch eine If-Abfrage als Bedingung formulieren und falls ja, wie wäre die zu formulieren?

Nein, nur ein Regex wird ausgewertet. Ich will es gleich halten mit den Schlüsseln swoncond und swoffcond.

Ist aber kein Problem.
Vllt. folgende Vorgehensweise...
Ersinne ein Reading, z.B. wallboxControl. Das kannst du im SolCast-Device selbst anlegen, dann ist alles beisammen.

Den Wert dafür setzt du mit einem DOIF oder diesem Perl Code:

Code Auswählen Erweitern

{
  if (ReadingsVal("Wallboxdevice","state", '') eq "loading" && ReadingsNum("SMAgateway","pvueberschuss",0) == 1) {
      fhem "setreading <SolCast-Device> wallboxControl 1";
  }
  else {
      fhem "setreading <SolCast-Device> wallboxControl 0";
  }
}
Diesen Code kannst du direkt im SolCast Device im Attr ctrlUserExitFn hinterlegen. Dann ist es noch etwas einfacher:

Code Auswählen Erweitern

{
  if (ReadingsVal("Wallboxdevice","state",'') eq "loading" && ReadingsNum("SMAgateway","pvueberschuss",0) == 1) {
      fhem "setreading $name wallboxControl 1";
  }
  else {
      fhem "setreading $name wallboxControl 0";
  }
}
Die Schlüsseldefinition wäre dann:

Code Auswählen Erweitern

spignorecond=<SolCast-Device>:wallboxControl:1
So hast du alle Steuerung in einem Device und kannst dich austoben. 

Edit: kleiner Nachteil dabei ist, dass der Code in ctrlUserExitFn am Ende eines intervalls ausgeführt wird. Heißt also das Modul durchläuft seine Task, am Ende wird erst wallboxControl gesetzt. Beim nächsten Intervall wird dann das neu gesetzte wallboxControl ausgewertet. Kann man aber sicherlich verschmerzen. 

[Dracolein]

Habe es eingebaut und muss warten, bis ich mit dem Tesla zuhause laden kann, um zu sehen was passiert.

Ich glaube noch einen zweiten Anwendungsfall entdeckt zu haben: Mein Luftentfeuchter im Keller, welcher seit jeher mittels DOIF gesteuert wird (DOIF PV-Erzeugung >1000 Watt then einschalten DOELSEIF Feuchtigkeit >70% then einschalten DOELSE ausschalten). Mir fehlte bisher zur Integration in SolarForecast immer eine Zwangseinschaltvorgabe im Winter, wenn Feuchtigkeit zu hoch, aber kein PV-Überschuss vorhanden.

edit:
Weitere Frage / Idee:
gibts einen Parameter, der inhaltlich das Gegenteil zu "locktime" bewirkt? Sprich, eine Art Mindestlaufzeit nach Einschaltzeitpunkt? Wenn mein Luftentfeuchter durch Bedingungen eingeschaltet wurde, soll er wenigstens 10-15 Minuten laufen dürfen, bevor möglicherweise geänderte Rahmenbedingungen ihn wieder abschalten dürfen.
Mit "locktime" erreiche ich immerhin Zwangsstop-Intervalle bis zum nächsten Einschaltzeitpunkt.

Hintergrund:
Während beispielsweise meinen IR-Heizungen minütliches Ein- und Ausschalten völlig egal ist, läuft im Luftentfeuchter ein mechanischer Kompressor, der im möglichen Extremfall 20-30x Schaltzyklen pro Stunde über Zeit nicht so toll finden wird.

edit2:
Vielleicht ist mein Gedanke auch Quatsch... den mit "locktime" reduziere ich bereits die möglichen Schaltzyklen auf (im obigen Beispiel) höchstens 4x stündlich.

[Dracolein]

Habe im Logfile nach Restart heute vormittag folgende Meldung gesehen:

Code Auswählen Erweitern

2023.07.14 09:30:36 1: PERL WARNING: Use of uninitialized value $lang in string eq at ./FHEM/76_SolarForecast.pm line 10625.

[DS_Starter]

Hmmm, konnte die Warnung bei mir nicht nachvollziehen.
Schalte dir mal das globale stacktrace ein, dann restart.
Im Log sollten dann mehr Infos kommen zu dem Call-Verlauf.

[cbl]

Zwischen den Wünschen zur Verbesserung und Benutzungsfragen möchte ich nach mehreren Wochen Nutzung des Moduls ein riesengroßes Dankeschön aussprechen an DS_Starter und alle, die das Modul dorthin gebracht haben, wo es mittlerweile steht.

Ich habe in Vorfreude auf die Inbetriebnahme meiner PV-Anlage angefangen, das Modul zu konfigurieren und erfreue mich seit dem ersten Tag vor drei Wochen an der immer besser werdenden Prognose (v.a. die Bewölkung war arg unterschiedlich) und der Darstellung im Modul. Die Automatisierungen zum Ein-/Ausschalten von Verbrauchern klappt leider gerade noch nicht - was aber nicht am Modul sondern an einem derzeit nicht funktionierenden Luftfeuchtigkeitsmesser im Zigbee-Netz hängt.

DANKE!