76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[bismosa]

Hallo Heiko,

vielen Dank für die Ausführliche Antwort!

Ja. Du würdest dann notafter=09:00 setzen und z.B. mintime=540. Dann würde die Einplanung in der Zeit 09:00 bis 18:00 erfolgen. Die Einplanung ist nicht zwangsläufig gleichzusetzen mit der tatsächlichen Startzeit. Die Einschaltung des Verbrauchers innerhalb der Planungszeit ist noch von mode und anderen Parametern wie swoncond, interruptable, etc. abhängig.

Das werde ich dann mal ausprobieren. Das notafter hatte ich ganz anders verstanden...und zwar das die Schaltzeit danach nicht mehr sein darf.
Mit deiner Erklärung macht das aber Sinn 
Mit swoncond könnte ich evtl. mit einem doif etwas passendes basteln. Gut, das der  Pool noch nicht aufgebaut ist.

Nein. Die aktualisiert bei jedem Update. Allerdings muß "state" einen Event erzeugen, was im Normalfall so ist. In der Detailansicht erfolgt keine Aktualisierung der Ansicht.

state erzeugt ein Event. In der Raumseite wird auch brav aktualisiert. War mir nicht aufgefallen, da ich immer auf der Detailseite unterwegs war.

Dafür habe ich noch keine Template bereitgestellt (nutze kein FTUI). Aber es gibt glaube ich User die FTUI3 nutzen wenn ich mich nicht irre. Vllt. meldet sich jemand mal dazu.
Ich nehem auch gerne einen Prototypen entgegen. Bin mit JavaScript nicht so familiär. 

Mal schauen, was sich da vielleicht machen lässt.    Profi bin ich da allerdings auch gar nicht. Aber mit der Vorlage für FTUI2 kann man ja vielleicht schon was anfangen. Es sei denn, hier hat das schon mal jemand gemacht?

Gruß
Bismosa

[DS_Starter]

Hallo Thomas,

die Nachtverarbeitung hat noch nicht so funktioniert wie ich es mir vorstelle.
In meinem contrib liegt ein Update der Version 1.29.2.

Falls es heute auch bei dir noch die Readings "pvCorrectionFactor_XX_autocalc" als Überbleibsel von Gestern geben sollte, lösche sie bitte manuell. Die aktualisierte Version sollte dieses Manko beseitigen.

LG,
Heiko

[tomcat.x]

Hallo Heiko,

ich war gestern nicht mehr dazu gekommen, habe gerade erst die neue Version installiert und werde berichten.

Aber man kann alle Einstellungen in ein kopiertes Device übernehmen

Genau, habe ich auch schon so gemacht.

Vielen Dank erst mal.
Thomas

[tomcat.x]

Allerdings muß "state" einen Event erzeugen

Dabei fällt mir eine Frage wieder ein: Bei mir ist es so eingestellt, dass nur state ein Event erzeugt. Bei der Konfigurationsprüfung kommt daher "Attribute 'event-on-change-reading' is not set to .*. ". Da wollte ich immer schon mal fragen, ob das ok ist, falls ich selbst aktuell keine weiteren Events für irgendwas brauche. Das für state zu lassen, machte für mich Sinn, um überhaupt irgendeine Aktivität erkennen zu können.

[DS_Starter]

Ja das ist ok. Das Device hat halt sehr viele Readings die bei einem Update Events werfen.
Ich habe zwar schon mit readingsBulkUpdateIfChanged experimentiert (falls jemand die Idee hat ). Hier ist allerdings nachteilig, dass sich der Update-Zeitstempel nicht ändert, wenn der Wert beim Update gleich bleibt, d.h. das Reading wird in diesem Fall nicht aktualisiert. Das ist unschön, denn ich möchte schon wissen ob ein Wert (ohne Event) aktualisiert wurde. Teilweise wird das auch ausgewertet.

Edit: Du kannst dennoch 'event-on-change-reading=.*' setzen. state wird auch in diesem Fall Events werfen.

[tomcat.x]

Du kannst dennoch 'event-on-change-reading=.*' setzen. state wird auch in diesem Fall Events werfen.

Ja, ist klar. Aber ich will die anderen nicht, wenn sie nicht gebraucht werden. Bin da letzt mal über alle Geräte gegangen, die viele Events erzeugen und bei neuen schränke ich immer gleich stark ein.

[DS_Starter]

Jetzt sieht es so aus wie ich es mir vorstelle.

[tomcat.x]

Bei mir auch. Auch wenn ich nicht weiß, was Du Dir vorstellst  Danke!

Aufgrund der aktuellen Wettervorhersage ist für heute auch noch eine Stunde drin, in der mein Wert genommen wird (falls es so bleibt). Es passiert aber natürlich immer seltener, dass kein berechneter Wert vorhanden ist. Bei 20% kommt die "KI" ins Spiel. Das alles nur so als Info. Interessant zu beobachten, wie sich die Werte ändern.

[DS_Starter]

Habe die neue V 1.29.0 eingecheckt und ist morgen früh im Regelupdate enthalten.

[Skusi]

Hallo zusammen,

Ich nutze das Modul erfolgreich schon seit Jahren und bin sehr zufrieden. Nun habe ich allerdings aufgerüstet und meine Anlage um eine Anker SOLIX Solarbank E1600 erweitert.
Vorher bestand mein Setup aus 6 Balkonkraftwerken auf Dach Richtung Süden mit jeweils einem Hoymiles HM300. Dazu einen HM600 mit zwei weiteren Zellen dran in Süd-West bzw. West Ausrichtung.
Die Winkel der einzelnen Felder habe ich im Modul als 3 Verschiedene Strings angelegt.
Das funktionierte auch wirklich gut. Die Prognosen hatte unter 10 % Abweichung.

