76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[minierm]

ändere mal das "pv=PVALL:kW" in "pv=PVALL:W" ab

Gruß
Christian

Gute Idee, seh ich aber nicht, Tageswerte immer in Watt, Einheit Gesamtwert dynamisch, Daten nach einem Jahr:

Code Auswählen Erweitern

Strom_PV_All_Aktuell
Userreading:
PV_Total monotonic {my $Val = ReadingsNum("MTEC_Station", "data_eRatioGraph_edayTotal", 0);; if (ReadingsVal("MTEC_Station", "data_config_01_unit", 0) eq "kWh") {$Val} else {$Val/1000}}
PV_Total 14403.4

MTEC_Station:
data_config_01_key eTotal
data_config_01_unit kWh
data_eRatioGraph_eDayTotal 14072
data_curve_02_eTotal 10749.7 # Gesamterzeugung

BKW_Total 381.4
Mag sein, daß es in der Anfangs-/Übergangszeit Probleme mit der Einheit gab und deshalb die Summe nicht passt.

[300P]

Tipp:
Wer den alten Wert "Current_BatCharge" (als Summe für alle Ladestati der vorhandenen Batterien) auch zukünftig weiter nutzen möchte:

Legt euch dann selbst ein eigenes (User)reading an    
(ausgehend davon das es wohl max 3 X CurrentBatCharge_XX geben werden wird)

Code Auswählen Erweitern

Für 1 Batterie (mehr gehen aktuell noch nicht)
attr XYXYXYXYXY userReadings Current_BatCharge { ((ReadingsNum($name,"Current_BatCharge_01",0)))/1 }

Zukünftig...
Für 2 Batterien
attr X-2Batterien-X userReadings Current_BatCharge { ((ReadingsNum($name,"Current_BatCharge_01",0)) + (ReadingsNum($name,"Current_BatCharge_02",0)))/2 }

Für 3 Batterien
attr X-2Batterien-X userReadings Current_BatCharge { ((ReadingsNum($name,"Current_BatCharge_01",0)) + (ReadingsNum($name,"Current_BatCharge_02",0)) + (ReadingsNum($name,"Current_BatCharge_03",0)))/3 }
Gruß
300P

[DS_Starter]

Hallo Michael,

Es ist toll, wie engagiert und schnell Du Sachen umsetzt! Bei Breaking Changes - vor allem nicht zwingend notwendigen - hast Du ja mitbekommen, was eine schnelle Umsetzung für Aufregung verursachen kann. Leider gibt es auch keinen guten Mechanismus, um im Modul selbst darüber zu informieren (Warnung bei der Anlagenkonfiguration?)

Ich mache den "Job" hier schon viele Jahre und weiß um die Stolperfallen, gerade bei Umbenennung von Readings.
Manchmal muß ich den Schmerz bzw. Shitstorm einfach mal ertragen und eine Änderung machen die ich nicht ständig weiter mitschleppe, zuviel liegt noch vor mir. Und, wie gesagt, ich mache ja hier alles im Vorfeld und auch im Update-Text transparent. 

Hm, eigentlich alle summierbaren Werte im Sinne einer Gesamtübersicht:
* Current_BatCharge -> Current_BatCharge_XX
* Current_PowerBatOut -> Current_PowerBatOut_XX
* Current_PowerBatIn -> Current_PowerBatIn_XX
* Today_HourXX_BatIn -> Today_HourXX_BatIn_XX
* Today_HourXX_BatOut -> Today_HourXX_BatOut_XX

Wenn es den Bedarf gibt, kann ich diese Summen über die jetzigen special_-Readings problemlos bereitstellen.
Das mache ich aber erst wenn sich jemand mit dem Wunsch meldet. Die Implementierung ist dann aber recht zügig erledigt. Mache ich gerne bei Bedarf.

Btw: Die Benennung ist etwas inkonsistent:
* Current_BatCharge vs Current_PowerBatOut und Today_HourXX_BatOut
Kommt "Bat" jetzt zuerst oder zum Schluß? Mit oder ohne Power?
-> Current_BatPowerOut und Today_HourXX_BatPowerOut
(analog für In)

