Rückmeldungen openWB software 2.1.4 Alpha 1

[Gero]

Ja, da ist ein Mißvertändis passiert. Jetzt nach dem Update sehe ich auch die drei Modi.

Allerdigs stand es bei mir nach dem Update auf Mindest-SoC und das Auto hat angefangen zu laden obwohl die 80% noch nicht erreicht waren.

Dann umgestelllt auf Speicher und die Ladung stoppt.

IMG_0659.png

(1.1 MiB) Noch nie heruntergeladen

Vielleicht liegt es daran, dass durch einen Peak die Ladung wegen Einspeisung gestartet wurde, aber dann hätte ich erwartet, dass im weiteren Verlauf die Ladeleistung heruntergeregelt wird bis der Speicher auf 80% ist.

[ChristophR]

Ja, da ist ein Mißvertändis passiert. Jetzt nach dem Update sehe ich auch die drei Modi.

Allerdigs stand es bei mir nach dem Update auf Mindest-SoC und das Auto hat angefangen zu laden obwohl die 80% noch nicht erreicht waren.

Dann umgestelllt auf Speicher und die Ladung stoppt.

IMG_0659.png

Vielleicht liegt es daran, dass durch einen Peak die Ladung wegen Einspeisung gestartet wurde, aber dann hätte ich erwartet, dass im weiteren Verlauf die Ladeleistung heruntergeregelt wird bis der Speicher auf 80% ist.

Erste Erkenntnis:
Du musst jetzt bei "Ladeleistung für Speicher unterhalb des Mindest-SoC des Speichers [optional]" Deine maximale Speicherleistung eintragen, weil alles andere sonst bereits unterhalb des Mindest-SoC für´s Fahrzeugladen verwendet wird.
Steht so auch im Hilfetext und ist wohl (leider) ernst gemeint...

Ich habe daher dort erstmal 5kW und bei "Entladeleistung des Speichers oberhalb des Mindest-SoC des Speichers [optional]" 2kW eingetragen, damit es halbwegs so funktioniert, wie ich es vorher gewohnt war.
Details folgen...

[Gero]

Oha, noch ein neuer Parameter. Ich fand die Lösung über Einspeisung zu gehen eigentlich schöner. Gut, hab‘ ich mal 4kW eingetragen:

IMG_0661.png

(1.37 MiB) Noch nie heruntergeladen

Speicher wird mit 350W geladen und das Auto mit 5800W.

[openWBbeginner]

Ich habe 4 Hoymiles, per OpenDTU und MQTT gebündelt an openWB übermittelt, und 1 SMA WR per Solarlog an openWB und sporadisch Peaks, eigentlich nur Nachts und erst seit neueren openWB 2.0 Release Versionen. Daher bin ich eigentlich hier bei der Alpha Version falsch

Interessant ist, dass ab und zu die Peaks in der Tagesansicht nur in der Summe der beiden in openWB angezeigten PV-Werte auftreten und nicht in den beiden Einzelwerten MQTT und Solarlog. Daraus schließe ich, dass es ein openWB Problem bei der Summation ist und keine falschen WR-Werte.
Merkwürdig ist auch, dass der Peak ungefähr der Gesamtproduktion des SMAs/Solarlogs entspricht, als wenn openWB ab und zu Tages- und Gesamtproduktion verwechselt.

Im Log konnte ich das bisher nicht finden.

Ich möchte bitten und habe dafür ein Issue im Git angelegt, eine Editiermöglichkeit für falsche Tageswerte zu schaffen.

heute hatte ich wieder einen Peak. Wie meistens um exakt 3 Uhr in der Nacht und genau in der Höhe der Gesamtproduktion des SMA/Solarlog. MQTT / Hoymiles und die Einzelwerte SMA/Solarlog stimmen, nur die Summe nicht.

