76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[ch.eick]

vermutlich habe ich es noch nicht wirklich verstanden worum es dabei eigentlich geht. Wenn es nur darum geht einen vorhandenen PV-Überschuß in der WP zu "verbrauchen" kann man doch einen Consumer entsprechen konfigurieren. Vllt. kannst du das Anliegen noch etwas anders formulieren.

Hallo Heiko,
du hast recht - ich habe das ziemlich oberflächlich beschrieben - was ich meine ist das eine WP mit Puffer im Prinzip die gleichen Steuersignale braucht wie eine Batterie die konstant geladen werden soll. Um zu verdeutlichen was ich gern erreichen will habe ich ein typisches Schaltspiel eines Heiztages rangehangen und skizziert was ich gern erreichen möchte. Die Idee kam mir bei der Diskussion zu den zusätzlichen Bat-Readings. Falls meine Gedanken abwegig sind und/oder eine Implementation viel Aufwand verursacht ist es auch kein Problem meine bestehende Logik mit vorhanden Signalen aus SF verfeinern - aber eben ohne KI-Unterstützung

Hallo Gerd,
bei Deiner WP kannst Du sicherlich noch einiges vorab optimieren, bevor Du extern eingreifst. Ich habe 13 Zyklen gezählt, wohingegen ich auf ca.6 Zyklen komme, auch wenn es sehr kalt ist und inklusive WW Bereitung.

1. Sperrzeiten z.B. für WW nutzen
2. Wenn Dein Wohnobjekt wirklich gut isoliert ist und somit die Verlustwäre gering, kannst Du es machen wie ich.
2.1 Tagesanhebung am Tag von 10:00-16:00 Uhr für die Heizung.
2.2 Nachtabsenkung von 16:00-10:00 Uhr
2.3 Die Heizung wird so gegen 18 Uhr abgeschaltet und verwendet somit von 16-18 Uhr noch den Puffer.
2.3.1 An nicht so kalten Tagen schalte ich die Heizung nachts komplett bis 10 Uhr ab
2.3.2 Ist es bitterlich kalt wird die Heizung bereits früher wieder aktiviert und bedient sich aus dem Speicher

Durch die Nachtabsenkung reicht der Speicher oft einige Zeit und wird nur moderat in der Nacht nachgeheizt.
Ab 10 Uhr gehts dann erst richtig los und die WP läuft über Stunden durch, was weniger Taktzyklen bedeutet.

Der PV-Modus wird nur verwendet, wenn die Prognose für den nächsten Tag schlecht ist und es heute PV-Überschuss gibt.
Dadurch wird die Heizung nochmals am Tag intensiever und das WW auf z.B. 60°C angehoben. Wichtig ist jedoch, dass dann
die WP am nächsten Tag mit weniger PV ebenfalls weniger läuft. Bei mir fällt dann zB das WW am nächsten Tag komplett weg.

Das würde bereits die PV Verwendung optimieren, ist jedoch sehr stark vom Energiebedarf Deines Hauses und dem WW Bedarf abhängig.
Mehr gerne als PN.

Ein ständiges aktivieren des PV-Modus geht zu lasten der WP (Kompressor), oder man erzeugt Wärme, die man gar nicht wirklich benötigt.

VG   Christian

[Max_Meyer]

Der PV-Modus wird nur verwendet, wenn die Prognose für den nächsten Tag schlecht ist und es heute PV-Überschuss gibt.
Dadurch wird die Heizung nochmals am Tag intensiever und das WW auf z.B. 60°C angehoben. Wichtig ist jedoch, dass dann
die WP am nächsten Tag mit weniger PV ebenfalls weniger läuft. Bei mir fällt dann zB das WW am nächsten Tag komplett weg.

Das würde bereits die PV Verwendung optimieren, ist jedoch sehr stark vom Energiebedarf Deines Hauses und dem WW Bedarf abhängig.
Mehr gerne als PN.

Ein ständiges aktivieren des PV-Modus geht zu lasten der WP (Kompressor), oder man erzeugt Wärme, die man gar nicht wirklich benötigt.

