Leistungsprognose für Wechselrichter

[DS_Starter]

Deine Settings sehen jetzt ok aus soweit ich das beurteilen kann.

Wenn du noch am Anfang stehst, kannst du die bisher gespeicherten (falschen) Verbrauchsdaten löschen mit:

Code Auswählen Erweitern

set ... reset consumption

Sollte das nicht reichen, dann noch:

Code Auswählen Erweitern

set ... reset pvHistory

Das sollte dann passen.

Grüße,
Heiko

[oelidoc]

Wow,
danke für die schnelle Antwort und Danke für das tolle Modul!
Dann Werde ich mal resetten...

Gruß
oelidoc

[oelidoc]

Okay,
nach reset consumption & reset pvHistory sieht´s jetzt so aus:

Code Auswählen Erweitern

PV => aktuell: 0 W nächste 4h: 26 Wh Rest heute: 26 Wh morgen: 13966 Wh
CO => aktuell: 275 W nächste 4h: 1049358 Wh Rest heute: 1697255 Wh morgen: 0 WhIch würde sagen ein sehr durchmischtes Ergebnis 

Gruß
oelidoc

[DS_Starter]

Das sollte sich morgen dann gegeben haben. Kurz nach Mitternacht führt das Modul diverse Bereinigungen und resets aus.
Ein bisschen Geduld braucht man hier immer, ist sehr komplex.

[oelidoc]

Danke für die Unterstützung.
Kein Problem, ich hab Geduld.
Gruß
oelidoc

[DS_Starter]

@all,

soeben habe ich eine weiterentwickelte Version eingecheckt die morgen früh im Update ist.
Wer möchte, kann sie sich jetzt schon aus meinem contrib ziehen ... ist die gleiche.

In der Version gibt es ein neues Feature.
Der Kopfbereich (Header) der Grafik ist um eine Zone erweitert. Nun kann man sich beliebige Readings aus dem Device mit einem Label versehen in die Grafik holen, um die Übersicht zusätzlich zu den PV-Erzeugungen und Verbräuchen zu ergänzen. Dazu gibt es ein neues Attr graphicHeaderOwnspec.

In dem Zusammenhang ist das Attr graphicHeaderDetail nun als Auswahlliste gestaltet. Man kann sich die Zonen des Headers beliebig ein/ausblenden bzw. miteinander kombinieren.

Ansonsten ist das von ambiman in #3116 gemeldete Problem (hoffentlich) gefixt.

Nebenbei ... der heutige Tag war meteorologisch wieder recht herausfordernd, was man an der PV Übersicht im zweiten Screenshot sehen kann.

LG

[kask]

Das ist schick. Gefällt mir.

[tobi01001]

@all,

soeben habe ich eine weiterentwickelte Version eingecheckt die morgen früh im Update ist.
Wer möchte, kann sie sich jetzt schon aus meinem contrib ziehen ... ist die gleiche.

In der Version gibt es ein neues Feature.
Der Kopfbereich (Header) der Grafik ist um eine Zone erweitert. Nun kann man sich beliebige Readings aus dem Device mit einem Label versehen in die Grafik holen, um die Übersicht zusätzlich zu den PV-Erzeugungen und Verbräuchen zu ergänzen. Dazu gibt es ein neues Attr graphicHeaderOwnspec.

In dem Zusammenhang ist das Attr graphicHeaderDetail nun als Auswahlliste gestaltet. Man kann sich die Zonen des Headers beliebig ein/ausblenden bzw. miteinander kombinieren.

Ansonsten ist das von ambiman in #3116 gemeldete Problem (hoffentlich) gefixt.

Nebenbei ... der heutige Tag war meteorologisch wieder recht herausfordernd, was man an der PV Übersicht im zweiten Screenshot sehen kann.

LG

Hi Heiko,

das sieht gut aus. Direkt mal ausprobieren.

Nebenbei ... der heutige Tag war meteorologisch wieder recht herausfordernd, was man an der PV Übersicht im zweiten Screenshot sehen kann.