Update 1: im Log von openHAB, das auch auf den Solarlog zugreift, sehe ich um nur um 03:0x herum I/O Fehler, obwohl der Solarlog über Ethernet angebunden ist (2024-04-13 03:01:54.010 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'solarlog:meter:3481b615' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Communication error with the device. Please retry later.) Möglicherweise führt beim Auslesen des Solarlog durch OpenWB zum gleichen Zeitraum ein solcher I/O-Fehler zu den Peaks bei der Summation der Einzelwerte.

Update 2: ich habe die Stelle im Main-Log der openWB gefunden, bei einem anderen Peak

Code: Alles auswählen

2024-04-09 00:38:40,462 - {modules.common.fault_state:49} - {ERROR:device14} - Solar-Log Wechselrichter: FaultState FaultStateLevel.ERROR, FaultStr Die Verbindung zum Server http://192.168.0.49/getjp ist fehlgeschlagen. Überprüfe Adresse und Netzwerk., Traceback: 
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 169, in _new_conn
    conn = connection.create_connection(
  File "/usr/lib/python3/dist-packages/urllib3/util/connection.py", line 96, in create_connection
    raise err
  File "/usr/lib/python3/dist-packages/urllib3/util/connection.py", line 86, in create_connection
    sock.connect(sa)
ConnectionResetError: [Errno 104] Connection reset by peer

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 699, in urlopen
    httplib_response = self._make_request(
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 394, in _make_request
    conn.request(method, url, **httplib_request_kw)
  File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 234, in request
    super(HTTPConnection, self).request(method, url, body=body, headers=headers)
  File "/usr/lib/python3.9/http/client.py", line 1255, in request
    self._send_request(method, url, body, headers, encode_chunked)
  File "/usr/lib/python3.9/http/client.py", line 1301, in _send_request
    self.endheaders(body, encode_chunked=encode_chunked)
  File "/usr/lib/python3.9/http/client.py", line 1250, in endheaders
    self._send_output(message_body, encode_chunked=encode_chunked)
  File "/usr/lib/python3.9/http/client.py", line 1010, in _send_output
    self.send(msg)
  File "/usr/lib/python3.9/http/client.py", line 950, in send
    self.connect()
  File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 200, in connect
    conn = self._new_conn()
  File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 181, in _new_conn
    raise NewConnectionError(
urllib3.exceptions.NewConnectionError: <urllib3.connection.HTTPConnection object at 0x6b8e5c70>: Failed to establish a new connection: [Errno 104] Connection reset by peer

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/requests/adapters.py", line 439, in send
    resp = conn.urlopen(
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 755, in urlopen
    retries = retries.increment(
  File "/usr/lib/python3/dist-packages/urllib3/util/retry.py", line 574, in increment
    raise MaxRetryError(_pool, url, error or ResponseError(cause))
urllib3.exceptions.MaxRetryError: HTTPConnectionPool(host='192.168.0.49', port=80): Max retries exceeded with url: /getjp (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x6b8e5c70>: Failed to establish a new connection: [Errno 104] Connection reset by peer'))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/var/www/html/openWB/packages/modules/common/configurable_device.py", line 36, in __call__
    self.__updater(components_list)
  File "/var/www/html/openWB/packages/modules/devices/solar_log/device.py", line 25, in update_components
    response = req.get_http_session().post('http://'+device_config.configuration.ip_address+'/getjp',
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 590, in post
    return self.request('POST', url, data=data, json=json, **kwargs)
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 542, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 655, in send
    r = adapter.send(request, **kwargs)
  File "/usr/lib/python3/dist-packages/requests/adapters.py", line 516, in send
    raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError: HTTPConnectionPool(host='192.168.0.49', port=80): Max retries exceeded with url: /getjp (Caused by NewConn

"Meine" Peaks enstehen also durch den I/O Fehler beim Zugriff auf den Solarlog. Ich vermute, dass die SD Karte des Solarlog einen Schlag weg hat. Darum muss ich mich kümmern. Unklar bleibt, warum sich dies nur auf den PV-Summenwert und nicht auf den einzelnen Solarlog-Wert auswirkt. Ich vermute, dass die inzwischen eingebaute Fehlerkorrektur bei unklaren Werten nur den einzelnen Solarlog-Wert korrigiert, aber nicht die Summe. Nur eine Vermutung.

[neotrace2]

Was soll ich sagen. Die neue Pv Regelung mit mindest Specher SOC funktioniert super. Um 11:30 war der Speicher wie eingestellt auf 90% und dann fing der Wagen an zu laden. Toll gemacht danke

[ChristophR]

Was soll ich sagen. Die neue Pv Regelung mit mindest Specher SOC funktioniert super. Um 11:30 war der Speicher wie eingestellt auf 90% und dann fing der Wagen an zu laden. Toll gemacht danke

Verrätst Du noch mit welchen Einstellungen das bei Dir lief?

[Gero]

Bei mir standen 80%, 4kW und 1kW drin, und es lief nicht. Nun habe ich die Autoladung gestoppt, damit ich morgen mal mit 90%, 6kW und 1kW eine neue Runde wagen kann.

[ChristophR]

Bei mir standen 80%, 4kW und 1kW drin, und es lief nicht. Nun habe ich die Autoladung gestoppt, damit ich morgen mal mit 90%, 6kW und 1kW eine neue Runde wagen kann.

Du musst die Entladeleistung höher stellen als die Einschaltschwelle, also im Standard auf ca. 1,5kW.
Die Ladung startet oberhalb des Mindest-SoC erst, wenn die Entladeleistung + Einspeisung > Einschaltschwelle ist. Speicherladung wird dabei nicht berücksichtigt.
Da der Speicher die Einspeisung unterbindet, startet die Ladung dann erst wenn der Speicher voll ist und daher eingespeist wird.

[neotrace2]

Bitte sehr

IMG_5318.png

(188.42 KiB) Noch nie heruntergeladen

IMG_5319.png

(225.28 KiB) Noch nie heruntergeladen

[Gero]

Du musst die Entladeleistung höher stellen als die Einschaltschwelle, also im Standard auf ca. 1,5kW.

Hmm. Meine überlegung war, dass ich schon noch mit 500W vom Dach weiterladen will. Also 500 vom Dach plus die 1000 aus dem Speicher ist noch OK. Erst wenn vom Dach nichts mehr kommt, soll die Autoladung beendet werden. Wenn man nun in beide Parameter den selben Wert eintragen soll, erscheint mir das unnötig kompliziert. Schön, wenn man das machen kann, aber dann könnte man vielleicht 0 eintragen und das bedeutet dann „nimm die Einspeisung“

Die Ladung startet oberhalb des Mindest-SoC erst, wenn die Entladeleistung + Einspeisung > Einschaltschwelle ist. Speicherladung wird dabei nicht berücksichtigt.

Also Speicherladung wird nicht berücksichtigt, die Entladung des Speichers aber schon? Gerade zu dem Zeitpunkt, wo man über den Mindest-SoC kommt, findet ja aller Wahrscheinlichkeit nach keine Einspeisung statt. Man möchte aber dann schon mal mit dem Autoladen beginnen und dem Speicher weniger übriglassen.

Da der Speicher die Einspeisung unterbindet, startet die Ladung dann erst wenn der Speicher voll ist und daher eingespeist wird.

Genau. Deshalb hätte ich erwartet, dass die Speicherladung mit der Einspeisegrenze verglichen wird um dann dem Speicher den überschuss wegzunehmen und ins Auto zu packen.

Meine Beobachtung heute war aber das Gegenteil: das Auto lädt, obwohl der Mindest-SoC nicht erreicht war.

Ziel des Mindest-SoC Lademodus soll doch sein, bis zum Mindest-SoC dem Speicher prio zu geben und danach den EVs. Oder habe ich da mein Verständnisproblem?