Da gibt es sicherlich Dinge die man nach den Jahren der Entwicklung angleichen könnte.
Allerdings ist Current_BatPowerOut und Today_HourXX_BatPowerOut genau richtig. Hier liegt der Sinn darin den gesamten Block der Today_HourXX_.*-Readings nach Stunden sortiert in der Detailansicht zu haben.
Diese Sortierung ist ein erhebliches Kriterium für die Bennennung -> hilft bei der Übersicht bei so vielen Readings.

Wenn das verwendete Modul AI nicht unterstützt ist klar das AI nicht verwendet wird. Und welches Modul wird denn verwendet? Könnte man noch erwähnen (Bei mir: SolCastAPI). Und wie man AI aktiviert (Welches Attribut).

Nicht "Modul" sondern "Model".
Welches Model aktuell verwendet wird steht im Kopf/Überschrift der Prüfung, z.B.  "Informationen zur Anlagenkonfigurationsprüfung - Model: DWD"
Ob man AI-Unterstützung verwenden kann hängt vom Model ab und wird bei einem entsprechend verwendeten Model im Setter pvCorrectionFactor_Auto angeboten.
Da kann ich höchstens mal auf das Wiki verweisen wenn ich soweit bin es beschrieben zu haben.

Ich habe kein Attribut forecastRefresh, nur forecastResolution ("Time resolution (number of hours between 2 samples)." mit dem Wert "1".

Nimm das DWD-Modul aus meinem contrib. Leider wurde diese Weiterentwicklung vom DWD Maintainer bisher nicht eingecheckt obwohl sie bereits schon sicherlich 9 Monate bereit steht und aktiv genutzt wird.
Sehr ärgerlich...

Wenn du etwas mehr dazu lesen möchtest wäre wahrscheinlich hier ein passender Aufsetzpunkt.

LG,
Heiko

[DS_Starter]

@300P

(ausgehend davon das es wohl max 3 X CurrentBatCharge_XX geben werden wird)

Wie kommst du darauf? 

[300P]

Du darfst diesen Dateianhang nicht ansehen.

[DS_Starter]

  
Bei den XX-Geräten gehe ich im Ansatz tatsächlich mit dem Startwert "3" in die Konfiguration, da ich glaube dass er meistens reichen wird.
Der Wert kann bei Bedarf aber angepasst werden ... nur zur Erläuterung.

[300P]

Userreadings sind "sehr geduldig"...

[DS_Starter]

Das Multi Batterie System wird übrigens in Kürze verfügbar sein denke ich. Habe heute den ganzen Tag weiter daran gearbeitet und getestet.
Wenn alles klappt, kann man sich die Stunden mit dem zukünftigen "Battery_ChargeRecommended" - Wert in der Grafik einblenden. Dann hat man einen Überblick wann das System diese Empfehlung geben wird. Ich denke das hilft ein gewisses Gefühl der Sicherheit, der Transparenz und des Vertrauens in die Entscheidungen zu bekommen.

[heramol]

Hallo Heiko,
vorweg danke für das tolle Modul

Jetzt zum "Problem". Seit dem letzten update wird hier wohl nicht mehr gerundet. Kann man das irgendwo einstellen, oder kommt da noch eine Anpassung. Anbei die Grafik mit Markierung.

VG Tom

[cwagner]

In meiner ConfigDB fand ich eine große Zahl (~500~) Dateien der Art './FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau.*'
Eine Durchsicht der Attribute zeigte mir keine Option etwas einzustellen, zum Beispiel eine Haltezeit.

• Wofür dienen diese Dateien?
• Kann ich die unbesorgt löschen, ohne z.B. das AI-Lernen zu beschädigen?
• Vielen Dank für zweckdienliche Antwort im

Voraus

Christian

[kask]

ctrlBackupFilesKeep? Haben die Dateien ein Datum am Ende des Namens?

[DS_Starter]

@Tom,

Jetzt zum "Problem". Seit dem letzten update wird hier wohl nicht mehr gerundet. Kann man das irgendwo einstellen, oder kommt da noch eine Anpassung. Anbei die Grafik mit Markierung.

Ja, das kann sein. Danke für die Info. Ist bei mir nicht aufgefallen. Richte ich mit der kommenden Version.

@Christian,

Wofür dienen diese Dateien?

Das ist die Sicherung des internen Ringspeichers. Siehe Wiki. Die Datei ist sehr wertvoll für die Funktion, besonders je länger die Laufzeit des Moduls ist.
Es sollte immer ein zeitnahes Backup vorhanden sein.

Kann ich die unbesorgt löschen, ohne z.B. das AI-Lernen zu beschädigen?

Zumindest ältere Dateien kannst du löschen. Die Datei wird regelmäßig neu geschrieben. Von einer aktuellen Version sollte es immer ein Backup geben.

Wie kask schon erwähnt hat, gibt es auch Sicherungen der Sicherungsdateien um ältere Versionen wieder herstellen zu können.
Das erwähnte ctrlBackupFilesKeep (Anzahl der Sicherungsdatei-Sicherungen) wird vermutlich nicht für configDB funktionieren weil hier über die Verzeichnisebene gearbeitet wird.
Möglicherweise gibt es in configDB eine Einstellung um die max. Anzahl der in der DB gespeicherten Versionen einer Datei festzulegen. Kann ich aber nicht sagen.

LG,
Heiko

[cwagner]

Danke für die schnellen Antworten:
@kask: Dieses CTRL habe ich nicht angerührt - es heißt in der CommandRef ja, dass der Default 3 sei. Heißt ich hätte erwartet, dass wenn diese Dateien durch da erwähnte und entsprechend eingestellte set <name> operatingMemory backup entstehen, nur drei existieren sollten.

@DS_Starter: Die Dateien tragen den Zeitstempel kurz nach Mitternacht: Hier Beispiele für die jüngsten:

Code Auswählen Erweitern

./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2024_12_25_00_09_23
./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2024_12_26_00_09_01
./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2024_12_27_00_09_51
./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2024_12_28_00_09_21
./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2024_12_29_00_10_00
./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2024_12_30_00_09_40
./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2024_12_31_00_09_40
./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2025_01_01_00_09_20
./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2025_01_02_00_09_41
./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2025_01_03_00_09_50
./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2025_01_04_00_09_59
./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2025_01_05_00_10_01
Ich werde jetzt mal das Attribut ctrlBackupFilesKeep jetzt mal auf 5 setzen und dann beobachten, ob sich etwas ändert.

Christian

[DS_Starter]

Das sind die Sicherungsdatei-Sicherungen, erkennbar an dem Zeitstempel am Ende des Namens. Sie werden kurz nach Mitternacht geschrieben.
Wie vermutet wird ctrlBackupFilesKeep bei configDB nicht funktionieren, d.h. auch der default 3 nicht.
Das SF Modul kann nicht (und will auch nicht) in configDB "hineingreifen".

In einem Filesystem würden per default nur dieses Dateien für ein mögl. Restore übrigbleiben:

Code Auswählen Erweitern

./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2025_01_03_00_09_50
./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2025_01_04_00_09_59
./FHEM/FhemUtils/PVC_SolarForecast_SolarVorschau_2025_01_05_00_10_01

Da es sich immer um eine unikate Datei handelt, wird configDB vermutlich kein automatisches Housekeeping anbieten.
Abhilfe könnte sein, dass ich für Nutzer von configDB diese regelmäßigen Sicherungsdatei-Sicherungen nicht erstellen lasse da eine Versionierung von PVC_SolarForecast_SolarVorschau bereits durch configDB gegeben ist?

Vermutlich hast du auch keine Auswahlliste beim Befehl:

Code Auswählen Erweitern

set ... operatingMemory recover-PVC....
?

Ggf. hast du als configDB eigene Housekeeping Möglichkeiten um alte Versionen automatisch zu löschen?

[minierm]

Ich mache den "Job" hier schon viele Jahre und weiß um die Stolperfallen, gerade bei Umbenennung von Readings.
Manchmal muß ich den Schmerz bzw. Shitstorm einfach mal ertragen und eine Änderung machen die ich nicht ständig weiter mitschleppe, zuviel liegt noch vor mir. Und, wie gesagt, ich mache ja hier alles im Vorfeld und auch im Update-Text transparent. 

Wer liest schon Update-Texte
Ja, du kommunizierst die Änderungen hier sehr transparent. Man muss halt nur am Ball bleiben.

Hm, eigentlich alle summierbaren Werte im Sinne einer Gesamtübersicht:
* Current_BatCharge -> Current_BatCharge_XX
* Current_PowerBatOut -> Current_PowerBatOut_XX
* Current_PowerBatIn -> Current_PowerBatIn_XX
* Today_HourXX_BatIn -> Today_HourXX_BatIn_XX
* Today_HourXX_BatOut -> Today_HourXX_BatOut_XX

Wenn es den Bedarf gibt, kann ich diese Summen über die jetzigen special_-Readings problemlos bereitstellen.
Das mache ich aber erst wenn sich jemand mit dem Wunsch meldet. Die Implementierung ist dann aber recht zügig erledigt. Mache ich gerne bei Bedarf.

Bevor sich da groß Bedarf meldet werden die bedürtigen User doch schnell eigene Userreadings erstellt haben...

Btw: Die Benennung ist etwas inkonsistent:
* Current_BatCharge vs Current_PowerBatOut und Today_HourXX_BatOut
Kommt "Bat" jetzt zuerst oder zum Schluß? Mit oder ohne Power?
-> Current_BatPowerOut und Today_HourXX_BatPowerOut
(analog für In)

Da gibt es sicherlich Dinge die man nach den Jahren der Entwicklung angleichen könnte.
Allerdings ist Current_BatPowerOut und Today_HourXX_BatPowerOut genau richtig. Hier liegt der Sinn darin den gesamten Block der Today_HourXX_.*-Readings nach Stunden sortiert in der Detailansicht zu haben.
Diese Sortierung ist ein erhebliches Kriterium für die Bennennung -> hilft bei der Übersicht bei so vielen Readings.

Vorsicht, es ging nur um den hinteren Teil mit "PowerBatOut" und "BatOut" in konsistent "BatPowerOut": <Device><Type><Direction>.
Du hast es ja schon selber richtig geschrieben

Wenn das verwendete Modul AI nicht unterstützt ist klar das AI nicht verwendet wird. Und welches Modul wird denn verwendet? Könnte man noch erwähnen (Bei mir: SolCastAPI). Und wie man AI aktiviert (Welches Attribut).

Nicht "Modul" sondern "Model".
Welches Model aktuell verwendet wird steht im Kopf/Überschrift der Prüfung, z.B.  "Informationen zur Anlagenkonfigurationsprüfung - Model: DWD"
Ob man AI-Unterstützung verwenden kann hängt vom Model ab und wird bei einem entsprechend verwendeten Model im Setter pvCorrectionFactor_Auto angeboten.
Da kann ich höchstens mal auf das Wiki verweisen wenn ich soweit bin es beschrieben zu haben.

Ja Model (SolCastAPI), in dem Hinweistext steht aber mehr "Modul"
Der Titel ist da schon soweit weg, aber passt.
Ein Link darauf, wie man auf einen Hinweis reagieren kann, wär schon toll.

Ich habe kein Attribut forecastRefresh, nur forecastResolution ("Time resolution (number of hours between 2 samples)." mit dem Wert "1".

Nimm das DWD-Modul aus meinem contrib. Leider wurde diese Weiterentwicklung vom DWD Maintainer bisher nicht eingecheckt obwohl sie bereits schon sicherlich 9 Monate bereit steht und aktiv genutzt wird.
Sehr ärgerlich...

Wenn du etwas mehr dazu lesen möchtest wäre wahrscheinlich hier ein passender Aufsetzpunkt.

[/quote]
Danke, werde ich machen. Ich hab mir zum Glück im Kommentar gemerkt, wie man Contrib einbindet
("wget -qO ./FHEM/55_DWD_OpenData.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/55_DWD_OpenData.pm") - hat funktioniert, aufgrund der SD-Card Warnung werd ich MOSMIX S wohl nicht aktivieren.
Es ist aber unglücklich, auf nicht offizielle Contribs zu verweisen. Typisches FOSS Problem mit der Maintenance

LG Michael
(Norddeutscher in der Nebel- und Sonnenhauptstadt Ulm, wie man an DWDUlm erraten konnte)