Oh ja, ich sehe für gestern eine Abweichung von 63%.   Aber das System lernt halt auch noch und viel hängt sicher eher an der Vorhersagequalität...

Noch eine Frage:
Gibt es eigentlich die Möglichkeit einzelne Consumer (dynamisch) auszublenden?
Beispielsweise habe ich eine Poolpumpe, die jetzt im Herbst/Winter nicht laufen wird, aber als Consumer mit gelistet ist. Da wäre es schön, den irgendwie ausblenden zu können.

Bei anderen Consumern (die ich z.B. nur zur Verbrauchsübersicht darstelle) wäre es nett, die nur Anzuzeigen, wenn sie aktiv sind - sprich aktiv verbrauchen....
Eventuell bin ich auch recht exotisch mit solchen Wünschen, dann kann ich mir auch was anderes überlegen. 


Bzgl. KI und/oder eines Consumer-Moduls:
Eine Anwendung die mir direkt einfällt, sind dynamische Stromtarife wie Tibber. Mit Verbrauchs- und Lastprognose sowie den Strompreisvorhersagen und (KI)-Erfahrungen könnte man die Stromkosten wahrscheinlich ziemlich optimieren.

Gruß,
Tobias

[DS_Starter]

Moin Tobias,

solche Witterungslagen sind immer eine Herausforderung. Nicht nur für das Modul, sondern auch für die Datenlieferanten. Jeder wird da eigene Beobachtungen machen. Ich persönlich bin mit dem SolCast-Dienst sehr zufrieden, dagegen von dem Dienst Forecast.Solar ziemlich enttäuscht. Die Victron API ist noch ein bisschen zu neu und muß noch etwas lernen. Die DWD-Vorhersage ist bei mir auch inzwischen sehr gut. Mal sehen was die KI noch dazu beitragen kann. Wir werden sehen ...

Möglicherweise, aber das ist natürlich nur eine Vermutung, sind die Datenlieferungen bei Abschuß eines bezahlten Abos genauer.

Noch eine Frage:
Gibt es eigentlich die Möglichkeit einzelne Consumer (dynamisch) auszublenden?

Zur Zeit gibt es die nicht.
Ich könnte mir aber vorstellen in den Consumerattributen einen Schlüssel "noshow" anzubieten der, wenn gesetzt, die Anzeige des Consumers in den Grafiken ausblendet.
Das wäre allerdings recht statisch.
Weitere Möglichkeit wäre den Schlüssel "noshow" ähnlich dem Schlüssel "auto" zu gestalten. Dann würde man ein Reading im Consumerdevice angeben das, wenn auf 1 gesetzt, die Anzeige ausblendet. Das wäre dann auch dynamisch möglich weil man als User in Abhängigkeit des Verbrauchs dieses Reading wahlweise auf 0/1 setzen könnte. Statisch natürlich ebenfalls, keine Frage. Ist der Schlüssel bzw. das Reading nicht gesetzt (default) bleibt alles wie bisher.

[DS_Starter]

@Guido, ich habe den Grund gefunden weshalb die Logausgabe manchmal nicht erscheint.
Es wurde immer dann nicht ausgegeben, wenn der alte und neu berechnete Korrekturfaktor gleich war.

Das ist verwirrend und ich habe es nun so geändert dass auch in diesen Fällen die Logausgabe erscheint.
Manchmal hilft eine Nacht darüber schlafen. 

Die Änderung fließt in das nächste Release mit ein.

[minierm]

Hallo @DS_Starter,
Danke für Dein Modul und Einbinden in das fhem Update!

Ich habe zwei Probleme mit dem Modul:
Die M-Tec Cloud verändert die total-Einheit, grad ist sie von kWh auf MWh gesprungen
Leider macht MWh aber keinen Sinn beim aktuellen Verbrauch, nichtdestotrotz wäre die Einheit insgesamt sinnvoll, ich behelf mir grad mit einem Userreading, das in kWh umrechnet, aber natürlich an Genauigkeit leidet (nur in 100 kWh Schritten, aktuell 1,1 MWh).
Kannst Du die aktuelle Ertragsermittlung optional auf einen täglichen Wert ändern?
Siehe https://forum.fhem.de/index.php?topic=135001.0 (data_accumulatedData_todayEnergy)

