76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Parallix]

Und das kann ja eigentlich weder negativ noch >100% werden, oder?

Wenn alles richtig eingegeben wurde nicht.

Da die in SF berechneten Werte ggf. ja von weitere Software-Instanzen genutzt und zu Aktionen führen können, bin ich - nach wie vor - der Ansicht, dass SF (und natürlich auch andere Module) keine Readings nach außen tragen sollten, die außerhalb des zu erwartenden Bereichs eines jeden Readings liegen. Signalisierungen über vermeintliche Fehlkonfigurationen sollten - nach meiner Ansicht - über geeignetere Mechanismen, wie wohldokumentierte ,,Notification, Warning & Error Masks" erfolgen, die ggf. von User explizit gelöscht werden müssen.

Stell Dir nur mal vor, der Fall SOC < 0 taucht für eine lange Zeit nicht auf, aber - wie der Zufall es so will - zu einem Zeitpunkt an dem der User der Anlage für mehrere Stunden, Tage oder gar Wochen verhindert ist aktiv in die Anlage einzugreifen. Aufgrund des von SF falsch, weil  (semantisch) nicht definierten  Werts, finden dann in anderen Software-Instanzen möglicherweise Aktionen statt, die nicht nur vom User unerwünscht, sondern vielleicht sogar schädlich für die Anlage sind.

Um dies schon im Ansatz zu verhindern, sollten daher für Readings eigentlich Definitionsbereiche festgelegt werden, in dessen Grenzen sich die Readingwerte bewegen dürfen. Wenn eine derartige Begrenzung (nach oben und unten) nicht möglich oder nicht gewollt ist, dann sollte dies in der Beschreibung von SF sehr deutlich klar kommuniziert werden.

[DS_Starter]

Da die in SF berechneten Werte ggf. ja von weitere Software-Instanzen genutzt und zu Aktionen führen können, bin ich - nach wie vor - der Ansicht, dass SF (und natürlich auch andere Module) keine Readings nach außen tragen sollten, die außerhalb des zu erwartenden Bereichs eines jeden Readings liegen. Signalisierungen über vermeintliche Fehlkonfigurationen sollten - nach meiner Ansicht - über geeignetere Mechanismen, wie wohldokumentierte ,,Notification, Warning & Error Masks" erfolgen, die ggf. von User explizit gelöscht werden müssen.

Den gleichen Anspruch habe ich eigentlich auch an die an SF gelieferten Input-Parameter und Werte. 
Leider kann ich mich nicht darauf verlassen und prüfe deswegen, sofern machbar, deren Sinnhaftigkeit.
Eine nachfolgende Verarbeitung kann/sollte das auch tun.

Dennoch versuche ich diversen Komfort zu bieten.
Du hast gerade eine Anregung gegeben. Das neue Mitteilungssystem kann ich evtl. auch dazu benutzen, z.B. direkt Inhalte der Readings Battery_NextHour00_SoCforecast_XX (in diesem Kontext) auf die Überschreitung von 0 bzw. 100 % zu überwachen. Verletzungen würden dem User direkt sichtbar signalisiert und ein Hinweis auf die mögliche Korrektur gegeben.
Das wäre zumindest mal auf die Praxistauglichkeit hin zu testen.

[minierm]

Mit der cap-Angabe im Attr erfolgt die Umrechnung in das Wh Äquivalent. Der Umwandlungsverlust der Ladung würde auch noch mit eingehen, hat allerdings im Verhältnis der beschriebenen Einflußfaktoren eine eher marginale Rolle.

8,5% Umwandlungsverlust (LFP) würde ich jetzt nicht als marginal bezeichnen...

