Leistungsprognose für Wechselrichter

[mcp]

...ja das ist so gewollt. Erst nach Produktionsende steht fest wie hoch die Abweichung ist.

das war im Screenshot nicht zu sehen, aber auch für den Fall wird's ein Mouseover Tooltip geben

[Elektron]

Wobei ab dem Moment wo die Produktion die Prognose überschreitet könnte man die ja als Prozentwerk anzeigen.
Denn der Wert wird im laufenden Tag ja nicht mir fallen.
Ob es Sinn macht den Wert anzuzeigen solange die Prognose (noch) nicht erreicht wird, kann man diskutieren. Ich fände das besser als ,,den ganzen Tag" keinen Wert angezeigt zu bekommen.

Hat es einen bestimmten Grund warum der Wert negativ angezeigt wird, obwohl es ja eigentlich positiv ist

Vielen Dank und Grüße Michael

[DS_Starter]

Wobei ab dem Moment wo die Produktion die Prognose überschreitet könnte man die ja als Prozentwerk anzeigen.

Macht sich allerdings ziemlich schlecht wenn man den Wert loggt um ihn grafisch oder per DbRep aus einer DB auszuwerten.
Es ist ja auch nicht gesagt dass die Prognose überhaupt überschritten wird.

Hat es einen bestimmten Grund warum der Wert negativ angezeigt wird, obwohl es ja eigentlich positiv ist

Kommt ja auf die Perspektive an. Wenn zu wenig prognostiziert wurde als erzeugt, dann ist die Abweichung negativ (wie implementiert). Das korrespondiert auch mit den Korrekturfaktoren die in diesem Fall nach oben korrigiert werden.
Das heißt die Erzeugung ist der Bezugswert. Man kann es auch anders sehen und die Prognose als Bezugswert benutzen ... ist eben eine Frage der Perspektive. 

[xerion]

Moin zusammen!

Habe ich eine Möglichkeit die beiden Grafiken nebeneinander, anstelle untereinander zu bekommen?

[DS_Starter]

Moin,

nein das ist aktuell nicht möglich.
Vllt. kommt es später mal ...

LG,
Heiko

[xerion]

Ich habe noch eine Anzeige Problem beim SoC. Kann es sein, das der nur auf ohne Nachkommastellen ausgelegt ist?

[mcp]

ja, Fix kommt dafür, habe ich bei mir bereits ebenso eingebaut.

[DS_Starter]

Guten Abend,

im contrib liegt die neue V 0.72.5

Was hat sich alles getan:

* es werden keine SolCast Percentile mehr gewählt sondern nur noch das 50er Percentil genutzt mit Korrekturfaktoren falls
   die Autokorrektur benutzt wird. Dadurch kann filigraner korrigiert werden falls nötig. Dadurch entfallen die 
   pvSolCastPercentile_XX Setter, man muß als User aber nichts aktiv tun nach dem Update

* es werden alle verfügbaren API Requests ausgenutzt. Bisher sind oft (immer ?) einige (2 ?) am Abend übrig geblieben

* das Attr graphicBeamWidth hat mehr verfügbare Werte im Slider

* der Neigungswinkel moduleTiltAngle hat weitere Zwischenwerte bekommen und kann nun mit diesen Werten
   gesetzt werden: 0,5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90

* die Consumption Forecast ist korrigiert

* weitere kleinere Fixes

Edit: gerade noch die Lage für die Ladung der Batterie korrigiert damit sie nicht hineinragt.

LG,
Heiko

[Skusi]

Hallo, und erstmal großes Lob und Respekt an DS_Starter für die Erschaffung dieses Moduls !

Ich beschäftige mich nun auch schon einige Wochen mit dem Modul und weite die Möglichkeiten Schritt für Schritt in meinem System aus.
Nun habe ich meine Waschmaschine und den Geschirrspüler auch angebunden und als consumer angelegt. Funktionier auch alles tadellos. Allerding versteh ich die Logik hinter der Zeitlich besten Einplanung nicht. Mein Geschirrspüler sieht z.B so aus:

Code Auswählen Erweitern

Geschirrspueler icon=scene_dishwasher@orange type=dishwasher mode=must power=2300 swstate=state:on:off on=on off=off auto=automatic etotal=energy:kWh:5 pcurr=power:W:5

Abgesehen davon das die Vorhersagen noch weit von zutreffend sind, was sicherlich an DWD liegt, plant das Modul nie wirklich in den vorhergesagten Ertragsspitzen ein.

Beispiel heute: siehe Bild

12-14 Uhr sind vorhergesagte Spitzenzeiten, aber eingeplant wird zwischen 9 und 12 Uhr.

