FHEM Forum

• Plenticore 10 Plus
• KSEM
• BYD HV
• Forecast/Leistungsprognose
• Bilanz
• Eigenverbrauch Steuerung

Zitat von: killah78 am 28 Oktober 2020, 13:37:48
Als Besonderheit bei mir ist, dass ich zwei Wechelrichter habe, einen Plenticore mit Batterie und einen IQ (quasi baugleich, aber ohne Batterie).
Derzeit lese ich Werte über Modbus aus und rechne mir was zusammen. Leider klappt das nicht komplett und ich komme nicht auf die Werte, die ich im Portal sehe.

Zitat
Ich denke, das in der Api Informationen vorhanden sein müssen, die ich im Modbus nicht bekomme.

Zitat
Nochmal Edit: Habe das API Device jetzt eingerichtet. Aber komme nicht weiter. Muss ich "%IP-Address_Plenticore%" mit der IP-Adresse ersetzen oder wird da automatisch irgendwo ersetzt? Wenn ich jetzt die Statistik abrufen möchte, muss ich manuell zuerst get 01... und get 02... ausführen? Im moment bekomme ich immer die Meldung "authentication failed". Das password ist wirklich der Masterkey vom Gehäuse?

Zitat von: killah78 am 28 Oktober 2020, 13:37:48
ZB. ist es so, dass der Plenticore auch über die AC Seite lädt (das was halt der IQ erzeugt). Hier erhalte ich dann falsche Ertragswerte. Denn der Plenticore zählt keine "Yield"-Werte, wenn die Batterie geladen wird, der IQ zählt aber immer "Yield", da es für ihn immer eine Einspeisung ist. Somit zählt der Plenticore dann beim Batterieentladen "Yield", die der IQ aber bereits gezählt hat. Also ist bei mir die "Yield"-Summe zu hoch. Ich habe somit keine korrekten Ertragswerte. Im Portal werden die Etragswerte gezählt, die wirklich vom Dach kommen. Also auch was in die Batterie geht. Da passt das, es muss also dann doch irgendwie errechenbar sein. Ob Ertrag jetzt gezählt wird, beim Laden oder Entladen der Batterie sei mal dahingestellt.

Zitat von: killah78 am 28 Oktober 2020, 21:07:54
Also irgendwie klappt das nicht mit dem Api abfragen. Ist es denn tatsächlich der masterkey vom Etikett des Gehäuses? Das ist das einzige was ich da finde. Oder ist es das vergeben Passwort für das webinterface?
Ich bekomme jetzt immer "user locked" .

Edit: Ok, User war tatsächlich gesperrt und musste über das Webinterface "freigeschaltet" werden. Passwort ist in dem Kontext also das Passwort "Anlagenbetreiber" aus dem Webinterface. Damit klappt jetzt auch der Datenabruf. Jetzt muss ich mir erstmal den Kopf zerbrechen zu den ganzen Zahlen die ich bekomme.

Zitat
Ich denke, das ja keine andere Daten als wir aus dem Modbus bzw Api bekommen, auch ans Portal gehen. Im Portal können die Werte auf mit zwei Wechelrichtern korrekt aufsummiert werden. Daher denke ich, sollte das im FHEM auch klappen. Nur mit Modbus bekomme ich es aber nicht hin.
Aber ja, wie du sagst, erstmal Schritt für Schritt.

Zitat
Sind übrigens 9,9kwp auf 3 Dachflächen bzw 4 Strings aufgeteilt.

Zitat
Aber es klappt erstmal. Schon mal vielen Dank. Werde bestimmt weitere Fragen haben.... :-)

Zitat
ich bin weiterhin am Thema dran und sammle noch, da mein KSEM noch nicht installiert ist. Ich habe die ersten Grafana-Dashboards erstellt und merke jetzt was mir wo noch fehlt. Ist halt ein iterativer Prozess...

Zitat
Auch beim Forecast habe ich noch Verbesserungspotential. Aktuell nutze ich noch dwdforecast von kilianknoll.

Zitat
Das kannst Du auch bei meiner Umsetzung anpassen. Ich habe mit Kilian zusammen gefachsimpelt, bis ich die Lösung auf Fhem optimiert habe und er die pvlib eingeführt hat.
Die Besonderheit der Module kannst Du auf die Nennleistung und den Temperaturkoeffizienten runter brechen.
Für die Sonnenstände könntest Du mit einfachen Mitteln in der Solar_plain Funktion weitere Einschränkungen vornehmen.
Ein generelles zu hoch/niedrig der Werte stellst Du über den fixen Faktor in der PV_Anlage_1_config ein.
Regen und Wolken mit den anderen Anpassungskurven alla "Heizungskurve".
Das Ergebnis findest Du für heute im Anhang.

Zitat
PV_Anlage ist aktuell ein Sammlung von verschiedenen Elementen und Programmiersprachen. Da könnte man ein schönes Modul draus machen ...

Zitat von: plin am 08 November 2020, 12:14:08
Bei mir sieht es durchwachsen aus. Mein Prod-FHEM hat Probleme. In meiner Dev-Instanz habe ich die PV_Anlage_1_API gelöscht und neu eingerichtet. Nach kurzer Zeit ging es, die auth-Readings wurden gesetzt, es erschienen Werte in der Status-Tabelle.
"update all" der Prod-Instanz => keine Änderung
"update all" der Dev-Instanz => jetzt geht's auch da nicht mehr

Zitat
Der Knackpunkt scheint die Erzeugung des auth_randomString64  zu sein. Im Log erscheint folgende Meldung

Code Auswählen Erweitern


2020.11.08 12:02:46 5: PV_Anlage_1_API: get called with 01_/auth/start
2020.11.08 12:02:46 5: PV_Anlage_1_API: get found option 01_/auth/start in attribute get01Name
2020.11.08 12:02:46 4: PV_Anlage_1_API: get will now request 01_/auth/start, no optional value
2020.11.08 12:02:46 5: PV_Anlage_1_API: AddToQueue adds type get01 to URL http://%IP-Address_Plenticore%/api/v1/auth/start, data {"nonce": "%randomString64%","username": "user"}, header Accept-Encoding: gzip,deflate
Content-type:application/json, Accept:application/json, Connection:keep-alive, retry 0, initial queue len: 0
2020.11.08 12:02:46 5: PV_Anlage_1_API: HandleSendQueue called from HTTPMOD::AddToSendQueue, qlen = 1
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, 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.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%auth_transactionId%), mode reading, value auth_transactionId input: Accept-Encoding: gzip,deflate
Content-type:application/json, Accept:application/json, Connection:keep-alive
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%auth_proof%), mode reading, value auth_proof input: Accept-Encoding: gzip,deflate
Content-type:application/json, Accept:application/json, Connection:keep-alive
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%randomString64%), mode expression, value {my $NAME = "PV_Anlage_1_API" ;;fhem("deletereading ".$NAME." message");;fhem("deletereading ".$NAME." auth.*");;my @chars=('a'..'z','A'..'Z','0'..'9'); my $r; foreach(1..16) {$r.=$chars[rand @chars];};; fhem("setreading ".$NAME." auth_randomString64 ".$r);; $r;;} input: Accept-Encoding: gzip,deflate
Content-type:application/json, Accept:application/json, Connection:keep-alive
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%auth_randomString64%), mode reading, value auth_randomString64 input: Accept-Encoding: gzip,deflate
Content-type:application/json, Accept:application/json, Connection:keep-alive
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%auth_token%), mode reading, value auth_token input: Accept-Encoding: gzip,deflate
Content-type:application/json, Accept:application/json, Connection:keep-alive
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, 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.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%auth_authtag%), mode reading, value auth_authtag input: Accept-Encoding: gzip,deflate
Content-type:application/json, Accept:application/json, Connection:keep-alive
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%auth_payload%), mode reading, value auth_payload input: Accept-Encoding: gzip,deflate
Content-type:application/json, Accept:application/json, Connection:keep-alive
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%auth_iv%), mode reading, value auth_iv input: Accept-Encoding: gzip,deflate
Content-type:application/json, Accept:application/json, Connection:keep-alive
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, 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.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, 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.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, 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
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%IP-Address_Plenticore%), mode expression, value {ReadingsVal("PV_Anlage_1_config","IP-Address_Plenticore","")} input: {"nonce": "%randomString64%","username": "user"}
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%auth_transactionId%), mode reading, value auth_transactionId input: {"nonce": "%randomString64%","username": "user"}
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%auth_proof%), mode reading, value auth_proof input: {"nonce": "%randomString64%","username": "user"}
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%randomString64%), mode expression, value {my $NAME = "PV_Anlage_1_API" ;;fhem("deletereading ".$NAME." message");;fhem("deletereading ".$NAME." auth.*");;my @chars=('a'..'z','A'..'Z','0'..'9'); my $r; foreach(1..16) {$r.=$chars[rand @chars];};; fhem("setreading ".$NAME." auth_randomString64 ".$r);; $r;;} input: {"nonce": "%randomString64%","username": "user"}
2020.11.08 12:02:46 3: PV_Anlage_1_API: Replacement 04 with expression {my $NAME = "PV_Anlage_1_API" ;;fhem("deletereading ".$NAME." message");;fhem("deletereading ".$NAME." auth.*");;my @chars=('a'..'z','A'..'Z','0'..'9'); my $r; foreach(1..16) {$r.=$chars[rand @chars];};; fhem("setreading ".$NAME." auth_randomString64 ".$r);; $r;;} (s/(?^:%randomString64%)/{my $NAME = "PV_Anlage_1_API" ;;fhem("deletereading ".$NAME." message");;fhem("deletereading ".$NAME." auth.*");;my @chars=('a'..'z','A'..'Z','0'..'9'); my $r; foreach(1..16) {$r.=$chars[rand @chars];};; fhem("setreading ".$NAME." auth_randomString64 ".$r);; $r;;}/gee) created warning: Use of uninitialized value in substitution iterator at ./FHEM/98_HTTPMOD.pm line 877.

