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

Begonnen von ch.eick, 07 Oktober 2020, 16:09:12

Vorheriges Thema - Nächstes Thema

plin

Ich habe ein Problem mit dem Statement
setreading PV_Anlage_1_API replacement01Value {ReadingsVal("PV_Anlage_1_config","IP-Address_Plenticore","")}

Beim Aufruf von 01_/auth/start kriege ich in meiner Test-Instanz (Raspi4 mit Debian Buster) ein
gethostbyname {ReadingsVal("PV_Anlage_1_config","IP-Address_Plenticore","")} failed

Wenn ich {ReadingsVal("PV_Anlage_1_config","IP-Address_Plenticore","")} in der FHEMWEB Kommandozeile eingebe erhalte ich die korrekte IP-Adresse.

Auf meiner Prod-Instanz (x86 mit openSUSE Leap 15.2) erhalte ich eine
info_message      The method is not allowed for the requested URL.

Das zugehörige Log von der Prod-Instanz als Anlage.
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

ch.eick

EDIT: Hallo plin, eventuell könnte es ja mit der Korrektur von plenticore_auth() nun besser laufen. Ich würde mich freuen, wenn Du das noch testen könntest.


Zitat von: plin am 15 November 2020, 09:14:20
Ich habe ein Problem mit dem Statement
setreading PV_Anlage_1_API replacement01Value {ReadingsVal("PV_Anlage_1_config","IP-Address_Plenticore","")}

Beim Aufruf von 01_/auth/start kriege ich in meiner Test-Instanz (Raspi4 mit Debian Buster) ein
gethostbyname {ReadingsVal("PV_Anlage_1_config","IP-Address_Plenticore","")} failed
Da musst Du leider die beiden Umgebungen miteinander vergleichen. Hast Du das PV_Anlage_1_API vollständig ersetzt?
An dem PV_Anlage_1_config hat sich soweit nichts verändert.

Zitat
Wenn ich {ReadingsVal("PV_Anlage_1_config","IP-Address_Plenticore","")} in der FHEMWEB Kommandozeile eingebe erhalte ich die korrekte IP-Adresse.
Das wäre der richtige Test und sollte auf beiden Umgebungen die IP-Adresse liefern.

Hast Du das neueste HTTPMOD schon drauf? Ich bin noch immer bei der alten Version, weil bei der neuen noch Merkwürdigkeiten auftreten, wie ich im Forum gelesen habe.
Ich könnte Dir die alte Version nochmal schicken, falls Du kein Backup hast.

Zitat
Auf meiner Prod-Instanz (x86 mit openSUSE Leap 15.2) erhalte ich eine
info_message      The method is not allowed for the requested URL.

Zitat
Das zugehörige Log von der Prod-Instanz

snip..
http://192.168.3.71/api/v1/processdata/scb:statistic:EnergyFlow
2020.11.15 09:40:48 4: PV_Anlage_1_API: HandleSendQueue sends get20 with timeout 7 to http://192.168.3.71/api/v1/processdata/scb:statistic:EnergyFlow, No Data,
header: authorization: Session
2020.11.15 09:40:48 5: PV_Anlage_1_API: ReadCallback called from __ANON__
2020.11.15 09:40:48 4: PV_Anlage_1_API: Read callback: request type was get20 retry 0,
header: HTTP/1.1 200 OK
Server: nginx/1.15.2
Date: Sun, 15 Nov 2020 08:40:48 GMT
Content-Type: application/json
Content-Length: 59
Connection: close
Access-Control-Allow-Origin: *
Cache-Control: max-age=0, no-cache, no-store, must-revalidate, body length 59
2020.11.15 09:40:48 5: PV_Anlage_1_API: Read callback: body
[{"processdata":[],"moduleid":"scb:statistic:EnergyFlow"}]

