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

[ch.eick]

Hallo zusammen,
ich glaube es war unser Schweizer Mitglied, der diese Frage mal hatte.
Es geht um die eventuell zu erreichende Leistung für den nächsten Tag aus dem Forecast. Daraus habe ich nun zumindest die Summe der Stundenprognose gebildet.
Zumindest bekommt man einen Wert, der mindestens erreicht werden sollt. Es ist natürlich ein Glaskugellesen, da der Himmel auch mal schnell aufreißen kann. Die Qualität
hängt natürlich auch von Eurem fine Tuning mit den Parametern von Solar_forecast() ab. Für meinen Fall bin ich zumindest zufrieden.

Code Auswählen Erweitern


defmod LogDBRep_Test DbRep LogDB
attr LogDBRep_Test DbLogExclude .*
attr LogDBRep_Test comment Version 2020.11.18 09:00
attr LogDBRep_Test device PV_Anlage_1
attr LogDBRep_Test reading Solar_Calculation_fc1
attr LogDBRep_Test room Strom->Energie,System

setstate LogDBRep_Test 2020-11-17 19:59:17 sqlCmd SELECT sum(VALUE) AS 'Solar_calculation_fc1_tomorrow' FROM history WHERE DEVICE = 'PV_Anlage_1' AND READING = 'Solar_Calculation_fc1' AND TIMESTAMP > DATE_ADD(DATE(now()),INTERVAL 1 DAY) AND TIMESTAMP < DATE_ADD(DATE(now()),INTERVAL 2 DAY);;

Das Ergebnis sähe dann z.B. so aus und Ihr könnt über das reading SqlResultRow_2 den Wert abfragen.

Code Auswählen Erweitern


SqlResultRow_1 SOLAR_CALCULATION_FC1_TOMORROW
SqlResultRow_2 9288


Generisch betrachtet gibt es so die Möglichkeit mit SQL jeden beliebigen Wert zu errechnen und das Ergebnis mit dieser Abfrage weiter zu verarbeiten.

Code Auswählen Erweitern


ReadingVal("LogDBRep_Test","SqlResultRow_2","error")


Gruß
    Christian

[ch.eick]

Kurze Zwischenfrage:
Ich habe bei mir bemerkt, dass wenn ich apptime starte, keine Aktualisierung der Modbus Devices mehr stattfindet.
Ich muss dann fhem restarten, dann geht es weiter.
Betroffen sind bei mir beide Wechelrichter und auch der KSEM.
Kann das mal jemand probieren, ob das bei mir ein lokales Problem ist?
Danke und Gruss

Hi killah78,
das solltest Du besser im Thread für Modbus platzieren, da wird es von den passenden Fachleuten gesehen.

Das ist jedoch wieder ein gutes Beispiel, warum ich kein Modul erstellt habe

EDIT: Ich habe das apptime noch nie verwendet, aber gerade mal ein "apptime max" ausgeführt
          Bei mir läuft das PV_Anlage_1 Device mit den reading updates ganz normal weiter.
          Was möchtest Du bitte genau als Aufruf getestet haben?

Gruß
    Christian

[ch.eick]

Hallo zusammen,
jetzt habe ich auch mal eine Frage.
Hat schon mal jemand die neuen readings gedeutet? Ich hab da momentan eine Gedanken Blockade und bekomme die Werte im Kopf nicht zugeordnet.

Der Hintergrund ist, dass ich gerne einige userreadings, die ich erstellt habe ablösen möchte.
Bitte erhellt mich mit Euren Erklärungen

PV_Anlage_1_API

Code Auswählen Erweitern


Das ist neu für die Batterie
Statistic_EnergyChargeGrid_Day 0.00          <<< Wenn aus dem Netz geladen wird
Statistic_EnergyChargeInvIn_Day 0.02          <<< Was soll das sein?
Statistic_EnergyChargePv_Day 4483.88          <<< Das ist dann von PV in die Batterie geladen worden

Statistic_EnergyDischargeGrid_Day 0.17         <<< Leider kann wohl auch mal was ins Netz entladen werden.
Statistic_EnergyDischarge_Day 1711.62          <<< Das wird dann über den Tag aus der Batterie entnommen

