Photovoltaik Eigenverbrauch,Bilanz,Prognose (Kostal Plenticore; KSEM; BYD HV)

[ch.eick]

Moin zusammen,
da ich nun schon mehrfach per PN angeschrieben wurde und es bei den Benutzernamen/Passworten fragen gegeben hat, kommt hier nochmal ein Versuch der Aufklärung:

Code Auswählen Erweitern


in FHEM kann man den Device Namen frei wählen, wenn man meine Implementierung nachbaut, wäre es gut den Namen beizubehalten.

z.B. PV_1 oder WR_1, da ich in der Zwischenzeit bereits einen zweiten Wechselrichter habe. Meine heißen somit jetzt WR_1 und WR_2.
Manchmal stellt sich heraus, dass der Device Name oder readings doch besser anders genannte werden sollten, dann beschreibe ich im
Forum, wie man das ändern kann und Dman könnte dann fast 1zu1 die Komandos übernehmen.

>>  dass ich Dich richtig verstanden habe <Passwort> = key auf dem Gehäuse

Genau so ist es.

>>  Device Name wäre ablesbar auf der internen Wechselrichter Seite?  (Problem mein Plenticore blockiert Unterstriche)

Den Netzwerk Namen im Wechselrichter kann man so lassen wie er ist. Bei zwei Wechselrichtern sollte man unterschiedliche Namen wählen. Hierbei habe ich WR-1 und WR-2 gewählt, das der "_" und auch Umlaute nicht genommen werden hängt mit der Namensauflösung im TCP/IP vorwiegend in Windows Netzwerken zusammen.

>> und für "user" muß ich den aus dem Portal (..@ .. ) oder den "Anlagenbetreiber" nehmen  ?

Am Plenticore verwendt man für die Oberfläche den "Anlagenbetreiber". Dies ist eine interne Rolle des Benutzernamens "user", was man dort aber nicht sehen kann.
Für die Anmeldung mit dem WR_1_API Device im FHEM wird deshalb auch der Benutzername "user" verwendet.

Die Anmeldung im Portal oder mit der Handy APP ist eine vollständig separate Angelegenheit. Dort hat man einen eigenen Benutzernamen vergeben, der oft einer E-Mail Adresse entspricht. Das Passwort ist auch frei wählbar und hat nichts mit der Weboberfläche des Plenticore zu tun.


VG
  Christian

[ch.eick]

Und nun noch ein Punkt.
Die neu hinzugekommenen Anwender, die also einen frisch ausgelieferten Wechselrichter haben sollten bitte als erstes einen Firmware Update machen. Stand heute sind wir bei v1.18 . Der Hintergrund ist, dass mit einer der letzten Versionen zusätzliche Register dazu gekommen sind. Dies betrifft insbesondere die API , die ansonsten zuwenig Register liefert und dann bei der Auswertung im FHEM nicht alles anzeigt.

[ch.eick]

Soooo, Ihr stillen Mitleser 
Ich habe heute das komplette Wiki überarbeitet und auf meine letzte Implementierung aktualisiert.
Natürlich kann das ganze auch weiterhin mit einem einzelnen Wechselrichter verwendet werden. Solltet Ihr da Probleme erkennen, dann meldet Euch bitte.

Für alle die, die gerne auf die aktuelle Benennung der Devices und readings folgen möchten werde ich noch Beispiele für die Umbenennung in der Datenbank bereitstellen. Einiges ist schon weiter vorne in diesem Thread zu finden.

Das ist übrigens auch eine Vorbereitung für die Integration meiner bestellten openWB Ladepunkte, falls Ihr da auch etwas geplant habt.

Es lohnt sich auf jeden Fall die Wiki Seite nochmals zu  lesen, da auch hier und da neue Tips aus dem bisherigen Support eingeflossen sind.

Viele Grüße
     Christian

[ch.eick]

Hallo zusammen,
ich habe mal im Wiki die Links zur Hersteller Dokumentation und Firmware aktualisiert.

[ch.eick]

Hallo zusammen,
im Photovoltaik Forum werden es immer mehr, die einen zweiten WR und Speicher haben. Ich denke der Weg für Euch mit der Umbenennung wäre keine schlechte Idee.
Seit gestern habe ich im Wiki auch schon etwas für die Umbenennungen im Allgemeinen aufgenommen. Das ist aber noch work in progress
Wenn_man_mal_etwas_umbenennen_möchte

[ch.eick]

Für die Umfrage zum Stammtisch wäre es schön, wenn Ihr mir Euro Wünsche/Ideen als PN schickt. Ich fasse es dann zusammen und Poste es dann hier wieder als sortierte Zusammenfassung.

[ch.eick]

