76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[grappa24]

Hallo,

ich musste leider meinen RasPi mit FHEM neu aufsetzen, konnte allerdings die fhem.cfg wiederverwenden.

Allerdings ist mein Solarforecast Device weg 

(wo) sind die Daten auf dem RasPi gespeichert und könnten somit wiederhergestellt werden?

Grüße,
Dieter

[DS_Starter]

Hallo Dieter,

zu diesem Thema habe ich einen Wiki Artikel geschrieben.

Die einzelnen Schritte zur Wiederherstellung sind in dem Beitrag beschrieben:

Code Auswählen Erweitern

Wird das SolarForecast Device gelöscht und anschließend wieder neu mit dem gleichen Namen definiert, können die bisher verfügbaren Daten sehr einfach wiederhergestellt werden:

    1. definieren des neuen SolarForecast Devices und sichern der FHEM Konfiguration
    2. stoppen von FHEM
    3. wiederherstellen der oben beschriebenen Dateien aus einem Backup in das Verzeichnis ../fhem/FHEM/FhemUtils (Überschreiben evtl. vorhandener Dateien)
    4. starten von FHEM (bestimmte Daten werden automatisch importiert)
    5. mit dem Befehl "set <name> plantConfiguration restore" die Anlagenkonfiguration wiederherstellen

LG

[grappa24]

Danke Heiko,

gilt das (nur) für die bisher erfassten Werte oder auch für die Defintion des Device samt seiner Attribute und Readings?

Gruß,
Dieter

[DS_Starter]

Durch das Restore "plantConfiguration restore" werden die eingestellten Konfigurations-Readings und Attribute (Consumer etc.) wiederhergestellt.
Das Device an sich muß zunächst "raw" (Punkt 1) definiert werden damit der Restore ausgeführt werden kann.

Nun hatte ich bei den letzten Releases diverse Readings in Attribute gewandelt. Wenn du immer fleißig upgedated hast, sollte die Sicherung von gestern z.B. passgenau sein.

[oelidoc]

Hallo,
angeregt durch das Beispiel im Wiki

Code Auswählen Erweitern

interruptable=og.bad.wandthermostat:diff-temp:[0-9]\.[0-9]:0.2 würde ich in der derzeitigen kalten Übergangszeit gerne eine Elektroheizung bei Erreichen einer measured-temp eines Homematic Wandthermostat HM-TC-IT-WM-W-EU abschalten und nach Unterschreiten der measured-temp wieder einschalten. Da die Zentralheizung aber schon abgeschaltet ist, steht zur Schonung der Ventile die desired-Temp auf "off". Ich würde daher gerne auf das userReadings diff-temp aus dem Beispiel verzichten und stattdessen eine feste Wunschtemperatur von sagen wir mal 23° mit einer Hysterese von 0.2 vorgeben. Leider habe ich aber keine Ahnung von Regex und Perl und kann das nicht umsetzen.

Code Auswählen Erweitern

interruptable=Thermostat_Arbeitszimmer_Climate:measured-temp:23.0:0.2    ?????Vielleicht kann mir ja jemand den code etwas anpassen?
Vielen Dank
oelidoc

[DS_Starter]

So würde der Consumer ab 23.2 (bis 59.9) abschalten:

Code Auswählen Erweitern

interruptable=Thermostat_Arbeitszimmer_Climate:measured-temp:(2[3-9]|[3-5][0-9])\.[0-9]:0.2

Enschalten würde er unter 23.0.
Ich verwende zur Prüfung der Regex https://regex101.com/. Eine Hysterese muß man natürlich simulieren durch entsprechende Werteeingabe.

Erläuterung zur Selbsthilfe. Der Regex matched (ist wahr) wenn