2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace: match for type get01, regex (?^:%randomString64%), mode expression, value {my $NAME = "PV_Anlage_1_API" ;;fhem("deletereading ".$NAME." message");;fhem("deletereading ".$NAME." auth.*");;my @chars=('a'..'z','A'..'Z','0'..'9'); my $r; foreach(1..16) {$r.=$chars[rand @chars];};; fhem("setreading ".$NAME." auth_randomString64 ".$r);; $r;;}, input: {"nonce": "%randomString64%","username": "user"}, result is {"nonce": "","username": "user"}
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%auth_randomString64%), mode reading, value auth_randomString64 input: {"nonce": "","username": "user"}
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%auth_token%), mode reading, value auth_token input: {"nonce": "","username": "user"}
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%auth_signature%), mode reading, value auth_signature input: {"nonce": "","username": "user"}
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%auth_authtag%), mode reading, value auth_authtag input: {"nonce": "","username": "user"}
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%auth_payload%), mode reading, value auth_payload input: {"nonce": "","username": "user"}
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%auth_iv%), mode reading, value auth_iv input: {"nonce": "","username": "user"}
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%auth_sessionId%), mode reading, value auth_sessionId input: {"nonce": "","username": "user"}
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%begin_date%), mode expression, value {POSIX::strftime("%Y-%m-%d",localtime(time))} input: {"nonce": "","username": "user"}
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%end_date%), mode expression, value {POSIX::strftime("%Y-%m-%d",localtime(time))} input: {"nonce": "","username": "user"}
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%IP-Address_Plenticore%), mode expression, value {ReadingsVal("PV_Anlage_1_config","IP-Address_Plenticore","")} input: http://%IP-Address_Plenticore%/api/v1/auth/start
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace: match for type get01, regex (?^:%IP-Address_Plenticore%), mode expression, value {ReadingsVal("PV_Anlage_1_config","IP-Address_Plenticore","")}, input: http://%IP-Address_Plenticore%/api/v1/auth/start, result is http://192.168.3.71/api/v1/auth/start
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%auth_transactionId%), mode reading, value auth_transactionId input: http://192.168.3.71/api/v1/auth/start
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%auth_proof%), mode reading, value auth_proof input: http://192.168.3.71/api/v1/auth/start
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%randomString64%), mode expression, value {my $NAME = "PV_Anlage_1_API" ;;fhem("deletereading ".$NAME." message");;fhem("deletereading ".$NAME." auth.*");;my @chars=('a'..'z','A'..'Z','0'..'9'); my $r; foreach(1..16) {$r.=$chars[rand @chars];};; fhem("setreading ".$NAME." auth_randomString64 ".$r);; $r;;} input: http://192.168.3.71/api/v1/auth/start
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%auth_randomString64%), mode reading, value auth_randomString64 input: http://192.168.3.71/api/v1/auth/start
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%auth_token%), mode reading, value auth_token input: http://192.168.3.71/api/v1/auth/start
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%auth_signature%), mode reading, value auth_signature input: http://192.168.3.71/api/v1/auth/start
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%auth_authtag%), mode reading, value auth_authtag input: http://192.168.3.71/api/v1/auth/start
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%auth_payload%), mode reading, value auth_payload input: http://192.168.3.71/api/v1/auth/start
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%auth_iv%), mode reading, value auth_iv input: http://192.168.3.71/api/v1/auth/start
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%auth_sessionId%), mode reading, value auth_sessionId input: http://192.168.3.71/api/v1/auth/start
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%begin_date%), mode expression, value {POSIX::strftime("%Y-%m-%d",localtime(time))} input: http://192.168.3.71/api/v1/auth/start
2020.11.08 12:02:46 5: PV_Anlage_1_API: Replace called for type get01, regex (?^:%end_date%), mode expression, value {POSIX::strftime("%Y-%m-%d",localtime(time))} input: http://192.168.3.71/api/v1/auth/start
2020.11.08 12:02:46 4: PV_Anlage_1_API: HandleSendQueue sends get01 with timeout 7 to http://192.168.3.71/api/v1/auth/start,
data: {"nonce": "","username": "user"},
header: Accept-Encoding: gzip,deflate
Content-type:application/json, Accept:application/json, Connection:keep-alive
2020.11.08 12:02:46 5: PV_Anlage_1_API: ReadCallback called from __ANON__
2020.11.08 12:02:46 4: PV_Anlage_1_API: Read callback: request type was get01 retry 0,
header: HTTP/1.1 200 OK
Server: nginx/1.15.2
Date: Sun, 08 Nov 2020 11:02:46 GMT
Content-Type: application/json
Content-Length: 154
Connection: close
Access-Control-Allow-Origin: *
Cache-Control: max-age=0, no-cache, no-store, must-revalidate, body length 154
2020.11.08 12:02:46 5: PV_Anlage_1_API: Read callback: body
{"nonce":"zDrc7AMVkr8JWEJH","salt":"v89J\/Ggdnq0GW8mh","rounds":29000,"transactionId":"6310d6d61e9e201bf2f1e739a358426f3abaea4a69339df5a520fdf80d862d30"}


Zitat von: ch.eick am 08 November 2020, 14:03:08
Das hier sieht komisch aus...

Code Auswählen Erweitern

ndomString64 ".$r);; $r;;}/gee)
Woher kommt das "/gee)" ist das ein Copy/Paste Fehler?
Durch den Fehler wird an dieser Stelle das Replacement nicht gemacht.

Zitat von: plin am 08 November 2020, 14:18:28
Das "/gee" habe ich gesehen aber nicht hinterfragt (habe die '}' übersehen und gedacht das wäre der Ersatzcode).
Ich habe das replacement04Value noch mal alleine übernommen und nun klappt's.
Vielleicht ist der Fehler beim Upload passiert. Ich hatte die raw-Defintion in ein separates File kopiert und via telnet hochgeladen. Bisher hatte ich damit noch keine Probleme. Aber es gibt für alles ein erste Mal.

Zitat
Als nächstes brauche ich jetzt noch die DWD_Forecast-Daten. Bisher hole ich mir Regen und Bewölkung aus den Proplanata-Daten, die DWD-Daten sind aber granularer.

Zitat
Ich glaube die HttpUtils_NonblockingGet  müssen in einem FHEM-Modul ausgeführt werden. Jedenfalls braucht man $hash für die Antwort. Mit dem Wissen kann ich einen neuen Versuch starten. Was erforderlich ist ist in meinen python-Skipten drin. Ich hoffe es so aufbauen zu können, dass man es als function in die 99_myUtils.pm übernehmen kann.

Zitat von: ch.eick am 08 November 2020, 17:06:42
Das ist von plin:

Zitat von: plin am 08 November 2020, 20:56:29
Und ich habe erfolgreich den ersten Schritt (Step1) in perl realisiert, einige Grundsatzfragen sind damit geklärt, der Rest ist nur noch Arbeit.

Zitat von: plin am 08 November 2020, 14:18:28
Das "/gee" habe ich gesehen aber nicht hinterfragt (habe die '}' übersehen und gedacht das wäre der Ersatzcode).
Ich habe das replacement04Value noch mal alleine übernommen und nun klappt's.
Vielleicht ist der Fehler beim Upload passiert. Ich hatte die raw-Defintion in ein separates File kopiert und via telnet hochgeladen. Bisher hatte ich damit noch keine Probleme. Aber es gibt für alles ein erste Mal.

