Leistungsprognose für Wechselrichter

[ClausL]

Hallo,

ich dachte auch erst, das sieht aber komisch aus. Bis ich gemerkt habe, dass man die Farben einstellen kann.

Viele Grüße, Claus

[papa]

Die Farben sind erst mal egal - aber was bedeutet 24-33 ? Und sind die 6-19 von heute oder morgen ?

[DS_Starter]

Habe gerade herausbekommen, dass man mit

    showNight = 1

wieder die normale Ansicht hat.

@Wzut, wäre es nicht besser wenn showNight = 1 der Standard wäre ?
Kann nicht sagen wie es ursprünglich war weil ich dieses Attr bei mir immer gesetzt habe.

@papa, in deiner Darstellung sind die Nachtstunden ausgeblendet, d.h. 6-19 sind morgen. Aber nach 24 müsste es mit 00 wieder weitergehen. Da muß Wzut nochmal schauen ...

[ch.eick]

Nachdem ich gestern noch die neueste Firmware in den Kostal gespielt habe, gibt es jetzt das Reading Total_DC_PV_Energy_(sumOfAllPVInputs). Das sollte doch die aufsummierte PV-Leistung beinhalten. Die aktuelle Leistung sollte in Total_DC_Power_(sumOfAllPVInputs) stehen - alles aus dem ModBus-Device.

Ab v1.16 sollten die readings da sein. Historisch bedingt habe ich die jedoch nur in wenigen Fällen in Verwendung. Die muss ich mir noch genauer anschauen.

VG Christian

[Wzut]

@HTML Grafik Nutzer,
Wenn ihr die das erste Mal einsetzt : surft etwas durch die Attribute
Die Grafik lässt durch etliche Attribute in ihrem Aussehen stark verändern.
IMHO wird das richtig wichtig wenn man sich später mehr als eine Grafik auf eine Seite packt, je nach dem welche Werte dann dargestellt werden sollen ist es u.A. sinnvoll die Nachtsunden ein und auszuschalten, die Höhe zu verändern, die Anzahl der angezeigten Stunden , die Zeitverschiebung auf der X-Achse , usw.

@Heiko, ja kein Problem. Natürlich kann man show_night wieder auf 1 setzen, ich dachte halt gerade bei Forecast macht die Nacht realtiv wenig Sinn.
Bei der Grafik von papa fallen mir zwei Dinge auf :
a. liefert offensichtlich das DWD Device zuwenig Daten für die Zukunft (die vielen ? Icons ab 19:00 Uhr)
b. hat er eine Situation in der die X Achse Stundenwerte über 23 darstellt. Hier muß ich etwas tiefer graben wie es zu diesem Fehler kommt.     

[papa]

Bei der Grafik von papa fallen mir zwei Dinge auf :
a. liefert offensichtlich das DWD Device zuwenig Daten für die Zukunft (die vielen ? Icons ab 19:00 Uhr)
b. hat er eine Situation in der die X Achse Stundenwerte über 23 darstellt. Hier muß ich etwas tiefer graben wie es zu diesem Fehler kommt.     

Ich glaube ich kann Entwarnung geben. heute sieht die Grafik schon besser aus. 2x von 6-19. Das macht so ach Sinn. Kann jetzt leider keinen Screenshot anhängen. Ich habe in meine DWD-Device nur 2 Tage eingestellt. Vielleicht hängt es damit zusammen ?

[DS_Starter]

Moin zusammen,

@Heiko, ja kein Problem. Natürlich kann man show_night wieder auf 1 setzen, ich dachte halt gerade bei Forecast macht die Nacht realtiv wenig Sinn.

Naja, stimmt schon. Ich betrachte es nur aus der Sicht eines Nutzers der zum ersten mal das Device definiert und noch nichts weiß. Der würde sich vermutlich als erstes wundern was er da sieht und wie er es interpretieren muss.
Deswegen fand ich den bisherigen Standard hilfreich.

[DS_Starter]

Hallo,

in meinem contrib liegt die V 0.14.0.
Mit dieser Version wird auch der stündliche Netzbezug über das currentMeterDev ermittelt und gespeichert. Damit erhoffe ich mir zukünftig auch eine Prognose des Bezugs erstellen zu können. Aus der Differenz aus PV Forecast und der Bezugsprognose ergäbe sich dann ein prognostizierter Überschuß den man für Steurungen einsetzen könnte.

Den Setter currentMeterDev müsst ihr bitte ergänzen:

  set <> currentMeterDev <Meter Device Name> gcon=<Reading aktueller Netzbezug>:<Einheit> contotal=<Reading Summe Netzbezug>:<Einheit>

Wer das Modul SMAEM nutzt gibt dort an:

<SMAEM-Device> gcon=Bezug_Wirkleistung:W contotal=Bezug_Wirkleistung_Zaehler:kWh

