76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[kask]

Ich denke die Volleinspeisung könnte man schon mit einbringen. Alleine um zusehen was so passiert. War ich vorher auch nicht von angetan aber mittlereweile sehe ich das eher wie pah und könnte mir das wie folgt vorstellen.

Mit den DC Ladereglern könntew man eventuell genauso vorgehen. Die zielen aber auf die batterie ab.Die sonne könnte da generell durch einen "generator ersetzen und die Producer bekommen Sonne,generator,windrad was auch immer es halt ist.

[DS_Starter]

Wenn man eine Direkteinspeiseanlage zusätzlich zu einer Überschußeinspeiseanlage in einem zusammengehörigen Kontext (sagen wir dem Grundstück) betreibt wäre es m.M. nach ein Muß bzw. ein eindeutiges Identifikationsmerkmal dass die Direkteinspeiseanlage einen eigenen Generator (Module + Inverter) hat.

Weitergedacht wäre es evtl. ein Lösungsansatz wenn im Modul die Möglichkeit gäbe mehrere Inverter anzugeben mit einer optionalen Klassifizierung als Direkteinspeiser. Deren Anteil kann man dann in der Flußgrafik separat darstellen.
Muß man nochmal drüber nachdenken ... 

[DS_Starter]

@kask, dein Bild gefällt mir. Sieht gut aus.
Aber auch hier muß ich zunächst wie zuvor geschrieben den Anteil der Direkteinspeisung kennzeichnen/separieren.
Evtl. reicht hier auch die Möglichkeit im Modul mehrere Netzzähler angeben zu können (Direkteinspeisezähler, Hauszähler,...). Das würde auf das erwähnte Meßkonzept einzahlen.

Mit den Ladereglern ist es ähnlich. Ich müßte neben den Attr setupInverterDev auch ein oder mehrere setupSmartloaderDev einführen um deren Energieanteile messen und demzufolge darstellen zu können.

[kask]

Ich glaube du hast folgenden Satz nicht Verstanden oder ich habe mich nicht genau genug ausgedrückt.

Das könnte man aber Lösen indem man dem "Producer" eventuell ein "gridonly" attribute spendiert. Damit und einem weiteren "ignoreProducerForPlanning" könnte man dann bei der Consumerschaltung zudem reagieren ob diese erzeugte Leistung mit in die "Haus"-Einspeisung wirkt und als Nutzenergie zur Verfügung steht.

attr "gridonly" sagt das das Icon direkt auf das Netz zeigt.
attr "ignoreProducerForPlanning" gibt an das man den Wert aus dem Erzeuger mit gridonly nur anzeigt und nicht verrechnet um die Consumerplanung zu gestallten.

Sozusagen somit nur eine Anzeige im Flow.

Edit.: @DS_Starter genau so wie gerade von dir geschrieben.

[kask]

Das Haus symbol wurde ich gegen das "measure_power" ersetzen.

Einen generator habe ich nicht gefunden in den standard icons.

[DS_Starter]

Ich glaube du hast folgenden Satz nicht Verstanden oder ich habe mich nicht genau genug ausgedrückt.

Hatte ich gelesen, verstanden aber im Nachdenken schon wieder vergessen. 

Ja, ist eine gute Idee. Trotzdem braucht das Modul weitere "Inverterdevices" weil ich in dem Fall auch eine Zuordnung zu den angegebenen PV-Strings vornehmen muß. Der Direkteinspeiser hat ja auch eigene PV-Generatoren.
Alternativ wäre es vermutlich auch eine praktikable Lösung den erwähnten separierenden Zählersatz umzusetzen. Eine getrennte Betrachtung (mehrere Inverter + PV-Strings) ist allerdings zielführender wenn wir die sicherlich nicht so selten vorkommende Überkonfiguration (String Peakleistung größer als Inverter Maxleistung) berücksichtigen. Dann wäre die Prognose genauer möglich.

Die allgemeinen setupOtherProducerXX bekommen keinerlei PV-Anteile zugeordnet und deren Energie nicht in die Betrachtung PV Vorhersage/realer Ertrag integriert. Deren Anteile sind in der Prognose nicht kalkulierbar.

Stand jetzt würde ich sagen die Einführungen weiterer setupInverterDev und die Einführung eines optionalen "gridonly" wäre ein guter Weg. Dann braucht es aber auch noch einen separaten Netzzähler (Prognose/Ist Auswertung). Ich muß natürlich noch Details lösen wie die Zuordnung von Strings, die momentan alle auf das setupInverterDev einzahlen.

[DS_Starter]

Das Haus symbol wurde ich gegen das "measure_power" ersetzen.

Einen generator habe ich nicht gefunden in den standard icons.

sani_garden_pump? ... könnte auch als Generator durchgehen.

[Prof. Dr. Peter Henning]

