76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[SebastianM83]

Hallo Heiko,

ich habe schon ne Weile (glaube schon von Anfang an, seit ich SolarForecast nutze) das Phänomen, dass die Höhe der Balkendiagramme (ich nutze alle 3 Balkendiagramme mit je 2 Graphen) manchmal nicht richtig skaliert.

Ich glaube ich habe inzwischen herausgefunden weshalb (Annahme von mir):

Du ermittelst das Maximum der beiden Graphen für jedes Diagramm, um daraus die Höhe der einzelnen Balken zu berechnen. Dabei wird vermutlich der Wert des ersten Balkens nicht berücksichtigt, was zu dem manchmal störenden Verhalten führt. Ist nämlich der erste Balken das Maximum, wächst das entsprechende Diagramm sehr stark in der Höhe, weil die Berechnung mit dem Maximum der anderen Balken rechnet. Da ich meinen Akku regelmäßig aus dem Netz lade und zu Zeiten mit teurem Strompreis (Tibber) nichts aus dem Netz entnehme, kommt es immer wieder dazu, dass ich ewig scrollen muss um den 11kWh Balken entlang zu scrollen, da alle anderen Balken nur wenige Wh hoch sind. Wächst zum Beispiel der Balken der aktuellen Stunde an, kann man zusehen, wie sich die Skalierung anpasst und wieder "normal" wird.
Meine Vermutung ist, dass evtl. ein Array mit Werten nur von Index 1 beginnend ausgewertet wird statt von Index 0 beginnend.

Des Weiteren zeigt die Zeit unter dem ersten Balken immer -01:00, wenn es eigentlich 23:00 vom Vortag anzeigen müsste. Die Balken zeigen aber die korrekten Werte. Ist der erste Balken 22:00 und der zweite Balken 23:00, dann passt alles.

Ich habe die Anzeige auf insgesammt 24 Balken mit 6h Historie eingestellt. Beide Fehler sind aber unabhängig von der Historien-Einstellung und treten auch bei anderen Einstellungen auf, wenn die von mir geschriebenen Bedingungen erfüllt sind.

Ich hoffe die Fehlerbeschreibung hilft dir.

Gruß
Sebastian

EDIT: Rechtschreibfehler und Grammatik korrigiert.

[DS_Starter]

Hallo Sebasian,

das Problem bei "manchmal" auftretenden Phänomänen ist eben dass sie nicht nachvollziehbar sind und dadurch sehr schwer zu finden und zu beseitigen.
Selten habe ich das beschriebene Problem der Anzeige -01:00 verbunden mit einem nicht vorhandenen Wettersymbol bei mir auch schon beobachtet. Es ist aber immer eine unchristliche Zeit zu der ich im allgemeinen keinen Nerv mehr für eine Ursachensuche habe. Leider ist im nachhinein die Ursache nicht mehr zu ermitteln.

Deinen Hinweis bzgl. "Ist nämlich der erste Balken das Maximum, wächst das entsprechende Diagramm sehr stark in der Höhe ..." gehe ich mal nach, wobei ich mir nicht denken kann einen Wert nicht zu berücksichtigen. Aber wer weiß, vllt. ist es eine heiße Spur.

LG,
Heiko

[cs-online]

Hallo cs-online,

wie kann es senn sein, dass hier eine Abweichung von -136 % ausgerechnet wird ? Der Tooltip sagt, mehr produziert als vorhergesagt, wieso ist der Wert dann negativ ?

Das ist eine Frage der Perspektive. Es wurde weniger vorhergesagt als tatsächlich produziert, also negativ (nach unten) verschätzt. Das ist eine Ansichtssache und kann mit

Code Auswählen Erweitern

plantControl->genPVdeviation=...:reverse

umgestellt werden.

Und noch eine Frage: Was ist denn die CO-Abweichung ?

Das ist die Abweichung der Verbrauchsprognose, also der Prognose des Energieverbrauchs im Haushalt.

LG,
Heiko

Danke dir, das macht es klarer

Grüße

Christian

[lorisurfen]