Hallo Christian,
prinzipiell habe ich die Einstellungen bei mir sehr ähnlich - die Anlage ist (geringfügig) anders - z.B. mache ich das WW nicht mit der WP und die Dämmung ist nach WSVO 95... - Über Details können wir gerne auch anderswo fachsimpeln - ist hier out topic denke ich.
Aber ich wollte mit meiner Initiative auf etwas anderes abzielen - es geht mir primär gar nicht um eine Verringerung der Einschaltspiele der WP, sondern eine Erhöhung der Effizienz. Also wie ich das Maximum an Heizenergie aus der eingesetzten elektrischen Energie produzieren kann (erst einmal ohne PV einzukalkulieren). Im Prinzip gilt ja: je geringer die eingesetzte elektrische Energie ist, desto größer der COB - also die aus der EE erzielbare thermische Leistung - in den Grenzen die die WP erlaubt. (gibt für jede WP Effizienz-Kennlinien oder Tabellen oder Auslegetools) andersherum ausgedrückt wenn ich lange mit gleichmäßiger el. Energie fahre (die man berechnen muss) dann sollte ich nach 8,10,....x h genug Heizenergie produziert haben um über den Tag zu kommen. Theoretisch!!soll das effizienter sein als das bisherige Schaltspiel der WP - je nach Rechnung um 10-20%. Du hat sicher Recht das man Teile davon auch in den Parametern der WP hinterlegen könnte (Heiz- , Mischerkennlinie. Puffertemperatur etc.) das geht nur nur schlecht dynamisch - heute gebe ich nur das PV-Angebot (wattgenau bis zur Obergrenze) an die WP weiter und bin damit gut gefahren so hab ich dafür zuerst in diese Richtung gedacht.
Vielleicht hab ich mich auch verrannt aber generisch gesehen ist die WP wie ein Inverter und der Puffer die dazugehörige Batterie. die notwendige Heizenergie für den z.B. Tag ließe sich ermitteln und durch die Lauf-h und den erwarteten COP teilen und die WP damit füttern. Es wird nicht unnötig thermische Energie erzeugt da der Puffer einen Verlust von 1K/d hat - (nachgemessen) und der Mischer nur die notwendige Wärme entnimmt.
So zumindest die Idee
Gruß Gerd

[mannil]

Guten Abend Gemeinde,

ich habe eine kurze Zwischenfrage.
Warum wird bei der Klimaanlage (ganz rechts) kein Stromfluss dargestellt?
Eingerichtet ist der consumer wie alle andere auch.


VG,
Heiko

Du darfst diesen Dateianhang nicht ansehen.

Edit: Konnte mir selbst helfen. Das Device (Shelly EM) war auf "off". Nach Umschalten auf "on" kommt die Grafik.
Bekomme ich den Schalter "Ein/Aus" Schalter da irgendwie weg? Bei der Wärmepump (Shelly Pro3EM) erscheint der garnicht. Die setsates habe ich im Pana device schon gelöscht.
Du darfst diesen Dateianhang nicht ansehen.

[DS_Starter]

Nabend zusammen,

@Heiko:

Bekomme ich den Schalter "Ein/Aus" Schalter da irgendwie weg?

Ja, mit einem Trick (der eigentlich normalerweise einen Fehler darstellt):
In dem Consumer setzt du weder "on" noch "off" und setzt swstate auf einen on:off-Regex der weder für ein noch aus gültig ist d.h. weder ein noch aus-Zustand erkannt wird, z.B.:

SolCastDummy6 icon=sani_buffer_electric_heater_side type=noSchedule power=1000 swstate=state:bla:bluff

LG,
Heiko

[mannil]

Danke, funktioniert 

[DS_Starter]

Ich habe heute etwas weiter gearbeitet.
In meinem contrib liegt die Version 1.53.0.

In dieser Version ist folgendes umgesetzt:

- die Beschriftung an den Batterien kann wahlweise mit dem Attr setupBatteryDevXX->label angewendet werden

label    Wird die Batterie in der Balkengrafik mit dem Schüssel 'show' angezeigt, kann das Symbol mit dem
    aktuellen SOC-Wert (%) beschriftet werden.
    none - keine Beschriftung (default)
    below - Beschriftung unterhalb des Batteriesymbols
    beside - Beschriftung neben dem Batteriesymbol