Hab ich was falsch konfiguriert, oder falsch verstanden ?

[DS_Starter]

Guten Abend,

Hab ich was falsch konfiguriert, oder falsch verstanden ?

Nein, sieht alles soweit gut aus.

Die Vorgehensweise ist etwa folgende bezogen auf einen Verbraucher mit mode=must ...
Zunächst wird nicht die max. PV Vorhersage allein herangezogen, sondern der max. zu erwartende PV Überschuß. D.h. es wird für jede relevante Stunde der erwartetete Überschuß (Diff Erzeugungsprognose - Verbrauchsprognose) gebildet. Dadurch findet man die Stunde des max. Überschusses.
Nun wird die angenommene (internes Schema im Modul) oder die explizit angegebene mintime halbiert und dieser Wert von der Stunde des max. Überschusses abgezogen, sodass der geplante Consumer Start und Consumer Finish die  Stunde des max. Überschusse umschließt. Die Standard mintime für einen dishwasher sind 3 Stunden.

Nun kann es sein, dass du in der Vergangenheit üblicherweise über Mittag ohnehin größere Verbraucher eingeschaltet hast. Dann prognostiziert das Modul  für diese Stunden einen hohen Verbrauch der uU die PV Erzeugung aufbraucht.
Man sieht diese Werte in der aktuellen Version des Moduls mit "get ... nextHours" in dem Schlüssel confcEx.

Es kann natürlich nicht ausgeschlossen werden, dass ich irgendwo noch einen Fehler in der Logik habe.
Man kann den Ablauf der Einplanung verfolgen (In der Zeit 00:00 - 01:00) wenn man sich debug=1 einschaltet.
Die Ausgabe müsste man sich mal genauer anschauen.

Es sind  viele Informationen die im Logfile stehen. Ich werde den Debug-Modus noch etwas untersetzen damit man sich nur bestimmte Vorgänge im Modul genauer anschauen kann. Die Informationen sind für die herkömmlichen verbose Level einfach zu viel und unübersichtlich.

[Skusi]

OK, danke für die Einblicke.

Allerdings denke ich das es zwar hilfreich sein kann die Verbräuche vorherzusagen und mit in das Planen einzubeziehen, aber je nach Haushalt kann das auch ein zu hoch gegriffenes Ziel sein.
In meine Fall hätte ich gerne die Möglichkeit das Einbeziehen der vorausgesagten Verbräuche auszuschalten. Ich denke das sich für unseren Haushalt nicht verlässlich vorhersagen lässt wieviel Strom wir zu einer bestimmten Stunde verbrauchen. Das Modul wird das nie richtig treffen.

Vielleicht wäre es denkbar ein Attribut einzufügen, womit man entscheiden kann ob der prognostizierte Verbrauch mit in die Planung einfließen soll, oder nicht.

[DS_Starter]

Vielleicht wäre es denkbar ein Attribut einzufügen, womit man entscheiden kann ob der prognostizierte Verbrauch mit in die Planung einfließen soll, oder nicht.

Gerne. Ich muß nur darüber nachdenken ob der default in- oder exclude der Verbrauchsprognose ist.
Ich würde zunächst das Debugging umbauen, ein solches Attribut einbauen und dir zum Test in deiner Umgebung zur Verfügung stellen.

[mcp]

Moin Heiko,

heute wurde das Solcast API Limit bei mir bereits bei 47 erreicht, bin auch selber Schuld, weil ich paar manuelle Abfragen gemacht habe

Allerdings hat SolarForecast danach noch 3 weitere Abfragen probiert bis es auf 50 war und dann aufgehört.

IMHO können bei API Limit überschritten alle weiteren Solcast API Abfragen aufhören, da man eh bis kurz nach 0 Uhr an keine weiteren Daten mehr kommt.

[mcp]

Moin Heiko,

Auch zu dem Thema hab ich Code Änderungen, welche deutlich mehr Klarheit reinbringen (finde/hoffe ich )
...
Edit: anbei schon mal 2 Screenshots von meinen sichtbaren Änderungen.

anbei nun endlich meine Code Änderungen.

Ich hab's alles aufgedröselt, sind 16 Patches.

00. whitespace cleanup (ich hasse Leerzeichen wo sie nicht hingehören )
      spart übrigens ca. 15 KB (ja, fünfzehn Kilobyte Modulgröße)
      und das sind nur Leerzeichen am Ende, nicht mittendrin oder am Anfang oder so.
      hier kannst du auch einfach selber sed aufrufen (sed -i 's/[[:space:]]*$//' 76_SolarForecast.pm), der Patch hätte sonst 509 KB, den ich erstmal nicht angehängt habe.