Zitat von: ch.eick am 08 November 2020, 21:57:43
??? Das sieht nach dem Python Skript aus, das ich bereits ausgebaut habe ???
In der alten Implementierung gab es diese http Aufrufe mit Python bereits, inklusive der Übergabe an Fhem.
Das verstehe ich jetzt nicht.

Ich bin sehr gespannt auf die Perl Umsetzung.

Zitat von: plin am 09 November 2020, 07:17:14
Ok, das ist lustig. Ich bin ja spät eingestiegen (erst Ende Oktober) und habe anscheinend einen Programmrumpf von Dir gefunden (Anfang des Programms) und den Code wieder ergänzt, den Du entfernt hast (ich brauchte ja eine Übergangslösung für mein \gee-Problem). Das Ende stammt eindeutig von mir  :).

Anyway: Die Logik und der Ablauf passen, daran kann ich mich orientieren.

Zitat von: KölnSolar am 09 November 2020, 13:16:09
das https://forum.fhem.de/index.php/topic,115702.msg1099652.html#msg1099652 wär doch noch was für Dich. Scheinbar eine etwas feinere Prognose.
Meine Meinung kennst Du ja zu Prognosen.  ;)

Zitat von: Mumpitz am 10 November 2020, 19:58:49
Ich habe den Forecast ebenfalls integriegriet und zum laufen bekommen.
Nun ist es so dass alle berechneten Werte ausführlich in das Fhem Log geschrieben werden. Kann man das irgendwie einfach unterbinden? Mir würde es reichen wenn die entsprechenden Readings geschrieben werden.

Zitat von: killah78 am 14 November 2020, 11:02:17
Hat sich nach dem Firmwareupdate eigentlich was am API verändert oder ist was hinzugekommen? Im Modbus gibts ein paar neue Werte, die mir bei meinen zwei Wechselrichtern hoffentlich helfen. ZB wird die Lade- und Entladenergie gezählt.
Naja, bin immer noch dabei die Zahlen zu beobachten und die Enden zusammenzubekommen.
Echt sehr gute Arbeit die Du/ihr hier leistet. :-)

ZitatDank der Arbeit von plin , der die Python Skripte zu Perl migriert hat

Zitat von: KölnSolar am 14 November 2020, 12:46:25
Prima. Ein externer Fremdzugriff mit Fremdsoftware weniger.

Zitat von: plin am 15 November 2020, 09:14:20
Ich habe ein Problem mit dem Statement

Code Auswählen Erweitern

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

Code Auswählen Erweitern

gethostbyname {ReadingsVal("PV_Anlage_1_config","IP-Address_Plenticore","")} failed

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

Zitat
Auf meiner Prod-Instanz (x86 mit openSUSE Leap 15.2) erhalte ich eine

Code Auswählen Erweitern

info_message      The method is not allowed for the requested URL.

Zitat
Das zugehörige Log von der Prod-Instanz

Code Auswählen Erweitern


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

Code Auswählen Erweitern


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.

Code Auswählen Erweitern


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


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

Code Auswählen Erweitern


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 !

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.

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.

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.

Zitat von: killah78 am 18 November 2020, 09:24:44
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

Zitat von: ch.eick am 18 November 2020, 09:34:48
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

Zitat von: Mumpitz am 18 November 2020, 20:33:51
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...

Zitat von: killah78 am 20 November 2020, 09:55:39
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.

Zitat
Sehe ich auch so.

Zitat
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)


Zitat
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.

Zitat
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

Zitat von: billy-boy am 21 November 2020, 02:21:06
Einloggen mit Python3 funktioniert.

Zitat
Der KeyValue() Test klappt noch.

Zitat
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."

Zitat
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.

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

Zitat von: ch.eick am 21 November 2020, 08:26:10

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;


Zitat von: Mumpitz am 21 November 2020, 14:02:50
Das verstehe ich ebenfalls nicht ganz. Wo muss man das in der 99_myUtils eintragen? Im Wiki sind die beiden Routinen ja beschrieben welche in die 99_myUtils müssen. Dort finde ich den obigen Teil jedoch nicht. Kannst Du das etwas präzisieren?

Zitat von: ch.eick am 21 November 2020, 14:05:58
Mit diesen Einträgen lädt man zusätzliche Funktionen aus Perl Bibliotheken in ein Modul.

Zitat
Hast Du auch das hier in 99_myUtils aufgenommen?
Code: [Auswählen]
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;

Zitat

Zitat
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.

Zitat
Was nützen diese Werte wenn das Device PV_Anlage_1 später deinstaliert werden. Es handelt sich ja um die mit Python abgefragten Werte.

Zitat von: ujaudio am 01 Dezember 2020, 10:39:40
Trotzdem werde ich mich damit beschäftigen, ich sehe das Ganze mehr als Hobby. Dennoch hier mal die Frage: wie stark konntest du die Eigenverbrauchsquote mit deiner Applikation denn erhöhen?

Zitat von: kanenas am 04 Dezember 2020, 06:37:10
Es geht um die Kapazität von BYD Batterien und die reale/gemessene Effektivität.

Zitat von: Mumpitz am 08 Dezember 2020, 05:23:01
Unteranderem wird dabei ja die Batterie zuerst auf 90% geladen bevor sie wieder entladen wird. Im Moment steht sie seit Tagen auf ca. 54%. Die Batterie befindet sich dabei im Normal Modus. Ist das bei euch auch so oder ist sie bei euch im Ruhemodus?

Zitat von: DS_Starter am 14 Dezember 2020, 16:06:21
vielleicht hast du/ihr schon gesehen dass ich gerade an einem Solar Forecast Modul baue.
Grundlage ist wie bei deiner Lösung auch DWD_OpenData.

Nun meine Frage. Gibt es schon Erfahrungen wie gut die Strahlungserwartung des DWD ist ?
Heute zum Beispiel habe ich eine starke Abweichung des tatsächlichen Geschehens von der Vorhersage festgestellt.
Vielleicht war es einfach nur ein ungünstiger Fall. Ich schaue mir DWD Data erst seit kurzem an. Wie sind eure Erfahrungen ?

Zitat von: DS_Starter am 15 Dezember 2020, 17:07:45
Das Forecast-Modul ist eigentlich nur ein "Abfallprodukt" des SMAPortal-Moduls welches durch die SMA Strategie leider zu den Akten gelegt werden musste.
Wir hatte seinerzeit viel Arbeit in die Grafik investiert und das wollte ich einfach nur retten und etwas brauchbares damit der Community zur Verfügung stellen. In diesem Forecast Device soll aber nicht nur die Prognose für den Standort vorausgesagt werden, sondern auch andere Mehrwerte die man für eine Steuerung auswerten kann. Zum Beispiel eine 4h Forecast bzw. eine Empfehlung per Reading, wann man planen könnte zusätzliche Verbraucher einzuschalten und solche Dinge.

Nur sollte es etwas mehr als ein bloßer Blick in die Glaskugel sein.  ;)

Jetzt frage ich mich natürlich, der rad1h Wert nicht bereits die prognostizierten Wetterverhältnisse (Bewölkung, Regen usw.) beinhaltet ?
Und was ist mit einer Direktstrahlung, gibt es diese Angabe im DWD_OpenData ? Der Rad1h Wert ist doch nur die diffuse Globalstrahlung oder sehe ich das falsch ?

Zitat von: DS_Starter am 15 Dezember 2020, 17:58:51
Danke Christian und ich gebe dir der Sinnhaftigkeit von Vorhersagen weitgehend Recht.
Aber du hast etwas wichtiges vergessen zu erwähnen ... den Spieltrieb  :D

Zitat von: ch.eick am 16 Dezember 2020, 08:59:08
Guten morgen zusammen,

der Fehlerteufel hat wieder zugeschlagen. In der API von Kostal ist ein Schreibfehler, den ich durch Copy/Paste der Wertenamen einfach mit übernommen habe.

Es lässt sich recht einfach korrigieren, da dieser Wert in meiner Implementierung nicht in die Datenbank geht.

Code Auswählen Erweitern


## Achtung, beim http Aufruf der API muss der Rechtschreibfehler bestehen bleiben, da Kostal ja die API noch nicht korrigiert hat.
attr PV_Anlage_1_API get22-3Name Battery_InternControl_MinHomeConsumption
attr PV_Anlage_1_API set223Name 22_3_Battery_MinHomeConsumption

## Im PV_Schedule müssen ebenfalls zwei Zeilen im DEF korrigiert werden, aber nur wenn Ihr die Batteriesteuerung im Herbst/Winter einsetzt.

1.) (set PV_Anlage_1_API 22_3_Battery_MinHomeConsumption [PV_Anlage_1_API:Battery_Info_WorkCapacity])
2.) (set PV_Anlage_1_API 22_3_Battery_MinHomeConsumption 50)


Viele Grüße
    Christian

