76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Persuasiv]

Hi Heiko,

ich habe ein Anzeige Problem seit dem letzten Update.
Für mein Tablet UI scheint der Header etwas breit geworden zu sein.

Wie kann man den Akkufüllstand dort einblenden? Besten Dank!

[grappa24]

Wie kann man den Akkufüllstand dort einblenden? Besten Dank!

Das kannst du beim setupBatteryDevXX mit show festlegen
show    Steuerung der Anzeige der Batterie in der Balkengrafik (optional)
    0 - keine Anzeige des Gerätes (default)
    1..3[:top|bottom] - Anzeige des Gerätes in der Ebene 1,2 oder 3 (über|unter) den Balken

[Bozan]

Hab jetzt endlich eine Möglichkeit gefunden, pvIn/pvOut beim Fronius SymoGEN24 korrekt abzugreifen und komme auf Wandlungsverluste von 2-5 %

Hallo Grappa,

welche Werte vom SymoGen24 nimmst Du hier nun für pvIn/pvOut?
Danke für Deine Hilfe,

Bozan

[grappa24]

welche Werte vom SymoGen24 nimmst Du hier nun für pvIn/pvOut?

Code Auswählen Erweitern

pvOut=Inverter_Common_PAC_Value - PowerFlow_Site_P_Akku
pvIn=Inverter_Common_IDC_Value * Inverter_Common_UDC_Value + Inverter_Common_IDC_2_Value * Inverter_Common_UDC_2_ValueAusgangsleistung als Summe aus der Wechselstromleistung PAC des Inverters plus das was aus der Batterie kommt (ist negativ, deshalb minus)
Eingangsleistung als I*U meiner beiden Strings

100% sicher bin ich mir zwar nicht, liefert aber sehr plausible Werte und flow-Grafik; konnte es noch nicht für alle Situationen testen.

[Parallix]

Die letzten Tage habe ich mich mit Strategien zur optimalen Batteriebeladung beschäftigt und mir dabei u.a. auch das Beispiel ,,Dynamische Ladestromsteuerung eines Victron MultiPlus II Chargers mit Pylontech Batterie" angesehen. Hierbei ist mir aufgefallen, dass diese und meine (sehr ähnliche) Lösung nicht optimal ist,  da ein fixer ,,Verkürzungsfaktor Zeit bis Vollladung vor Sunset" verwendet wird.

Was man bräuchte wäre einige wenige gemäß Forecast berechnete Readings:

Eins (Battery_ChargingHoursRemain_XX), das angibt, wie viele Stunden ein BAT-System voraussichtlich (auf Basis einer minimal geforderten Ladeleistung Battery_MinimalTerminationPower_XX) geladen werden kann, die oberhalb der Differenz zwischen prognostiziertem solarem Ertrag und dem prognostiziertem Verbrauch liegt.

Zusätzlich bräuchte man noch ein Reading mit der Anzahl der verbleibenden Stunden ohne Ladeempfehlung (Battery_RemainingHoursWithoutChargeRecommendation_XX).

Insofern möchte ich vorschlagen, die o.g. (special)Readings noch in SF aufzunehmen.