2020.11.15 09:40:48 4: PV_Anlage_1_API: BodyDecode found no charset header (bodyDecode was set to auto)
2020.11.15 09:40:48 4: PV_Anlage_1_API: extracted JSON values to internal
2020.11.15 09:40:48 5: PV_Anlage_1_API: GetCookies is looking for Cookies
2020.11.15 09:40:48 5: PV_Anlage_1_API: ExtractSid called, context get, num 20
2020.11.15 09:40:48 4: PV_Anlage_1_API: checking for redirects, code=200, ignore=0
2020.11.15 09:40:48 4: PV_Anlage_1_API: no redirects to handle
2020.11.15 09:40:48 5: PV_Anlage_1_API: Read callback sets LAST_REQUEST to get20
2020.11.15 09:40:48 5: PV_Anlage_1_API: CheckAuth is checking buffer with ReAuthRegex (?^:"authenticated":false|"processdata":\[\]|wrong credentials|Not authorized)
2020.11.15 09:40:48 4: PV_Anlage_1_API: CheckAuth decided new authentication required

Das ist korrekt und der Plenticore liefert keine Information, weil das Login noch fehlt.
HTTPMOD hat dies auch erkannt und geht jetzt zur Anmeldung über



2020.11.15 09:40:48 4: PV_Anlage_1_API: DoAuth called with Steps: 01 02 03
2020.11.15 09:40:48 5: PV_Anlage_1_API: AddToQueue prepends type auth03 to URL http://%IP-Address_Plenticore%/api/v1/auth/create_session, data %SESSION%, header Accept-Encoding: gzip,deflate
Content-type: application/json, Accept: application/json, Connection: keep-alive, retry 0, initial queue len: 0
2020.11.15 09:40:48 5: PV_Anlage_1_API: AddToQueue prepends type auth02 to URL http://%IP-Address_Plenticore%/api/v1/auth/finish, data %FINISH%, header Accept-Encoding: gzip,deflate
Content-type: application/json, Accept: application/json, Connection: keep-alive, retry 0, initial queue len: 1
2020.11.15 09:40:48 5: PV_Anlage_1_API: AddToQueue prepends type auth01 to URL http://%IP-Address_Plenticore%/api/v1/auth/start, data %START%, header Accept-Encoding: gzip,deflate
Content-type: application/json, Accept: application/json, Connection: keep-alive, retry 0, initial queue len: 2
2020.11.15 09:40:48 5: PV_Anlage_1_API: HandleSendQueue called from HTTPMOD::DoAuth, qlen = 3
>>> drei Anmeldeschritte sind in die Queue gestellt

2020.11.15 09:40:48 5: PV_Anlage_1_API: StartQueueTimer called from HTTPMOD::ReadyForSending sets internal timer to process queue in 1.000 seconds, minSendDelay 0.2 not over
2020.11.15 09:40:48 5: PV_Anlage_1_API: AddToQueue adds type get20 to URL http://%IP-Address_Plenticore%/api/v1/processdata/scb:statistic:EnergyFlow, no data, header authorization: Session %auth_sessionId%, retry 1, initial queue len: 3
2020.11.15 09:40:48 5: PV_Anlage_1_API: HandleSendQueue called from HTTPMOD::AddToSendQueue, qlen = 4
>>> die original Anfrage kommt ans Ende der Queue

