76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Hallo erwin,

danke, habe es eingebaut. Wird noch eingecheckt.

notifyRegexpChanged kenne ich, kann man aber hier nicht verwenden.
Problem ist, dass notifyRegexpChanged prüft ob $defs{<name>} vorhanden ist. Werden die Consumer Devices erst später in der Define Reihenfolge angelegt, ist $defs{<name>} nicht vorhanden und NOTIFYDEV wird gelöscht.
Das ist dann nicht zielführend. Deswegen habe ich NOTIFYDEV diskret aufgebaut.

Grüße,
Heiko

[TheTrumpeter]

Mal etwas Off-topic... wär's möglich die stündlichen Strombezugspreise irgendwo in der Grafik einzublenden, vielleicht jeweils unter den Balken mit der stündlichen Vorhersage?
Dann hätte man die Übersicht auf einen Blick wann es sich ggf. lohnt Hochstromverbraucher trotz geringer PV-Leistung manuell einzuschalten.

[DS_Starter]

Moin,

möglich ist das sicherlich.
Es steht zunächst aber die generelle Frage im Raum woher die Daten bezogen werden sollen/können?

Ihr kennt ja inzwischen die Modularchitektur. Eine Datenquelle wird über ihren Namen und die relevanten Readingstrukturen bei SolarForecast registriert. Diese Daten können dann verarbeitet und bei Bedarf in irgendeiner Weise visualisiert werden.

LG

[TheTrumpeter]

Ihr kennt ja inzwischen die Modularchitektur. Eine Datenquelle wird über ihren Namen und die relevanten Readingstrukturen bei SolarForecast registriert. Diese Daten können dann verarbeitet und bei Bedarf in irgendeiner Weise visualisiert werden.

Genau, sind aus meiner Sicht 2 unterschiedliche Themen:
1. SolarForecast muss die Möglichkeit schaffen eine solche Datenquelle zu registrieren. Jeder der einen stündlich variablen Stromtarif hat, hat vmtl. bereits ein Gerät, das die Daten bereitstellt. Diese Daten in die von SolarForecast dann vorgegebene Syntax zu bringen, sollte nicht schwer sein, haben wir bei den übrigen Daten bisher auch geschafft.
2. Die Grafik muss erweitert werden, dass sie die Daten auch anzeigt, so wie jetzt z.B. schon die stündliche Wetter-/PV-Vorhersage bzw. die Ist-Werte.

In weiterer Folge könnte - bei Vorhandensein dieser Daten - die Planung der Verbraucher zusätzlich die Bezugspreise berücksichtigen.

[dkreutz]

Für die stündlichen Strompreise von AWATTAR könnte das hier hilfreich sein:
https://wiki.fhem.de/wiki/AWATTar_-_Virtueller_Stromkunde

[DS_Starter]

Da ich AWATTAR nicht habe... kann jemand von euch ein Beispiel eines "lebenden" AWATTAR Devices? Ich bräuchte eine Vorstellung der vorhandenenen Readingsstruktur.

[ch.eick]

Für die stündlichen Strompreise von AWATTAR könnte das hier hilfreich sein:
https://wiki.fhem.de/wiki/AWATTar_-_Virtueller_Stromkunde

Im aWATTar und Tibber Thread gibt es auch eine Implementierung von mir, die als RAW Device in meinem contrib ch.eick zu finden sind. Beide Devices verwenden soweit möglich die gleiche readings Struktur. Für EVU_Tibber_connect gibt es zur Visualisierung auch ein EVU_Tibber Device.

VG Christian

[ch.eick]

Da ich AWATTAR nicht habe... kann jemand von euch ein Beispiel eines "lebenden" AWATTAR Devices? Ich bräuchte eine Vorstellung der vorhandenenen Readingsstruktur.

Beim aWATTar werden eigentlich nur die Preise aufbereitet. Bei Tibber bekommt man nur die Preise, wenn man Kunde ist.

VG Christian

[ch.eick]

Ich nochmal,
beide Devices verwenden jedoch in den userreadings eine DbLog , was hier im Thread ja vermieden werden soll.

[TheTrumpeter]

Da ich AWATTAR nicht habe... kann jemand von euch ein Beispiel eines "lebenden" AWATTAR Devices? Ich bräuchte eine Vorstellung der vorhandenenen Readingsstruktur.

