Rückmeldungen software2 2.1.8-Alpha.1

[miradarya]

Jetzt, wo ich mein ostrom-Tarifmodul mit meiner realen openWB nutze, fällt auf, dass des Öfteren Timeouts bei den HTTP-Requests auftreten (sehe ich jetzt im Nachhinein aber auch in der WSL-Testumgebung, hat also nix mit der Hardware zu tun):

Code: Alles auswählen

2025-03-28 09:30:07,286 - {modules.common.fault_state:49} - {ERROR:electricity tariff} - ostrom: FaultState FaultStateLevel.ERROR, FaultStr OSError None: Unbekannter Fehler None, Traceback: 
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 445, in _make_request
    six.raise_from(e, None)
  File "<string>", line 3, in raise_from
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 440, in _make_request
    httplib_response = conn.getresponse()
  File "/usr/lib/python3.9/http/client.py", line 1347, in getresponse
    response.begin()
  File "/usr/lib/python3.9/http/client.py", line 307, in begin
    version, status, reason = self._read_status()
  File "/usr/lib/python3.9/http/client.py", line 268, in _read_status
    line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
  File "/usr/lib/python3.9/socket.py", line 704, in readinto
    return self._sock.recv_into(b)
  File "/usr/lib/python3.9/ssl.py", line 1241, in recv_into
    return self.read(nbytes, buffer)
  File "/usr/lib/python3.9/ssl.py", line 1099, in read
    return self._sslobj.read(len, buffer)