>>> Jetzt geht es mid sid01 los
2020.11.15 09:40:48 5: PV_Anlage_1_API: StartQueueTimer called from HTTPMOD::ReadyForSending sets internal timer to process queue in 1.000 seconds, minSendDelay 0.2 not over
2020.11.15 09:40:48 4: PV_Anlage_1_API: CheckAuth requeued request get20 after auth, retryCount 0 ...
2020.11.15 09:40:49 5: PV_Anlage_1_API: HandleSendQueue called from HandleTimeout, qlen = 4
2020.11.15 09:40:49 5: PV_Anlage_1_API: Replace called for type auth01, regex (?^:%IP-Address_Plenticore%), mode expression, value {ReadingsVal("PV_Anlage_1_config","IP-Address_Plenticore","")} input: Accept-Encoding: gzip,deflate
Content-type: application/json, Accept: application/json, Connection: keep-alive
2020.11.15 09:40:49 5: PV_Anlage_1_API: Replace called for type auth01, regex (?^:%START%), mode expression, value {my $NAME="PV_Anlage_1_API"; plenticore_auth("start","user","$NAME")} input: Accept-Encoding: gzip,deflate
Content-type: application/json, Accept: application/json, Connection: keep-alive
2020.11.15 09:40:49 5: PV_Anlage_1_API: Replace called for type auth01, regex (?^:%FINISH%), mode expression, value {my $NAME="PV_Anlage_1_API"; plenticore_auth("finish","user","$NAME",ReadingsVal("$NAME","auth_randomString64","missed"),ReadingsVal("$NAME","auth_nonce","missed"),ReadingsVal("$NAME","auth_salt","missed"),ReadingsVal("$NAME","auth_rounds","missed"),ReadingsVal("$NAME","auth_transactionId","missed"))} input: Accept-Encoding: gzip,deflate
Content-type: application/json, Accept: application/json, Connection: keep-alive
2020.11.15 09:40:49 5: PV_Anlage_1_API: Replace called for type auth01, regex (?^:%SESSION%), mode expression, value {my $NAME="PV_Anlage_1_API"; plenticore_auth("session","user","$NAME",ReadingsVal("$NAME","auth_randomString64","missed"),ReadingsVal("$NAME","auth_nonce","missed"),ReadingsVal("$NAME","auth_salt","missed"),ReadingsVal("$NAME","auth_rounds","missed"),ReadingsVal("$NAME","auth_transactionId","missed"),ReadingsVal("$NAME","auth_token","missed"))} input: Accept-Encoding: gzip,deflate
Content-type: application/json, Accept: application/json, Connection: keep-alive
2020.11.15 09:40:49 5: PV_Anlage_1_API: Replace called for type auth01, regex (?^:%auth_signature%), mode reading, value auth_signature input: Accept-Encoding: gzip,deflate
Content-type: application/json, Accept: application/json, Connection: keep-alive
2020.11.15 09:40:49 5: PV_Anlage_1_API: Replace called for type auth01, regex (?^:%auth_sessionId%), mode reading, value auth_sessionId input: Accept-Encoding: gzip,deflate
Content-type: application/json, Accept: application/json, Connection: keep-alive
2020.11.15 09:40:49 5: PV_Anlage_1_API: Replace called for type auth01, regex (?^:%begin_date%), mode expression, value {POSIX::strftime("%Y-%m-%d",localtime(time))} input: Accept-Encoding: gzip,deflate
Content-type: application/json, Accept: application/json, Connection: keep-alive
2020.11.15 09:40:49 5: PV_Anlage_1_API: Replace called for type auth01, regex (?^:%end_date%), mode expression, value {POSIX::strftime("%Y-%m-%d",localtime(time))} input: Accept-Encoding: gzip,deflate
Content-type: application/json, Accept: application/json, Connection: keep-alive

>>> Hier kommt das replacement für %START%
2020.11.15 09:40:49 5: PV_Anlage_1_API: Replace called for type auth01, regex (?^:%IP-Address_Plenticore%), mode expression, value {ReadingsVal("PV_Anlage_1_config","IP-Address_Plenticore","")} input: %START%
2020.11.15 09:40:49 5: PV_Anlage_1_API: Replace called for type auth01, regex (?^:%START%), mode expression, value {my $NAME="PV_Anlage_1_API"; plenticore_auth("start","user","$NAME")} input: %START%