Statistic_EnergyPv1_Day 7837.86                <<< Leistung aus den einzelnen Strings zusammen 15,9 KW
Statistic_EnergyPv2_Day 8067.02
Statistic_EnergyPv3_Day 0 <<< da ist die Batterie dran


PV_Anlage_1

Code Auswählen Erweitern


Total ist immer ein Statistik Wert

Battery_Total_AC_Charge_Energy_(AC-sideToBattery) 2.33                   <<< Das war ein Test mit MinSoc, da wurde aus dem Netz geladen
Battery_Total_AC_Charge_Energy_(gridToBattery) 0.00                      <<< aber dann sollte das ja eigentlich hier stehen. Ich habe keine zweite AC Quelle

Battery_Total_AC_Discharge_Energy_(batteryToGrid) 8.79                   <<< Wo das her kommt verstehe ich auch nicht. Das könnten 8.79 KWh seit betrieb der Anlage sein, die ins Netz gelaufen sind.
Battery_Total_DC_Charge_Energy_(DC-sideToBattery) 9468.69                <<< Brutto in die Batterie
Battery_Total_DC_Discharge_Energy_(DC-sideFromBattery) 7917.56          <<< Netto wieder raus    Wirkungsgrad wäre dann 84 % auf die Gesamtzeit des Speichers

Battery_charge_current 20.00                                            <<< Das ist der Entladestrom, ich laufe gerade auf Batterie
Battery_gross_capacity 1638400


Nun sind folgende userreadings im PV_Anlage_1

Code Auswählen Erweitern


Power_DC_Sum:Total_DC_Power.* { ReadingsVal($NAME,"Power_DC1","0")+ReadingsVal($NAME,"Power_DC2","0") },

Total_PV_Power_reserve:Total_DC_Power.* {my $reserve = ReadingsVal($NAME,"Power_DC_Sum","0") * 0.90 - ReadingsVal($NAME,"Home_own_consumption_from_PV","0");; ($reserve lt 0)?0:round($reserve,3)  },

Total_DC_Power_Max:Total_DC_Power.* { my $Bat_out = (ReadingsVal($NAME,"Actual_battery_charge_-minus_or_discharge_-plus_current","0")*ReadingsVal($NAME,"Battery_voltage","0"));; ($Bat_out gt 0)?ReadingsVal($NAME,"Power_DC_Sum","0") + $Bat_out :ReadingsVal($NAME,"Power_DC_Sum","0") },

Actual_battery_charge_-minus_or_discharge_-plus_Power:Actual_battery_charge_-minus_or_discharge_-plus_current.* {round((ReadingsVal($NAME,"Actual_battery_charge_-minus_or_discharge_-plus_current","0")*ReadingsVal($NAME,"Battery_voltage","0")),0)},

Actual_battery_charge_usable_Power:Act_state_of_charge.* {my $x = (ReadingsVal($NAME."_config","Battery_Total_Power","0")*(ReadingsVal($NAME,"Act_state_of_charge","0")-10)/100);; ($x lt 0)?0:round($x,0) }


und im PV_Anlage_1_API sind diese

Code Auswählen Erweitern


Statistic_EnergyHomePvSum_Day:Statistic_EnergyHomePv_Day.* {round( (ReadingsVal("$NAME","Statistic_EnergyHomeBat_Day", "0")+ReadingsVal("$NAME","Statistic_EnergyHomePv_Day", "0")) ,2)},

Statistic_EnergyFeedInGrid_Day:Statistic_Yield_Day.* {round((ReadingsVal("$NAME","Statistic_Yield_Day", "")-ReadingsVal("$NAME","Statistic_EnergyHomeBat_Day", "0")-ReadingsVal("$NAME","Statistic_EnergyHomePv_Day", "0")),2)},

Statistic_TotalConsumption_Day:Statistic_EnergyHomePv_Day.* {round( (ReadingsVal("$NAME","Statistic_EnergyHomePv_Day","0")+ReadingsVal("$NAME","Statistic_EnergyHomeBat_Day","0")+ReadingsVal("$NAME","Statistic_EnergyHomeGrid_Day","0") ) ,2)},