- es gibt das neue Reading Battery_ChargeUnrestricted_XX als Ersatz für das Reading Battery_ChargeRecommended_XX.
  Beide Reading werden vorerst beide parallel bereitgestellt damit jeder genügend Zeit hat seine
  eigenen Skripte und Steuerungen auf das neu Reading umzustellen (mich eingeschlossen  ).
  Ich werde mit genügend Vorlauf ankündigen bevor das alte Reading Battery_ChargeRecommended_XX entfernt wird.

- Das Attribut graphicShowDiff wurde durch graphicControl->showDiff ersetzt

- Weil die globalen Attribute latitude, longitude und altitude so wichtig sind, prüft SF ständig deren
  Vorhandensein und teilt dem User einen fehlerhaften Zustand sofort über das Messagesystem mit.
  Man wird also unmittelbar darauf aufmerksam gemacht. Man muß natürlich auch mal die Post öffnen und lesen. 
  Im Anhang seht ihr wie sich das Ganze darstellt.

- Es gibt jetzt auch die Möglichkeit, die Consumer-Schaltersymbole im Paneel auszublenden. Dazu gibt es im consumer-Attribut
  eine Werte-Erweiterung des Key noshow -> 9 - das Schaltelement des Verbrauchers wird in der Verbraucherlegende ausgeblendet.
  Die Werte sind jetzt auch kombinierbar, z.B. noshow=39.


Ich hoffe damit wieder ein Puzzlesteinchen für mehr Zuverlässigkeit gesetzt zu haben.
Nach Download wie üblich restarten.

LG,
Heiko

[DS_Starter]

Hallo Gerd,

wie versprochen habe ich mir deine Sache nochmal durch den Kopf gehen lassen. Ich muß gestehen, da ich keine WP habe, sind für mich manche Dinge nur wage nachvollziehbar. Aber ungeachtet dessen bin ich mir sehr sicher, dass wenn wir eine spezifische Unterstützung für WP einbauen wollen, es nur über einen spezifischen Consumer WP gemacht werden kann der dann mehr Parameter und spezifische Logik eingebaut hat ... so ähnlich wie ich es für das Batteriesystem gemacht habe. D.h. auch dafür würden dann spezifische Steuerungs- und Signalreadings bereitgestellt werden.
Die Schwierigkeit für mich besteht darin, dass ich eben keine WP habe um meine entwickelten Logiken im eigenen Haus zu überprüpfen, im Gegensatz zum Batteriesystem.

Ich gebe aber zu, dass es ein reizvolles und vor allem sicher auch ein Thema mit viel Optimierungspotential wäre. Momentan muß ich da leider passen fürchte ich. 

LG,
Heiko

[TheTrumpeter]

Aber ich wollte mit meiner Initiative auf etwas anderes abzielen - es geht mir primär gar nicht um eine Verringerung der Einschaltspiele der WP, sondern eine Erhöhung der Effizienz. Also wie ich das Maximum an Heizenergie aus der eingesetzten elektrischen Energie produzieren kann (erst einmal ohne PV einzukalkulieren). Im Prinzip gilt ja: je geringer die eingesetzte elektrische Energie ist, desto größer der COB - also die aus der EE erzielbare thermische Leistung - in den Grenzen die die WP erlaubt. (gibt für jede WP Effizienz-Kennlinien oder Tabellen oder Auslegetools) andersherum ausgedrückt wenn ich lange mit gleichmäßiger el. Energie fahre (die man berechnen muss) dann sollte ich nach 8,10,....x h genug Heizenergie produziert haben um über den Tag zu kommen. Theoretisch!!soll das effizienter sein als das bisherige Schaltspiel der WP - je nach Rechnung um 10-20%. Du hat sicher Recht das man Teile davon auch in den Parametern der WP hinterlegen könnte (Heiz- , Mischerkennlinie. Puffertemperatur etc.) das geht nur nur schlecht dynamisch - heute gebe ich nur das PV-Angebot (wattgenau bis zur Obergrenze) an die WP weiter und bin damit gut gefahren so hab ich dafür zuerst in diese Richtung gedacht.