Guten Morgen,

wie kann man die consumer Steuerung global deaktivieren?
Bei 10 consumer möchte ich wenn die Tage wärmer werden bzw. über Solarthermie die Energie ausreicht nicht alle einzelnen an einem (sonnigen) Tag deaktivieren und am nächsten wieder alle aktivieren (z.B. über mode=mustNot oder auto=0)

Danke und Grüße
Markus

[DS_Starter]

Moin @all,

im contrib liegt ein kleines Update 2.2.2:

- ein einfaches Aufrufen von "get ... pvHistory" entfernt ungültige Tages- und Stundenschlüssel automatisch
- bei der Berechnung der PV-Erträge wird mathematisch korrekt gerundet.
  (Danke an einen User der bemerkt hatte, dass immer nur abgerundet wurde)

Weiterhin wurde der Stundenwechsel bzgl. Inverter etotal dahingehend geändert, dass eine evtl. auftretende Differenz zwischen dem letzten etotal der vorangegangenen Stunde und der ersten etotal-Messung der aktuellen Stunde, die einige Sekunden nach XX:00 stattfindet, berechnet und der vorangegenagenen Stunde als PV-Ertrag nachträglich zugeschlagen wird.

[Parallix]

@Parallix,

Anmerkung: In vielen Fallen ist es nicht möglich, den SOC eines BEVs aus FHEM heraus abzufragen. Was aber praktisch immer festgestellt werden kann ist, ob das BEV auf einen im Fahrzeug eingestellten Ziel-SOC gebracht worden ist. In diesem Fall erfolgt nämlich ein seitens des Consumers (hier BEV) initiiertes Pausieren des Ladevorgangs, welches FHEM via Wallbox signalisiert wird.

So wie ich bisher gelesen habe, ist es in den dargestellten Fällen kein Problem den SoC des BEV auszulesen.

Leider doch! Wenn man auf Cloud-Services der BEV-Hersteller - aus welchen Gründen auch immer - verzichtet, kommt man in vielen Fällen nur über den analogen Weg (Ablesen) an den SOC des Fahrzeugs.

Für eine Betrachtung der Wahrscheinlichkeit eines (zukünftigen) Energieverbauchs durch die KI Prognose ist dieser Wert von grundlgender Bedeutung, es ist ein Kernsignal für "Ladebedarf".
Sollte dieser Wert nicht geliefert werden können muß man einfach festhalten, dass ein Consumer vom Typ "BEV" nicht sinnvoll angelegt werden kann sofern man damit die Prognose-KI füttern möchte.

Der Ladebedarf kann praktisch immer aus dem Neuanstecken eines BEV an der Wallbox abgeleitet werden. Der Energiemenge sollte sich aus früheren Ladevorgängen abschätzen lassen. Hierzu braucht man übrigens nicht einmal eine KI: Jeder Mensch, der ein Kraftfahrzeug führt, kennt seinen üblichen Wochen oder Monatsverbrauch oder kann diesen leicht durch Summation der Tankquittungen bestimmen. Und auch die beste KI kann nicht erahnen, in welcher Woche man z.B. zu einem Konzert fährt, für das man Tickets ergattert hat oder ob und wann man im laufenden Jahr in Urlaub fährt. Hier hilft ein Klick auf einen entsprechenden Button seines FHEM-Dashboards/Control-Panels oder das dortige Eintragen des Urlaubszeitraums sicher und - geeignete Modellierung vorausgesetzt - auch sehr präzise.

Vor diesem Hintergrund macht es sehr viel Sinn, den BEV-SOC als optionalen, nicht aber als zwingenden Parameter zur Behandlung von BEVs in SF aufzunehmen.

[DS_Starter]

Ich habe noch etwas an der contrib nachgebessert und hochgeladen.

[DS_Starter]

@Parallix,

Der Ladebedarf kann praktisch immer aus dem Neuanstecken eines BEV an der Wallbox abgeleitet werden. Der Energiemenge sollte sich aus früheren Ladevorgängen abschätzen lassen.