Statistic_Yield_NoBat_Day:Statistic_Yield_Day.* {round((ReadingsVal("$NAME","Statistic_Yield_Day", "0")-ReadingsVal("$NAME","Statistic_EnergyHomeBat_Day", "0")),2)},


Es wäre toll, wenn sich da mal jemand ran setzen könnte um zu schauen, welche von den Werten nun überflüssig wären?

Gruß
   Christian

[Mumpitz]

Hallo zusammen,
ich glaube es war unser Schweizer Mitglied, der diese Frage mal hatte.
Es geht um die eventuell zu erreichende Leistung für den nächsten Tag aus dem Forecast. Daraus habe ich nun zumindest die Summe der Stundenprognose gebildet.
Zumindest bekommt man einen Wert, der mindestens erreicht werden sollt. Es ist natürlich ein Glaskugellesen, da der Himmel auch mal schnell aufreißen kann. Die Qualität
hängt natürlich auch von Eurem fine Tuning mit den Parametern von Solar_forecast() ab. Für meinen Fall bin ich zumindest zufrieden.

Code Auswählen Erweitern


defmod LogDBRep_Test DbRep LogDB
attr LogDBRep_Test DbLogExclude .*
attr LogDBRep_Test comment Version 2020.11.18 09:00
attr LogDBRep_Test device PV_Anlage_1
attr LogDBRep_Test reading Solar_Calculation_fc1
attr LogDBRep_Test room Strom->Energie,System

setstate LogDBRep_Test 2020-11-17 19:59:17 sqlCmd SELECT sum(VALUE) AS 'Solar_calculation_fc1_tomorrow' FROM history WHERE DEVICE = 'PV_Anlage_1' AND READING = 'Solar_Calculation_fc1' AND TIMESTAMP > DATE_ADD(DATE(now()),INTERVAL 1 DAY) AND TIMESTAMP < DATE_ADD(DATE(now()),INTERVAL 2 DAY);;

Das Ergebnis sähe dann z.B. so aus und Ihr könnt über das reading SqlResultRow_2 den Wert abfragen.

Code Auswählen Erweitern


SqlResultRow_1 SOLAR_CALCULATION_FC1_TOMORROW
SqlResultRow_2 9288


Generisch betrachtet gibt es so die Möglichkeit mit SQL jeden beliebigen Wert zu errechnen und das Ergebnis mit dieser Abfrage weiter zu verarbeiten.

Code Auswählen Erweitern


ReadingVal("LogDBRep_Test","SqlResultRow_2","error")


Gruß
    Christian

Funktioniert 1A! Vielen Dank. Ich bin gespannt auf den Vergleich zwischen Forecast und tatsächliche Werte!
Gruss aus der Schweiz

Jetzt bleibt mir nur noch die Umstellung auf das neue API Device.. Leider happerts da noch, ich erhalte beim RAW Import immer eine Fehlermeldung...
mal schauen...

[ch.eick]

Jetzt bleibt mir nur noch die Umstellung auf das neue API Device.. Leider happerts da noch, ich erhalte beim RAW Import immer eine Fehlermeldung...
mal schauen...

Schick mir doch mal die Meldungen, ich hatte heute noch updates gemacht. Es war leider wieder sehr viel Arbeit und d leidet die Konzentration

[ch.eick]

Hey Mitstreiter,
für die unter uns, die noch einen BYD HV Speicher Ihr eigen nennen können habe ich das BYD_Speicher Device umgebaut.
Die Anmeldung war nicht wirklich schön und mit etwas Mühe habe ich das nun umgestellt.

- KeyValue() wird nun auch hier verwendet, wodurch das Passwort nun nicht mehr im Device zu sehen ist.
- Die Anmeldung erfolgt nun über den sid Mechanismus vom HTTPMOD
- Es konnten einige replacements entfernt werden
- Das userreading ist nun aufgeräumt
- Ein frisches Login kann man durch "deletereading BYD_Status .*" erzwingen
- Eine beliebige Abfrage fürt ein eventuell notwendiges Login automatisch durch