365.0 Zyklen (0.7 Zyklen / Tag * 494.5 Tage) 8.51% Verlust
Bat_Loss {sprintf("%0.2f", (ReadingsNum($NAME, "data_data_ETotalbatteryCharge", 0) - ReadingsNum($NAME, "data_data_ETotalbatteryDischarge", 0)) / ReadingsNum($NAME, "data_data_ETotalbatteryCharge", 0) * 100)
data_data_ETotalbatteryCharge: 4197.8
data_data_ETotalbatteryDischarge: 3840.6
SOH: 99.32

[minierm]

Oder aber bzw. und auch dadurch, dass die Einheit nicht nur im Falle eines Readings mitzugeben ist.

Das ist auch so.

Wenn die Doku stimmt, dass ist das nicht richtig! Bei der Verwendung einer Konstanten als Kapazität ist keine Einheit anzugeben. Das ist so auch in der Doku angegeben:

Code Auswählen Erweitern

cap     installierte Batteriekapazität. Option kann sein:
    numerischer Wert - direkte Angabe der Batteriekapazität in Wh
    <Readingname>:<Einheit> - Reading welches die Kapazität liefert und Einheit (Wh, kWh)


Ganz toll wäre es natürlich, wenn auch bei konstanten Werten eine Einheit angegeben werden kann
...aber das ist grad nicht so wichtig, würd es nur rund machen.

[DS_Starter]

8,5% Umwandlungsverlust (LFP) würde ich jetzt nicht als marginal bezeichnen...

Das ist sicher nicht marginal.
Jedoch geht es um den Energieverlust nur für die nächste(n) Stunde(n) wenn bereits für die PV-Prognose eine Unsicherheit von 10% und auch für die Verbrauchsprognose 10% vorhanden sind (10 % ist schon ein guter Wert).
Was sollte man da ansetzen? Einen fixen Wert? Wie hoch? Gültig für alle Typen und alle Leistungsklassen? Für Laden und Entladen gleich? 
Vllt. gibt es eine Dokumentation die ein Modell liefert. Gerne mal stöbern ...

Wenn die Doku stimmt, dass ist das nicht richtig! Bei der Verwendung einer Konstanten als Kapazität ist keine Einheit anzugeben.

Ach, ich habe das "nicht" überlesen, sorry. Die Doku stimmt / trifft zu.

Ganz toll wäre es natürlich, wenn auch bei konstanten Werten eine Einheit angegeben werden kann
...aber das ist grad nicht so wichtig, würd es nur rund machen.

Naja so toll ist das nicht. Beispiel...
Hier ist die 9000 ein konstanter Wert:

Code Auswählen Erweitern

cap=9000:Wh
Und hier hat sich der User ein userReading 9020.99 ausgedacht

Code Auswählen Erweitern

cap=9020.99:Wh
Das ist sicherlich unüblich, aber erlaubt. Du glaubst garnicht auf welche Ideen manche User kommen.

Welche Variante davon ist jetzt ein konstanter Wert vs. Reading? 

LG

[Parallix]

...
Und hier hat sich der User ein userReading 9020.99 ausgedacht

Code Auswählen Erweitern

cap=9020.99:Wh
Das ist sicherlich unüblich, aber erlaubt. Du glaubst garnicht auf welche Ideen manche User kommen.

Welche Variante davon ist jetzt ein konstanter Wert vs. Reading? 
...

Das hatte ich gar nicht auf dem Schirm. Gibt es denn keinen Style-Guide aus dem hervorgeht, dass Readings stets mit einem nicht Ziffernsymbol beginnen müssen?

[DS_Starter]

Gibt es denn keinen Style-Guide aus dem hervorgeht, dass Readings stets mit einem nicht Ziffernsymbol beginnen müssen?

Es gibt eine Festlegung aus welchen Zeichen ein Reading bestehen darf, schau hier: https://wiki.fhem.de/wiki/DevelopmentModuleAPI#goodReadingName

[Parallix]

8,5% Umwandlungsverlust (LFP) würde ich jetzt nicht als marginal bezeichnen...

Das ist sicher nicht marginal.
Jedoch geht es um den Energieverlust nur für die nächste(n) Stunde(n) wenn bereits für die PV-Prognose eine Unsicherheit von 10% und auch für die Verbrauchsprognose 10% vorhanden sind (10 % ist schon ein guter Wert).
Was sollte man da ansetzen?
...

Mein Vorschlag (siehe weiter oben):

Für's erste schlage ich – analog zu den pv_correctionFactors – vor, auch bei der Berücksichtigung von Be- und Endladung der BATs in SF entsprechende Korrekturfaktoren einzubauen und ...

[Parallix]

Gibt es denn keinen Style-Guide aus dem hervorgeht, dass Readings stets mit einem nicht Ziffernsymbol beginnen müssen?

Es gibt eine Festlegung aus welchen Zeichen ein Reading bestehen darf, schau hier: https://wiki.fhem.de/wiki/DevelopmentModuleAPI#goodReadingName

Und dann heißt die Funktion, die auch Reading-Namen wir 83724.24 erlaubt, auch noch goodReadingName(). Ich fasse es nicht

Edit: Überdies ist die Beschreibung für den Aufbau von Reading-Namen mehrdeutig, da man

Ein gültiger Readingname besteht aus folgenden Zeichen bzw. Zeichengruppen

auch so verstehen kann, dass stets alle Zeichen bzw. Zeichengruppen im Reading-Namen auftauen müssen.

[DS_Starter]

Naja nicht so hart sein. Es gibt theoritisch keinen Grund einen solchen Readingnamen zu verbieten, auch wenn es uns gerade nicht so gefällt. Solche Dinge muß ich als Modulautor wissen und im Blick haben wenn ich eine Anwendung baue und es berücksichtigen.

[Parallix]

Naja nicht so hart sein. Es gibt theoritisch keinen Grund einen solchen Readingnamen zu verbieten, auch wenn es uns gerade nicht so gefällt.
...

Sorry, aber da kann ich nicht folgen, da es sicherlich absolut keine gute Praxis ist, Reading-Namen zu verwenden, die sich ausschließlich aus Ziffern und einem Punkt zusammensetzen.

Edit: Kann ein Reading tatsächlich mit einem beliebigen Zeichen anfangen? Mich irritiert, dass es hier keine Beschreibung in (E)BNF-Form gibt, was bei Programmiersprachen ja recht üblich ist.

[DS_Starter]

Kann ein Reading tatsächlich mit einem beliebigen Zeichen anfangen?

Probiere es aus, z.B.:

Code Auswählen Erweitern

9999.9:Bezug_Wirkleistung.* {ReadingsVal($name, "Bezug_Wirkleistung", 0)},


[Henno]

D.h. die Korrektur sollte über das besagte UserReading erfolgen.
Da die geschilderte Problematik durchaus allgemeiner Natur ist, wäre alternativ zu überlegen, ob ich setupInverterDevXX einen Schlüssel für "Verlustleistung" spendiere.
Ich kenne momentan aber kein FHEM-Device welches die Verlustleistung ablesbar liefert oder gibt es das?

Hi, danke für deine schnelle Rückmeldung, ein Reading das den Verlust liefert habe ich leider nicht, ich überlege noch wie ich eins errechnen könnte.

Ich habe zwei Strings an einem WR, die Summe beider Strings gibt die PV Leistung.
Von der PV Leistung wird dann der Eigenbedarf gedeckt sowie Akku geladen, was dann noch über bleibt wird eingespeist.
Messwerte die ich habe:
PV Leistung
WR AC Ausgangsleistung
Batterie Ladeleistung
Batterie Endladeleistung
Smartmeter Leistung (positiv Bezug, negativ Einspeisung)

So wäre dann "PV Verlustleistung"
PV Leistung - WR AC Ausgangsleistung - Batterie Ladeleistung - Smartmeter Leistung
Aber, wenn nun Smartmeter Leistung Positiv ist, also Bezug, passt das ganze nicht mehr.
Auch wenn wie grade
Out: 0.313 kW | Laden: 0.00 kW | Entladen: 0.41 kW
Beim Entladen grade ist das Delta etwa 100W

Ich bin mir grade noch nicht sicher wie man das Sinnvoll berechnen könnte.










 

[BlackHawk133]

Hallo,

ich habe jetzt eine PV Anlage mit Batteriepuffer installiert und mein Netzbetreiber verweigert mir die Einspeisung.
Das funktioniert so, dass der WR den Verbrauch inkl. Batterie Laden ermittelt und dann die Solarmodule entsprechend drosselt, so dass sie GENAU das liefern, was grade verbraucht wird. Daher werden meine Algorithmen zum an/ausschalten massiv !! vom Forcast getriggert werden müssen.

Beispiel: Meine Anlage würde grade 7 kW liefern können, es sind aber nur Verbraucher mit 0,5 kW aktiv  dann liefern die Module auch nur 0,5 kW.

Problem: Wenn dein Forecast ständig lernt, so wird das bei mir definitiv nicht funktionieren. Kann man das lernen bei deinem Algo irgendwie ausschalten und rein auf die Anlagenwerte fokusieren (Stringleistung, Dachschräge etc.)? Deine Forcast Werte sind echt gut und ich würde das Modul gerne bei mir einsetzen !!!

Und noch eine letzte Frage: Die forecast Werte sind exorbitatnt hoch - da scheint bei mir ein Faktor 1000??? drin zu sein?
Today_Hour12_PVforecast     3855064 Wh
==> Edit: Fehler war die String Config in W statt in KW. Habe es korrigiert, aber der forecast ändert sich leider dadurch nicht. Der Faktor 1000 bleibt da erst mal drinnen.

[300P]

Da würde ich empfehlen per "set SFxyxyx reset XXXXXX" zu agieren um die "dollen" Werte zu eliminieren.

Vorher evtl. per "get SFXYXYXY XXXX". die entsprechenden Zeiträume evtl. noch aussuchen.

1 Alternative - => : Alle dem zugehörigen WR-Setup-Werte in einen 2ten WR kopieren / alle Werte in WR1 löschen / alle Werte nach einem Neustart wieder in einen WR 1 eintragen und dann den Werte vom WR2 wieder löschen   

2 Alternative - => warten bis die Statistik sich selbst bereinigt nach X Tagen 

OT:
Wieso will der VNB denn die Einspeisung bei 7kW verbieten (Grund)??
Marke Eigenbau - oder warum ?