76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Hallo Christian,

ja es gibt einige Bibliotheken.
Im Modul setze ich zur Zeit AI::DecisionTree ein. Es ist gut handhabbar mit dem Nachteil keine diskreten Werte verarbeiten zu können. Man muss sie ggf. vorher in "bins" kategorisieren. Interessant ist auch Algorithm::DecisionTree was ich mir noch anschauen möchte.
Dann habe ich noch AI::MXNet was den Zugang zum Apache MXNet herstellt und wohl am leistungsfähigsten anzusehen ist.

Zu AI::General habe ich keinen Zugang gefunden. Es wäre noch AI::TensorFlow, AI::FANN oder AI::Perceptron zu nennen.
Wie gut die Bibliotheken in unseren Anwendungsfall passen, kann ich dir nicht sagen. Bis jetzt fand ich nur die Zeit mich näher mit AI::DecisionTree zu befassen.

Im KI Umfeld ist Python eigentlich eher das Mittel der Wahl, aber ich selbst bleibe auch lieber monolithisch. Das wird mir sonst einfach too much.

Grüße,
Heiko

[Prof. Dr. Peter Henning]

Gibt es denn ein Perl-Binding von dem zentralen TensorFlow? Ich denke, eher nicht.

LG

pah

[DS_Starter]

Hallo pah,

ich bewege mich jetzt auf dünnem Eis    ...
Wenn ich mir die Quickstart-Doku anschaue https://metacpan.org/dist/AI-TensorFlow-Libtensorflow/view/lib/AI/TensorFlow/Libtensorflow/Manual/Quickstart.pod
dann verweist man dort im Verlauf auch direkt auf die TensorFlow home page. Dort wiederum unter API wird Perl mit Verweis auf genau die AI::TensorFlow::Libtensorflow Lib erwähnt.

Meintest du das mit "zentralen TensorFlow"?

Und AI::TensorFlow::Libtensorflow ist sogar recht aktuell (2023).

LG,
Heiko

[ch.eick]

Okay, danke für die Info.
Ich bleib beim Python, was ich bereits mit diversen Meldungen ins FHEM gekoppelt habe.

VG Christian

[Prof. Dr. Peter Henning]

@DS_Starter: I stand corrected, gibt es offenbar doch.

LG

pah

[Ingo298]

Hallo zusammen,
ich habe folgendes Problem. Ich benutze das Model DWD, wenn ich nun die pvCorrectionFactor_Auto auf on_complex(_ai) umstelle
startet mein FHEM neu. In der LOG finde ich nur den den Eintrag: Illegal division by zero at ./FHEM/76_SolarForecast.pm line 6546.
Kann das jemand replizieren? Diese passiert dann auch zu jeden vollen Stunde.

LG Ingo 

[DS_Starter]

Moin Ingo,

das ist ein Fehler den ich abfabgen muß.
Er kommt zum Tragen wenn in der Kombination einer "normalen" PV Erwartung von 0 in Verbindung mit einem AI Hit eine Kalkulation erfolgen muß.
Das werde ich mit dem kommenden Relaese fixen oder evtl. heute Abend als Reparatur über mein contrib bereitstellen.
Verzichte einstweilen auf die Umschaltung ai.

Edit: Führe aber bitte noch eine Anlagenprüfung durch (set ... plantConfig check)

LG,
Heiko

[Ingo298]

Moin Ingo,

das ist ein Fehler den ich abfabgen muß.
Er kommt zum Tragen wenn in der Kombination einer "normalen" PV Erwartung von 0 in Verbindung mit einem AI Hit eine Kalkulation erfolgen muß.
Das werde ich mit dem kommenden Relaese fixen oder evtl. heute Abend als Reparatur über mein contrib bereitstellen.
Verzichte einstweilen auf die Umschaltung ai.

Edit: Führe aber bitte noch eine Anlagenprüfung durch (set ... plantConfig check)

LG,
Heiko

Danke für die Info, plantConfig check hatte ich im Vorfeld schon ausgeführt dabei waren keine Fehler oder Hinweise aufgetaucht.

[DS_Starter]

Hallo Ingo,

du kannst dir die gefixte Version 1.16.2 aus meinem contrib herunterladen und Restart nicht vergessen!