Momentan gibt es noch Probleme mit der aktuellen HTTPMOD Version, wodurch diverse zwischen readings, die bisher gelöscht wurden nun leider stehen bleiben.
Als workaround kann man diese so löschen:

Code Auswählen Erweitern


deletereading BYD_Status .*-.*


Um diese Neuerung nutzen zu können sollte man zuerst auf die Plenticore v1.16 und die PV_Anlage_1* Devices umgestellt haben, da dort z.B. die KeyVakue() Installation durchgeführt wird.

VG
   Christian

[ch.eick]

Moin, moin.
Gestern hatten wir mal wieder ein undercover Thema, was dann auch in der Prognoseanpassung mündete. Hier mal ein Beispiel, wie man Solar_Plain() im Grenzbereich für sich anpassen kann.
Der Grenzbereich ist morgens und abends, da wird aufgrund vom elevation Stand der Funktionswert auf 0.001 gesetzt, wenn es unwahrscheinlich ist, das der errechnete Wert sinn macht.

Wir testen nun noch einwenig und ich würde dann diesen Wert mit in PV_Anlage_1_config mit aufnehmen.

An welchen Parametern muss ich da schrauben ?

Code Auswählen Erweitern


attr global verbose 3
https://wiki.fhem.de/wiki/Kostal_Plenticore_10_Plus#Solar_plain.28.29_Test

Um 08:00 Uhr regelt die Funktion noch ab., da die Sonne zu tief steht
{Solar_plain(45,40,"2020-11-19 08:00:00") }
2020.11.19 10:59:15.530 3: get Astro text SunAz 2020-11-19 08:00:00 : 123
2020.11.19 10:59:15.537 3: get Astro text SunAlt 2020-11-19 08:00:00 : 1.6
2020.11.19 10:59:15.538 3: Solar_plain: azimuth = 123, orientation=-1.89296285953644, elevation=0.0279251605696733, angle=0.785395141022061
2020.11.19 10:59:15.538 3: Solar_plain: factor = 0.001

Ab 09:00 Uhr geht es dann los
{Solar_plain(45,40,"2020-11-19 09:00:00") } => 1.091
2020.11.19 11:00:27.433 3: get Astro text SunAz 2020-11-19 09:00:00 : 135
2020.11.19 11:00:27.438 3: get Astro text SunAlt 2020-11-19 09:00:00 : 9.1
2020.11.19 11:00:27.438 3: Solar_plain: azimuth = 135, orientation=-1.48352415526389, elevation=0.158824350740017, angle=0.785395141022061
2020.11.19 11:00:27.439 3: Solar_plain: factor = 1.09189342979292

=========== code Zeilen
    # avoid unrealistic values (normally formula should only be used within boundaries of orientation +/- 90 degrees)
    if ($elevation <= 0.14) {
      Log 3, "Solar_plain: factor = $factor";
      return($factor);
    };
==================

Änderung des Gültigkeitbereiches
=========== code Zeilen
    # avoid unrealistic values (normally formula should only be used within boundaries of orientation +/- 90 degrees)
#    if ($elevation <= 0.14) {
    if ($elevation <= 0.02792) {
      Log 3, "Solar_plain: factor = $factor";
      return($factor);
    };
==================

Danach testen und schauen, ob es passt
{Solar_forecast("LogDB","LogDBRep_delete_PV_Forecast","PV_Anlage_1","Solar_Calculation_fc","DWD_Forecast",0)}

Die neue Kurve wird dann um 7:00 Uhr auf Null sein und für 8:00 Uhr einen Wert liefern.

Das ist dann aber ein experimentelles Tuning, wenn es klappt bitte bescheid geben, dann könnte ich den Wert mit in PV_Anlage_1_config aufnehmen.

Das eine Diagramm zeigt den Forecast mit einem letzten Null Wert um 8:00 Uhr und einer Teilverschattung um 14:45 durch ein Nachbarhaus im Winter.
Deim zweiten Diagramm von heute Morgen sieht man den neuen Null Wert um 07:00 Uhr und den ersten Prognose Wert um 08:00 Uhr. Dadurch bekommt die Kurve einen leichten Knick am frühen Morgen. Dieser Knick müsste nun noch mit den Sommerdaten verglichen werden, was sich dann nächstes Jahr zeigen wird. Ich denke Jürgen wird uns heute Abend nochmal einen Update schicken