In der Anfangsphase hatte ich Problem mit den Zählerständen, auch wenn z.B. wenn die Daten grad nicht erreichbar waren. Dabei wurde der alte Wert häufiger mal auf 0 gesetzt und wenn die Werte wieder verfügbar waren gab es einen immensen Wert. Da wäre eine Fehlerbehandlung beim Einlesen und eine Plausibiliätsprüfung beim Verarbeiten gut, z.B. Zähler neu darf nicht kleiner Zähler alt sein.
Aktuell bin ich dank 9,6kWp plus 10kW Speicher z.B. quasi autark unterwegs, bei meinem Balkonkraftwerk (600W) habe ich folgende Werte:
Today_Hour14_PVforecast 600 Wh
Today_Hour14_PVreal 381500 Wh
Tomorrow_ConsumptionForecast -470964262 Wh
Circular:
13 => pvapifc: 539, pvaifc: -, pvfc: 539, aihit: 0, pvrl: 100
      batin: -, batout: -, confc: -3779, gcon: 17, gfeedin: 24, wcc: 42, wrp: 1.00
14 => pvapifc: 600, pvaifc: -, pvfc: 600, aihit: 0, pvrl: 381500
      batin: -, batout: -, confc: 8725, gcon: 20, gfeedin: 25, wcc: 41, wrp: 1.00
15 => pvapifc: 600, pvaifc: -, pvfc: 600, aihit: 0, pvrl: 0
      batin: -, batout: -, confc: 10019, gcon: 20, gfeedin: 25, wcc: 44, wrp: 0.00
99 =>
   tdayDvtn: 163.25, ydayDvtn: 260.67
   feedintotal: 811287.1327, initdayfeedin: 810894.2975
   gridcontotal: 2692805.583, initdaygcon: 2692446.9319

bzw. History
13 => etotal: 589600, pvfc: 187, pvrl: 100, rad1h: -
            confc: -3779, con: 93, gcon: 17, gfeedin: 24
            wid: 3, wcc: 81, wrp: 2.00, temp: 19.2, pvcorrf: 0.84/0.95
14 => etotal: 589700, pvfc: 600, pvrl: 381500, rad1h: -
            confc: 8725, con: 381495, gcon: 20, gfeedin: 25
            wid: 3, wcc: 87, wrp: 2.00, temp: 20.4, pvcorrf: 7.96/0.00
15 => etotal: 971200, pvfc: 220, pvrl: 0, rad1h: -
            confc: 10019, con: -5, gcon: 20, gfeedin: 25

[minierm]

Moin Tobias,

solche Witterungslagen sind immer eine Herausforderung. Nicht nur für das Modul, sondern auch für die Datenlieferanten. Jeder wird da eigene Beobachtungen machen. Ich persönlich bin mit dem SolCast-Dienst sehr zufrieden, dagegen von dem Dienst Forecast.Solar ziemlich enttäuscht. Die Victron API ist noch ein bisschen zu neu und muß noch etwas lernen. Die DWD-Vorhersage ist bei mir auch inzwischen sehr gut. Mal sehen was die KI noch dazu beitragen kann. Wir werden sehen ...

Möglicherweise, aber das ist natürlich nur eine Vermutung, sind die Datenlieferungen bei Abschuß eines bezahlten Abos genauer.

Noch eine Frage:
Gibt es eigentlich die Möglichkeit einzelne Consumer (dynamisch) auszublenden?

Zur Zeit gibt es die nicht.
Ich könnte mir aber vorstellen in den Consumerattributen einen Schlüssel "noshow" anzubieten der, wenn gesetzt, die Anzeige des Consumers in den Grafiken ausblendet.
Das wäre allerdings recht statisch.
Weitere Möglichkeit wäre den Schlüssel "noshow" ähnlich dem Schlüssel "auto" zu gestalten. Dann würde man ein Reading im Consumerdevice angeben das, wenn auf 1 gesetzt, die Anzeige ausblendet. Das wäre dann auch dynamisch möglich weil man als User in Abhängigkeit des Verbrauchs dieses Reading wahlweise auf 0/1 setzen könnte. Statisch natürlich ebenfalls, keine Frage. Ist der Schlüssel bzw. das Reading nicht gesetzt (default) bleibt alles wie bisher.

