Leistungsprognose für Wechselrichter

[DS_Starter]

ich meine, wenn man von einer Version vor deinen ctrlDebug Änderungen auf die aktuelle geht, bekam ctrlDebug den Wert 0 und jede Menge Debug Ausgaben. Hab's nicht weiter verfolgt, weil 1x ctrlDebug setzen und/oder danach wieder löschen behebt das.

Ja, das kann natürlich sein.

da fehlt IMHO die Abfrage auf consumerPlanning, Fix anbei.

Da ist mir doch tatsächlich so ein Scheißerchen durchgerutscht. 
Bereinige ich ....

EDIT: ins contrib geladen

[mcp]

Moin Heiko,

mir ist FHEM vorhin abgeraucht (ich sollte nicht in der Prod-Umgebung Code testen ) und beim Neustart stand im Header rechts "SolCast: 15.11.2022 16:bla" - also gestern, API Abfragen: 50/0
Obwohl es heute morgen um 08:08 Uhr schon bei 7/43 war.

Daraufhin 1x get roofTopData und dann siehe Screenshot.

Kann es sein, dass für die Daten ein InternalTimer fehlt, welcher die Daten auf die Platte schreibt?

Ich sehe zwar den alle 900 Sekunden Timer für die History, aber weiß nicht was da alles drin ist.

[DS_Starter]

Moin Marc,

Faux Pax  ... dadurch wurde aber deutlich, dass ich die interne SolCast Cache-Datenbank blöderweise nur bei einem regulären Shutdown gesichert habe.
Deswegen wurde der letzte Stand eines solchen Shutdowns bei Restart wieder geladen, vermutlich von gestern Abend.

Das habe ich gleich gefixt und ins contrib geladen.

[mcp]

Moin Heiko,

mir ist aufgefallen, daß ich seit Tagen (vielleicht auch schon länger/immer) eine Diskrepanz zwischen Today_PVreal und dem tatsächlichen etoday bzw. etotal vom Wechselrichter habe.
Es ist zwar nicht viel aber täglich eine Differenz von 0,4 bis 0,9 kWh welche bei SolarForecast nicht "ankommen".

etotal vom WR zählt immer korrekt, etotal_stop-PV-prod minus etotal_start-PV-prod = etoday

Aufgefallen ist mir das eigentlich auch nur, weil ich beim Wechselrichter in FHEM ebenso die Abweichung (aus anderem Blickwinkel) anzeige.

Code Auswählen Erweitern


currentInverterDev        SMA_SUNNY_TRIPOWER_10.0 pv=total_pac:kW etotal=etotal:kWh capacity=10000


Bug? Feature?

[DS_Starter]

Moin,

Bug? Feature?

Eigentlich weder noch.
Das Reading Today_PVreal ist der Summenwert der Readings Today_HourXX_PVreal, das heißt der Einzelstundenwerte.
Nun müsste das Modul um die ganz exakten Stundenwerte zu ermitteln genau um XX:00:00 und um XX:59:59 das WR-Modul abfragen. Das ist jedoch durch die Intervallabfrage so nicht möglich.
Es ergeben sich also rein logisch immer kleine Differenzen des Stundenwertes (Mal abgesehen davon dass auch das Invertermodul nicht exakt zu Anfang Ende einer Stunde die Werte aktualisiert).

D.h. die Stundenwerte haben immer kleine Differenzen die aufsummiert zu der von dir beschriebenen Auffälligkeit führen.
Ich fürchte da wird nichts zu machen sein außer wenn ich das Reading Today_PVreal einkassiere. 

[mcp]

Ok, verstehe.

Idee: bei Sonnenuntergang das WR Reading auslesen und sich die Differenz holen und aufsummieren?
Dann stimmen natürlich die Stundenwerte nicht aber die Summe wäre dann 1:1.

[DS_Starter]

Naja, man kann nach Sonnenuntergang (wenn das Reading Today_PVdeviation erstellt wird) das Reading etotal aus dem WR auslesen und mit dem gespeicherten Anfangswert (aus pvHistory) vor Sonnenaufgang subtrahieren. Dann ergibt sich ein Wert der dann, zu diesem Zeitpunkt, den vorherigen Stunden-Summenwert im Reading Today_PVreal korrigiert/überschreibt.
Das wäre möglich.

Allerdings auch nur dann wenn das Modul zum Zeitpunkt des Sonnenaufgangs aktiv war. Das ist nicht so wenn der User das Device das erste mal definiert. Da gehört auch ein bisschen Fehlertoleranzbehandlung dazu.

[FosCo]

Moin und erstmal ein dickes DANKE!
Nach solch einem Modul habe ich vor zwei Jahren gesucht und wollte mir immer mal das kostal anschauen, bin aber nie dazu gekommen.
Zunächst dachte ich "SolCast klingt ja toll" - dann fiel mir auf, dass ich zu der "1 rooftop" Zeit schon einen Account erstellt hatte und eine Ausrichtung nicht reichte, 2 leider bei OSW Walmdach auch nicht. Mal sehen, ob der support mir ein drittes als Hobbyist gewährt.

Also mit meinem alten brachliegendenddn DWD Modul weitergemacht, dort muss in den properties auch "Rad1h" rein, dann klappt es. Vielleicht könnt ihr das im PlantConfiguration Check mit reinnehmen, die Daten sind seit 2021 anscheinend mit drin, müssen eben nur in die properties. (Satellitendaten, also vermutlich egal welche Station).