Nun zur Teilverschattung, der eigentlichen Frage. Hier hat der Solarteur keine Leistungsoptimierer verbaut und auch nur einen String1 verdrahtet, obwohl es am WR noch einen freien String2 gibt. Hätte man die verschatteten Module separat verdrahtet und von den unverschatteten getrennt, wäre nur dieser String eingebrochen und der zweite könnte noch länger produzieren. Dies wird wahrscheinlich nun noch korrigiert.

Im dritten Diagramm sind mal die drei Prognosen meiner Anlage für Ost/Süd/West und der daraus resultierende gesamt Forecast zu sehen. Bei dieser Anlage sind Ost und West die größten Flächen und der Süden ist hälftig mit Leistungsoptimierern zu Ost und West im jeweiligen String aufgenommen. Der Plenticore 10 hat drei Strings , wobei einer für die batterie verwendet wird und somit nur zwei Strings für die Module verwendet werden konnten.

VG
   Christian
und dank an Jürgen für diesen Einblick.

[killah78]

Hallo ch.eick
Also zu den Deutungen:
die neuen API Werte sind analog zu den neuen Modbuswerten. Nur halt kumulierte Tageswerte.
Derzeit lese ich per Modbus und kumuliere per statistics Modul.


TotalACChargeEnergy(AC-sideToBattery)
TotalACChargeEnergy(gridToBattery)

Das sind Zählwerte, wenn die Batterie über AC geladen wird. Dazu gibt es ja auch die Option im Wechselrichter, dass man das explizit erlauben muss.
Ich habe einen zweiten Wechselrichter, daher kommen bei mir Werte an.
Allerding habe ich immer beide Readings gefüllt. GridToBattery immer einen Tick weniger als AC-sideToBattery. Wenn die Idee dahinter ist zwischen "interner" AC Ladung und Ladung über EVU zu unterscheiden, funktioniert sie leider nicht.


TotalACDischargeEnergy(batteryToGrid) -> Einspeisung aus Batterie. Wird ja immer minimal anfallen, weil Wechselrichter ja nicht so schnell auf ändernden Energiebedarf reagieren kann. Werte sind bei mir auch immer minimal.

TotalDCChargeEnergy(DC-sideToBattery) -> Laden aus DC Seite. Allerdings scheint nicht das Laden der AC Seite eingeschlossen zu sein. Mein Wert für DCCharge ist deutlich geringer als der DCDischarge. Da kann man nicht mit Effizienz erklären. Wenn ich ACCharge und DCCharge addiere hätte ich gegen das DCDischarge einen Verlust von 7%

TotalDCDischargeEnergy(DC-sideFromBattery) -> Entladen der Batterie
TotalDCEnergyFromPV1
TotalDCEnergyFromPV2
TotalDCEnergyFromPV3
TotalDCPVEnergy(sumOfAllPVInputs) -> DC Energiezähler der Photovoltaikstrings. Also das was wirklich vom Dach reinkommt.

TotalDCPower(sumOfAllPVInputs) -> DC Leistung vom Dach.
TotalEnergyAC-sideToGrid -> Einspeisung ins EVU Netz. Im Gegensatz zu Yield scheint das die Energie zu sein, die tatsächlich eingespeist wird, wogegen Yield die über AC abgegebene Energie ist, die gegebenfalls auch selbst verbraucht werden kann.




Zu den userReadings:
Power_DC_Sum ist jetzt TotalDCPower(sumOfAllPVInputs).
Statistic_EnergyFeedInGrid ist TotalEnergyAC-sideToGrid.
Die anderen sollten beibehalten werden denke ich.

[ch.eick]

TotalACChargeEnergy(AC-sideToBattery)
TotalACChargeEnergy(gridToBattery)

Das sind Zählwerte, wenn die Batterie über AC geladen wird. Dazu gibt es ja auch die Option im Wechselrichter, dass man das explizit erlauben muss.
Ich habe einen zweiten Wechselrichter, daher kommen bei mir Werte an.
Allerding habe ich immer beide Readings gefüllt. GridToBattery immer einen Tick weniger als AC-sideToBattery. Wenn die Idee dahinter ist zwischen "interner" AC Ladung und Ladung über EVU zu unterscheiden, funktioniert sie leider nicht.