Zitat von: Mumpitz am 16 Dezember 2020, 09:09:16
Einmal mehr ein grosses Dankeschön für deinen unermüdlichen Einsatz für uns alle!!! Echt unglaublich wie du uns alle immer wieder sofort von deiner grossen Arbeit profitieren lässt!

Zitat von: knuddli am 18 Dezember 2020, 17:16:52

Code Auswählen Erweitern

Messages collected while initializing FHEM:
configfile: PV_Anlage_1_API: unknown attribute DbLogExclude. Type 'attr PV_Anlage_1_API ?' for a detailed list.
PV_Anlage_1_API: unknown attribute DbLogInclude. Type 'attr PV_Anlage_1_API ?' for a detailed list.
PV_KSEM: unknown attribute DbLogExclude. Type 'attr PV_KSEM ?' for a detailed list.
BYD_Status: unknown attribute DbLogExclude. Type 'attr BYD_Status ?' for a detailed list.
PV_Schedule: unknown attribute DbLogExclude. Type 'attr PV_Schedule ?' for a detailed list.
The specified DbLog-Device "LogDB" doesn't exist.
The specified DbLog-Device "LogDB" doesn't exist.
The specified DbLog-Device "LogDB" doesn't exist.
The specified DbLog-Device "LogDB" doesn't exist.
DB_Service_Schedule: unknown attribute DbLogExclude. Type 'attr DB_Service_Schedule ?' for a detailed list.
DWD_Forecast: unknown attribute DbLogExclude. Type 'attr DWD_Forecast ?' for a detailed list.
Astro: unknown attribute DbLogExclude. Type 'attr Astro ?' for a detailed list.
Astro: unknown attribute DbLogInclude. Type 'attr Astro ?' for a detailed list.
Can't open ./db.conf: No such file or directory
The specified DbLog-Device "LogDB" doesn't exist.
Invalid characters in name (not A-Za-z0-9._): wetter_
Unknown command
, try help. Unknown command ====, try help. Unknown command
, try help.
[Shelly] Invalid IP address  of Shelly device
[Shelly] Invalid IP address  of Shelly device

Autosave deactivated

Das FHEM (6) ist frisch auf Debian 10 installiert und ich habe auch die ganzen geforderten *perl*.deb installiert. Dennoch scheint da was mit der Datenbank (welche Datenbank eigentlich?) falsch zu sein. Den Plenticore und den KSEM sehe ich. Einen BYD habe ich nicht.
Ist es möglich einfach mal die fhem.cfg, 99_myUtils.pm und ggf. noch weitere fehlende Dateien anzuhängen. Damit hat man erst mal die initiale Konfiguration. Trotz copy & paste hab ich sicher was falsch gemacht. Die Schellys gibt es allerdings nicht! Welche Voraussetzungen muss das FHEM schon vorher mitbringen (Datenbank?).

So groß brauche ich das im Prinzip auch nicht. Mir reicht es schon einen Dummy (oder MQTT*dingens) bei 2000W DC ein und bei 1000W wieder aus zu schalten.

Zitat von: knuddli am 19 Dezember 2020, 13:07:00
danke für die schnelle Antwort. Die Datenbank ist angelegt und scheint zu funktionieren. Zumindest sind nun keine Fehlermeldungen mehr da.
Ist das Normal das die PV_Anlage_1_API nur "? ? ?" anzeigt? Die API meines Plenticore ist aber auch nur 0.2.0! Firmware 1.42/1.43.

Zitat
Wie schon erwähnt, ich hab schon alles abgeschrieben. Mittlerweile hab ich auch Astro und DWD richtig eingestellt.

Zitat
Deine Shellys sind fast baugleich mit meien sonoffs (ESP8266). Allerdings hab ich da Tasmota (MQTT) drauf, da bei mir nix nachhause telefonieren darf. Das passe ich mir noch an...

Zitat von: ch.eick am 23 Dezember 2020, 08:44:01

Hast Du einen verschieden teuren Strom Tarif, oder warum machst Du noch zusätzlich eine Freigabezeit?
Ich glaube Du hattest da mal etwas in einer Mail geschrieben. Ich würde das dann auch gerne ins Wiki als Hinweis mit a

Zitat von: Mumpitz am 25 Dezember 2020, 19:27:08
Das DOIF Problem mit dem mehrmaligen Triggern habe ich inzwischen mit einem Hilfs-DOIF gelöst:
Nun frage ich im PV_Schedule nur noch den Status dieses Hilfs-DOIF ab. Dadurch kann es keine mehrfach Triggerung mehr geben:

Zitat von: ch.eick am 25 Dezember 2020, 22:55:20
Das sollte aber nicht die Lösung sein, Hast Du Dir die Trigger mal angesehen und dazu das Log verglichen?
Ich hatte bereits Dein DOIF mal nachgebaut und bei mir ist das nicht aufgetreten.

Gruß
    Christian

Zitat von: Mumpitz am 25 Dezember 2020, 23:13:26
Darum habe ich mir damit beholfen!

Zitat von: Snakebyte91 am 30 Dezember 2020, 20:30:37
Welche Firmwareversion hat euer Wechselrichter?

Meiner wurde letzte Woche wegen eines Fehlers mit dem BYD Speicher auf die Firmware 1.46/1.45 aktualisiert. Als API Version wird mir 0.2.0 angezeigt.

Zitat von: ch.eick am 01 Januar 2021, 14:32:12
EDIT 15:43: Ich habe den Eintrag nochmals überarbeitet. Bei Bedarf bitte nochmals lesen.

Hallo Mumpitz,

ich hatte nun auch den Loop im PV_Schedule

Code Auswählen Erweitern


2021.01.01 10:59:16.089 2: PV Überschuss wird in Batterie geladen. Keine Entladung
2021.01.01 10:59:22.835 2: PV Überschuss wird in Batterie geladen. Keine Entladung
...

Das hat folgende Bewandtnis:

Code Auswählen Erweitern


Das entsprechende DOELSEIF reagiert auf den Trigger [PV_Anlage_1_API:Battery_InternControl_MinSoc]
dann erfolgt ein "get PV_Anlage_1_API 22_Battery_InternControl" , was wiederum den Status abfragt und wieder einen event-on-update erzeugt.


Um das nun abzustellen wäre eine Änderung der Events im PV_Anlage_1_API ,notwendig, was ich bereits getestet habe.

Code Auswählen Erweitern


attr PV_Anlage_1_API event-on-change-reading Battery_.*
attr PV_Anlage_1_API event-on-update-reading auth_.*,Statistic_Autarky.*,Statistic_Energy_.*arge.*,Statistic_EnergyFeedIn.*,Statistic_EnergyHome.*, Statistic_EnergyPv[1|2].*,Statistic_.*Consumption.*,Statistic_Yield.*


Weiterhin habe ich auch die Logmeldung im PV_Schedule etwas verändert, damit man sieht aus welchem Device die Meldung kommt.

VG
   Christian

Zitat von: Mumpitz am 01 Januar 2021, 20:13:07
Habe es bei mir eingebaut und das Hilfs DOIF vorerst disabled. Sobald die Batterie zum erstenmal voll ist werde ich berichten ob es geklappt hat!

Zitat von: ch.eick am 01 Januar 2021, 22:30:11
Du kannst es ja eher testen, wenn Du den Schwellwert in DOIF änderst ;-)

Alles Gute
  Christian

Zitat von: Mumpitz am 01 Januar 2021, 22:52:52
Habe mir vorhin überlegt das wir durch die Schaltung ja im Herbst und Winter den Speicher schonen. So zumindest die Theorie. Ob es so ist werden wir wohl erst bei der Pensionierung erfahren :-)

Zitat
Nun, was könnten wir im Frühling und Sonmer optimieren?
Meinen Akku Kenntnissen zur Folge hat es der Speicher ja ungern, wenn er auf 100% geladen wird. Das würde bedeuten, dass wir die maximale Kapazität begrenzen sollten auf 80-90%. Aber nur, wenn das Wetter am Tag darauf mitspielen wird. Was hältst du davon?

Zitat von: Mumpitz am 10 Januar 2021, 12:33:17
So, heute morgen hatte ich etwas Zeit, das erste DbRep Device für die regelmässige Löschung der Tageswerte, bis auf den höchsten, zu löschen:

Ich selber habe es bei mir noch nicht ausgeführt. Was haltet ihr davon? Meiner Meinung nach sollten keine Werte gelöscht werden, welche wir irgendwo benötigen, oder?

Zitat von: ch.eick am 10 Januar 2021, 14:13:08
Dies gilt insbesondere für die Autarkie und den Eigenverbrauch, der ja sogar innerhalb des Tages schwankt und somit nicht als maxValue zu verwenden wäre.