Abhängig vom Attr disableSernoInReading im SMAEM können die Readings auch anders heißen.

Darüber hinaus gibt es noch neue Getter die interne Informationen anzeigen. Das werde ich auch noch ausbauen, damit die Anzahl der Readings wieder verringert werden kann.

Grüße,
Heiko

[ch.eick]

Mit dieser Version wird auch der stündliche Netzbezug über das currentMeterDev ermittelt und gespeichert. Damit erhoffe ich mir zukünftig auch eine Prognose des Bezugs erstellen zu können. Aus der Differenz aus PV Forecast und der Bezugsprognose ergäbe sich dann ein prognostizierter Überschuß den man für Steurungen einsetzen könnte.

Hallo Heiko,
da ich mich ja nun schon über ein Jahr mit der Prognose bei meiner PV-Anlage beschäftige, denke ich, dass das nicht notwendig sein wird.
Eine reine Prognose der zu erwartenden Leistungen und das Definieren von Schwellwerten für den Sommer/Winter Betrieb reicht vollkommen aus. Ich denke es wird ansonsten noch komplexer und schießt über das Ziel hinaus.

Bei mir habe ich wegen der 70% Regel noch ein Mittagshoch mit eingebaut. Das dient der Speicher Steuerung, damit mittags der Speicher genügend platz hat um die Leistung oberhalb der 70% aufzunehmen.

Könntest Du mal ein fiktives Beispiel beschreiben, wo man den "prognostizierten Überschuß" verwenden würde?
Im Sommer habe ich immer Überschuss, bis ein E-Auto kommt und das bekommt alles, bis es voll ist.

VG
    Christian

[DS_Starter]

Moin,

da ich mich ja nun schon über ein Jahr mit der Prognose bei meiner PV-Anlage beschäftige, denke ich, dass das nicht notwendig sein wird.
Eine reine Prognose der zu erwartenden Leistungen und das Definieren von Schwellwerten für den Sommer/Winter Betrieb reicht vollkommen aus. Ich denke es wird ansonsten noch komplexer und schießt über das Ziel hinaus.

Warten wir mal wie andere User das sehen.

Könntest Du mal ein fiktives Beispiel beschreiben, wo man den "prognostizierten Überschuß" verwenden würde?

Ich weiß nicht ob du die originale SMA Lösung zur Planung der Einschaltzeiten ihrer Homemanager Dosen kennst.
Die planen zum Beispiel den Einschaltzeitpunkt für Geschirrspüler/Trockner etc. danach ab welchen Zeitpunkt genügend Überschuß vorhanden ist um für die Laufzeit des Gerätes diesen Energiebedarf abzudecken.

Was die Komplexität betrifft, du musst es ja auch nicht übernehmen und bei Kostal nachbauen 

LG,
Heiko

[Wzut]

Mit dieser Version wird auch der stündliche Netzbezug über das currentMeterDev ermittelt

fein dann kann man das zumindest für vergangene Stunden in der Grafik als beam nutzen.

@Christian, ja da gab es richtige Fans von. Ich selbst hatte es nie aktiv, aber getreu dem FHEM Motto : "des Users Wille ist sein Himmelreich"  

[DS_Starter]

Hi Wzut,
hatte dabei natürlich an deine Balken gedacht. 

Dadurch dass ich ein Verfahren entwickeln konnte um aus etotal den Stundenwert beim Inverter abzuleiten, konnte ich das recht einfach auch für den Meter tun. Und dieser Wert findet sich nun auch im pvHistory Hash wieder und kann ausgewertet werden.

Die anderen internen Hashes habe ich auch über die getter sichtbar gemacht. Könnte hilfreich sein wenn man mal etwas nachschauen will.

[ch.eick]

Ich weiß nicht ob du die originale SMA Lösung zur Planung der Einschaltzeiten ihrer Homemanager Dosen kennst.

Nein, das kenne ich nicht wirklich, ich hatte mir nur die Parameter in der Konfiguration angesehen und das dann als Grundlage für meine Portierung verwendet.

Die planen zum Beispiel den Einschaltzeitpunkt für Geschirrspüler/Trockner etc. danach ab welchen Zeitpunkt genügend Überschuß vorhanden ist um für die Laufzeit des Gerätes diesen Energiebedarf abzudecken.

Geschirrspüler und Waschmaschinen haben meisten zu beginn einen hohen Energiebedarf, um auf Temperatur zu kommen, danach ist der Verbrauch wieder recht normal und niedrig.
Zu diesem Zweck habe ich dann folgende Parameter aus der SMA Dokumentation übernommen:

Code Auswählen Erweitern