>>> Diese Meldung habe ich auch und stheht auch im Wiki
2020.11.15 09:40:49 3: PV_Anlage_1_API: Replacement 02 with expression {my $NAME="PV_Anlage_1_API"; plenticore_auth("start","user","$NAME")} (s/(?^:%START%)/{my $NAME="PV_Anlage_1_API"; plenticore_auth("start","user","$NAME")}/gee) created warning: Use of uninitialized value in substitution iterator at ./FHEM/98_HTTPMOD.pm line 878.
>>> Du verwendest eine aktuellere HTTPMOD Version, denn da kommt wieder die Meldung mit dem "/gee)" !!!

2020.11.15 09:40:49 5: PV_Anlage_1_API: Replace: match for type auth01, regex (?^:%START%), mode expression, value {my $NAME="PV_Anlage_1_API"; plenticore_auth("start","user","$NAME")}, input: %START%, result is
>>> Und hier ist die Auswirkung davon, das result ist leer !!!

snip...

2020.11.15 09:40:49 4: PV_Anlage_1_API: HandleSendQueue sends auth01 with timeout 7 to http://192.168.3.71/api/v1/auth/start, No Data,
header: Accept-Encoding: gzip,deflate
Content-type: application/json, Accept: application/json, Connection: keep-alive
>>> die Konsequenz ist ein "No Data"
>>> Ein Beispiel von plenticore_auth("start","user","PV_Anlage_1_API") findet sich im Wiki

2020.11.15 09:40:49 5: PV_Anlage_1_API: StartQueueTimer called from HTTPMOD::HandleSendQueue sets internal timer to process queue in 1.000 seconds
2020.11.15 09:40:49 5: PV_Anlage_1_API: ReadCallback called from __ANON__
2020.11.15 09:40:49 4: PV_Anlage_1_API: Read callback: request type was auth01 retry 0,
header: HTTP/1.1 405 METHOD NOT ALLOWED
Server: nginx/1.15.2
Date: Sun, 15 Nov 2020 08:40:49 GMT
Content-Type: application/json
Content-Length: 63
Connection: close
Allow: POST, OPTIONS
Access-Control-Allow-Origin: *, body length 63
2020.11.15 09:40:49 5: PV_Anlage_1_API: Read callback: body
{"message":"The method is not allowed for the requested URL."}

>>> Ohne das data Statement meldet der Plenticore einen Fehler.


Bei diesem Problem kann nur der HTTPMOD Thread helfen.

Ich empfehle einen restore vom HTTPMOD auf eine ältere version, bis das Problem mit dem "/gee)" gelöst ist.

FVERSION 98_HTTPMOD.pm:0.228400/2020-09-24
ModuleVersion 3.5.22 - 7.2.2020

Ich habe diesen Tread im HTTPMOD verlinkt.

Viele Grüße
    Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

EDIT: plin und ich haben die neueste Version gerade bereits getestet. Ich vermute mit dem nächsten Update sollte es dann auch mit der aktuellen Version laufen, sobald Stefan es eingechecked hat.

Zitat
Im HTTPMOD scheinen noch Probleme zu bestehen, bitte aktualisiert dieses Modul noch nicht!!!
Diese Version funktioniert noch.

FVERSION 98_HTTPMOD.pm:0.228400/2020-09-24
ModuleVersion 3.5.22 - 7.2.2020

Nach einer Wiederherstellung der alten Version ist ein "shutdown restart" notwendig !
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Hallo zusammen,
ich weiß zwar nicht mehr wer es gefragt hatte, aber es ist bald soweit.

Es ging um die zu erwartende gesamt Leistung aus der Prognose Solar_Calculation_fc[0|1] , die direkt in die Datenbank geschrieben wird, damit sie dann in den Diagrammen eingezeichnet wird.
Im PV_Anlage_1 Device steht immer nur der aktuelle Wert  der laufenden Stunde.

Nun war Heiko so nett und hat eine neue Begin- und Endezeit ins DbRep eingefügt. Vielen Dank dafür an Heiko :-) , auch wenn wir die ersten sind, die schon Werte für den nächsten Tag haben.