01. Schreibfehler: fullFilled muss fulFilled sein

02. diverse Hilfe-Text Fixes
      - Schreibfehler behoben
      - ein paar Sachen ergänzt
      - einige Optionen, welche 2 Spalten haben, klebten aneinander

03. maximale Verbraucher auf 12 erhöht

04. ein paar Schreibfehler & Formatierungen korrigiert

05. consumerXX Infos (Name & States) in eigene Readings erweitert/gesplittet

06. state Ausgaben von Verbrauchern: Gänsefüßchen (") durch Hochkommata (') ersetzt da DOIF's Event Processing damit ein Problem hat

07. Language Support
      - neues Attribut "ctrlLanguage" um nur die Sprache des Moduls zu ändern
         default ist Englisch, änderbar mit var $deflang

08. Verbraucher Link
      - neues Attribut "consumerLink" damit man in der Übersicht der Verbraucher per Click direkt auf das jeweilige Device kommen kann

09. Bugfix für Batterie-Lade-Text (Forum #2090)
      - Icon ein bisschen verschoben damit das alles nicht so gedrungen aussieht
      - das Problem war text-anchor middle, daher war's ohne Komma ok, mit Komma war der Text im Icon drin.

10. PV Abweichung/Deviation
      - sieht IMHO besser aus
      - diverse Mouse-Over-Tooltips in Deutsch/Englisch

11. Header mit <hr> unterteilen, fördert IMHO die Lesbarkeit enorm

12. Mehr Freiraum zwischen den beiden Verbraucher Reihen

13. Plantcheck Pimp-Up
      - sieht nun nicht mehr so gedrungen aus und ist übersichtlicher
      - Hinweis Text nur noch sichtbar, wenn wirklich mindestens 1 Hinweis existiert
      - timestamp-on-change-reading in die Checks mit aufgenommen
      - Überprüfung der Sprache aus Plantcheck rausgenommen.
        Ich sehe da keinen Mehrwert oder überhaupt einen Sinn darin, dem User zu
        sagen, er möge es bitte auf Deutsch stellen. Passt für die englischsprachigen
        FHEM User so gar nicht - ich hab's seit paar Tagen auf Englisch stehen und
        sieht genauso gut aus wie auf Deutsch
      - API Krams eigene "Rubrik" gegeben

14. Design Optimierungen
      - mehr Freiraum zwischen diversen Anzeigen, fördert die Lesbarkeit
      - Icons ein bißchen verschoben
      - viewbox Änderung & abhängig von flowGraphicShowConsumerRemainTime 0|1
         - bei 1 sieht es sonst unten zu gedrungen aus

15. Verbrauch unter den jeweiligen Verbrauchern zentriert
      - je größer der Verbrauch desto asymmetrischer war es bisher, driftete nach rechts ab
        ist zwar nicht perfekt und auch eine ziemliche Herumhackeritis aber fürs erste erfüllt es den Zweck

16. 2 englische Wörter ausgetauscht


Die Patches bauen in der Reihenfolge aufeinander auf - Du kannst natürlich auch gerne alles in einem haben

--
ciao, Marc

[DS_Starter]

Danke Marc,

schaue ich mir im Einzelnen der Reihe nach an .... jedoch ergeben sich addhoc ein paar Statements ...

whitespace cleanup (ich hasse Leerzeichen wo sie nicht hingehören )

Und ich hasse eine Formatierung ohne Leerzeichen wo nichts sauber untereinandersteht und ich Augenkrebs bekomme 
Da nehme ich lieber Leerezeichen in Kauf die angemeckert werden. (die 15 kb spendiere ich)

05. consumerXX Infos (Name & States) in eigene Readings erweitert/gesplittet

Wozu ? Bringt nur noch mehr Readings. Immerhin 36 ! bei 12 Consumern.
Sorry, den Sinn sehe ich nicht.

07. Language Support
      - neues Attribut "ctrlLanguage" um nur die Sprache des Moduls zu ändern
         default ist Englisch, änderbar mit var $deflang

Weshalb tut es das globale language nicht ?

      - Überprüfung der Sprache aus Plantcheck rausgenommen.
        Ich sehe da keinen Mehrwert oder überhaupt einen Sinn darin, dem User zu
        sagen, er möge es bitte auf Deutsch stellen.

Sehe ich nicht so. Es ist nur ein Hinweis und es wird dem User auch nicht gesagt er möge umstellen, sondern nur wenn er umstellt bekommt er die Ausgaben in deutsch, mehr nicht.

LG,
Heiko