Nun habe ich das Feld SW /W umgebaut und beide Zellen Richtung Süden ausgerichtet und dann eine SOLIX Solarbank dazwischen geklemmt.
Die veränderte Winkel habe ich dem Modul auch mitgeteilt. Nun wird per Anker App am Tage erstmal der Ertrag der beiden Zellen in den Akku geschoben und somit nicht dem Haus zugeführt.
Somit sind die Prognosen des Moduls natürlich auch immer höher als dann wirklich zur Verfügung steht.

Ich komme auf keine vernünftige Lösung wie ich das de Modul nun beibringen soll, das es mit der Prognose nicht immer mit diesen beiden Zellen rechnen kann.

Bleibt mir nix anderes als diese beiden Zellen "rauszunehmen" um dann wenigsten immer eine schlechtere Prognose zu bekommen ?

Hat jemand eine Idee wie man das besser lösen kann ?

An der Fhem Anbindung der SOLIX arbeite ich noch. Stand jetzt habe ich keine Daten des Akkus die man verwenden könnte. Ich hoffe das ich wenigstens das noch hin bekomme. Für HA gibt es da ja schon was: https://github.com/thomluther/hacs-anker-solix

Das kann ich leider wohl nicht für Fhem benutzen.
...

[kask]

Welche API nimmst du?
Je nachdem welche API du nutzt, könntest du bei dem attr "setupInverterDev" die "capacity" abändern wenn der speicher gerade geladen wird.
Wenn nicht dann wieder zurück ändern. Per DOIF, notify what ever.
Wie gut und ob das überhaupt geht kann ich nicht sagen. Wäre einen Versuch wert.

[DS_Starter]

Ich komme auf keine vernünftige Lösung wie ich das de Modul nun beibringen soll, das es mit der Prognose nicht immer mit diesen beiden Zellen rechnen kann.

In die Prognose gehören die Zellen schon hinein, denn sie erzeugen ja Energie die dir zufließt. Sie wird nur zunächst in der Batterie gespeichert.
Du brauchst nur einen Zähler in/out an deiner Batterie damit du die Batterie dem Modul mitteilen kannst. Dann ergiebt sich automatisch ein höherer Ertrag.

D.h. du brauchst ein Modul um die Batteriekennwerte zu messen und im Attr setupBatteryDev hinterlegen zu können. Dann passt es wieder.

[kask]

"Einen nackten Mann in die Tasche greifen" ist nicht so leicht.
Skusi sucht einen Work-around um das Modul zu benutzen, mit dem Wissen das er die Batteriedaten braucht aber (noch) nicht zur Verfügung hat.
So lese ich sein Anliegen.
Ich denke eher das er vorerst eine zähler am AC-Teil  anschliesst (shelly-plug, tasmota, was auch immer) um zu sehen was da passiert.
Dann kann er die Panels zu.- abschalten je nach AC-Wert.
Denn erstmal wird der Akku ja voll geschoben. Heisst das AC-seitig nix kommt. Dann die Zellen raus rausnehmen.
Kommt wieder AC-seitig was Positiv dann die Zellen reinnehmen.
Das ganze sollte allerdings auch mit allen Zellen im ganzen funktionieren. Denn AC-seitig kommt ja wieder was, auch wenn die Sonne nicht scheint.
Nur diesmal aus dem Speicher. Ist ja von der Sonne beladen worden. Das doofe ist nur der Tagesübergang. Dann wird in die Rechnung des Tages schon die "Batteriesonne" vom Vortag einkalkuliert.
Alles in allem ist hier in dem Fall die Abweichung aber eh irrelevant und nur interesant für sich selbst und zum optimieren in manchen API's.
Über kurz oder lang sollte sich das eh relativieren durch die auto_korrekturen.

[DS_Starter]

Moin,

ja, ich habe auch nochmal darüber nachgedacht.
Möglicherweise wäre es ein Weg alle Homiles auszulesen (habe einen Thread gefunden: https://forum.fhem.de/index.php?topic=121282.0), in einem Dummy zu konsolidieren und die Parameter wie gewöhnlich im Attr setupInverterDev zu hinterlegen. Dann sollte zumindest die gesamte Erzeugung erfasst sein und das Delta zur Prognose klein gehalten.
Durch die fehlenden Angaben zur Batterie werden die Verbräuche, AutarkyRate etc. nicht stimmen. Aber vllt. schafft skusi auch noch die Bat zu intergrieren.

[tomcat.x]

Hallo Heiko,

kann es sein, dass sich mit den letzten Änderungen ein Bug bezüglich graphicHistoryHour eingeschlichen hat? Bei mir sieht es so aus, als ob von dem gesetzten Wert immer 8 abgezogen werden. Also bis 8 passiert gar nichts (ich sehe nur die standardmäßigen 2 Stunden), mit 9 sehe ich 1 Stunde und mit meinen vorher einstellten 12 sehe ich 4 Stunden. graphicHourCount habe ich nicht gesetzt, nur jetzt testweise damit herumgespielt. Das ändert aber nichts. Ansonsten habe ich bezüglich Grafik nur graphicBeamHeightLevelX auf 250 gesetzt.

Und im Zusammenhang mit "Stunde" dann noch eine Frage: In der Grafik ist Stunde XX (oder besser Uhrzeit XX?) die Zeit von XX:00 bis XX:59, bei allen anderen Angaben/Readings/Settings ist es immer die XX. Stunde des Tages, also sozusagen XX-1:00 bis XX-1:59, richtig? Das hatte mich beim Analysieren von Ausreißern bei bestimmten Stunden in der Grafik anhand der Angaben bei Quatlität, in pvCorrectionFactor_XX oder pvHistory erst etwas verwirrt.

Viele Grüße
Thomas