Ich verwende das von ch.eick angepasst an meinen Stromlieferanten, die Readings schauen so aus:

fc0_00_total    0.0901    2024-03-13 00:00:02
fc0_01_total    0.0878    2024-03-13 00:00:02
fc0_02_total    0.0869    2024-03-13 00:00:02
fc0_03_total    0.0862    2024-03-13 00:00:02
fc0_04_total    0.0889    2024-03-13 00:00:02
fc0_05_total    0.0947    2024-03-13 00:00:02
fc0_06_total    0.1087    2024-03-13 00:00:02
fc0_07_total    0.1222    2024-03-13 00:00:02
fc0_08_total    0.1240    2024-03-13 00:00:02
fc0_09_total    0.1075    2024-03-13 00:00:02
fc0_10_total    0.0960    2024-03-13 00:00:02
fc0_11_total    0.0922    2024-03-13 00:00:02
fc0_12_total    0.0911    2024-03-13 00:00:02
fc0_13_total    0.0912    2024-03-13 00:00:02
fc0_14_total    0.0935    2024-03-13 00:00:02
fc0_15_total    0.0984    2024-03-13 00:00:02
fc0_16_total    0.1054    2024-03-13 00:00:02
fc0_17_total    0.1228    2024-03-13 00:00:02
fc0_18_total    0.1338    2024-03-13 00:00:02
fc0_19_total    0.1338    2024-03-13 00:00:02
fc0_20_total    0.1145    2024-03-13 00:00:02
fc0_21_total    0.1012    2024-03-13 00:00:02
fc0_22_total    0.0972    2024-03-13 00:00:02
fc0_23_total    0.0911    2024-03-13 00:00:02


fc[Tag-relativ]_[Stunde-absolut]_total
fc0_10_total gibt also den Preis des aktuellen Tags von 10-11 Uhr an.

[300P]

Warum in einem Modul alles ?


Aber es ja schon ganz einfach, nur an andere Stelle wie folgt:

Mittels der bestehenden Module für Tibber und Awattar ein Device seiner Wahl anlegen.(Bei mir ist es ein Device mit Namen myTibber)

Einfach im Attribut (von Solarforecast) graphicHeaderOwnspec nur noch zusätzlich eintragen:


Strompreis&nbsp;€:Strompreis@myTibber

PS:
Das ist der wirkliche aktuelle Stundenpreis inkl. MwSt. im März 24 für Neukunden im ersten Monat....😉

[DS_Starter]

eide Devices verwenden jedoch in den userreadings eine DbLog , was hier im Thread ja vermieden werden soll.

Eine "Datenbank" gibt es hier auch, aber keine SQL. 

Ich verwende das von ch.eick angepasst an meinen Stromlieferanten, die Readings schauen so aus:

Da hat sich Chritian an die DWD Struktur angelehnt. Sieht gut und praktikabel aus.

300P hat auch noch einen sehr guten Ansatz gepostet.
Nun kann ich mir vorstellen, dass es reizvoll ist in der grafischen Vorhersage auch die zukünftigen Bezugspreise fcx_xx_total abgetragen zu sehen (wenn man es wünscht).
Neben der visuellen Aufbereitung könnten sich Synergien bei der Einplanung von Cosumern höherer Leistung ergeben wenn man solche Daten zur Verfügung hat und berücksichtigen kann.

Wieder ein spannendes Thema.
Wie verarbeitet ihr diese Daten zur Zeit? Mal abgesehen von dem reinen Informationsaspekt.

LG

[ch.eick]

< snip >
Nun kann ich mir vorstellen, dass es reizvoll ist in der grafischen Vorhersage auch die zukünftigen Bezugspreise fcx_xx_total abgetragen zu sehen (wenn man es wünscht).
Neben der visuellen Aufbereitung könnten sich Synergien bei der Einplanung von Cosumern höherer Leistung ergeben wenn man solche Daten zur Verfügung hat und berücksichtigen kann.

Wieder ein spannendes Thema.
Wie verarbeitet ihr diese Daten zur Zeit? Mal abgesehen von dem reinen Informationsaspekt.

Die Anlehnung ans DWD Device ist nicht zufällig, da ich so gleiche SQL SELECTS und gleiche Mechanismen verwenden kann.
Meine Darstellung des Triggers erfolgt im Grafana als On/Off, sodass man schön die Zeiten sehen kann, in denen gespart werden könnte.