Zitat von: Mumpitz am 10 Januar 2021, 20:17:02
Ich schon wieder. Jetzt noch etwas zum Thema Forecast. Heute war bei uns endlich mal wieder ein Tag, bei welchem die Sonne durchgehend auf die Module brannte. Daher habe ich nun noch eine Frage zum Forecast. Die Berechnung gestern hat für den heutigen Tag 19677 Wh ergeben. Tatsächlich waren es 10900 Wh. Also fast die Hälfte daneben. Beim Diagramm sieht es ähnlich aus. Obwohl die Sonne nie durch Wolken getrübt wurde, erreicht die Produktion nie die Werte aus dem Forecast. Ich habe die entsprechende Grafik angehängt. An welchen Werten in der Config würdest du schrauben?

Moin Mumpitz,
als erstes sieht Dein Wert für SolarRadiationPrognose merkwürdig aus, wurden vom DWD so sehr unterschiedliche Werte geliefert? Ab 11:45 ist da ja ein richtiger Sprung drin.

Dann hast u den allgemeinen Korrektur Faktor gesetzt, der Dir die Prognose um 1,5 verstärkt. Setz den mal wieder auf 1

Code Auswählen Erweitern


setstate WR_Plenticore_config 2020-12-26 22:24:59 forecast_factor 1.5


Wenn Du einen festen Faktor erkennen kannst, dann könnte man dort etwas eintragen, oder diesen auch pro Jahreszeit verändern, dafür müsste man das ganze aber auch längere Zeit auswerten.

Gruß
    Christian

Zitat von: ch.eick am 11 Januar 2021, 08:46:48
Wenn Du einen festen Faktor erkennen kannst, dann könnte man dort etwas eintragen, oder diesen auch pro Jahreszeit verändern, dafür müsste man das ganze aber auch längere Zeit auswerten.

Zitat von: plin am 11 Januar 2021, 09:58:00
Kennt sich jemand mit KI aus? Wenn man auf Basis der eigenen Aufzeichnungen (Forecast Rad1h, Sonne, Bedeckung, ... , Ist-Werte) die KI die Abhängigkeiten und Faktoren ermitteln lässt wäre das die Gold-Lösung.

Andererseits gilt der Spruch: erstens kommt es anders und zweitens als man denkt

Zitat von: plin am 11 Januar 2021, 09:58:00
Wenn man auf Basis der eigenen Aufzeichnungen (Forecast Rad1h, Sonne, Bedeckung, ... , Ist-Werte) die KI die Abhängigkeiten und Faktoren ermitteln lässt wäre das die Gold-Lösung.

Zitat von: ch.eick am 11 Januar 2021, 12:36:45
hast Du eventuell noch eine Prognose für Schnee gefunden. Und eventuell einen Sittt Bum Faktor, wenn der Schnee, je nach Dachneigung , mit einem Bum, die PV Module wieder frei gibt? :-)
Das fände ich noch eine Änderung im Solar_forecast() für würdig.

Zitat von: plin am 11 Januar 2021, 13:31:25
P.S. DWD MOSMIX:
Schnee-Regen-Äquivalent (1-stündig)  letzte 1 Stunde    RRS1c
Schnee-Regen-Äquivalent (3-stündig)  letzte 3 Stunden   RRS3c

Zitat von: plin am 11 Januar 2021, 16:06:26
Bei uns war mehr angekündigt ...

Zitat von: ch.eick am 11 Januar 2021, 17:11:12
Macht es da Sinn, auch den Ertrag zu reduzieren, oder liegt dann wirklich schon Schnee auf den Modulen und es kommt gar nichts mehr?
Ich bräuchte mehr Informationen, ab wann der Ertrag leidet.

Zitat von: plin am 11 Januar 2021, 18:45:13
Dazu müsste der Schnee bei uns erst mal liegen bleiben. Das nächste Mal gehe ich raus und werfe einen Blick auf's Dach. Auf dem Rasen lagen vielleicht 2 cm.
Bei der Dicke kann man beim Effekt wahrscheinlich noch nicht zwischen Bewölkung und Schnee unterscheiden.

Zitat von: ch.eick am 12 Januar 2021, 13:15:44
Hallo zusammen,
ich habe mir ein Herz genommen und mal wieder etwas Copy/Past gemacht. Nach einer Stunde Arbeit ist nun über das Device PV_Anlage_1_API die externe Batterie Steuerung verfügbar, bisher war nur eine Abfrage möglich.

Zitat von: Mumpitz am 12 Januar 2021, 13:22:38
Auch jetzt wieder besten Dank. Kurze Verständnisfrage: Muss dafür die externe Batteriesteuerung durch den Installateur freigegeben werden?

Zitat von: ch.eick am 12 Januar 2021, 13:15:44

Es geht um diese Zeilen "set PV_Anlage_1_API 22_3_Battery* " , wo aus der "3" eine "03" wird.

Code Auswählen Erweitern


################################################################################################################
## 6 Wenn die Ladung im Herbst/Winter unter MinSoc geht allen PV Überschuss in die Batterie laden
##
DOELSEIF
(([Astro:ObsSeason] eq "Herbst" or [Astro:ObsSeason] eq "Winter") and
  [PV_Anlage_1_API:Battery_Info_SoC] <= [PV_Anlage_1_API:Battery_InternControl_MinSoc])
## and
##  [$SELF:cmd_nr] ne "6" )     ## wurde dieser Zweig bereits ausgeführt ?

  (get BYD_Status BatteryInformation)
  (set PV_Anlage_1_API 22_03_Battery_MinHomeConsumption [PV_Anlage_1_API:Battery_Info_WorkCapacity])
  (get PV_Anlage_1_API 22_Battery_InternControl, {Log 2, "PV_Schedule cmd_6 : PV Überschuss wird in Batterie geladen. Keine Entladung"})



Zitat von: Mumpitz am 12 Januar 2021, 20:03:02
Du hast die Prüfung ob der gleiche Zweig schon ausgeführt wurde maskiert. Absichtlich oder ein Copy Paste Fehler? Oder anders gefragt, machst du diese Prüfung

Zitat von: ch.eick am 14 Januar 2021, 13:14:33

Wenn Ihr noch Ideen für Steuerungsparameter habt, dann könnt Ihr die jetzt kund tun :-)

Code Auswählen Erweitern


- ASTRO Frühlahr/Sommer
- Uhrzeit zwischen 7:00 und 20:00 Uhr (In der Nacht kommt ja eh kein PV)
- Timeout für die Externe Steuerung 180 Sekunden (default im Plenticore)


Zitat von: Mumpitz am 14 Januar 2021, 20:51:17
Ich habe mir diese Frage auch schon gestellt, siehe den entsprechenden Beitrag. Das wären genau die Punkte welche ich gerne umsetzen würden. Allerdings hat es mich ein bisschen verunsichert, dass du geschrieben hast:
Mit diesem Eingriff übernimmt man jedoch auch die Verantwortung für die Batterieladung! Vergisst man die Batterie wieder zu aktivieren kann es z.B. zu einer Tiefentladung kommen.

Zitat von: Mumpitz am 15 Januar 2021, 08:24:16
Zeile

Code Auswählen Erweitern

attr PV_Anlage_1_API set2203Name 22_30_Battery_MinHomeConsumption
müsste durch

Code Auswählen Erweitern

attr PV_Anlage_1_API set2203Name 22_03_Battery_MinHomeConsumption
ersetzt werden!

Zitat von: killah78 am 15 Januar 2021, 16:54:53
Aber ich bekomme die Meldung:
"The method is not allowed for the requested URL."
Diese Meldung wurde schonmal gemeldet und liegt wohl an HTTPMOD, ich bekomme aktuell aber immernoch die Meldung.

Zitat von: Mumpitz am 15 Januar 2021, 21:09:42
Also irgendetwas stimmt nicht mehr seit den Änderungen. Ich habe wieder regelmässig diese Meldung im Log und die Bilanz wird nicht mehr aktualisiert. Wie sieht es bei dir aus?

Code Auswählen Erweitern


2021.01.15 20:57:03 2: PV_Schedule cmd_5 : PV Überschuss wird in Batterie geladen. Keine Entladung
2021.01.15 19:57:03 2: PV_Schedule cmd_5 : PV Überschuss wird in Batterie geladen. Keine Entladung
2021.01.15 08:57:03 2: PV_Schedule cmd_5 : PV Überschuss wird in Batterie geladen. Keine Entladung


Zitat von: ch.eick am 15 Januar 2021, 21:23:11
Das scheint wieder der Loop zu sein...

Zitat von: ch.eick am 15 Januar 2021, 10:44:49
Danke, ist im Post und Wiki erledigt.