Ich habe meine Wärmepumpe so eingestellt, dass die Tagestemperatur etwas höher als meine eigentliche Wunschtemperatur ist & die Nachttemperatur dafür etwas niedriger. Zusätzlich ist die Zeit für den Tagbetrieb auf 0930-1500 Uhr eingestellt.
In Kombination mit einer großen Speichermasse & einem sehr gut thermisch isolierten Gebäude läuft die Wärmepumpe damit - von einzelnen Ausnahmen abgesehen - in der finsteren Jahreszeit nur noch tagsüber. Da meine Wärmepumpe nicht modulieren kann, hole ich damit in erster Näherung bereits das Maximum an möglichem Eigenstromverbrauch heraus. Zusätzlich sind die Lufttemperaturen tagsüber tendenziell höher, sodass sich das auch positiv auf den COP auswirken müsste.
Während der Übergangszeit mit geringem Heizbedarf kann es mal passieren, dass während einer wolkigen Phase geheizt wird, obwohl später ev. noch ein Sonnenfenster käme. Diese Unschärfe habe ich bisher nicht abgebildet.

Warmwasserbereitung über die Wärmepumpe habe ich über SF durch Betriebsartenumschaltung realisiert.

[Wzut]

Wettersymbole nicht ausreichend voneinander unterscheidbar. Unterschiedliche Farbgebung Wolken/Sonne könnte das verbessern

@Heiko, dazu hatte ich gestern noch eine Idee : Man könnte doch die Wettericons in drei Gruppen einteilen ->
a. Icons mit guter Ertragsprognose  -> Sonnig / wenig Wolken , etc.
b. Icons für schlechtere Prognosen -> Regen , viele Wolken , etc.
c. die ganzen Nacht Icons , bzw. alles was nicht a. oder b. ist.

Bei der Ausgabe wird die Gruppe a. mit 100% Hellogikeit dargestellt. Gruppe b. um ein paar Prozent reduziert und Gruppe c. nochmal etwas dunkler. Das ist zwar dann immer noch keine unterschiedliche Farbgebung, aber eine Lösung die mit den heutigen Bordmitteln relativ leicht machbar wäre.

[DS_Starter]

Moin Wzut,

das wäre zwar möglich, aber ich glaube das ist nicht das was unsere User als Fortschritt sehen würden, mich eingeschlossen .

Vllt. macht es Sinn, dass wir bei OpenAutomation schauen, ob es einen kompletten Satz gut passender SVG-Wettericons gibt und die in FHEM laden? Die sind doch frei verwendbar und könnten uns so mit relativ wenig Aufwand einen schönen Satz zusammenstellen, oder?
Nur mal als Idee ...

LG,
Heiko

[DS_Starter]

Bekomme ich den Schalter "Ein/Aus" Schalter da irgendwie weg?

Es gibt jetzt auch die reguläre Möglichkeit, die Schaltersymbole auszublenden.

Dazu gibt es im consumer-Attribut eine Werte-Erweiterung des Key noshow -> 9 - das Schaltelement des Verbrauchers wird in der Verbraucherlegende ausgeblendet. Die Werte sind jetzt auch kombinierbar, z.B. noshow=39.

Liegt im contrib.

[Max_Meyer]

Die Schwierigkeit für mich besteht darin, dass ich eben keine WP habe um meine entwickelten Logiken im eigenen Haus zu überprüpfen, im Gegensatz zum Batteriesystem.

Ich gebe aber zu, dass es ein reizvolles und vor allem sicher auch ein Thema mit viel Optimierungspotential wäre. Momentan muß ich da leider passen fürchte ich

Hallo Heiko,
das ist OK - kein Problem - es ist so schon aller Ehren wert was du hier ablieferst!