Ich verwende, obwohl ich auch keine Börsenpreise habe, den Trigger und starte z.B. im Winter, wenn ich eh aus dem Netz beziehen muss einige Geräte zum Trigger Fenster.
Die E-Auto Fahrer laden mit dem Trigger Ihre Fahrzeuge.
Bei Tibber bekommt man zusätzlich noch die aufgelaufenen Kosten und die live Messwerte vom Tibber Pulse Lesekopf. Das läuft für die Kunden über eine Websocket Verbindung die innerhalb der userreadings aufgebaut wird.

Ich arbeite immer mal wiedere daran, dass die Börsen Devices vom Aufbau gleich erscheinen, damit man einfacher hin und her switchen kann.

VG   Christian

[TheTrumpeter]

Nun kann ich mir vorstellen, dass es reizvoll ist in der grafischen Vorhersage auch die zukünftigen Bezugspreise fcx_xx_total abgetragen zu sehen (wenn man es wünscht).

Genau darum geht's. Nur den aktuellen Preis zu sehen hat keinerlei Mehrwert für die (automatische oder manuelle) Verbrauchsplanung.

Synergien bei der Einplanung von Cosumern höherer Leistung ergeben wenn man solche Daten zur Verfügung hat und berücksichtigen kann.

Genau was ich oben angeregt habe

Wie verarbeitet ihr diese Daten zur Zeit? Mal abgesehen von dem reinen Informationsaspekt.

Derzeit noch kaum, weil ich erst seit 2 Wochen den variablen Tarif habe.
Mit dem alten Tarif war's immer besser, den PV-Eigenverbrauch zu optimieren, d.h. der größte Verbraucher (Wärmepumpe für Heizung und Warmwasser) ist ohnehin nur tagsüber gelaufen.
Mit dem neuen Tarif könnte es Situationen geben, in denen es günstiger wäre den Verbrauch zu einem Zeitpunkt eines niedrigen Bezugstarifs trotz fehlender PV-Abdeckung zu legen. Mit der Visualisierung könnte ich das zumindest mal händisch machen.

[Dracolein]

Guten Morgen,

oh je, da bist aber wirklich weit hinterher. Inzwischen ist das Modul ofiziell eingescheckt und wir sind Stand heute bei der Version v1.16.6 angekommen.
Manuelles Update ist nicht mehr nötig.

Es ist natürlich sehr viel passiert in der Zwischenzeit.
EIn Update sollte funktionieren. Dabei werden vermutlich viele Meldungen kommen, die zunächst mal ignorieren. Wenn das Device noch lebt einen "set ... plantConfiguration check" ausführen und schauen was da kommt.

Zum DWD gibt es eine optionale Entwicklungsversion in meinem contrib. Damit kann mit forecastRefresh=1 eine höhere Updategenauigkeit (MOSMIX_S) erreicht werden. Näheres dazu im DWD Thread.
Grüße,
Heiko

update all...
shutdown restart...

Logfile:

2024.03.13 09:55:03 1: PVVorschau - ERROR - consumer >04< use >mintime=SunPath< but readings >Today_SunRise< / >Today_SunSet< are not set properly.
2024.03.13 09:55:03 1: PERL WARNING: Argument "SunPath" isn't numeric in division (/) at ./FHEM/76_SolarForecast.pm line 8128.
2024.03.13 09:55:03 1: PVVorschau - ERROR - consumer >05< use >mintime=SunPath< but readings >Today_SunRise< / >Today_SunSet< are not set properly.
2024.03.13 09:55:03 1: PVVorschau - ERROR - consumer >06< use >mintime=SunPath< but readings >Today_SunRise< / >Today_SunSet< are not set properly.

Modulübersicht war "weg", wurde aber sehr gut durch die Benutzerführung erklärt --> Wettervorhersage Device fehlte --> korrigiert.

Erneutes set plantConfigurationCheck check...
alles gut (FTUI2 = tangiert mich nicht)

The selected SolarForecast model cannot use AI support.

Gibts inzwischen empfehlenswertere Möglichkeiten des Moduls ? (ich suche nach den Begriffen hier im Forum, wenn ich weiß wonach ich suchen soll)