Nachtrag 1: Aufgefallen ist mir auch, dass die bisherige SoC-Prognose in SF von einer Ladung mit maximal zur Verfügung stehenden Überschussleistung ausgeht. Im dem in Wiki beschriebenen Beispiel (,,Dynamische Ladestromsteuerung eines Victron ...") ist dies aber nicht der Fall. Abhilfe könnte eine vom User anpassbare Methode schaffen, die maximalen Ladeleistungen für die restlichen Stunden des Tages liefert.

Nachtrag 2: Dass upSoC und lowSoC Attribute sind, halte ich persönlich für ungünstig. Grund: upSoC ist - nach meinem Verständnis - optimal gesetzt, wenn die BAT nach einen (abendlichen) Dunkelzyklus mindestens noch lowSoc erreicht. Beide Werte  müssten hierzu im Jahresverlauf programmgesteuert angepasst werden können, was vorliegend aber nicht geht. Daher schlage ich vor, beide in ein Reading zu überführen.

[Bison]

Hallo DS_Starter,

ich habe wohl aus versehen was an meinem Forecast Modul verstellt. Leider weiß ich nicht wo ich den Fehler suchen soll. Kannst du mir helfen wo ich in den Einstellungen nachschauen muß?

Mein Forecast sieht wie folgt aus:

[DS_Starter]

Moin,

Ich bin zur Zeit unterwegs und kann erst kommende Woche wieder aktiv sein. Vllt. Kann die Community helfen. Das Bild alleine hilft nicht viel. Da sind mehr Infos nötig wie das verwendete Model, die verwendete Autokorrektur etc. Ich tippe ins Blaue, du hast KI eingeschaltet, aber evtl. Ungenügende Trainingsdaten. Aber kann auch etwas anderes sein. Zumindest vermute ich, du meinst mit der Frage die starken Sprünge in den Stundenvorhersagen.

Lg,
Heiko

[Prof. Dr. Peter Henning]

ich habe wohl aus versehen was an meinem Forecast Modul verstellt. Leider weiß ich nicht wo ich den Fehler suchen soll. Kannst du mir helfen wo ich in den Einstellungen nachschauen muß?

Vlt. einfach auf die configdb umstellen, dann kann man problemlos ältere Versionen - sofern diese auch wirklich liefen - eines Devices wiederherstellen.

LG

pah

[Bison]

Hallo DS_Starter,

ja das mit der KI könnte sein. Ich habe glaube in den Reiter Autokorrektur auf on_complex_ai gesetzt. Heute sind die Lücken kleiner geworden. Also ich beobachte es jetzt mal.

Wücnche dir noch einen schönen #urlaub und danke für das tolle Tool.

Gruß Bison

[Wzut]

@Heiko, ich habe die aktuelle Version auf meinem Testystem und die Batterieanzeige aktiviert.
Da ich an diversen Stellen in meinem System mit Batterie Icons von rot über gelb nach grün spiele und ich vor einger Zeit im Wiki einen uiTable Beitrag von Damian gelesen habe wo er IstWerte von 0 bis 100 in RGB Werte von FF0000 bis 00FF00 umrechnet wollte ich auch so etwas haben.
Anbei eine kleine abgespeckte Sub :

Code Auswählen Erweitern

sub hsv{
  my $cur= shift;
 
  $cur = 100 if ($cur>100);
  $cur = 0   if ($cur<0);
  my $h = $cur * 0.003333;

  my ($r,$g,$b) = Color::hsv2rgb ($h,1,1);

  $r *= 255;
  $g *= 255;

  return sprintf("#%02X%02X00", $r+0.5, $g+0.5);
}
ich habe die in meinem SolarForecast drin und verwende stat "gray" bzw #cccccc hsv($soc) für die History und Forecast Batterie Icons einzufärben.
Der Screenshot ist halt nicht so toll da mein Speicher z.Z immer relativ voll ist

[DS_Starter]

Hallo zusammen,

nun tritt das SF Modul bei mir wieder mehr in den Fokus. Nach einer längeren Abstinenz muss ich mich wieder langsam herantasten was eigentlich der letzte Stand war, an dem ich anknüpfen wollte. Ist schon eigenartig, so lange war die Zeit doch gar nicht. 

@Parallix,
was ich an zusätzlichen Readings liefern kann, stelle ich gern zur Verfügung, muß die Details mir erstmal anschauen.

Nachtrag 1: Aufgefallen ist mir auch, dass die bisherige SoC-Prognose in SF von einer Ladung mit maximal zur Verfügung stehenden Überschussleistung ausgeht. Im dem in Wiki beschriebenen Beispiel (,,Dynamische Ladestromsteuerung eines Victron ...") ist dies aber nicht der Fall. Abhilfe könnte eine vom User anpassbare Methode schaffen, die maximalen Ladeleistungen für die restlichen Stunden des Tages liefert.

Der User kann mit dem Schlüssel pinmax die maximal mögliche Ladeleistung in Watt festlegen. mit welcher die Batterie geladen werden kann. Dieser Wert wird durch die SoC-Prognose auch beachtet.
Der User kann diesen Schlüssel dynamisch setzen mit:

Code Auswählen Erweitern

set ... attrKeyVal setupBatteryDevXX pinmax=<Wert>
D.h., das Script aus dem Wiki kann um einen solchen Befehl ergänzt werden um SF die Einstellung für den Lader mitzuteilen. (Zur Zeit der Erstellung des Wiki-Beitrages gab es attrKeyVal bzw. die aktuelle Bat-Prognose noch nicht).

 

Nachtrag 2: Dass upSoC und lowSoC Attribute sind, halte ich persönlich für ungünstig. Grund: upSoC ist - nach meinem Verständnis - optimal gesetzt, wenn die BAT nach einen (abendlichen) Dunkelzyklus mindestens noch lowSoc erreicht. Beide Werte  müssten hierzu im Jahresverlauf programmgesteuert angepasst werden können, was vorliegend aber nicht geht. Daher schlage ich vor, beide in ein Reading zu überführen.

Eine Überführung in ein Reading ist durch die Verfügbarkeit von attrKeyVal nicht (mehr) nötig.
Der User kann den/die Schlüssel mit:

Code Auswählen Erweitern

set ... attrKeyVal ctrlBatSocManagementXX lowSoc=<Wert> upSoC=<Wert>
dynamisch setzen.

Allerdings ist m.M. nach im Normalfall keine ständige Änderung nötig, da dieser Wert im Prinzip während der Zeiten mit sehr wenig Solarerzeugung einen Mindestvorrat an Energie für den Fall des Netzausfalls in der Batterie belässt. (siehe diesen Beitrag im Wiki).


@Wzut,
deinen Vorschlag kann ich gern in den Standard übernehmen, sodass der User im icon-Schlüssel eine solche Gestaltung wählen kann.

LG,
Heiko

[DS_Starter]

Guten Morgen,

@grappa24,

mir ist beim Lesen der letzten Beiträge aufgefallen:

Ausgangsleistung als Summe aus der Wechselstromleistung PAC des Inverters plus das was aus der Batterie kommt (ist negativ, deshalb minus)

Der Wert pvOut wird vom Modul als PV-Erzeugung gewertet. D.h., wenn dort Batterie-Anteile drin sind, wird deine reale Erzeugung gegenüber der Prognose falsch interpretiert und führt dann zu falschen Korrekturfaktoren etc.

Als Alternative (solange ich keinen Hybridwechselrichter als Typ integriert habe) bietet sich an zwei Inverterdevices im Modul anzulegen, einen PV-Wechselrichter und einen Batterie-Wechselrichter. Durch die Angabe der Readings gemäß der verwendeten Logik in der Attributschlüsseln wird es dann richtig abgebildet und auch richtig interpretiert.

LG,
Heiko

[Persuasiv]

Ich versuche aktuell einen Hybridwechselrichter noch besser in das Modul einzubinden. Die Einrichtung des PV-Inverter hat geklappt, aber beim Einrichten des Batterieinverters sagt er: "An inverter with connected solar cells don't need the key 'ac2dc'. Please delete this key." bzw. "An inverter with connected solar cells don't need the key 'dc2ac'. Please delete this key."

Was mache ich falsch?

[Persuasiv]

ich habe die in meinem SolarForecast drin und verwende stat "gray" bzw #cccccc hsv($soc) für die History und Forecast Batterie Icons einzufärben.
Der Screenshot ist halt nicht so toll da mein Speicher z.Z immer relativ voll ist

Kannst Du die Definition von deinem setupBatteryDev01 (inkl. Icon) posten? Besten Dank!

[DS_Starter]

@Persuasiv,

wenn du einen Batteriewechselrichter definieren willst, musst du strings=none setzen.

Commandref -> Batterie-Wechselrichter    
   Dieses Gerät hat keine angeschlossenen Solarzellen und arbeitet als DC-AC bzw. AC-DC Wandler zwischen einer
   Batterie und dem Hausnetz.
   Die Funktion als Batterie-Wechselrichter wird mit strings=none aktiviert.
   

Das Feature von Wzut bin ich gerade dabei einzubauen. Ihr bekommt nachhher noch die Info wenn die V im Contrib ist zum Ausprobieren.