- die erste Ziffer eine 2 ist UND die zweite Ziffer eine 3 bis 9 gefolgt von einem Punkt und der Ziffer 0-9
  (also 23.0, 23.1 ... 23.9, 24.(0 ... 9), 25..., 26...., 29.9

ODER (durch das '|' bedingt)

- die erste Ziffer eine 3 - 5 ist, die zweite eine 0 - 9 ist gefolgt von einem Punkt und der Ziffer 0-9
  (also 30.0, 30.1...9, 31.0..9, ... 59.9)

Vielleicht ist es dadurch verständlicher.

[oelidoc]

Hallo Heiko,
vielen Dank für den code.

Vielleicht ist es dadurch verständlicher.

ja, so ist es für mich gut verständlich bzw. nachvollziehbar! Leider reichen aber meine Kenntnisse überhaupt nicht aus, sowas selber zu schreiben. Und ich fürchte, ich bin auch zu alt, das noch zu lernen. Ich habe in meiner gesamten akademischen Ausbildung keinen Computer gesehen und mir später am PC alles selber beigebracht. Programmiersprachen sind für mich aber Bücher mit sieben Siegeln geblieben. Alle Versuche, z.B Perl zu verstehen, habe ich frustriert ad acta gelegt. Ich könnte nicht mal sagen, was für eine Sprache du in deinem Beispiel benutzt hast... 
Insofern bin ich dir sehr dankbar, dass du mir den code zur Verfügung stellst und auch noch erklärst. Das ist in Foren nicht immer üblich, oft wird man darauf verwiesen, sich das fehlende Wissen doch selbst anzueignen. Das geht aber m.E. ab einem gewissen Alter, und wenn man anderweitig beruflich und familiär voll beschäftigt ist, nicht mehr so ohne weiteres.

Also: Chapeau und vielen Dank für deine unermüdliche Hilfsbereitschaft und das tolle Modul!

Grüße

oelidoc

[DS_Starter]

Ich könnte nicht mal sagen, was für eine Sprache du in deinem Beispiel benutzt hast...

Naja das ist keine Sprache sondern ein regulärer Ausdruck (Regex). Der ist unabhäbgig von einer Sprache und gilt in Perl als auch in anderen Sprachen.
Ich bin übrigens auch Autodidakt und keinesfalls Programmierer. Also nicht aufgeben, auch kleine Schritte führen irgendwann zum Ziel

Ich habe mir auch mal ein Buch über Reguläre Ausdrücke gekauft um es besser zu verstehen. Bin da auch kein Profi.

LG

[oelidoc]

Bin da auch kein Profi.

Na das nenn ich mal eine gepflegte Untertreibung  

LG
oelidoc

[Jewe]

Hallo,

habe mal mit der Verbrauchersteuerung ein wenig rumgespielt. Meine Idee ist es die Leistung, die ich normalerweise einspeisen würde in einem Getränkekühlschrank zu verbrauchen.

Ich habe jedoch nur ein Balkonkraftwerk mit max. 750W. Die Einspeisung ist auch recht gering und reicht vmtl. nicht wirklich für den Kühlschrank.
Die Einspeisung pro Tag ist ca. 0 bis max. 2KW (Urlaub).

Den Consumer habe ich so eingestellt:

Code Auswählen Erweitern

Steckdose2
icon=fridge
type=other
power=100
mode=can
on=on
off=off
pcurr=power:W:0
auto=automatic
swstate=state:on:off 
etotal=consumption:Wh:0
interruptable=1
locktime=300
Wenn ich das nun beobachte, geht der Kühlschrank ab und zu mal an, aber nur sehr kurz bzw. gleich wieder aus. Machen die Einstellungen Sinn?

Danke, Jens

[DS_Starter]

Machen die Einstellungen Sinn?

In dieser Form vermutlich nicht.
Das "Problem" ist der wahrscheinlich häufig vorhandene/nicht vorhandene Überschuß. Ist der Verbraucher gestartet, unterbricht ein nicht vorhandener Überschuß den Verbraucher sofort und startet ihn erst wieder nach 5 Minuten sofern zu diesem Zeitpunkt Überschuß wieder vorhanden ist.

Ich hätte die Idee power=0 zu setzen um die Schaltung zunächst von einem Überschuß zu entkoppeln. Die Einplanung würde ich mit mintime=SunPath über den gesammten Sonnentag vornehmen lassen.
Dann würde ich swoncond verwenden um das erste Einschalten zu veranlassen, d.h. wenn die in diesem Key angegebene Bedingung erfüllt ist, erfolgt das Starten des Consumers innerhalb der Einplanungszeit. Das könnte das erste Vorhandensein eines Überschusses sein (Reading Current_Surplus).

Damit der nun laufende Kühlschrank nicht bei jeder kleinen Überschußänderung an bzw. ausgeht, würde ich den Key

      interruptable=Device:Reading:Regex[:Hysterese]

verwenden, um den Kühlschrank erst bei Über- bzw. Unterschreiten eines Readingwertes (Differenz zw. Verbrauch und Einspeisung) zu schalten. Die Differenz könnte in einem Userreading aus Current_GridConsumption - Current_GridFeedIn gebildet werden. Ist die Differenz entsprechend hoch, liegt ein Bezug X vor und der Kühlschrank wird über interruptable unterbrochen. Liegt Überschuß vor, d.h. die Differenz ist hinreichend _negativ_, wird der Kühlschrank wieder eingeschaltet.

locktime kann man zusätzlich verwenden. Dann würde ich allerdings locktime=300:300 setzen damit auch nach dem Einschalten ein zu schnelles Ausschalten verhindert wird.

Das alles soll als Anregung dienen. Es gibt viele Kombinationsmöglichkeiten, z.B. Readings mit dem Setter powerTrigger erstellen zu lassen und sie über Consumer Keys auswerten lassen.

[Jewe]

Danke Dir, ich werde mal versuchen das umzusetzen.

[grappa24]

Durch das Restore "plantConfiguration restore" werden die eingestellten Konfigurations-Readings und Attribute (Consumer etc.) wiederhergestellt.
Das Device an sich muß zunächst "raw" (Punkt 1) definiert werden damit der Restore ausgeführt werden kann.

Nun hatte ich bei den letzten Releases diverse Readings in Attribute gewandelt. Wenn du immer fleißig upgedated hast, sollte die Sicherung von gestern z.B. passgenau sein.

Super Heiko,

konnte mein System perfekt auf den Stand vor dem restore zurücksetzen, hat zwar einen Tag gedauert, bis sich die Werte aktualisiert haben, aber jetzt läuft es wieder.

Sonnige Grüße
Dieter

[tomcat.x]

Hallo Heiko,

könntest Du mir bitte noch mal ein paar Fragen beantworten, die mich vielleicht auf der Suche der Ursache für die Abweichungen bei mir helfen?

1. Wenn es heißt "Die automatische Vorhersagekorrektur ist lernend und benötigt Zeit um die Korrekturwerte zu optimieren.", von welcher Zeit reden wir da (ungefähr, Tage, Woche, Monate)? Oder anders gefragt, welcher Zeitraum wird überhaupt berücksichtigt? Optimieren heißt ja, dass die Werte besser werden, aber irgendein Wert sollte nach dem ersten Lauf da sein?

2. Beim Beobachten sind mir die Readings "pvCorrectionFactor_xx" aufgefallen. Bei Nutzung der Automatik sind die nicht ständig gefüllt, richtig? Sie werden täglich bis zur aktuellen Stunde neu eingetragen, die anderen sind jeweils leer (zumindest in der Anzeige)?

   Wenn ich dann so etwas sehe, was bedeutet "Days in range: 1"? Der eine wäre dann der aktuelle Tag und daher der "old Factor" gleich 1. Aber warum und warum so unterschiedlich für verschiedene Stunden?

Code Auswählen Erweitern

nextCycletime                     14:38:00                                                                                       10.06.2024 14:36
nextRadiationAPICall              nach 10.06.2024 14:42:31                                                                       10.06.2024 14:27
pvCorrectionFactor_07             0.59 (automatic - old factor: 1, Sun Alt range: 10, Cloud range: 45, Days in range: 1)         10.06.2024 07:00
pvCorrectionFactor_07_autocalc    done                                                                                           10.06.2024 07:00
pvCorrectionFactor_08             0.57 (automatic - old factor: 1, Sun Alt range: 20, Cloud range: 30, Days in range: 1)         10.06.2024 08:00
pvCorrectionFactor_08_autocalc    done                                                                                           10.06.2024 08:00
pvCorrectionFactor_09             0.44 (automatic - old factor: 0.58, Sun Alt range: 30, Cloud range: 100, Days in range: 5)     10.06.2024 09:00
pvCorrectionFactor_09_autocalc    done                                                                                           10.06.2024 09:00
pvCorrectionFactor_10             0.24 (automatic - old factor: 0.22, Sun Alt range: 35, Cloud range: 00, Days in range: 5)      10.06.2024 10:00
pvCorrectionFactor_10_autocalc    done                                                                                           10.06.2024 10:00
pvCorrectionFactor_11             0.57 (automatic - old factor: 1, Sun Alt range: 45, Cloud range: 10, Days in range: 1)         10.06.2024 11:00
pvCorrectionFactor_11_autocalc    done                                                                                           10.06.2024 11:00
pvCorrectionFactor_12             0.69 (automatic - old factor: 1, Sun Alt range: 55, Cloud range: 75, Days in range: 1)         10.06.2024 12:00
pvCorrectionFactor_12_autocalc    done                                                                                           10.06.2024 12:00
pvCorrectionFactor_13             0.74 (automatic - old factor: 0.72, Sun Alt range: 60, Cloud range: 100, Days in range: 17)    10.06.2024 13:00
pvCorrectionFactor_13_autocalc    done                                                                                           10.06.2024 13:00
pvCorrectionFactor_14             0.93 (automatic - old factor: 0.70, Sun Alt range: 65, Cloud range: 100, Days in range: 4)     10.06.2024 14:00
pvCorrectionFactor_14_autocalc    done                                                                                           10.06.2024 14:00
pvCorrectionFactor_Auto           on_complex_ai                                                                                  10.06.2024 14:36
state                             updated                                                                                        10.06.2024 14:48
3. Bei der Anzeige der Qualität sehe ich jetzt gerade (ca. 15:30) z. B. unter anderem die folgenden Einträge:

Code Auswählen Erweitern

...
Start: 2024-06-13 19:00:00, Quality: 0.73, Factor: 0.79, AI usage: 0 ...
...
Start: 2024-06-14 12:00:00, Quality: -, Factor: 1.00, AI usage: 0 ...
...
Start: 2024-06-14 19:00:00, Quality: -, Factor: 1.00, AI usage: 1 ...
...   Warum kann es für heute einen Korrekturfaktor für eine bestimmte Stunde geben, für morgen aber noch nicht?
   Oder für morgen keinen, obwohl die Stunde heute schon durch ist.
   Und was genau bedeutet der Faktor, ist darin schon der Sonnenstand und die Bewölkung eingeschlossen oder kommt der obendrauf?

Vielen Dank
Thomas

[tpm88]

Kann es sein, dass sich in der aktuellen Version

Code Auswählen Erweitern

76_SolarForecast.pm       28963 2024-06-11 19:54:23Z DS_Starter

ein Memory Leak eingeschlichen hat?

Ich habe gestern ein FHEM-Update durchgeführt, bei dem nur zwei bei mir aktive Module 00_MQTT2_SERVER.pm und 76_SolarForecast.pm aktualisiert wurden. Die Änderung bei 00_MQTT2_SERVER ist nach meinem Verständnis nur eine zusätzliche Log-Ausgabe. Nach dem Ausschlußverfahren bleibt eigentlich nur das SolarForecast Modul.

Meine VM mit FHEM läuft hat 4 GB Hauptspeicher, bis zum FHEM Update gestern waren über Tage konstant ca 1 GB Speicher belegt. In ca 21h seit dem Update gestern hat FHEM heute sämtlichen Hauptspeicher aufgebraucht, bis der OOM kurz nach 18 Uhr zugeschlagen hat (siehe die Anhänge).

Es sind drei SolarForecast Instanzen mit verschiedenen DWD Modellen aktiv.

VG
Tobias