Hier ein Beispiel für die Definition des DbRep für eine Prognoseabfrage vom nächsten Tag.

defmod LogDBRep_Test DbRep LogDB
attr LogDBRep_Test DbLogExclude .*
attr LogDBRep_Test aggregation day
attr LogDBRep_Test allowDeletion 0
attr LogDBRep_Test device PV_Anlage_1
attr LogDBRep_Test reading Solar_Calculation_fc1
attr LogDBRep_Test room Strom->Energie,System
attr LogDBRep_Test timestamp_begin next_day_begin
attr LogDBRep_Test timestamp_end next_day_end


Hiermit kann man nun den Wert im Device erstellen lassen

set LogDBRep_Test sumValue display

und es entsteht ein reading

2020-11-15__PV_Anlage_1__Solar_Calculation_fc1__SUM__2020-11-15     8240.0000      2020-11-15 15:37:07

dies kann man noch etwas umbenennen lassen

attr LogDBRep_Test readingNameMap Solar_Calculation_fc1_Sum


2020-11-15__Solar_Calculation_fc1_Sum__2020-11-15     8240.0000      2020-11-15 15:39:07


oder man schreibt den Wert wieder in die Datenbank.

Die Genauigkeit von diesem Wert kann man nur als grobe Schätzung bezeichnen und soll letztendlich das ergeben, was auf jeden Fall zu erwarten ist.
Am Diagramm von heute kann man sehen, das es über der Prognose noch einiges an Ertrag gegeben hat
Hier mal die Summen für den heutigen Tag.

Laut Plenticore Statistik 10.01 KWh Bezug von PV.
Summe Forecast fc_1  8.24 KWh (wurde gestern berechnet)
Dazu noch das passende Diagram


Gruß
    Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Und nun der Bericht zum Plenticore FW update.

Die FW und das PDF mit der Beschreibung von der Webseite runterladen.
Im Web Gui des Plenticore den update nach der Anleitung ausführen.
Nach dem Neustart dauert es einige Zeit, bis man sich wieder am Plenticore anmelden kann, nur Geduld.

Ich vermute, durch die Erweiterung im Bereich der Batteriesteuerung wurden die Einstellungen nicht sauber übernommen.
Bitte überprüft die Einstellungen im Servicemenü/Batterieeinstellungen.
Die neue Option Batteriesteuerung intern ist für den Anwender nicht zu verstellen.
"MinSoc" und "Intelligente Batteriesteuerung aktivieren" waren wohl auf einem Default Wert.

Die Abfrage von ModBus mit dem PV_Anlage_1 lief problemlos weiter.

Leider passen die Abfragen vom PV_Anlage_1_API Statistic_* nicht mehr, die ich dann noch anpassen werde.

VG
   Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Hallo zusammen,

ich werde gleich noch die PV_Anlage_1_API für Firmware 01.16.05025 des Plenticore ins Wiki stellen.
Diese beinhaltet dann schon mal einige neue Statistiken und die bisherigen natürlich auch.
Neu sind dann bisher diese, die als day, month, year und total verfügbar sind.

Diese hier sind für die Batterie recht interessant und werden dann sicherlich einige userreadings ablösen.
Das dürfte dann auch weiterhin mit Vermutungen über die Batterie Energieflüsse aufräumen.
Statistic_EnergyChargeGrid_Day
Statistic_EnergyChargeInvIn_Day
Statistic_EnergyChargePv_Day
Statistic_EnergyDischarge_Day
Statistic_EnergyDischargeGrid_Day

Das spart dann noch das Aufsummieren
Statistic_EnergyHomeOwn_Total

Und hier kommt noch die Leistung pro String.
Der String, an dem der Speicher hängt ist dann auf Null.
Statistic_EnergyPv1_Day
Statistic_EnergyPv2_Day
Statistic_EnergyPv3_Day