Zitat von: Mumpitz am 15 Januar 2021, 22:17:11
Ja genau. Die beiden Readings sind gesetzt!
Was mich auch stark verunsichert ist der Umstand, dass ich MinSoC auf 20 gestellt habe, der Batteriestand jedoch heute über den Tag von 22% auf nun 14% abgenommen hat...
Keine Ahnung was ihn entladen hat..

Update:
Dann wäre es allerdings auch klar warum immer getriggert wird. Der MinSoC ist ja jedesmal tiefer und darum triggert er. Hmm, nur warum entlädt sich meine Batterie derart?

Zitat von: Mumpitz am 15 Januar 2021, 22:28:42

Code Auswählen Erweitern

attr PV_Anlage_1_API get24Name 24_Battery_TimeControl

Zitat von: ch.eick am 15 Januar 2021, 17:55:42
Ich denke Du meinst die HTTPMOD Version, da habe ich momentan folgende in Verwendung.

Zitat von: killah78 am 18 Januar 2021, 15:29:27
Auch mit der von dir angehangenen HTTPMOD Version bekomme ich den Fehler.
Kannst du mal einen Blick auf mein Log werfen, ob dir da was auffällt?

Zitat von: killah78 am 18 Januar 2021, 17:37:48
Das ist verrückt. Kaum macht man es richtig, schon funktioniert es. :-D
Du hattest recht, die "use"-Zeilen hatte ich nicht übernommen in der 99_myUtils und die Funktionen waren dadurch unbekannt.
Danke für die Hilfe.

Zitat von: DS_Starter am 18 Januar 2021, 20:43:11
vielleicht hast du/ihr schon gesehen dass ich ein Modul SolarForecast gebaut habe (https://forum.fhem.de/index.php/topic,102112.msg1123116.html#msg1123116) was auch eine informative Grafik (Anhang) enthält.
Es ist aus dem Projekt SMAPortal hervorgegangen und ist jetzt aber unabhängig vom Hersteller. Es sollte also auch mit einem Kostal gefüttert werden können.

Zitat von: DS_Starter am 18 Januar 2021, 20:43:11
vielleicht hast du/ihr schon gesehen dass ich ein Modul SolarForecast gebaut habe (https://forum.fhem.de/index.php/topic,102112.msg1123116.html#msg1123116) was auch eine informative Grafik (Anhang) enthält.

Zitat von: plin am 11 Januar 2021, 09:58:00
Kennt sich jemand mit KI aus? Wenn man auf Basis der eigenen Aufzeichnungen (Forecast Rad1h, Sonne, Bedeckung, ... , Ist-Werte) die KI die Abhängigkeiten und Faktoren ermitteln lässt wäre das die Gold-Lösung.

Zitat von: plin am 20 Januar 2021, 21:59:47
Ich habe mich etwas schlau gemacht und gebastelt.  Aktuell lasse ich die DWD-Forcast-Werte 'Rad1h','Neff','R600','Azimuth','Altitude','SunD1','VV' sowie den Durchschnitt der erzeugten Leistung in das Modell einfließen.

In den Grafiken seht Ihr
- die erzeugte Leistung (Total_AC_active_power mit hoher zeitlcher Auflösung, gelbe Linie)
- den Mittelwert der verstrichenen Stunde dieser Leistung (yield, orangefarbene Linie)
- die Vorhersage des Modells (Forecast, Stundenbasis, blaue Linie)

Jetzt heißt es abwarten, denn meine Anlage ist erste Ende Oktober live gegangen und ich habe ca. 1.700 Datensätze als Basis für die Analyse. Aktuell kann die PV-Erzeung bei schlechtem Wetter schon recht gut vorhergesagt werden. Sommer muss noch trainiert werden  :).

Zitat von: ch.eick am 01 Januar 2021, 14:32:12
EDIT 15:43: Ich habe den Eintrag nochmals überarbeitet. Bei Bedarf bitte nochmals lesen.

Hallo Mumpitz,

ich hatte nun auch den Loop im PV_Schedule

Code Auswählen Erweitern


2021.01.01 10:59:16.089 2: PV Überschuss wird in Batterie geladen. Keine Entladung
2021.01.01 10:59:22.835 2: PV Überschuss wird in Batterie geladen. Keine Entladung
...

Das hat folgende Bewandtnis:

Code Auswählen Erweitern


Das entsprechende DOELSEIF reagiert auf den Trigger [PV_Anlage_1_API:Battery_InternControl_MinSoc]
dann erfolgt ein "get PV_Anlage_1_API 22_Battery_InternControl" , was wiederum den Status abfragt und wieder einen event-on-update erzeugt.


Um das nun abzustellen wäre eine Änderung der Events im PV_Anlage_1_API ,notwendig, was ich bereits getestet habe.

Code Auswählen Erweitern


attr PV_Anlage_1_API event-on-change-reading Battery_.*
attr PV_Anlage_1_API event-on-update-reading auth_.*,Statistic_Autarky.*,Statistic_Energy_.*arge.*,Statistic_EnergyFeedIn.*,Statistic_EnergyHome.*, Statistic_EnergyPv[1|2].*,Statistic_.*Consumption.*,Statistic_Yield.*


Weiterhin habe ich auch die Logmeldung im PV_Schedule etwas verändert, damit man sieht aus welchem Device die Meldung kommt.

Code Auswählen Erweitern


snip...
################################################################################################################
## 6 Wenn die Ladung im Herbst/Winter unter MinSoc geht allen PV Überschuss in die Batterie laden
##
DOELSEIF
(([Astro:ObsSeason] eq "Herbst" or [Astro:ObsSeason] eq "Winter") and
  [PV_Anlage_1_API:Battery_Info_SoC] <= [PV_Anlage_1_API:Battery_InternControl_MinSoc])
  (get BYD_Status BatteryInformation)
  (set PV_Anlage_1_API 22_3_Battery_MinHomeConsumption [PV_Anlage_1_API:Battery_Info_WorkCapacity])
  (get PV_Anlage_1_API 22_Battery_InternControl, {Log 2, "PV_Schedule cmd_6 : PV Überschuss wird in Batterie geladen. Keine Entladung"})

################################################################################################################
## 7 Beim erreichen von 90% Soc die Entladung wieder frei geben
##
DOELSEIF
(([Astro:ObsSeason] eq "Herbst" or [Astro:ObsSeason] eq "Winter") and
  [PV_Anlage_1_API:Battery_Info_SoC] >= 90)

  (set PV_Anlage_1_API 22_3_Battery_MinHomeConsumption 50)
  (get PV_Anlage_1_API 22_Battery_InternControl, {Log 2, "PV_Schedule cmd_7 : Batterie über 90%, Entlademodus freigegeben"})


VG
   Christian

Zitat von: Mumpitz am 22 Januar 2021, 13:06:26
Nun ist endlich mal wieder der Fall eingetroffen, dass die Batterie über 90% gekommen ist und den Entlademodus freigegeben hat. Leider komme ich dadurch wieder in den Loop und die Bilanz wird nicht mehr aktualisiert:

Code Auswählen Erweitern


2021.01.22 12:57:03 2: PV_Schedule cmd_6 : Batterie über 90%, Entlademodus freigegeben
2021.01.22 11:57:03 2: PV_Schedule cmd_6 : Batterie über 90%, Entlademodus freigegeben

Hast du eine Idee wie wir diesen rausbringen?

Zitat von: ch.eick am 25 Januar 2021, 13:26:08
@Mumpitz
Beim PV_Schedule war der Fehlerteufel da das "> 100" muss ein "gt 100" sein, sorry.

Code Auswählen Erweitern


################################################################################################################
## 6 Beim erreichen von 90% Soc die Entladung wieder frei geben
##
DOELSEIF
(([Astro:ObsSeason] eq "Herbst" or [Astro:ObsSeason] eq "Winter") and
  [PV_Anlage_1_API:Battery_Info_SoC] >= 90 and
  [PV_Anlage_1_API:Battery_MinHomeConsumption] gt 100 )

  (set PV_Anlage_1_API 22_03_Battery_MinHomeConsumption 50)
  ({Log 3, "PV_Schedule cmd_7 : Batterie über 90%, Entlademodus freigegeben"})


Zitat von: Mumpitz am 25 Januar 2021, 16:55:46
Bist du sicher? Aus meiner bescheidenen Sicht stimmt das >. Es haben sich eher folgende Fehler eingeschlichen:

bei cmd_5:
{Log 2, "PV_Schedule cmd_5 : PV Überschuss wird in Batterie geladen. Keine Entladung"}
bei cmd_6:
{Log 2, "PV_Schedule cmd_6 : PV Überschuss wird in Batterie geladen. Keine Entladung"}
Sowie bei beiden heisst das Reading nicht mehr

Code Auswählen Erweitern

Battery_MinHomeConsumption sondern

Code Auswählen Erweitern

Battery_InternControl_MinHomeConsumption

Zitat von: ch.eick am 25 Januar 2021, 18:23:47

Code Auswählen Erweitern



################################################################################################################
## 7 Test zur Begrenzung des MaxSoc
##
DOELSEIF
(([Astro:ObsSeason] eq "Frühjahr" or [Astro:ObsSeason] eq "Sommer") and
[07:00-20:00|1234] and [+180] )
 
  (set PV_Anlage_1_API 23_09_Battery_ExternControl_MaxSocRel 90)
  ({Log 3, "PV_Schedule cmd_7 : Batterie MaxSoc halten"})


unter cmd_7 findest Du zur Entschädigung schon mal die nächste Idee.
Von 7-20 Uhr wird alle 180 Minuten der Ladezustand der Batterie auf Soc 90 begrenzt, damit sie nicht permanent auf Soc 100 geladen wird.
Bei mir komme ich im Sommer noch mit 40% aus der Nacht und denke so, dass ich dann zwischen 30 und 90 pendle.
Das gilt dann für Montags bis Donnerstags und am Wochenende kann man es dann mal richtig krachen lassen :-)

