openWB Forum

installierte Version: 1.7.309Nightly
openWB Variante: openWB series2 custom mit Touch-Display und RFID, 11kW

PV Modul / Wechselrichter: LG ESSV1 + Kostal Piko MP plus
EVU Modul: LG ESSV1
Speichermodul: LG ESSV1

Hallo

Gerne habe ich die aktuelle Nightly mit dem zweiten WR getestet, da ich selbst ein großes Interesse an dem feature habe, zwei verschiedene Wechselrichter einbinden zu können.

1. Die IP-Adresse wird nicht vorgeblendet, wenn sie denn schon einmal eingetragen/gespeichert wurde. Dies ist bei anderen Modulen der Fall, siehe Bild
2. Ich habe den code im wr2_smamodbus script durch meinen code für den Kostal_Piko_MP ersetzt und es werden beide PV Leistungen addiert angezeigt (LG+Kostal). => sieht gut aus

Was den Gesamtertrag angeht sehe ich: PV Gesamt-Anlagendaten: PV Gesamtertrag [kWh] 0 (entnommen der Statusseite) aber die Null habe ich auch vorher schon gehabt (in stable) => keine Ahnung woran das liegt, aber wohl nicht an der WR2 Implementierung.

3. In der aktuellen nightly sieht es so aus, als wenn es die Einstellung „Geschwindigkeit Regelintervall: schnell“ nicht mehr gibt. Ist es möglich schnell (5s) als Auswahl zu erhalten?
4. Auch schon in der stable 1.7 sehe ich bei „Logging Tagesansicht“ nur den SOC meiner LG Batterie. Die anderen Werte wollen sich nicht zeigen, was habe ich falsch gemacht?
5. Mein letzter Vorschlag für ein Script für den Kostal_Piko_MP/StecaGrid_Coolcept ist ja nicht auf großes Wohlwollen gestoßen. Ich habe es daher nochmal überarbeitet. Ich hoffe das es in dieser Form Einzug in die Gruppe WR2 findet. Auf xmlstarlet wurde verzichtet. Ich habe „wrkostalpikoip“ re-used. Ich denke hier müsste aber in einem neuen Modul „Kostal_Piko_MP“ eine neue Maske zur Abfrage und eine neue Variable z.B. „wrkostalpiko_mp_ip“ angelegt werden.

Kostal_Piko_MP_ and_StecaGrid_Coolcept.sh

#!/bin/bash
#
# RainerW 8th of April 2020
# Unfortunately Kostal has introduced the third version of interface: XML
# This script is for Kostal_Piko_MP_plus and StecaGrid coolcept (single phase inverter)
# In fact Kostal is not developing own single phase inverter anymore but is sourcing them from Steca
# If you have the chance to test this module for the latest three phase inverter from Kostal (Plenticore) or Steca (coolcept3 or coolcept XL) let us know if it works

. /var/www/html/openWB/openwb.conf

# call for XML file and parse it for current PV power
power_kostal_piko_MP=$(curl --connect-timeout 5 -s $wrkostalpikoip/measurements.xml | grep -Po "Value=\'\K[^\']*" | sed -n 3p)

# cut the comma and the digit behind the comma
power_kostal_piko_MP=$(echo $power_kostal_piko_MP | sed 's/\..*$//')

# allow only numbers
re='^-?[0-9]+$'
if ! [[ $power_kostal_piko_MP =~ $re ]] ; then
power_kostal_piko_MP="0"
fi

# call for XM file and parse it for total produced kwh
pvkwh_kostal_piko_MP=$(curl --connect-timeout 5 -s $wrkostalpikoip/yields.xml | grep -Po "Value=\'\K[^\']*" | sed -n 1p)


## Daten in Ramdisk schreiben

echo $pvkwh_kostal_piko_MP > /var/www/html/openWB/ramdisk/pv2kwh
echo '-'$power_kostal_piko_MP > /var/www/html/openWB/ramdisk/pv2watt
echo '-'$power_kostal_piko_MP