Frage: Wofür brauche ich die "Meter" Daten für die Prognose?
Meine Meter Daten sind ein Discovergy workaround bisher, ohne Summenbildung - behindert das eine Funktion in der Auswertung?
Habe erstmal dummy readings angegeben zur Befriedigung der Konfiguration, hoffe der FHEM hängt sich nicht auf

Für morgen sind grob 11kWh prognostiziert, passt ganz grob zu meinem Bauchgefühl mach Blick auf die DWD wetterApp

Nochmal: DANKE!

[DS_Starter]

Guten Morgen,

im contrib habe ich die kleine Ergänzung zur abschließenden Erstellung von Today_PVreal wie oben beschrieben implementiert.
Das funktioniert soweit.

[DS_Starter]

Hallo FosCo,

Zunächst dachte ich "SolCast klingt ja toll" - dann fiel mir auf, dass ich zu der "1 rooftop" Zeit schon einen Account erstellt hatte und eine Ausrichtung nicht reichte, 2 leider bei OSW Walmdach auch nicht. Mal sehen, ob der support mir ein drittes als Hobbyist gewährt.

Man kann nur 2 Rooftops mit einem Account nutzen. Aber das Modul bietet die Möglichkeit mehrere Accounts zu haben.
Man kann sich also z.B. 2 Accounts mit einmal zwei und einmal einem Rooftop anlegen und im Modul hinterlegen.

Vielleicht könnt ihr das (Rad1h) im PlantConfiguration Check mit reinnehmen, die Daten sind seit 2021 anscheinend mit drin, müssen eben nur in die properties. (Satellitendaten, also vermutlich egal welche Station).

Das ist drin, d.h. es wird geprüft ob forecastProperties Rad1h enthält.

Frage: Wofür brauche ich die "Meter" Daten für die Prognose?
Meine Meter Daten sind ein Discovergy workaround bisher, ohne Summenbildung - behindert das eine Funktion in der Auswertung?

Für die Prognose nicht. Aber das Modul ist ja ein Gesamtwerk um Mehrwerte zu bieten. Dazu zählen Informationen In/Out, aber auch Verbrauchsprognosen, Verbraucherplanung und deren Steuerung usw.
Dazu wird das Meterdevice verwendet.
Man natürlich wie du es gemacht hast Dummy Device und Readings an der Stelle zu hinterlegen. Es passiert auch nichts, außer dass dann bestimmte Readings und Ableitungen in der Übersicht nicht stimmen werden.

Was deinen Meter betrifft müsste man schauen was genau der liefert. Wenn deiner keine Summenbildung bietet, fehlen dir vermutlich diese Readings zur Angabe:

contotal    Reading welches die Summe der aus dem Netz bezogenen Energie liefert
feedtotal    Reading welches die Summe der in das Netz eingespeisten Energie liefert

Aber du kannst dir in deinem Meterdevice dazu userreadungs erstellen, die diese Angaben errechenn und dieses Readings dann im Device angeben.
Das Modul leitet aus diesen Angaben Stundenwerte ab, die an verschiedenen Stellen benötigt werden.

[FosCo]

Vielen lieben Dank für die schnelle und ausführliche Antwort!

Im Hinweistext zu den properties steht es noch nicht drin mit rad1h, neben den anderen, gemeckert wird, wenn es fehlt

Meine Meter config lokalisiere ich demnächst per IR Kopf, da hat das keine Priorität.

Erstmal müssen die WR Werte rein, mal nachher schauen, warum die nicht kommen.

Verbose 5 zeigt leider nix, wie kann ich das debuggen?

[DS_Starter]

Im Hinweistext zu den properties steht es noch nicht drin mit rad1h, neben den anderen, gemeckert wird, wenn es fehlt

Hmm, bin mir unschlüssig welche Stelle du genau meinst. Es steht bei der Hilfe zu currentRadiationDev drin:

    im ausgewählten DWD_OpenData Device müssen mindestens diese Attribute gesetzt sein:

        forecastDays    1
        forecastProperties    Rad1h
        .....

Erstmal müssen die WR Werte rein, mal nachher schauen, warum die nicht kommen.

Verbose 5 zeigt leider nix, wie kann ich das debuggen?

Im Modul gibt es zu viele Daten, deswegen kann man sich gewünschte Debugdaten mit dem Attr ctrlDebug ein/ausschalten.

[FosCo]

Im PlantConfiguration Check, wenn rad1h fehlt, steht das nicht so schön aufgeführt wie bei den weatherproperties meine ich.

Nun muss ich erstmal deine ganzen Tipps testen, danke

[DS_Starter]

schau mal den Screenshot 

[FosCo]

Uff, ja, ist ja bewusst getrennt, weil SolCast auch Wetter braucht, kapiert.
Hatte nur aus dem zweiten einfach rüberkopiert und dann recherchiert, wie ich rad1h reinbekomme, ich nehme alles zurück, Fehler im OSI Layer 8!

edit: und noch einer, da war ein : zuviel und Umlaute gehören nicht in Bezeichner Einmal DAU gespielt, ich sollte sowas nicht abends über das Handy machen

Jetzt bin ich gespannt auf die Zahlen

Kann ich in der graphischen Ansicht die Balkendiagramme der letzten Tage sehen?