socket.timeout: The read operation timed out

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 532, in increment
    raise six.reraise(type(error), error, _stacktrace)
  File "/usr/lib/python3/dist-packages/six.py", line 719, in reraise
    raise value
  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 447, in _make_request
    self._raise_timeout(err=e, url=url, timeout_value=read_timeout)
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 336, in _raise_timeout
    raise ReadTimeoutError(
urllib3.exceptions.ReadTimeoutError: HTTPSConnectionPool(host='production.ostrom-api.io', port=443): Read timed out. (read timeout=5)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/var/www/html/openWB/packages/modules/common/configurable_tariff.py", line 27, in update
    tariff_state = self._component_updater()
  File "/var/www/html/openWB/packages/modules/electricity_tariffs/ostrom/tariff.py", line 50, in updater
    return TariffState(prices=fetch_prices(config.configuration))
  File "/var/www/html/openWB/packages/modules/electricity_tariffs/ostrom/tariff.py", line 30, in fetch_prices
    raw_prices = req.get_http_session().get(
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 555, in get
    return self.request('GET', url, **kwargs)
  File "/var/www/html/openWB/packages/modules/common/req.py", line 16, in request
    return super().request(method, url, *args, **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 529, in send
    raise ReadTimeout(e, request=request)
requests.exceptions.ReadTimeout: HTTPSConnectionPool(host='production.ostrom-api.io', port=443): Read timed out. (read timeout=5)

Dasselbe hatte ich vorher auch schon immer mit dem Energy-Charts-Modul, hatte das da aber auf eine Überlastung von Energy-Charts geschoben. Selbst mit auf 7 Sekunden vergrößertem Timeout treten weiterhin Fehler auf. Ich bin mir nicht sicher, wie weit man das mit dem Timeout-Limit treiben könnte.

Nun wäre es im Prinzip ja nicht schlimm, wenn sporadisch ein Preis-Abruf nicht funktioniert. Das Problem ist aber, dass das Zielladen jedes Mal unterbrochen wird, wenn das Tarif-Modul im Fehlerzustand steht. So sah beispielsweise heute Nacht das Zielladen aus :

2025-03-28 10_47_44-Clipboard.png (55.43 KiB) 1060 mal betrachtet

Wäre es evtl. sinnvoller, das Zielladen trotz Fehlerzustand des Tarif-Moduls fortzusetzen, sofern noch vom vorherigen Abruf Preisinformationen für den relevanten Zeitraum vorliegen? Die sind ja eigentlich weiterhin gültig.

[mrinas]

Ist bekannt warum die Verbindung zu dem Endpunkt von ostrom unzuverlässig ist und teilweise nicht antwortet? Macht es ggf. Sinn hier ein wenig mehr resilienz einzubauen, ggf. mit try/catch 3 Versuche mit kurzer Wartezeit zwischen den Versuchen?

[miradarya]

Keine Ahnung, aber ich sehe das gleiche wie gesagt auch bei Energy-Charts. Ich kann probieren, sowas in das ostrom-Modul einzubauen mit mehreren Versuchen. Dann wäre aber interessant zu wissen, wie lange ein Preisabruf insgesamt maximal dauern darf. Kommt man da irgendwann in Konflikt mit der restlichen Regelung?

Ich denke aber trotzdem, dass es unglücklich ist, das preisbasierte (Ziel-)Laden zu unterbrechen, wenn das Tarif-Modul im Fehlerzustand steht, obwohl noch Preisinformationen vorhanden sind. Es kann ja auch durchaus mal sein, dass der Internet-Provider gerade Probleme hat oder eine Wartung am Anschluss durchführt. Gerade nachts, da kündigt Deutsche Glasfaser regelmäßig Wartungen mit Unterbrechung der Internet-Verbindung bei uns an. Dass dann die Wallbox nicht mehr lädt, weil sie keine brandneuen Preise bekommt, ist nicht ideal.

[mrinas]

Keine Ahnung, aber ich sehe das gleiche wie gesagt auch bei Energy-Charts. Ich kann probieren, sowas in das ostrom-Modul einzubauen mit mehreren Versuchen. Dann wäre aber interessant zu wissen, wie lange ein Preisabruf insgesamt maximal dauern darf. Kommt man da irgendwann in Konflikt mit der restlichen Regelung?

Ich denke aber trotzdem, dass es unglücklich ist, das preisbasierte (Ziel-)Laden zu unterbrechen, wenn das Tarif-Modul im Fehlerzustand steht, obwohl noch Preisinformationen vorhanden sind. Es kann ja auch durchaus mal sein, dass der Internet-Provider gerade Probleme hat oder eine Wartung am Anschluss durchführt. Gerade nachts, da kündigt Deutsche Glasfaser regelmäßig Wartungen mit Unterbrechung der Internet-Verbindung bei uns an. Dass dann die Wallbox nicht mehr lädt, weil sie keine brandneuen Preise bekommt, ist nicht ideal.

Bin da bei dir, openWB sollte m.e. die vorhandenen Preise nutzen solange die noch da sind, auch wenn ein Fehler vorliegt - unter der Annahme dass bereits ermittelte Preise weiterhin gültigt sind, auch wenn das Modul einen Fehler läuft.
urllib3 bietet wohl integrierte retry Fähigkeiten, vielleicht ist das eine elegante, einfache Möglichkeit diesen Abruf fehlertoleranter zu gestalten? https://urllib3.readthedocs.io/en/stabl ... g-requests

[neotrace2]

Ich wollte mal was positives melden und auch Martin Rinas zusätzlich loben. Seit dem langersehnten Fix für SMA Hybrid WR stimmen die Werte überall, auch der Anzeigefehler beim Laden ist weg. Echt toll
Und bisher läuft die 2,1,8A1 bei mir sehr gut. Das Dimmen muss ich noch testen. Aber PV Überschuss Laden, Phasenumschaltung etc klappen problemlos.

[mrinas]

Ich wollte mal was positives melden und auch Martin Rinas zusätzlich loben. Seit dem langersehnten Fix für SMA Hybrid WR stimmen die Werte überall, auch der Anzeigefehler beim Laden ist weg. Echt toll
Und bisher läuft die 2,1,8A1 bei mir sehr gut. Das Dimmen muss ich noch testen. Aber PV Überschuss Laden, Phasenumschaltung etc klappen problemlos.

danke, freut mich dass es auch bei dir hilft. Ggf. müssen noch ein paar weitere WR Module (Solaredge ist schon aufgefallen) angepasst werden um in den Genuss der gleichen Verbesserungen kommen. Jetzt fehlt noch der PR für die SMA Speichersteuerung, der behebt dann hoffentlich auch die negative PV Leistung am Abend.

[cava]

Gibt es eigentlich schon eine Dokumentation zu den Einstellungen bezüglich §14? Habe ich da etwas übersehen?

Aber mal eine allgemeine Frage: Angenommen, ich habe eine openWB und ein Victron-System, das über einen digitalen Ausgang verbunden ist und über Direktsteuerung mit einem EMS konfiguriert wurde. Die openWB weiß zwar, wie viel Energie das Victron-System in die Batterie lädt, aber sie weiß nicht, dass es über den digitalen Ausgang gesteuert wird. Wie wird das in diesem Fall verrechnet?

1. Falls kein PV-Ertrag vorhanden ist (zum Beispiel nachts) und das Victron-System nicht aus dem Netz lädt, aber das Dimm-Signal empfangen wird, dann dürfte die volle Leistung doch der Wallbox zur Verfügung gestellt werden.

2. Falls PV-Ertrag vorhanden ist, wenn das Dimm-Signal kommt, wird der Ertrag dann gegengerechnet? Angenommen, wir haben 10 kW PV-Ertrag, 1 kW Verbrauch im Haus, 6 kW Ladeleistung von Victron in die Batterie und 3 kW Ladeleistung über die Wallbox. In diesem Fall sollte keines der Geräte gedimmt werden, da kein Netzbezug vorhanden ist. Ich weiß nicht, wie der Victron Multiplus reagiert, wenn das Dimm-Signal anliegt, ich vermute aber, er wird immer auf 4,2 kW reduzieren, wenn das Dimm-Signal aktiv ist – unabhängig davon, ob ein Netzbezug besteht oder nicht.

Wäre es nicht sinnvoller, das Dimm-Signal nur dann zu aktivieren, wenn der Netzbezug zu hoch ist? In diesem Fall könnte der Netzbezug 8,5 kW betragen (1 kW Verbrauch im Haus + 7,5 kW für die beiden SteuVE). Zudem weiß die openWB auch, ob Victron die Batterie überhaupt gerade lädt oder nicht.

=> wenn rein mit PV-Überschuss gearbeitet wird und der Multiplus auch mit PV-Strom lädt, müsste gar nichts gedimmt werden
=> wenn auch mit Netzstrom geladen wird, dann müsste nur dann gedimmt werden, wenn der Netzbezug größer ist als Verbrauch aller nicht SteuVE + maximal erlaubte Leistung aller SteuVE.

Gruß
Werner

[mrinas]

Ja gibt es, im aktuellen master ist Unterstützung dafür hinzu gekommen.

[Gero]

Allerdings werden die Speicher (wie auch alle anderen SteuVE außer openWB-Ladepunkten) noch nicht gesteuert d.h. Das empfangene Dimmsignal wird aktuell nur auf dem D&C-Kit ausgegeben.

[cava]

Ja gibt es, im aktuellen master ist Unterstützung dafür hinzu gekommen.

War das eine Antwort auf meinen Kommentar? Ich weiß, dass die Unterstützung im aktuellen Master ist, nur eine Doku finde ich nicht.