Mit freundlichen Grüßen
RainerW

Hallo Rainer,

zu 1. Ist gefixt.
zu 2. ja ist unerheblich und ein reiner Anzeigewert der nicht zum Tragen kommt.
zu 3. richtig. Nach letzter Normenanpassung darf nur alle 10 Sekunden ein neuer Wert vorgegeben werden. Es gibt zwar eine Übergangsphase, aber wir haben das schon umgesetzt.
zu 4. Das ist der Fall wenn die Module "nur" den Watt Wert aber keinen Zählerstand liefern. openWB hat eine eigene Berechnung die für diese Module die Berechnung eines Zählerstands übernimmt.
LG gehört aber eigentlich zu den Modulen die die Werte liefern können.
Welche Module werden noch eingesetzt?
zu 5.
Das lag nur am xmlstarlet und ging danach etwas unter, sorry!
Die config befindet sich gerade im Umbau, künftig wird es nur noch generische Variablen geben.

edit:
modul ist in der nightly, bitte testen

Hallo

Zu3.
Leider habe ich Problem mit meiner Powerline Installation, wenn ich nur alle 10 Sekunden abrufe, es kommt zu Übertragungsfehlern wie im Bild zu erkennen. Zu meiner etwas abseits gelegenen Garage kann ich keine neuen Kabel oder Wlan-Verbindungen verlegen/einrichten.
Mit 5 Sekunden läuft es ohne Verbindungsfehler (innerhalb meines Testzeitraumes von 24h). Ich habe beide Einstellungen mit Wireshark überprüft und tatsächlich gibt es bei 10sec Fehler auf TCP IP Ebene und bei 5sec nicht. Ich habe keine Ahnung woran das liegen könnte.

In Web/settings/Misc.php ab Zeile 584

Vorschlag a)
Wiedereinführung von 5 Sekunden mit dem Tag „Experimentell“
<option <?php if($dspeedold == 1) echo "selected" ?> value="1">Experimentell</option>

Vorschlag b) falls a nicht möglich
Die betreffende Zeile mit dem Kommentarzeichen versehen, das macht es mir einfacher es wieder zu aktivieren
#<option <?php if($dspeedold == 1) echo "selected" ?> value="1">Experimentell</option>

Vorschlag c) falls a und c) nicht möglich
Bitte keine weiteren Programmteile entnehmen, die die Reaktivierung von 5sec unterbinden.
Das heißt den jetzigen Zustand (in der Nightly) so belassen

Vorschlag d) falls a,b und c nicht möglich
Ich suche weiter nach dem root cause => ich habe aber keine Idee mehr was ich noch ausprobieren könnte


Zu 4.
Seit WR2 mit dem Kostal_piko_MP Modul vollständig implementiert ist, sehe ich in der Tagesansicht auch Werte. Allerdings nur Kostal Werte wie man schön in der Graphik erkennt maximal 3KW allerdings sollte hier mit der LG Anlage zusammen um maximal 7kW sichtbar sein. Keine Ahnung was da schief läuft. Mir ist nur aufgefallen das die Ausleseroutinen etwas modifiziert sind. Könnten sie das eventuell nochmal prüfen?
Im Langzeit ist alles O.K.
Zu 5.
Das script für WR2 KostalPikoMP_Steca funktioniert bei mir einwandfrei. Allerdings möchte ich mir erlauben sie auf einen kleinen Flüchtigkeitsfehler bei der Modifizierung bezüglich der generischen IP Adresse hinzuweisen. In der ersten Ausleseroutine haben sie wrkostalpikoip durch pv2ip ersetzt.
Dies haben sie aber in der zweiten Ausleseroutine übersehen, so dass dort noch immer wrkostalpikoip auftaucht.
Dies würde bedeuten das das script nur vollständig funktioniert, wenn zuvor wrkostalpikoip gesetzt wurde.
Ich würde empfhelen auch die zweite Stell durch pv2ip zu ersetzen.