Edit: In der Version sind schon Weiterentwicklungen enthalten. Setze in dem verwendeten DWD Wetterdevice im Attribut forecastProperties die Eigenschaft "RR1c" nach dem Update. Dafür kannst du R101 löschen.

LG

[DS_Starter]

Hallo zusammen,

in meinem contrib liegt eine weiterentwicklte Version von 55_DWD_OpenData.
Diese Version besitzt das Attribut forecastDataPrecision zur Umschaltung auf die Nutzung von MOSMIX_S. Diese Werte werden jede Stunde vom DWD upgedated gegenüber alle 6 Stunden im Standard MOSMIX_L.

Weitere Infos zum Fortgang findet ihr hier: https://forum.fhem.de/index.php?msg=1304074

Ungeachtet weiterer Optimierungen könnt ihr die V aus meinem contrib einsetzen und nach Download/Restart das Attribut forecastDataPrecision auf "high" stellen. Fügt dann bitte im Attribut forecastProperties den Wert "RR1c" noch hinzu. Das gilt generell für die DWD Devices die ihr für SolarForecast verwendet.

Mit dem nächsten Update von SolarForecast (vermutlich Donnerstag) wird die Nutzung von R101 auf RR1c umgestellt.

LG,
Heiko

[Ingo298]

Danke schön, jetzt funktioniert es

[DS_Starter]

Hallo zusammen,

wie angekündigt, wird morgen früh ein Update ausgeliefert.
Neben einigen internen Codechanges wird in den DWD Devices die Nutzung von R101 auf RR1c umgestellt.

In allen beteiligten DWD Devices setzt bitte im Attribut forecastProperties RR1c statt R101.

RR1c kann natürlich auch zusätzlich eingetragen werden.
Die Eigenschaft wird auch geprüft und im plantConfigcheck überwacht. Ebenso erfolgt eine Anzeige in der GUI falls der Rad1h (Globalstrahlung) Wert älter als 2 Stunden ist. Die Anzeige wird in diesem Fall gelb statt grün.
Wenn ihr das neue DWD_OpenData Modul aus meinem contrib nutzt, stellt forecastDataPrecision auf "high". Im herkömmlichen DWD_OpenData erfolgt das Update der Wetterwerte nur alle 6 Stunden durch den DWD. Die GUI Anzeige wird dann fast immer auf "gelb" stehen.
Das ist natürlich nicht schädlich und entspricht dem bisherigen Verhalten. Aber um schnelle Wetteränderungen mitzubekommen ist das DWD_OpenData Modul aus meinem contrib hilfreich.

LG,
Heiko

[300P]

Guten Morgen!

das sieht erst einmal gut aus:

[Prof. Dr. Peter Henning]

Ich habe da so einen Wunsch...

Die Komplexität des Moduls ist inzwischen so hoch, dass ich etwas zurückhaltend mit der Integration in meine FHEM-Hauptserver bin. Auch verhindert diese Komplexität, dass Einfachnutzer oder Anfänger es installieren.

Es wäre schön, wenn man das Ganze auf einen eigenen Raspberry Pi auslagern könnte. Dafür bräuchten wir natürlich Mechanismen, mit denen dieser SolarServer aus anderen FHEM-Instanzen die notwendigen Daten erhält. Das geht eigentlich mit FHEM2FHEM ganz gut, solche "ausgelagerten Subsysteme" betreibe ich schon mehrfach. Es besteht aber auch die Möglichkeit, das einfach über REST von anderen System zu holen.

Das hätte noch einen weiteren Bonus in sich: Man könnte eine komplette virtuelle Maschine zur Verfügung stellen, die alle notwendigen Softwarekomponenten beinhaltet. Und, das ist der Punkt, auch ganz unabhängig von einer Hausautomation laufen würde.

Nun ist das ja mit Wünsche so eine Sache: Man muss schon etwas dafür tun. Werde ich, mal sehen, ob das in die Richtung zu entwickeln ist.

LG

pah

[ch.eick]

Darüber hinaus hätte ich gerne Prognose und Steuerung, sowie gerne auch die Visualisierung getrennt.
Ja, ich weiß, das habe ich bereits geschrieben, aber es scheint ja neuen Wind zu geben
VG Christian