Mit den nacharbeiten mach ich dann die Woche weiter.

EDIT: Die bisherigen get/set Möglichkeiten habe ich getestet und sie funktionieren mit der Version 1.16 des Plenticore weiterhin.

VG
  Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

killah78

Hi ch.eick

die neuen Modbus Register habe ich so eingebunden:

attr Plenticore dev-type-Fl_R2-format %.2f
attr Plenticore dev-type-Fl_R2-len 2
attr Plenticore dev-type-Fl_R2-revRegs 1
attr Plenticore dev-type-Fl_R2-unpack f>

attr Plenticore obj-h1046-poll 1
attr Plenticore obj-h1046-reading TotalDCChargeEnergy(DC-sideToBattery)
attr Plenticore obj-h1046-type Fl_R2
attr Plenticore obj-h1048-poll 1
attr Plenticore obj-h1048-reading TotalDCDischargeEnergy(DC-sideFromBattery)
attr Plenticore obj-h1048-type Fl_R2
attr Plenticore obj-h1050-poll 1
attr Plenticore obj-h1050-reading TotalACChargeEnergy(AC-sideToBattery)
attr Plenticore obj-h1050-type Fl_R2
attr Plenticore obj-h1052-poll 1
attr Plenticore obj-h1052-reading TotalACDischargeEnergy(batteryToGrid)
attr Plenticore obj-h1052-type Fl_R2
attr Plenticore obj-h1054-poll 1
attr Plenticore obj-h1054-reading TotalACChargeEnergy(gridToBattery)
attr Plenticore obj-h1054-type Fl_R2
attr Plenticore obj-h1056-poll 1
attr Plenticore obj-h1056-reading TotalDCPVEnergy(sumOfAllPVInputs)
attr Plenticore obj-h1056-type Fl_R2
attr Plenticore obj-h1058-poll 1
attr Plenticore obj-h1058-reading TotalDCEnergyFromPV1
attr Plenticore obj-h1058-type Fl_R2
attr Plenticore obj-h1060-poll 1
attr Plenticore obj-h1060-reading TotalDCEnergyFromPV2
attr Plenticore obj-h1060-type Fl_R2
attr Plenticore obj-h1062-poll 1
attr Plenticore obj-h1062-reading TotalDCEnergyFromPV3
attr Plenticore obj-h1062-type Fl_R2
attr Plenticore obj-h1064-poll 1
attr Plenticore obj-h1064-reading TotalEnergyAC-sideToGrid
attr Plenticore obj-h1064-type Fl_R2
attr Plenticore obj-h1066-poll 1
attr Plenticore obj-h1066-reading TotalDCPower(sumOfAllPVInputs)
attr Plenticore obj-h1066-type Fl_R2


So werden die Werte gelesen.
Ich habe bisher noch nicht verstanden, was der Unterschied zwischen TotalACChargeEnergy(AC-sideToBattery) und TotalACChargeEnergy(gridToBattery) ist. Wird bei euch vermutich 0 sein, da mit einem Wechserichter ja nicht aus AC geladen wird.
Gewünscht hätte ich mir sowas wie, Laden aus EVU Netz und Laden aus anderer AC Quelle, aber nicht aus EVU Netz. Ist es bei mir aber nicht. GridToBattery ist geringfügig niedriger als AC-sideToBattery.
Viele Grüße

ch.eick

Zitat von: killah78 am 16 November 2020, 12:19:29
die neuen Modbus Register habe ich so eingebunden:

So werden die Werte gelesen.
Ich habe bisher noch nicht verstanden, was der Unterschied zwischen TotalACChargeEnergy(AC-sideToBattery) und TotalACChargeEnergy(gridToBattery) ist. Wird bei euch vermutich 0 sein, da mit einem Wechserichter ja nicht aus AC geladen wird.
Gewünscht hätte ich mir sowas wie, Laden aus EVU Netz und Laden aus anderer AC Quelle, aber nicht aus EVU Netz. Ist es bei mir aber nicht. GridToBattery ist geringfügig niedriger als AC-sideToBattery.