Das sehe ich auch als Fehler an. Wenn Du Muße hast, kannst Du es ja mal bei Kostal melden.

[/quote]
TotalACDischargeEnergy(batteryToGrid) -> Einspeisung aus Batterie. Wird ja immer minimal anfallen, weil Wechselrichter ja nicht so schnell auf ändernden Energiebedarf reagieren kann. Werte sind bei mir auch immer minimal.

Sehe ich auch so.

TotalDCChargeEnergy(DC-sideToBattery) -> Laden aus DC Seite. Allerdings scheint nicht das Laden der AC Seite eingeschlossen zu sein. Mein Wert für DCCharge ist deutlich geringer als der DCDischarge. Da kann man nicht mit Effizienz erklären. Wenn ich ACCharge und DCCharge addiere hätte ich gegen das DCDischarge einen Verlust von 7%

Okay, dann nehme ich eine Statistic_Effizienz aus diesen Werten mit auf.

Code Auswählen Erweitern


DCDischarge * 100 / (ACCharge + DCCharge)


TotalDCDischargeEnergy(DC-sideFromBattery) -> Entladen der Batterie
TotalDCEnergyFromPV1
TotalDCEnergyFromPV2
TotalDCEnergyFromPV3
TotalDCPVEnergy(sumOfAllPVInputs) -> DC Energiezähler der Photovoltaikstrings. Also das was wirklich vom Dach reinkommt.

TotalDCPower(sumOfAllPVInputs) -> DC Leistung vom Dach.
TotalEnergyAC-sideToGrid -> Einspeisung ins EVU Netz. Im Gegensatz zu Yield scheint das die Energie zu sein, die tatsächlich eingespeist wird, wogegen Yield die über AC abgegebene Energie ist, die gegebenfalls auch selbst verbraucht werden kann.

Zu den userReadings:
Power_DC_Sum ist jetzt TotalDCPower(sumOfAllPVInputs).
Statistic_EnergyFeedInGrid ist TotalEnergyAC-sideToGrid.
Die anderen sollten beibehalten werden denke ich.

Okay, wenn dann kein Widerspruch kommt werde ich die zwei userreading raus nehmen und wider SQL für die Migration der Daten in in der DbLog bereitstellen.

VG
  Christian

[ch.eick]

Bei diesen Werten ist jedoch noch eine Diskrepanz von 120 Watt.
Die Batterie wird momentan weder geladen, noch entladen!

Code Auswählen Erweitern

Power_DC1 540.41
Power_DC2 523.15
Total_DC_Power 1058.02                     <<< das ist auch vom Plenticore, jedoch mit Batterie
Home_own_consumption_from_PV 1051.04

Power_DC_Sum 1027.96                       <<< mein userreading
Total_DC_Power_(sumOfAllPVInputs) 932.58   <<< Und das von Kostal


EDIT:
Es wird wohl ein Lesezeitfehler sein, da die ModBus Register zeitlich versetzt aktualisiert werde. => Das userreading fliegt raus

Geändert wurde hierdurch:

Code Auswählen Erweitern


https://wiki.fhem.de/wiki/Kostal_Plenticore_10_Plus#RAW_Definition_PV_Anlage_1
- DbLogInclude
- event-on-change-reading
- stateFormat
- userreading
- delete des reading
    deletereading PV_Anlage_1 Power_DC_Sum

- verschieben der alten Werte in der Datenbank
   UPDATE history SET TIMESTAMP=TIMESTAMP, READING='Total_DC_Power_(sumOfAllPVInputs)' WHERE DEVICE='PV_Anlage_1' and READING='Power_DC_Sum' AND TIMESTAMP > '2019-09-01 00:00:00';

- Diagramm eventuell korrigieren
https://wiki.fhem.de/wiki/Kostal_Plenticore_10_Plus#GPLOTFILE_SVG_LogDB_Photovoltaik_4.gplot


[ch.eick]