Und noch etwas Kosmetik...
in der Solar-forecast() Funktion lief der Forcast nur bis 19:00 Uhr, das habe ich auf 20:00 Uhr verlängert, dann geht die Kurve im Sommer auch wieder bis 0 runter
Hier ist die Stelle im Code

Code Auswählen Erweitern


     # Es werden Stundenwerte von 07:00 bis 20:00 Uhr berechnet
     for ($i = 7; $i <= 20; $i++) {


EDIT:
Und noch eine kleine Änderung, für die die das Mittagshoch verwenden.
Heute war die Situation, das es ein kleines Hoch in der Prognose gab, danach war die nächste Stunde wieder niedrig und dann kam nochmal eine Überschreitung hinterher.
Das Mittagshoch hat hier nur die Zeit von 11-15 Uhr angegeben. Durch die Änderung setze ich es bei einem weiteren Hoch nochmal zurück und nehme das nächste auch noch mit rein.
So kommt dann für heute eine zeit von 11-17 Uhr raus, in der der Speicher dann mit 1000 Watt (ist in der Konfig einstellbar) geladen wird. Hierdurch verringert sich die steile Ladestufe nach 15:00 Uhr im angehängten Diagramm.

Hier sind die Code Zeilen, die auch schon im Wiki sind.

Code Auswählen Erweitern


       if ( $logdb ne "none" ) {
         CommandSet(undef, $logdb." addCacheLine ".$timestamp."|".$logdevice."|addlog|".$reading.": ".$logentry1h."|".$reading."|".$logentry1h."|") ;

         if ( $middayhigh == 0 and $logentry1h > $Inverter_Max_Power ) {
           $middayhigh       = 1;
           $middayhigh_start = sprintf("%02d:00",$i-1);
           CommandSetReading(undef, $logdevice." Solar_middayhigh_fc".$fc." ".$middayhigh) ;
           CommandSetReading(undef, $logdevice." Solar_middayhigh_fc".$fc."_start ".$middayhigh_start) ;
         };
         if ( $middayhigh == 1 and $logentry1h < $Inverter_Max_Power and $middayhigh_stop eq "00:00" )  {
           $middayhigh_stop  = sprintf("%02d:00",$i);
           CommandSetReading(undef, $logdevice." Solar_middayhigh_fc".$fc."_stop ".$middayhigh_stop) ;
         };
         if ( $middayhigh == 1 and $logentry1h > $Inverter_Max_Power and $middayhigh_stop ne "00:00" )  {
           $middayhigh_stop  = "00:00";                             # da war ein kurzer Einbruch, es sollte noch länger sein.
         };
         ##   print($i." ".$logentry1h." ".$middayhigh." ".$middayhigh_start." ".$middayhigh_stop."\n");
       };


[ch.eick]

Hallo zusammen,
ich räume gerade die Datenbank bezüglich des Übergangs von einem WR zum Schwarm auf. Wie ja jetzt bekannt ist stimmen einige Werte dann nicht mehr, die ich mit den SW_* readings korrigiert habe.
Nun solltet Ihr euch fragen, ob Ihr Eure Installation so lasst  wie sie ist, oder ob Ihr im zuge der Vereinheitlichung auch auf die SW_* readings wechselt. Meine zukünftigen Anpassunge beziehen sich nun natürlich im weiteren auf die SW_* readings.

Schaut man sich die SW_* userreadings an, so sieht man, dass dort der WR_2 mit einem Default Wert 0 verrechnet wird. Somit hat es keinen Einfluss, wenn Ihr nur einen WR habt. Somit könnte die Implementierung für zwei oder auch nur für einen WR verwendet werden, was ich gedanklich auch so beibehalten möchte. Die Auswirkungen gehen natürlich bis in alle anderen Devices herein. Im Wiki habe ich ein Kapitel "Wenn man mal etwas umbenennen möchte" begonnen, wo alles zu diesem Thema eingepflegt werden soll. Dort werde ich dann auch Beispiele für die Datenbank Bereinigungen ablegen.

Ihr habt nun halt die Wahl, alle zukünftigen Änderungen jeweils wieder auf Eure alte Implementierung zurück zu führen, oder jetzt schon vorzusehen, dass es eventuell auch mal zwei AC-Quellen geben wird.
Einige von Euch haben ja auch schon gemerkt, wieviel Mehraufwand es ist auch nur schon den Device Namen bei jedem Update auf einen eigenen zurück zu führen. Leute es ist Frühjahrsputz angesagt

Wann Kostal das mal in der Firmware gerade zieht und welche Änderungen daraus wieder entstehen kann ich natürlich nicht vorhersagen.

Für die zukunft bin ich mir noch nicht ganz sicher, ob ich nur die SW_* readings in die Datenbank schreiben möchte, oder ob ich auch jeden einzelnen Wechselrichter sehen möchte. Durch das DbLogInclude laufen momentan beide Werte in Datenbank, also z.B. Home_own_consumption.* und SW_Home_own_consumption.* , was bei nur einem einzelnen Wechselrichter identisch ist und somit doppelt.

Code Auswählen Erweitern


DbLogInclude
Act_state_of_charge,Actual_Battery_charge_-minus_or_discharge_-plus_P,Actual_Battery_charge_usable_P,Battery_Total.*,Battery_charge.*,Battery_gross.*,Battery_temperature,Home_own_consumption.*,P_DC1,P_DC2,Total_DC_P.*,Total_DC_PV_Energy.*,Total_PV_P_reserve,Solar_Calculation,Solar_Calculation_fc0_4h,Solar_Calculation_fc0_day,Solar_Calculation_fc0_rest,Solar_Correction.*,Solar_Cloud,Solar_East_Covered,Solar_Rain,Solar_SolarRadiation,Solar_Temp,Solar_WR_.*,Solar_middayhigh.*,SW_.*


Eure Meinung dazu wäre mir auch wichtig.

EDIT:
Grundlegende SQLs sind nun bereits im Wiki

VG
   Christian

[ch.eick]

Hallo zusammen,
wer außer mir steuert denn noch in das Schwarm Problem?
Oder schreibe ich hier mitlerweile nur noch für mich

VG
   Christian

[papa]

Ich werde im Laufe des Jahres auch 2 WRs haben - den Kostal mit Batterie und nen SMA. Dann wird die Berechnung der Produktion / Verbrauch auch komplexer. Aber ich habe nicht Dein volles Setup. War mit zuviel Kram. Allerdings wäre es schon interessant, wenn es ein Template gibt, um mehrere Quellen/Senken zu verrechnen.

[ch.eick]

Ich werde im Laufe des Jahres auch 2 WRs haben - den Kostal mit Batterie und nen SMA. Dann wird die Berechnung der Produktion / Verbrauch auch komplexer. Aber ich habe nicht Dein volles Setup. War mit zuviel Kram. Allerdings wäre es schon interessant, wenn es ein Template gibt, um mehrere Quellen/Senken zu verrechnen.

Wenn da nur nicht das Problem mit dem Namensstandard gäbe Das war mit ein Grund, warum ich nicht zwei Hersteller haben wollte.
Aber ja, ich verfeinere noch und das Prinzip sollte man verwenden können.
Bei Dir wäre es dann eventuell sinnvoll z.B. in einem Dummy den Schwarm abzubilden und dort von den AC-Quellen beide WR zu vereinen.
Aus der DB kann man natürlich auch alles mit SQL berechnen, das wäre aber für die sofort Bilanz ein overkill.

Das volle Setup ist ja auch nicht nur Wechselrichter Im Prinzip habe ich meine Dokumentation ins Wiki verlagert.

VG
   Christian

[ch.eick]

Hallo zusammen,
ich habe das Wiki nun mit den Erweiterungen für den Schwarm oder mehrere AC-Quellen aktualisiert. Für diejenigen, die nur einen Wechselrichter betreiben gibt es auch einige Hinweise, falls Ihr nicht die komplette Definition übernehmen möchtet. Dann entsteht jedoch bei jedem Update wieder erneuter Aufwand, es sollte allerdings auch mit der vollen Definition für nur einen WR laufen, da die SW_* Definitionen dann halt die Werte vom WR_1 beinhalten.

Schaut es Euch bitte an und gebt mir bescheid, wenn ich wirres Zeug geschrieben habe.

VG
   Christian

[ch.eick]

Ich werde im Laufe des Jahres auch 2 WRs haben - den Kostal mit Batterie und nen SMA. Dann wird die Berechnung der Produktion / Verbrauch auch komplexer. Aber ich habe nicht Dein volles Setup. War mit zuviel Kram. Allerdings wäre es schon interessant, wenn es ein Template gibt, um mehrere Quellen/Senken zu verrechnen.

Wenn Du im WR_1 und WR_1_API die Stellen im userReading, die auf den WR_2 und WR_2_API zeigen mit den passenden readings vom SMA anpasst, dann sollte das auch mit unterschiedlichen Herstellern funktionieren.

[papa]

Wenn Du im WR_1 und WR_1_API die Stellen im userReading, die auf den WR_2 und WR_2_API zeigen mit den passenden readings vom SMA anpasst, dann sollte das auch mit unterschiedlichen Herstellern funktionieren.

Puuh ... muss ich mir mal bei Gelegenheit in Ruhe ansehen.

[ch.eick]

Puuh ... muss ich mir mal bei Gelegenheit in Ruhe ansehen.

Gerne