Das gilt vllt. für den initialen Bedarf, jedoch nicht für eine Fortschreibung die den Ladebedarf kontinuierlich neu bewertet - Unterbrechungen und Phasenreduktionen inklusive.
Außerdem würde es voraussetzen, dass der Ladebedarf bei jeder Ladesession immer nahezu gleich bleiben würde. Das bezweifle ich. Wenn es so simpel ist, braucht es eigentlich keinerlei Messungen mehr und wir schätzen nur noch.

Hierzu braucht man übrigens nicht einmal eine KI: Jeder Mensch, der ein Kraftfahrzeug führt, kennt seinen üblichen Wochen oder Monatsverbrauch oder kann diesen leicht durch Summation der Tankquittungen bestimmen.

Wenn es so einfach ist, kann man ein userReading mit diesem Wert anlegen welches ich konsumieren kann.
Dann steht auch der Pflichtangabe nichts im Wege.

Und auch die beste KI kann nicht erahnen, in welcher Woche man z.B. zu einem Konzert fährt, für das man Tickets ergattert hat oder ob und wann man im laufenden Jahr in Urlaub fährt. Hier hilft ein Klick auf einen entsprechenden Button seines FHEM-Dashboards/Control-Panels oder das dortige Eintragen des Urlaubszeitraums sicher und - geeignete Modellierung vorausgesetzt - auch sehr präzise.

Kann sie nicht, aber sehr wohl den E-Bedarf der nächsten Stunden schätzen wenn das EV angesteckt ist und der StartSOC sowie die Bat-Kapazität -> Ziel-Soc bekannt ist.

[Parallix]

...

Vielleicht bin ja der einzige mit o.g. Problem. Dann werde ich ein Dummy schreiben, welches für SF einen fiktiven SOC auf Basis früherer Verbrauchswerte bestimmt.

[DS_Starter]

Nicht traurig sein  ... es ist besser diesen Parameter als Pflichtangabe zu definieren und ein userReading "in Kauf" zu nehmen als irgendwann eine freiwillige Angabe doch als verpflichtend umzuwidmen weil es ohne eben nicht geht. Vielleicht ergibt sich ja später die Möglichkeit über Hilfswerte doch noch das Ziel auf anderem Wege zu erreichen was ich zum aktuellen Zeitpunkt aber noch nicht beurteilen kann.

[DS_Starter]

@Markus,

wie kann man die consumer Steuerung global deaktivieren?

Das geht momentan nicht.
Aber ich kann eine solche Möglichkeit über consumerControl->XXX einbauen wenn gewünscht.

Soll die Möglichkeit gegeben sein, die Steuerungsinfo über ein externes Reading bereitzustellen oder reicht ein klassischer Attributwert dafür?

LG,
Heiko

[Parallix]

...
wie kann man die consumer Steuerung global deaktivieren?
Bei 10 consumer möchte ich wenn die Tage wärmer werden bzw. über Solarthermie die Energie ausreicht nicht alle einzelnen an einem (sonnigen) Tag deaktivieren und am nächsten wieder alle aktivieren (z.B. über mode=mustNot oder auto=0)
...

Den Mode kannst Du SF doch komfortabel über ein Reading zuführen. Da Du den Anlass für einen Wechsel explizit benennst, kannst Du die globale Abschaltung doch prima über einen kleinen Controller erledigen lassen. Vielleicht verstehe ich Deinen Anwendungsfall aber auch nicht. Aktuell verstehe ich ihn so: Aktivierung der Consumer-Einplanung und -Steuerung bei kalten Tagen, Deaktivierung bei warmen Tagen. Richtig?

[lorisurfen]

Das geht momentan nicht.
Aber ich kann eine solche Möglichkeit über consumerControl->XXX einbauen wenn gewünscht.

Soll die Möglichkeit gegeben sein, die Steuerungsinfo über ein externes Reading bereitzustellen oder reicht ein klassischer Attributwert dafür?

LG,
Heiko

Mir würde erstmal ein klassischer Attributwert reichen z.B. consumerControl disable (Wert: 0|1, default: 0)