Gruß
    Christian

Zitat von: Mumpitz am 25 Januar 2021, 20:30:56
Nun, denken wir mal etwas weiter.
Meiner Meinung nach wäre hier zb auch die richtige Stelle, den Forecast einzubauen. Denn auch im Sommer, wenn er schlechtes Wetter hat am nächsten Tag, ist irgendwann Ende Feuer der Batterie.
Da reuen mich dann die 10%, bei mir 1kWh.

Zitat
Weiter würde ich vorschlagen, das PV_Schedule DOIF auseinanderzunehmen und die Batteriesteuerung in ein eigenes DOIF zu übernehmen. Denke es wäre übersichtlicher!

Zitat
Nächste Idee was mir schon länger im Kopf herum geistert. Du hast bei dir die Begrenzung am Wochenende ausser Kraft gesetzt. Ich finde das etwas undynamisch.
Es wäre doch viel besser, Wochentagsprofile zu erstellen, nicht?
Daher schlage ich vor, dieses cmd_7 nur zu triggern, wenn der Forecast am nächsten Tag mehr als 15 kWh oder bis 12 Uhr 8 kWh prognostiziert.
Die Werte müsste man dann noch einstellen könne, z.B. in der config.

Zitat
Bei mir zu Hause z.b ist die ganze Familie an einzelnen Wochentagen grösstenteils abwesend. An meistens den gleichen Tagen wird gewaschen. Dies könnte man doch ebenfalls berücksichtigen mit der Lademenge...

Zitat
Zum Anfangen würde ich gerne mal erheben, welchen Gesamtenergie Verbrauch ich pro Wochentag hatte? Hast du als SQL Freak hier einen Ansatz?
Falls nein, würde ich mal mit einem Dummy und einem DOIF beginnen, welches mir jeden Abend in ein Reading im Wochentagsdummy den Wert um 23:59 schreibt und addiert.

Zitat

Zitat
Nächste Idee was mir schon länger im Kopf herum geistert. Du hast bei dir die Begrenzung am Wochenende ausser Kraft gesetzt. Ich finde das etwas undynamisch.
Es wäre doch viel besser, Wochentagsprofile zu erstellen, nicht?
Daher schlage ich vor, dieses cmd_7 nur zu triggern, wenn der Forecast am nächsten Tag mehr als 15 kWh oder bis 12 Uhr 8 kWh prognostiziert.
Die Werte müsste man dann noch einstellen könne, z.B. in der config.

In die _config werde ich dann Prozent Werte einarbeiten, die dann die Limitierung im Verhältnis zur Speichergröße darstellen.
Das passt eventuell besser zum Haushaltsverbrauch, da der je die Grundlage der Speichergöße sein sollte.

Zitat von: ch.eick am 26 Januar 2021, 13:56:21

Das wären dann mal meine ersten Gedanken, wobei ich das Tarifmodel der Schweiz mit teurem Strom am Morgen und am Abend nicht mit drin hätte :-) Bitte schick mir das doch auch nochmal.

VG
   Christian

Zitat von: Mumpitz am 25 Januar 2021, 20:30:56
Bei mir zu Hause z.b ist die ganze Familie an einzelnen Wochentagen grösstenteils abwesend. An meistens den gleichen Tagen wird gewaschen. Dies könnte man doch ebenfalls berücksichtigen mit der Lademenge...

Zum anfangen würde ich gerne mal erheben, welchen Gesamtenergie Verbrauch ich pro Wochentag hatte? Hast du als SQL Freak hier einen Ansatz?

Zitat von: ch.eick am 29 Januar 2021, 17:12:50
Hallo Mumpitz,
ich fühlte mich da noch einer Antwort schuldig.

Letztes Jahr hatte ich da mal ein SQL geliefert, dass als sqlSpecial in DbRep eingegangen ist.
Die PV_Anlage_1_API readings werden ja regelmäßig in die DbLog geschrieben und Statistic_EnergyHome_Day wächst über den Tag an.

Mit diesem DbRep Device bekommst Du dann nun den Zähler und in einer weiteren Spalte noch die Differenzen berechnet :-)
Die letzte Spalte gibt dann noch die Zeitdifferenz in Minuten an,  weil es nicht immer regelmäßig ist.

Das reading kannst Du ja auf den gewünschten Zählerwert *[Bat|Grid|Pv|PvSum] setzen.

set LogDBRep_select_Tagesverbrauch  sqlSpecial ReadingsDifferenceByTimeDelta

Code Auswählen Erweitern


defmod LogDBRep_select_Tagesverbrauch DbRep LogDB
attr LogDBRep_select_Tagesverbrauch DbLogExclude .*
attr LogDBRep_select_Tagesverbrauch device PV_Anlage_1_API
attr LogDBRep_select_Tagesverbrauch reading Statistic_EnergyHome_Day
attr LogDBRep_select_Tagesverbrauch room System
attr LogDBRep_select_Tagesverbrauch timestamp_begin previous_week_begin
attr LogDBRep_select_Tagesverbrauch timestamp_end previous_week_end


Mit aggregation und maxValue bekommst Du dann z.B. auch die Tageswerte.

set LogDBRep_select_Tagesverbrauch  maxValue display

Code Auswählen Erweitern


defmod LogDBRep_select_Tagesverbrauch DbRep LogDB
attr LogDBRep_select_Tagesverbrauch DbLogExclude .*
attr LogDBRep_select_Tagesverbrauch aggregation day
attr LogDBRep_select_Tagesverbrauch device PV_Anlage_1_API
attr LogDBRep_select_Tagesverbrauch reading Statistic_EnergyHome_Day
attr LogDBRep_select_Tagesverbrauch room System
attr LogDBRep_select_Tagesverbrauch timestamp_begin previous_week_begin
attr LogDBRep_select_Tagesverbrauch timestamp_end previous_week_end


Die zugrundeliegenden SQLs lassen sich natürlich auch, mit kleiner Anpassung, in Grafana anwenden ;-)

Viele Grüße
    Christian

Zitat von: Mumpitz am 29 Januar 2021, 22:46:08
Ich habe bei mir ja bereits die täglichen Werte über einen Monat aus mit einem Chart visualisiert. Was ich bei meinem Post angesprochen habe ist, dass ich gerne auswerten würde, welchen Verbrauch ich an allen Montagen, allen Dienstagen, allen Mittwochen und so weiter hatte. Mit Hilfe dieser Erkenntnis könnte man auch die nötige Ladung der Batterie berechnen.

Mit deinem DbRep Device bekomme ich einfach die täglichen Werte. Weisst Du was ich meine?

Zitat von: ch.eick am 30 Januar 2021, 10:34:19
Moin,
dann sag das doch :-) :-) , das geht natürlich auch.

Zitat von: Mumpitz am 30 Januar 2021, 13:57:33
Hier mal meine Werte des Durchschnittlichen Totalverbrauchs im Januar:

Zitat
Ich habe heute mal folgende Steuerung eingebaut und getestet:

- Während die Batterie geladen wird teste ich auf den SOC, ab 90% limitiere ich das
  MaxChargeLimit auf 800 Watt, ab 95% auf 400 Watt. Meine Zellen zeigen bei über 90% SOC während
  dem Laden extreme Abweichungen, einzelne gehen auf über 3600 mV (die anderen sind dabei um 3430 mV),
  das kann nicht gut sein. Je geringer der Ladestrom desto geringer die Ausreißer.

- Nachdem einmal 100% erreicht sind (gut fürs Balancing und was wir hier sonst schon alles an
  Empfehlungen gelesen haben) setze ich den MaxSOC auf 90%, d.h. der Speicher wird nicht ständig
  auf 100% gehalten und lädt ständig im obersten Bereich wieder nach. Erst wenn der SOC wieder mal
  unter 90% gefallen ist, setze ich MaxSOC wieder auf 100.