Hallo und vielen Dank,
dann kann ich die jetzt ja so übernehmen.

Ich deute jetzt mal, unter der Prämisse, dass es dort einen KSEM gibt, die Glaskugel.
   TotalACChargeEnergy(AC-sideToBattery)
        Hier wird die Energie von der AC Seite genommen, ohne das es aus dem Grid kommt. Dafür muss ein zweiter WR da sein, der die Energie liefert.
        Speicher wird geladen, aber KSEM sagt kein Bezug aus dem Netz und kein Bezug über PV

   TotalACChargeEnergy(gridToBattery)
        Hier wurde mit dem KSEM festgestellt, dass die Energie aus dem Grid kam
        Speicher wird geladen und KSEM meldet Netzbezug. Wird gleichzeitig PV Energie geliefert, müsste diese natürlich mit berücksichtigt werden.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

killah78

Ja genauso hätte ich es mir auch vorgestellt.
So funktioniert es aber leider nicht. Es wird von AC Seite geladen, aber eben nicht aus dem Netz. Trotzdem werden diese beiden Register gefüllt.
Der eine eben nur einen Tick geringer als der andere.
Und ja, KSEM ist Netzseitig verbaut.

ch.eick

Zitat von: killah78 am 16 November 2020, 15:14:24
Ja genauso hätte ich es mir auch vorgestellt.
So funktioniert es aber leider nicht. Es wird von AC Seite geladen, aber eben nicht aus dem Netz. Trotzdem werden diese beiden Register gefüllt.
Der eine eben nur einen Tick geringer als der andere.
Und ja, KSEM ist Netzseitig verbaut.
Dann würde ich das direkt bei Kostal melden.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

So, auf der Wiki Seite gibt es eine aktualisierte Versin des PV_Anlage_1_API für v1.16


- Die Benennung der get und set Aufrufe hat sich geändert
- interne/externe Batterie Abfragen
- Batterie Abfrage ist nun nach intern/extern gruppiert, sodass gleichzeitig mehrere Werte gelesen werden
- interne Batterie Steuerung mit set Befehlen (ging bisher auch schon)
- Statistic_ Werte sind nun mit zwei Nachkommastellen Formatiert
- Es gibt zusätzliche Statistic_* Werte


Natürlich wird hier noch einiges kommen um die neuen Werte mit ein zu bauen. Dafür muss ich sie aber erstmal sichten.
Eigene userreadings können wahrscheinlich entfernt werden, so wie das bisher gesehen habe.

Bei der Batteriesteuerung könnte man sich noch sinnvolle Szenarien überlegen. Bitte seit etwas vorsichtig und schreibt Euch die bisherige Konfiguration auf, bevor Ihr dort Werte ändert.

RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

ch.eick

Hallo zusammen,
mal wieder ein Randthema. Wer die Prognosekurve für Morgen schon mal sehen möchte, der das in Grafana mit der Angabe einer Absoluten Zeit erreichen.

Im DbRep ist nun auch ein next_day_[begin|end] enthalten, mit dem man nun auch die daten wieder abfragen und z.B. ein sumValue durchführen kann.
Genaueres siehe hier: Prognose vom nächsten Tag sehen

Gruß
   Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

DS_Starter

ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

plin

Zitat von: ch.eick am 17 November 2020, 18:14:40
Wer die Prognosekurve für Morgen schon mal sehen möchte, der das in Grafana mit der Angabe einer Absoluten Zeit erreichen.

Nicht nur. Ich verwende dafür den Zeitraum now/d to now+7d. Dann sieht man den aktuellen Tag sowie die nächsten x Tage.

VG Peter
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

killah78

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