Das Attribut zum Anzeigen kann man dann ja per Programmierung ändern, also z.B. im Frühjahr/Herbst umschalten...

[DS_Starter]

Da wäre eine Fehlerbehandlung beim Einlesen und eine Plausibiliätsprüfung beim Verarbeiten gut, z.B. Zähler neu darf nicht kleiner Zähler alt sein.

Das muß ich prüfen ob es an irgendeiner Stelle unerwünschte Nebenwirkungen geben würde die ihrerseits eine Behandlung notwendig machen würden.

Kannst Du die aktuelle Ertragsermittlung optional auf einen täglichen Wert ändern?

Was meinst du genau mit "tägliche Ertragsermittlung"?
Wenn damit gemeint ist, dass nur einmal am Tag der PV-Ertrag ermittelt werden soll, dann ist das nicht möglich.
Allerdings wird im Prinzip bereits jetzt in gewisser Weise ein Tageswert ermittelt wenn ausgehend vom Tagesstartwert sich am Ende des Tages eine positive Differenz ergibt. In der Grafik würden dann wohl mehrere Stunden lang Erträge von 0 zu beobachten sein und sich am Ende des Tages in einem einzelnen Balken niederschlagen. Ist nicht schön, aber wenn die Input-Daten so üngenügend bzw. grob sind sehe ich keine Lösung.

[minierm]

Kannst Du die aktuelle Ertragsermittlung optional auf einen täglichen Wert ändern?

Was meinst du genau mit "tägliche Ertragsermittlung"?
Wenn damit gemeint ist, dass nur einmal am Tag der PV-Ertrag ermittelt werden soll, dann ist das nicht möglich.
Allerdings wird im Prinzip bereits jetzt in gewisser Weise ein Tageswert ermittelt wenn ausgehend vom Tagesstartwert sich am Ende des Tages eine positive Differenz ergibt. In der Grafik würden dann wohl mehrere Stunden lang Erträge von 0 zu beobachten sein und sich am Ende des Tages in einem einzelnen Balken niederschlagen. Ist nicht schön, aber wenn die Input-Daten so üngenügend bzw. grob sind sehe ich keine Lösung.

Die PV Anlage liefert den Total-Wert über die Lebenszeit, Jahreswerte, Monatswerte und halt den täglich Wert, der jeden Tag bei 0 anfängt und die Erzeugung im Laufe des Tages summiert. Dieser Tageswert hat eine passende Genauigkeit. Mit diesem Tagessaldo statt dem Lebenszeitsaldo könnte man die Stundenwerte berechnen. Man muss halt nur berücksichtigen, daß der Zähler jeden Tag bei 0 anfängt.

[DS_Starter]

Die PV Anlage liefert den Total-Wert über die Lebenszeit, Jahreswerte, Monatswerte und halt den täglich Wert, der jeden Tag bei 0 anfängt und die Erzeugung im Laufe des Tages summiert. Dieser Tageswert hat eine passende Genauigkeit. Mit diesem Tagessaldo statt dem Lebenszeitsaldo könnte man die Stundenwerte berechnen. Man muss halt nur berücksichtigen, daß der Zähler jeden Tag bei 0 anfängt.

Jetzt ist es klarer, danke. Ein solches Thema hatte wir bereits öfter.
Eine Lösung gibt es bereits durch Erstellung eines userReadings mit dem modifier "monotonic".
siehe https://fhem.de/commandref_DE.html#userReadings

Im Prinzip ist diese Variante ebenfalls eine Lösung für dich bzgl. der unsteten und unzuverlässigen Zählerereichbarkeit.

In allen diesen Fällen gibt man das entsprechende userReading in den Modulsettern an. Diese Readings enthalten dann durch den monotonic Modifier immer den geforderten sich stetig erhöhenden Zählerwert.