# call for XML file and parse it for current PV power
power_kostal_piko_MP=$(curl --connect-timeout 5 -s $pv2ip/measurements.xml | grep -Po "Value=\'\K[^\']*" | sed -n 3p)

# call for XM file and parse it for total produced kwh
pvkwh_kostal_piko_MP=$(curl --connect-timeout 5 -s $wrkostalpikoip/yields.xml | grep -Po "Value=\'\K[^\']*" | sed -n 1p)

Mit freundlichen Grüßen
Rainer Wiesmann

Zu 3.

Das macht nicht wirklich Sinn das eine höhere Netzbelastung weniger Fehler verursacht.
Timeouts können es theoretisch nicht sein da dann ja alles bei 5s noch schlimmer werden würde.
An deiner Stelle würde ich die betreffende Hardware wechseln um die Ursache zu beheben, ist ja nur eine Frage der Zeit bis es garnicht mehr geht.
In einer künftigen openWB Version wird das Modul handling dynamisch erfolgen, spätestens dann hast du ggf. ein Problem oder auch nicht.

Zu 4.

Bitte mal Nightly 311 testen und berichten.

Zu 5.
Danke, ist behoben!

Zu 3.
Auf den ersten Blick erscheint das widersinnig. Ich kann aber doch zwei Beispielen aus meiner Vergangenheit berichten, wo solche Dinge zu beobachten waren. Diese hatten immer mit den Energiesparversuchen der Hardware zu tun.

1. Fall vor mehr als 7 Jahren
Notebook und Switch habe ein Energiesparprotokoll über LAN gefahren, wenn beide im Sparmodus waren, wurde nicht mehr automatisch hochgefahren. Lösung war konstant Traffic erzeugen oder Kabel neu stecken (oder alten Switch ohne Energiesparen einsetzen)
2. Fall vor ca. 4 Jahren
WLAN beim Notebook hat nur sauber funktioniert, wenn das zu empfangende WLAN schwach war. Wenn es zu stark war hat das Notebook den eigenen Transmitter zu weit runtergeregelt und es gab Verbindungsabbrüche, Lösung war ein Firmware/Treiber update des Notebooks

Die Powerline Adapter rühmen sich auch des Energiesparens ...

Wie auch immer, ich habe die Powerline Hardware schon mal ausgetauscht bzw. mit anderen neuern Adaptern getestet. Das Ergebnis war das Gleiche.
Kann ich davon ausgehen, dass sie die betreffenden „Geschwindigkeits“- Routinen so belassen, bis sie auf „dynamisch“ umstellen (Vorschlag c)?
Wann soll denn umgestellt werden?
Was bedeutet eigentlich dynamisches Modul handling? Ich kann mir da nichts drunter vorstellen.

Zu 4.
Nightly 311:
Nix verändert, Kostal Werte zeigen sich LG_ESS Werte nicht

Zu 5.
Getestet und funktioniert.

Wie auch immer, ich habe die Powerline Hardware schon mal ausgetauscht bzw. mit anderen neuern Adaptern getestet. Das Ergebnis war das Gleiche.
Kann ich davon ausgehen, dass sie die betreffenden „Geschwindigkeits“- Routinen so belassen, bis sie auf „dynamisch“ umstellen (Vorschlag c)?

Ja.

Wann soll denn umgestellt werden?

Weg von Bash Skripten zu Python.

Was bedeutet eigentlich dynamisches Modul handling? Ich kann mir da nichts drunter vorstellen.

Parallelisieren von Aufgaben und aufteilen der "Module".
Sprich ein Part der sich um Datenbeschaffung kümmert, einer für Regelung, einer für SmartHome, einer für MQTT Handling, usw...

zu 4.
was steht in den folgenden Variablen (im Browser aufrufen reicht)
http://ipderopenWB/openWB/ramdisk/pvkwh
http://ipderopenWB/openWB/ramdisk/pv2kwh
http://ipderopenWB/openWB/ramdisk/pvallwh