LWP_Button off                <<< Manueller Softbutton
PowerLevelMinTime 600         <<< Mindest Zeit, die die PV diese Leistung liefern muss, bevor eingeschaltet werden darf
PowerLimitOff 2250            <<< Schwellwert unten zum Abschalten
PowerLimitOn 3000             <<< Schwellwert oben zum Einschalten
RunTimeMin 3600               <<< Wenn es aktiviert wurde muss das Gerät mindestens so lange laufen
RunTimePerDay 28800           <<< Gesamte Laufzeit pro Tag
SetCmdOff set shelly01 off 0  <<< Indirektes komando zum Abschalten. Dadurch wird es von der Steuerung entkoppelt
SetCmdOn set shelly01 on 0
TimeEnd 16:00                 <<< Ab dieser Zeit nicht mehr den PV-Modus verwenden
TimeStart 11:30               <<< Früheste Zeit zum aktivieren


Die Praxis hat gezeigt, dass es am besten ist, wenn sich die Kleinverbraucher entlang der aktuellen PV-Situation hangeln. Also lieber sofort verbrauchen.
Für die weiße Haushaltsware macht es keinen Sinn die Prognose des nächsten Tages zu verwenden.
Ich lade meine Waschmaschine voll und sobald das erste mal genug PV-Leistung da ist läuft sie los. Zu stark schwankenden Zeiten ergänzt der Speicher den Rest.

Bei eine Wärmepumpe ist das meistens auch nur im Herbst oder Frühjahr wirklich relevant und da reagiert man auch besser sofort.

Bei der Speicher Steuerung interessiert meist nur die zu erwartende Gesamtleistung des nächsten Tages, was wir ja schon drin haben.
Auch hier ist der Herbst/Winter besonders interessant, wo aber eine Prognose des Überschusses eher 0 Anzeigen wird zumindest wenn man eine Wärmepumpe hat.

Das Template oben ist als DUMMY auf meiner Wiki Seite zu finden. Dort sind auch unterschiedliche Definitionen und DOIFs für die verschiedenen Geräte Typen zu finden.
Bei Bedarf mache ich auch gerne nochmal einen Update mit den Erfahrungen aus der letzten Wintersaison

Was die Komplexität betrifft, du musst es ja auch nicht übernehmen und bei Kostal nachbauen 

Was gut ist baue ich alles mit ein
Sogar die Tarif Steuerung bei unterschiedlichen Strompreisen war eine tolle Bereicherung. Hier nochmal Dank an Reto für die Zusammenarbeit und die Idee.

VG
    Christian

[DS_Starter]

Geschirrspüler und Waschmaschinen haben meisten zu beginn einen hohen Energiebedarf, um auf Temperatur zu kommen, danach ist der Verbrauch wieder recht normal und niedrig.

Das war nur ein Beispiel Christian. Diese SMA-Dosen beinhalten eine Energiemessung und dadurch sieht SMA den Verbrauch des angeschlossenen Devs über die Laufzeit (z.B. Trockner) und der geht mit in die Betrachtung ein. Wir hatten früher in der Grafik sehr schön die geplanten Anschaltzeiten der Devices mit drin.
Vllt. gelingt uns soetwas zukünftig wieder, mal schauen.

[ch.eick]

Das war nur ein Beispiel Christian. Diese SMA-Dosen beinhalten eine Energiemessung und dadurch sieht SMA den Verbrauch des angeschlossenen Devs über die Laufzeit (z.B. Trockner) und der geht mit in die Betrachtung ein. Wir hatten früher in der Grafik sehr schön die geplanten Anschaltzeiten der Devices mit drin.
Vllt. gelingt uns soetwas zukünftig wieder, mal schauen.

Da bin ich dabei Das ist eine gute Idee, die in Richtung von NILM geht.
Ich versuche schon geraume Zeit eine Formel zu finden, die aus den Leistungs Messwerten (bei mir im Abstand von 1 Minute) ein Lastprofil erstellt. Ich stelle mir eine Art HASH Code vor, der dann verglichen werde könnte.
Es gab mal im mp3 Umfeld eine Datenbank, die mit dem HASH von mp3 Dateien die Ermittlung des id3 Tags ermöglicht, was bei mir zu 90% funktioniert hatte.
Es gab auch eine Aussage, zu wieviel Prozent es passen würde, was bei Leistungskurven ziemlich gut wäre

EDIT: Hier habe ich noch eine schöne Erklärung zu HASH gefunden, wo auch der Vergleich von Daten angesprochen wird.
Somit müsste ich aus der Datenbank nur die Leistungswerte eines Gerätes separieren und diese dann als "Datei", als Datensammlung mit einem HASH versehen, der dann als Referenz verwendet wird.
Wie dann ein Vergleich mit einem Trefferergebnis in z.B. % aussehen würde kann ich mir noch nicht vorstellen, da ja vom Strom Zähler eine Überlagerung von verschiedenen Geräten kommen würde.

VG
   Christian