Und jetzt auch noch das Thema des Tages , die Batterie Steuerung.

Die Steuerung von MinSoc und MinHomeConsumtion ist bereits über das device PV_Anlage_1_API auch für den Betreiber möglich.
Für den Herbst/Winter habe ich nun einen Vorschlag aus dem Photovoltaikform umgesetzt.

Hintergrund:

Code Auswählen Erweitern


Meine Batterie wurde bisher am Tag immer kurz geladen, dann wieder durch die LWP geleert und das immer im Wechsel.
Da ich ja eh Strom zukaufen muss lasse ich die Batterie einfach stetig mit dem Überschuss, den ich nicht sofort verbrauchen kann, laden.
Nun ist Ruhe eingekehrt :-),

Laut dem EFT Service ist es zwar kein Problem die Batterie einfach immer wieder kurz zu laden und sofort wieder zu entladen, doch die jetzige Variante sieht mir schonender aus.
Ich hoffe, dass macht sich dann in längerer Lebenszeit bemerkbar, aber davon kann ich erst in 10 Jahren berichten :-)


Umsetzung:

Code Auswählen Erweitern


Bei MinSoc 15% wird MinHomeConsumtion auf den Wert Battery_Info_SoC gesetzt und die Batterie kann schön den ganzen Tag laden, oder im Forum vorgeschlagen bis SoC 90% .
Dadurch, dass MinHomeConsumtion auf die Maximalleistung gesetzt wurde würde die Batterie erst bei diesem Wert entladen dürfen, was eher unwahrscheinlich ist. Wichtig ist nur, dass der gesetzte Wert höher ist, als der zu erwartende Maximalverbrauch des Hauses. Setzt man MinHomeConsumtion auf einen Wert, der den Verbrauch eines Großverbrauchers im Haus nahe kommt, dann würde nur dieser unterstützt. Das nur als Randbemerkung.


Nebeneffekte:

Code Auswählen Erweitern


- Das Laden der Batterie kann somit auch mal Tage dauern, wenn zu wenig PV Leistung vom Dach kommt.
- Es wird vermutet, dass der MinSoC Wert bei geringer Leistung in der Batterie ungenau wird,
   aber bei Ladung bis 100% exacter berechnet wird. MinSoC ist keine exakte Wissenschaft.
- Stellt der Kontroller der Batterie fest, das die Leistung in der Batterie einen Grenzwert unterschritten hat,
   wird der MinSoC korrigiert und es kommt zu dem Effekt, das mitten in der Nacht der MinSoC auf einmal
   nach unten fällt. Damit wird dem Wechselrichter signalisiert, das nachgeladen werden muss, um MinSoC
   wieder zu erreichen. Das Resultat ist die bekannte Notladung in der Nacht aus dem Netz.


Meine Umsetzung ist nun im Wiki im PV_Schedule Device (cmd_6 und cmd_7) zu finden. Für die Rosinen Picker, beachtet auch das wait Attribut.

Gruß
   Christian

[killah78]

wegen der Diskrepanz:

Code Auswählen Erweitern

2020-11-20 11:19:02 DC_Power1 374.53
2020-11-20 11:19:02 DC_Power2 348.59
2020-11-20 11:19:02 DC_Power_Total_W_sum 723.12
2020-11-20 11:19:01 TotalDCPower(sumOfAllPVInputs) 723.12

Passt bei mir ganz gut. Vielleicht "ungünstig" gelesen (zeitlich). Hast du die Abweichung über längere Zeit? Ab und an habe ich auch minimale Abweichungen, aber das wird die Lesezeitfolge sein.

[ch.eick]

Die Änderung für Power_DC_Sum ist hier beschrieben.
https://forum.fhem.de/index.php/topic,114849.msg1102811.html#msg1102811

Und hier nochmal ein SQL Query, um alle readings von einem Device zu listen, die in den letzten 24 Stunden aktualisiert wurden.

Code Auswählen Erweitern


SET @device = 'PV_Anlage_1';