Hallo

zu 4.)
http://192.yyy.xxx.29/openWB/ramdisk/pvkwh
4921718
http://192.yyy.xxx.29/openWB/ramdisk/pv2kwh
4534490 (stimmt mit dem aktuellen Wert aus dem WR Kostal überein)
http://192.yyy.xxx.29/openWB/ramdisk/pvallwh
4921722

Bei pvkwh LG ESS hätte um 7850000 stehen sollen.


Mit freundlichen Grüßen
RainerW

bitte nochmal update machen und zu den werten zusätzlich pv1kwh_temp
abfragen

Hallo

Ich denke es liegt am script zur Auslesung der LG_ESSV1

http://192.29/openWB/ramdisk/pvkwh
4922210
http://192.29/openWB/ramdisk/pv2kwh
4534981
http://192.29/openWB/ramdisk/pvallwh
4922211
http://192.29/openWB/ramdisk/pv1kwh_temp
387229

Ich hab mir mal einen alten jason File von der LG Büchse angeschaut. Es sieht so aus als, wenn der falsche Wert extrahiert
wird, der sich zudem nicht ändert (siehe fette Zahl unten). Keine Ahnung welcher der richtige Wert ist.
Wenn ich in das Portal von LG schaue ist der Ertrag 2019: 5630000 und 2020: 2220000 = 7850000
unten könnte aufsummiert vieleicht für 2020 stimmen (den jason file hat mein Sohn für mich schon vor 21 Tagen gezogen)
2019 fehlt ganz. Oh je das scheint komplexer zu sein, wenn man immer die Jahreszahlen kennen muß bzw. es für jedes Jahr einen Jason gibt. Vielleicht verlängert sich auch der Jason File mit jedem Monat "db 0 bis 3"?
Vielleicht ist es an der Zeit den Originator von dem script zu kontaktieren?

{
"m_timeFrom": "20200101000000",
"m_timeTo": "20201231234500",
"db": "success",
"loginfo": [
{
"db": "0",
"time": "20200101000000",
"generation": "387229",
"feed_in": "238816",
"self_consum": "38.32693",
"total_generation": "387229",
"total_Feed_in": "238816"
},
{
"db": "1",
"time": "20200201000000",
"generation": "453643",
"feed_in": "296692",
"self_consum": "34.59791",
"total_generation": "840872",
"total_Feed_in": "535508"
},
{
"db": "2",
"time": "20200301000000",
"generation": "55649",
"feed_in": "34994",
"self_consum": "37.11657",
"total_generation": "896521",
"total_Feed_in": "570502"
},
{
"db": "3",
"time": "20200301000000",
"generation": "639992",
"feed_in": "460404",
"self_consum": "28.06098",
"total_generation": "1536513",
"total_Feed_in": "1030906"
}
]
}

Mit freundlichen Grüßen
Rainer Wiesmann

noch mehr Jason von der LG_ESS nur der Vollständigkeit halber
{
"statistics": {
"pcs_pv_total_power": "0",
"batconv_power": "749",
"bat_use": "1",
"bat_status": "2",
"bat_user_soc": "84.48276",
"load_power": "732",
"load_today": "0.0",
"grid_power": "17",
"current_day_self_consumption": "28.3",
"current_pv_generation_sum": "30143",
"current_grid_feed_in_energy": "21614"
},
"direction": {
"is_direct_consuming_": "0",
"is_battery_charging_": "0",
"is_battery_discharging_": "1",
"is_grid_selling_": "0",
"is_grid_buying_": "0",
"is_charging_from_grid_": "0"
},
"operation": {
"status": "start",
"mode": "1"
},
"wintermode": {
"winter_status": "off"
},
"pcs_fault": {
"pcs_status": "pcs_ok"
}
}

Welche Formware / API Version ist installiert auf dem LG und welche in openWB eingestellt?