Das Bild von kask finde ich (sorry...) nicht optimal, denn es enthält mehrere geschlossene Schleifen. Dabei wird nicht so ganz klar, in welcher Richtung der Energiefluss geht. Die Animationen helfen da auch nur dann, wenn man kein statisches Bild betrachtet.

In meinem Diagramm ist das etwas anders gelöst:

1. Keine geschlossenen Schleifen
2. Anzeige der Energieflussrichtung sowohl durch Bewegungsrichtung der Streifen, als auch durch Pfeilrichtung
3. Solar erzeugte Energie: grüne Streifen, Netzenergie: rote Streifen. Schwarze Streifen, wenn kein Fluss.

Frage: Wieso Generator? Ist das ein BHKW?

LG

pah

[DS_Starter]

Frage: Wieso Generator? Ist das ein BHKW?

Ja, passt nicht zusammen -> "Das Haus symbol wurde ich gegen das "measure_power" ersetzen."
@kask, Das "Haus" ist kein Generator in dem Sinn sondern ein Symbol für einen zentralen Sammel/Verteilpunkt.
Vllt. passt das Icon "flux" als neutrale Darstellung ganz gut.

[kask]

Der Generator ist gedacht als das jetztige Sonnensymbol. Darüber dann eine Sonne für die Producer.
Oder ein generator für ein Diesel/Schweröl/Gas Aggregat.
Als BHKW würde ich einen Kessel nehmen. Wird ja meist in dem Fall thermisch aufbereitet.
Und als PV halt die sonne.

Das mit den Animationen ist wirklich als statisches Bild doof. Da müßte man dann die Vorzeichen des Gerätes beachten.
Aber ein animierter Pfeil sollte auch schick sein.

[DS_Starter]

Der Generator ist gedacht als das jetztige Sonnensymbol.

Verstehe. Darüber die Producer, unter anderem die Sonne für PV-Generatoren.

Für die allgemeinen Producer nimm irgendeinen Platzhalter. Ich werde in den setupOtherProducerXX einen Schlüssel vorsehen mit dem jeder User das ihm genehme Symbol einrichten kann, Windrad oder sonst etwas.

[kask]

Die Pfeile sind ja eigentlich nur im Zentrum interresant da es dort (aber nur) Teilweise bidirektional ist.
Die Producer sind statisch weil da ist ja nur Energie bereitstellen.
Die Comsumer auch da nur Energie verbraucht wird.

So wie in dem Anhang in etwa. Die zwei roten Linien sind bidirektional.
Man könnte aber auch die grünen Linien nehmen, dann wäre es auch nicht mehr in zwei Richtungen.
Du darfst diesen Dateianhang nicht ansehen.

[DS_Starter]

Jetzt ist dein Bild zu sehen.
Würde für mich passen. Den mittleren grünen Pfeil vom Netz zur Batterie kann man sich m.M. nach sparen, denn der Fluß würde zunächst in das "Haus" und dann in die Batterie laufen und nicht direkt. Macht sich grafisch auch besser.
Mit roten Linien würde ich sparsamer umgehen. Es suggeriert etwas schlechtes oder "Gefahr".
Die Linien zu den Verbrauchern würde ich orange (ist etwas kräftiger) nutzen wenn Strom fließt oder grau in Ruhe.
Für die rechten beiden Sonnen (sind sicher Smartloader) muß ich im Modul erst noch Voraussetzungen schaffen wie auch für die Direkteinspeisung.

Ich denke wir werden noch etwas Zeit brauchen für das nächste Level.
Für eine Interimslösung bis dahin wäre es gut den Anteil der allgemeinen Producer in der Flußgrafik in das Haus einfließen zu lassen damit es nicht verwirrt wenn jemand z.B. ein BHKW einbindet.

LG

[Prof. Dr. Peter Henning]

Ich habe das bei mir stärker differenziert.
- Sonnensymbol: Anzeige der Strahlungsenergie in kW/m² (geeichter Sensor)
- Symbole für Module/Strings: Anzeige Spannung, Leistung
- Symbole für Wechselrichter: Anzeige Leistung, Energie
- Symbole für Zähler - das was wirklich bei EVU ankommt. Das kann auch bei Volleinspeisung durchaus etwas von der Meldung vom WR abweichen. Genau in diesem Moment sagt mein alter WR 0,25 kW, aber der Einspeisezähler meldet 0,26 kW

Übrigens ist bei mir auch die Pfeilrichtung animiert. Bidirektionale Pfeile gibt es nicht.

Und natürlich ist der Netzbezug rot - den will ich ja nicht haben.

LG

pah

P.S.: BHKW - Motorsymbol?

[schwatter]

Ich selbst nutze nur Fhem, aber die Flowcard in "Home Assistant" finde ich genial.


Gruß schwatter