Damit wird der Speicher regelmäßig durchgeladen aber nicht permanent nachgeladen und nicht
auf 100% gehalten. Ich denke, das sollte schonender sein...

Zitat von: ch.eick am 30 Januar 2021, 14:54:25

Was hast Du denn da für Energieschleudern in Betrieb?
Bei läuft LWP HZ für 180m² 2 Wohnungen + WW für einen Haushalt, KWL, Pool, TV ganztägig, 4 Router, Home Office und der Rest vom Haushalt.
Du hast ja gut 20 kW höheren Verbrauch, ist da ein E-Auto dabei, ansonsten solltest Du das mal untersuchen?

Zitat von: Mumpitz am 30 Januar 2021, 17:14:31
Das weiss ich eben auch nicht. Ich vermute, nein ich weiss es eigentlich, dass meine LWP offenbar einen sehr hohen Verbrauch hat. Wieso weiss ich leider nicht. Allenfalls muss ich mal einen Techniker bemühen, welcher die Einstellungen kontrollieren muss. Leider habe ich 0,0 Möglichkeit einer externen Steuerung. Meine Umstände:

Zitat von: ch.eick am 17 Januar 2021, 15:35:33
Hallo zusammen,
Stefan war mit dem HTTPMOD Modul mal wieder fleißig un bietet ab der Version 4.1.00 ein neues Attribut an, was wir hier gut gebrauchen können.
set[0-9]*FollowGet (https://forum.fhem.de/index.php/topic,45176.msg1122340.html#msg1122340) dieses Attribut ermöglicht es nach einem Set als nächstes ein Get automatisch zu starten, um das Ergebnis direkt abzuholen. Dadurch können wir dann im PV_Schedule die Aufrufe für die Aktualisierung der Readings wieder entfernen. Das macht das ganze dann wieder übersichtlicher, weil man innerhalb der HTTPMOD direkt sehen kann, wie es aktualisiert wird.

Zitat von: Mumpitz am 06 Februar 2021, 19:41:06
Sollten also wieder auf dem selben Stand sein!

Zitat von: plin am 09 Februar 2021, 21:06:35
Kennt jemand eine Quelle für  MOSMIX Files des DWD der letzten Monate? Habe mir meine Datenbank verhunzt und dann festgestellt, dass die Dasi ein Problem hat ...

Zitat von: Mumpitz am 16 Februar 2021, 20:18:32
Ich habe heute zum Beispiel die Situation, dass meine Batterie heute Abend auf 76% geladen wurde. Morgen sind knapp 14000Wh angesagt. Dies dürfte bedeuten, dass ich vermutlich in die Entladung komme gegen Mittag. Nun wäre es natürlich sinnvoll, die Entladung bereits am Morgen um 7 Uhr frei zugeben.

Hast du eine Idee für eine schlaue Logik dafür. Es müsste der aktuelle Ladestand, die Prognose fc1 sowie der Beginn der Solarleistung, sprich Sonnenaufgang und allenfalls Tarifzeiten berücksichtigt werden. Ich bin gespannt auf Ideen  :)

Zitat von: ch.eick am 17 Februar 2021, 08:33:48
Sind die 14000Wh bei Dir viel?

Zitat von: Mumpitz am 17 Februar 2021, 08:42:47
Ich schau mir die Poolsteuerung mal an...

Zitat von: ch.eick am 23 Februar 2021, 18:17:15
Nochmal kurz zur Information,
ich habe begonnen das Wiki zu überarbeiten. Es wurden fast alle Devices aktualisiert, da es ja eine Namensveränderung gegeben hat.
Damit alles konsistent bleibt, solltest Ihr dort auf jeden Fall mal rein schauen und vergleichen. Für die neuen Funktionalitäten ist dies besonders wichtig.

Es dürfen natürlich auch Fehler gesucht und beseitigt werden :-)

Die Speichersteuerung werde ich in den nächsten Tagen dann auch dort ablegen.
Auch zur Tarif Steuerung und später noch zu aWATTar wird etwas kommen.

Viele Grüße
     Christian

Zitat von: Mumpitz am 23 Februar 2021, 18:39:23
Wie finden wir am einfachsten raus was sich alles geändert hat?

Bezüglich dem Test hoffe ich, dass ich heute das geschriebene übernehmen und morgen im Einsatz testen kann!

Zitat von: ch.eick am 25 Februar 2021, 17:49:57

ein "set PV_1 Battery_MaxSOC 80" hat bei mir bereits funktioniert, da ich die externe Batterie Steuerung aktiviert habe. Wenn das auch ohne die Aktivierung klappt, bitte ich um Rückmeldung.

Zitat von: ch.eick am 03 März 2021, 13:29:52
Hallo zusammen,
heute gab es einen Meilenstein bei der Speicher Steuerung, wodurch folgende Komponenten betroffen sind:

Code Auswählen Erweitern



PV_1_Speicher_1_ExternControl



Zitat von: Mumpitz am 07 März 2021, 12:09:03
Ich hätte hierzu noch einen Änderungsvorschlag sowie ein etwas unschönes Verhalten zu melden:
Also, grundsätzlich habe ich deinen Umsetzungsvorschlag seit ein paar Tagen in Gebrauch. Ich möchte dir daher zuerst ein grosses Kompliment aussprechen. Es funktioniert alles wunderbar!

Im cmd_10 führst du die Befehle erst um 10:07 Uhr aus. Gibt es einen Grund das du dies so spät machst? Hier würde ich vorschlagen, dies Abhängig vom Sunrise zu machen. Daher schlage ich vor,

Code Auswählen Erweitern

[10:07] durch

Code Auswählen Erweitern

[{sunrise_abs("HORIZON=+20.0",0,"6:00","10:00")}]
zu ersetzen. Was meinst du dazu?

Zitat
Weiter war es so, dass am Donnerst, die Prognose ziemlich mies gewesen ist für Freitag. Dadurch hat cmd_9 gegriffen und den MinSoc auf 20% gesetzt.

Zitat
Zudem wurde das Entladen verhindert. Am Samstag war dann aber der Forecast und das Wetter so gut, dass eigentlich bereits am morgen wieder hätte das Entladen erlaubt werden. Das hat es jedoch nicht getan. Das hat sich so ausgewirkt, dass der Speicher genug Reserve gehabt hätte, die Waschmaschine der Frau, als kurz Wolken gekommen sind, zu betreiben. Stattdessen wurde jedoch bei Speicherstand 39% Strom zu gekauft. Der Speicher hätte erst bei 90% wieder entladen (mit cmd_3)
Könnte dies nicht irgendwie früher eingeleitet werden wenn das Wetter und damit auch der Forecast an diesem Tag so gut ist?

Zitat von: papa am 15 März 2021, 19:17:30
Heute ist mein Plenticore mit BYD-Box in Betrieb gegangen. Ich habe mir die Modbus-Daten, wie im Wiki beschrieben, angelegt. Jetzt brauch ich mal kurz Hilfe, bei den Readings.
Für meine Auswertung hätte ich gern die für einen Tag durch die PV erzeugte Energie. Beim SMA (der ist jetzt erst mal aus bis die neuen Strings in Betrieb gehen) war hier für das Reading SPOT_ETODAY da. Die gesamte durch PV erzeugte Energie konnte ich im Reading SPOT_ETOTAL auslesen. Welche Readings sind das beim Kostal ? Ich dachte erst Daily_yield & Total_yield - aber da ist ja auch die aus der Batterie erzeugte Energie mit dabei.

Zitat von: papa am 16 März 2021, 08:13:02
Vielen Dank für die schnelle Reaktion. Das API-Dingens wollte ich mir eigentlich sparen. Na dann werde ich mir das mal ansehen. Mit Batterie ist halt doch noch mal ne andere Logik dahinter.

Zitat von: Darryl B am 17 März 2021, 21:29:45
Ich habe die Device eingepflegt aber es funktioniert nicht.
Mein Plenticore 10 plus arbeitet seit 8 Monaten. Hat noch keine Batterien werden aber in den nàchsten Jahren nachgerüstet.
Wenn die Device erstellt werden hat es einen Einfluss ob die Batterien vorhanden sind oder nicht?
Bleiben die direkten Batterie-Werte leer und beeinflussen sie die anderen nicht?
Mein KSEM ist am Plenticore angeschlossen, wo muss ich dies definieren?

Ich habe noch einen 3 String vorgesehen aber noch nicht realisiert. Sobald ich die Batterien realisiere muss für diesen String ein neuer Wechselrichter her. Wahrscheinlich ein kleiner Kostal. Was kann man vorplanen um die Umstellung in Grenzen zu halten?