SELECT t1.TIMESTAMP,t1.DEVICE,t1.READING,t1.VALUE
  FROM history t1
  INNER JOIN
   (SELECT max(TIMESTAMP) AS TIMESTAMP,DEVICE,READING
      FROM history
      WHERE DEVICE    = @device AND
            TIMESTAMP > NOW() - INTERVAL 1 DAY
      GROUP BY READING) x
  ON x.TIMESTAMP = t1.TIMESTAMP AND
     x.DEVICE    = t1.DEVICE    AND
     x.READING   = t1.READING;


[billy-boy]

Hallo Zusammen

Seit 2 Wochen habe ich nun meine Anlage auf dem Dach und wollte diese jetzt in Fhem integrieren.
Auslesen des KSEM funktioniert.
Einloggen mit Python3 funktioniert.
Beim Einloggen mit API habe ich keine Chance irgendwelche Werte auslesen zu können.
Der KeyValue() Test klappt noch, aber der plenticore_auth() Test mit {plenticore_auth("finish","user","PV_Anlage_1_API","TESMUWZnwkJZbnpF","TE2MUWZnwkJZbnpFQ5ulCfolNNdAD0vT","DbAC0R85jwF0rh+r","29000","1376720346bea40cdf770a8f84b5975cfeb20c5e6ac6d89b7862df3ca9695e43")}
ergibt: "Undefined subroutine &main::derive called at ./FHEM/99_myUtils.pm line 179."

Desweiteren habe ich mal eine Frage zur Einrichtung der PV_Anlage_1_API.
Warum steht im stateFormat nur "PV_Anlage_1" anstatt $name (also PV_Anlage_1_API)?
Das sind doch dann die Werte aus dem Einloggen mit Python.
Da ich diese Abfrage nicht disabled hatte wurden mir die Werte angezeigt.

Es wäre schön wenn mir einer einen Tipp geben könnte.

Danke

Gruß Rainer

[ch.eick]

Hallo Rainer,
willkommen im Team.

Einloggen mit Python3 funktioniert.

Python wurde bereits aus dem PV_Anlage_1_API entfernt.

Du solltest beim Wechselrichter direkt mit der FW 1.16 beginnen. Da ich schon umgestellt habe werden im weiteren nur noch die aktuellen Funktionen unterstützt.
Im Thread kannst Du die ganzen Neuerungen bereits mitverfolgen.
Solltest Du auch einen Speicher haben, dann wird es sicher die neue Generation sein. Meine Speicher direkt Abfrage funktioniert nur mit dem BYD HV, dann
kannst Du das überspringen.

Der KeyValue() Test klappt noch.

das ist gut, dann hast Du die Funktionen schon mal in der 99_myUtils und geladen.

aber der plenticore_auth() Test mit {plenticore_auth("finish","user","PV_Anlage_1_API","TESMUWZnwkJZbnpF","TE2MUWZnwkJZbnpFQ5ulCfolNNdAD0vT","DbAC0R85jwF0rh+r","29000","1376720346bea40cdf770a8f84b5975cfeb20c5e6ac6d89b7862df3ca9695e43")}
ergibt: "Undefined subroutine &main::derive called at ./FHEM/99_myUtils.pm line 179."

Hast Du auch das hier in 99_myUtils aufgenommen?

Code Auswählen Erweitern


use Encode qw(decode encode);
use PBKDF2::Tiny qw/derive verify/;                   <<< Das fehlt Dir definitiv
use Digest::SHA qw(sha256 hmac_sha256);
use Crypt::URandom qw( urandom );
use Crypt::AuthEnc::GCM;


Desweiteren habe ich mal eine Frage zur Einrichtung der PV_Anlage_1_API.
Warum steht im stateFormat nur "PV_Anlage_1" anstatt $name (also PV_Anlage_1_API)?

Da ich diese Abfrage nicht disabled hatte wurden mir die Werte angezeigt.

Damit werden aus dem PV_Anlage_1 Device die aktuellen Werte ergänzt., um sie den Statistischen Werten gegenüber zu stellen.

Das sind doch dann die Werte aus dem Einloggen mit Python.

Nein ,das ist falsch. Bitte nutze nicht mehr die Python Implementierung. Die Skripte kann man zwar noch verwenden, aber achte bitte auf Wechselwirkungen.

VG
   Christian