Und du hast Recht da muss man sich langsam annähern - schließlich soll es doch warm bleiben im Winter . Ich wollte diese Optimierung eigentlich diese Heizsaison angehen falls sich die Prios nicht verschieben  - erstmal mit Bordmitteln in der WP (wie ch.eick geschrieben) und zusätzlich über aus der Vergangenheit abgeleitete Vorgaben - kann die WP ziemlich umfangreich fremd steuern - bei Bedarf - falls das erfolgreich wird, können wir ja noch mal reden - bei Interesse.
Aber eines würde ich gern noch noch mal diskutieren - das ist der saisonale Einfluss der WP - wenn ich mir den Elektroenergiebedarf im Haushalt übers das Jahr ansehe dann liegt der Verbrauch bei ca. 12.000 kWh davon ca. 3000 kWh sind die WP --> während (fast) alle anderen Verbraucher kontinuierlich, über das ganze Jahr verteilt, konsumieren - ist die WP (im wesentlichen) nur reichlich 3 Monate aktiv - verbraucht in der Zeit aber 25% der Jahresenergiemenge - hab mal so einen BSP-Tag im Winter mit reingehangen - trotz  E-Car-laden dominiert der WP-Bedarf. So wie ich das verstehe verfälscht das dann die Prognose für die anderen Verbraucher?
Meine Frage wäre also ist es möglich/sinnvoll consumer als saisonal zu kennzeichnen - oder merkt das KI sowieso?
Gruß Gerd

[Max_Meyer]

Ich habe meine Wärmepumpe so eingestellt, dass die Tagestemperatur etwas höher als meine eigentliche Wunschtemperatur ist & die Nachttemperatur dafür etwas niedriger. Zusätzlich ist die Zeit für den Tagbetrieb auf 0930-1500 Uhr eingestellt.
In Kombination mit einer großen Speichermasse & einem sehr gut thermisch isolierten Gebäude läuft die Wärmepumpe damit - von einzelnen Ausnahmen abgesehen - in der finsteren Jahreszeit nur noch tagsüber. Da meine Wärmepumpe nicht modulieren kann, hole ich damit in erster Näherung bereits das Maximum an möglichem Eigenstromverbrauch heraus. Zusätzlich sind die Lufttemperaturen tagsüber tendenziell höher, sodass sich das auch positiv auf den COP auswirken müsste.
Während der Übergangszeit mit geringem Heizbedarf kann es mal passieren, dass während einer wolkigen Phase geheizt wird, obwohl später ev. noch ein Sonnenfenster käme. Diese Unschärfe habe ich bisher nicht abgebildet.

Hallo
Auch wenn bei mir die Situation leicht anders ist - ich hab eine WP mit Erdsonde und so immer (fast) konstante Zulauftemperaturen, die Dämmung ist WSVO 95, WW macht nicht die WP.. habe ich das ähnlich - über Zeitprogramme in der WP eingestellt. An Tagen ohne Sonne wird so nur die Wärme erzeugt die ich benötige (denke ich zumindest ) Zusätzlich nutze ich den Puffer (mit Offset) wenn es einen Solarüberschuss gibt. Der Plan jetzt ist das Verhalten der WP so zu strecken das ein ähnliches Schaltspiel herauskommt wie du es beschreibst  nur eben angepasst auf die höhere Heizleistung pro m²
Gruß Gerd

[DS_Starter]

Hallo Gerd,

Aber eines würde ich gern noch noch mal diskutieren - das ist der saisonale Einfluss der WP ... verbraucht in der Zeit aber 25% der Jahresenergiemenge - hab mal so einen BSP-Tag im Winter mit reingehangen - trotz  E-Car-laden dominiert der WP-Bedarf. So wie ich das verstehe verfälscht das dann die Prognose für die anderen Verbraucher? Meine Frage wäre also ist es möglich/sinnvoll consumer als saisonal zu kennzeichnen - oder merkt das KI sowieso?

Ja, das ist etwas problematisch. Zur Zeit gibt es für die Verbrauchsprognose keine KI-Unterstützung. Das will ich erst noch implementieren. Du siehst auch mit "get ... valDecTree aiRawData" dass es in den Daten noch keine separierten Felder von Verbrauchern enthalten sind.
Momentan würde ich dir raten einzustellen:

- plantControl->consForecastIdentWeekdays=1
- plantControl->consForecastLastDays=4 (oder kleiner)
- im WP-consumer: exconfc=1  (siehe auch im Wiki)

Dadurch werden nur die zeitnah in der pvHistory gespeicherten Daten genutzt und das Modul kann die Anteile der WP einkalkulieren bzw. würden sie jetzt im Sommer nicht zum Tragen kommen.
Wir werden sehen was meine KI-Implementierung leisten kann (wenn ich dazu komme...).

LG,
Heiko