Rückmeldungen Stable 1.9.295

[rleidner]

Bei der openWB meiner Mutter funktioniert der VW SOC für den ID3 leider nicht - weder mit der stable 1.9.925, noch mit der nightly 1.9.296 (2023-03-20 08:19:56 +0100 [6c86a804] ).

Bitte die Hinweise hier beachten: viewtopic.php?t=4803
Zunächst vor allem Punkt 1: T&Cs akzeptieren.
Weitere Fragen/Probleme zu SOC VWID bitte dort posten.

[phelix]

Bei der openWB meiner Mutter funktioniert der VW SOC für den ID3 leider nicht - weder mit der stable 1.9.925, noch mit der nightly 1.9.296 (2023-03-20 08:19:56 +0100 [6c86a804] ).

Bitte die Hinweise hier beachten: viewtopic.php?t=4803
Zunächst vor allem Punkt 1: T&Cs akzeptieren.
Weitere Fragen/Probleme zu SOC VWID bitte dort posten.

Super! Danke für den Tipp. Punkt 1 hats erledigt.

[Ilchi]

Hallo,

ich habe ein kleines Regelungsproblem im PV-Mode. Folgende Konfiguration:
OpenWB custom als Master
OpenWB Pro als Client
1.9.295 stable
2 PVs inkl Speicher, alles SMA, Abruf der Daten passt und sieht gut aus.

Ich hole einmal länger aus, da ich nicht weiß, was letztlich zum Fehler beiträgt:

• Ich bin mit LP2 im PV-Mode (Auto Vorrang) gestartet, LP1 war angesteckt aber blockiert. Alles gut.
• LP1 mit aktiviert, alles gut.
• LP2 abgesteckt, alles gut.
• Mode auf Speicher Vorrang gestellt, alles gut.
• ca. 1 h später LP2 wieder angesteckt, vermutlich alles gut
• LP1 deaktiviert, LP2 lädt weiter; danach kam richtig Sonne und der Speicher konnte nicht mehr so viel aufnehmen. Das Haus hat deutlich eingespeist, ca. 3 kW. Dennoch ist die Ladeleistung von LP2 nicht gestiegen, d.h. sie blieb auf 6 A.
• Mode auf Auto Vorrang gestellt, keine Änderung, weiterhin lädt Auto mit 6 A und es findet eine deutliche Einspeisung statt.

Erst ein Umstellen auf "Stopp" (ok, heißt in der OpenWB noch "Stop" ) und ein neuer Wechsel auf PV hat wieder zum erfolgreichen P-Mode geführt.

Ist dieser Fehler bekannt?

Danke
Ilchi

Ich habe weiterhin ein Regelungsproblem bei der aktuellen Stable für den 2. LP, kann das aber deutlich einfacher auslösen, als im Quote geschrieben:

• Beide LPs waren aktiv, kein Auto auf LP1, Auto auf LP2 im PV Mode mit Vorrang Hausakku; über Stunden lief das super, d.h. LP2 regelt die Hausakkuladung auf max und die Einspeisung auf 0.
• Sobald ich den LP1 deaktiviere, friert der Ladestrom auf LP2 ein. Oben dachte ich ja, dass das der minimale Strom ist, aber es scheint der zum Zeitpunkt der Deaktivierung gültige Strom zu sein. Ab dem Moment findet keinerlei Regelung mehr auf LP2 statt.

Was kann ich machen?

[A124Bob]

Hallo Zusammen,
ich stelle fest, dass der PV-Ertrag nicht korrekt aufgenommen wird.

Ohne Batterie-Speicher lief dies korrekt, nun vermute ich, dass tagsüber die Entladung des PV-Speichers auch als PV-Ertrag gezählt wird.

Aufbau: SMA STP10.0 Smart Energy mit BYD HVM Speicher

Abends nach Abschalten der PV vergleiche ich die Werte der SMA Energy App und OpenWB.
Hier gibt es eine Abweichung beim PV-Ertrag.

Siehe auch: viewtopic.php?p=82083#p82083

Gruß, Tobias

[JPRider]

... ich stelle fest, dass der PV-Ertrag nicht korrekt aufgenommen wird.

... und der Hausverbrauch vermutlich auch nicht (jeweils die Werte in Klammern). Wohingegen die Werte zum aktuellen PV-Ertrag und Hausverbrauch stimmen. Leider ein "altes" leiden, dass für den Hybriden noch nicht gelöst werden konnte.

[LutzB]

Hallo,

bei mir wird seit der 1.9.295 ein SOC von 1% angezeigt, obwohl die Hausbatterie tatsächlich bei 0% ist. Liegt da ein Fehler vor oder habe ich etwas falsch gemacht?
Ich hatte von der 1.9.271 auf die 1.9.295 upgedatet.

Über eine Antwort bzw. Lösung würde ich mich sehr freuen.

Habe SMA Tripower 10.0, SMA SBS 3.7 und den Sunny Homemanager 2.

Schönen Abend noch.

Tino

Da wurde wohl vergessen, eine entsprechende Korrektur aus der 2.0 zu migrieren. Fix kommt in die Nightly.

[LutzB]

Hallo,

ich habe ein kleines Regelungsproblem im PV-Mode. Folgende Konfiguration:
OpenWB custom als Master
OpenWB Pro als Client
1.9.295 stable
2 PVs inkl Speicher, alles SMA, Abruf der Daten passt und sieht gut aus.

Ich hole einmal länger aus, da ich nicht weiß, was letztlich zum Fehler beiträgt:

• Ich bin mit LP2 im PV-Mode (Auto Vorrang) gestartet, LP1 war angesteckt aber blockiert. Alles gut.
• LP1 mit aktiviert, alles gut.
• LP2 abgesteckt, alles gut.
• Mode auf Speicher Vorrang gestellt, alles gut.
• ca. 1 h später LP2 wieder angesteckt, vermutlich alles gut
• LP1 deaktiviert, LP2 lädt weiter; danach kam richtig Sonne und der Speicher konnte nicht mehr so viel aufnehmen. Das Haus hat deutlich eingespeist, ca. 3 kW. Dennoch ist die Ladeleistung von LP2 nicht gestiegen, d.h. sie blieb auf 6 A.
• Mode auf Auto Vorrang gestellt, keine Änderung, weiterhin lädt Auto mit 6 A und es findet eine deutliche Einspeisung statt.

Erst ein Umstellen auf "Stopp" (ok, heißt in der OpenWB noch "Stop" ) und ein neuer Wechsel auf PV hat wieder zum erfolgreichen P-Mode geführt.

Ist dieser Fehler bekannt?

Danke
Ilchi

Ich habe weiterhin ein Regelungsproblem bei der aktuellen Stable für den 2. LP, kann das aber deutlich einfacher auslösen, als im Quote geschrieben:

• Beide LPs waren aktiv, kein Auto auf LP1, Auto auf LP2 im PV Mode mit Vorrang Hausakku; über Stunden lief das super, d.h. LP2 regelt die Hausakkuladung auf max und die Einspeisung auf 0.
• Sobald ich den LP1 deaktiviere, friert der Ladestrom auf LP2 ein. Oben dachte ich ja, dass das der minimale Strom ist, aber es scheint der zum Zeitpunkt der Deaktivierung gültige Strom zu sein. Ab dem Moment findet keinerlei Regelung mehr auf LP2 statt.

Was kann ich machen?

Das konnte ich nachvollziehen und auf eine Anpassung im Dezember zurückführen: https://github.com/snaptec/openWB/pull/2562
Anscheinend gibt es da noch weitere unsaubere Abhängigkeiten im Code. Bevor noch mehr kaputt geht, stelle ich den alten Stand wieder her. Das bedeutet, dass es bei PV-Laden mit zwei oder drei LP wieder zu einer kurzen Unterbrechung auf LP2/3 kommen wird, wenn LP1 deaktiviert wird. Ist nicht schön, aber immer noch besser als eine fortgesetzte Ladung ohne Regelung.

Fix kommt in die Nightly.

[bocanea]

Hallo,
ich habe wohl seit dem Upgrade auf 1.9.288 und auch jetzt noch bei 1.9.295 ein eigenartiges Phänomen:

Auch wenn gar kein Auto an der openWB angehängt ist bekomme ich in der Tagesansicht als auch in der Monatsansicht angezeigt das der LP1 (wir haben nur einen) ca. 300-400Watt ziehen würde. Am Tag dann um die 7KW in der Monatsübersicht - auch wenn kein Fahrzeug angesteckt war.

Im Ladelog ist davon aber nichts zu sehen.

Ab und zu mal geht der Wert für eine kurze Zeit auf 0 runter um dann wieder auf die reativ konstante Höhe zu gehen - dieses ist aber unabhängig von Ladezyklen. Ich habe mir jetzt mal die alten Werte angeschaut und festgestellt dass es wohl mit dem update auf 1.9.288 gekommen sein muss.

Die Frage für mich ist jetzt vor allem - zieht die openWB wirklich die 300-400W durchgehend oder ist das ein Anzeigefehler und der Strom wird sonst im Haus verbraucht?

Der Gesammtverbrauch aus LP1 + Hausverbrauch stimmt aber leider in etwa mit dem Gesammtverbrauch von der SMA-Anlage gemessen wird überein.

Irgendwelche Ideen - ist soetwas bekannt?

Danke und Gruß

Bocanea

[rleidner]

Ich bin leider in dem Forum noch etwas unbedarft und mir ist noch nicht geläufig, wie ich ein neues Thema aufmache.

Neues Thema geht hier:

Weitere Schritte in dem neuen Thema.

[floycion]

Hallo zusammen,

nach dem update von 1.9.288 auf 1.9.295 kommen auch bei mir die PV-Werte nicht mehr rein.

OpenWB Series 2
PV-Modul: wr2-kostalsteca, Variant 1

Anscheinend ein timeout beim Aufrufen der Wechselrichter-IP.
Per Browser lassen sich alle Daten aufrufen, sowohl die .xml (Momentanwerte) als auch die .js (Ertrag)

Debug-Log:

Code: Alles auswählen

2023-03-29 21:30:17: PID: 26523: **** Regulation loop needs 6 seconds (LV2) at 62 cleanup /var/www/html/openWB/regel.sh
2023-03-29 21:30:17: PID: 26523: Timing Umschaltung: 780 / 180 (LV1) at 17 u1p3pswitch u1p3p.sh
2023-03-29 21:30:17: PID: 26523: automatische Umschaltung aktiv (LV1) at 16 u1p3pswitch u1p3p.sh
2023-03-29 21:30:16: PID: 26523: Zeit zum abfragen aller Werte 5 Sekunden (LV1) at 186 main /var/www/html/openWB/regel.sh
2023-03-29 21:30:16: PID: 26523: chargestatlp1 0 chargestatlp2 0 chargestatlp3 0 (LV1) at 1310 loadvars loadvars.sh
2023-03-29 21:30:16: PID: 26523: plugstatlp1 0 plugstatlp2 0 plugstatlp3 0 (LV1) at 1309 loadvars loadvars.sh
2023-03-29 21:30:16: PID: 26523: lp1enabled 1 lp2enabled 1 lp3enabled 1 (LV1) at 1308 loadvars loadvars.sh
2023-03-29 21:30:16: PID: 26523: EVU 1:V/0A 2: V/0A 3: V/0A (LV1) at 1307 loadvars loadvars.sh
2023-03-29 21:30:16: PID: 26523: lla3 0 llv3 228.3 llas13  llas23  soclp1 0 soclp2  (LV1) at 1306 loadvars loadvars.sh
2023-03-29 21:30:16: PID: 26523: lla2 0 llv2 229.2 llas12  llas22  sofortll 16 hausverbrauch 343 wattbezug 343 uberschuss -343 (LV1) at 1305 loadvars loadvars.sh
2023-03-29 21:30:16: PID: 26523: lla1 0 llv1 229.3 llas11  llas21  mindestuberschuss 1500 abschaltuberschuss 5 lademodus 3 (LV1) at 1304 loadvars loadvars.sh
2023-03-29 21:30:16: PID: 26523: pv1watt 0 pv2watt 0 pvwatt 0 ladeleistung 0 llalt 0 nachtladen 1 nachtladen 0 minimalA 10 maximalA 16 (LV1) at 1303 loadvars loadvars.sh
2023-03-29 21:30:16: PID: 26720: EVU RET: 0 (LV2) at 17 main modules/bezug_ethmpm3pm/main.sh
2023-03-29 21:30:16: PID: 29797: legacy run server: Completed running command in 0.72s: ["modules.devices.openwb_evu_kit.device","counter","2"]
2023-03-29 21:30:15: PID: 29797: soc.modules.common.store._api: Saving CounterState(frequency=49.95917892456055, currents=[0.49358320236206055, 0.36706840991973877, 0.7700966000556946], voltages=[229.21873474121094, 229.29766845703125, 228.58457946777344], power_factors=[0.9484899044036865, 0.7831757664680481, 0.9663785099983215], powers=[106.98072052001953, 66.4781265258789, 169.98416137695312], power=343.44300842285156, exported=8097116.115702861, imported=5015143.55359641)
2023-03-29 21:30:15: PID: 29797: modules.common.simcount._simcount: imported: 0.94364 Wh, exported: 0 Wh, new state: SimCounterState(imported=5015143.55359641, timestamp=1680118215.8068285, power=343.44300842285156, exported=8097116.115702861)
2023-03-29 21:30:15: PID: 29797: modules.common.simcount._calculate: power did not change sign. Total energy: 0.94364
2023-03-29 21:30:15: PID: 29797: modules.common.simcount._calculate: time passed: 0.00272909, power1: 348.099, power2: 343.443
2023-03-29 21:30:15: PID: 29797: modules.common.simcount._simcount: Previous state: SimCounterState(imported=5015142.609956829, timestamp=1680118205.982113, power=348.0991439819336, exported=8097116.115702861)
2023-03-29 21:30:15: PID: 29797: soc.modules.common.component_context: Update Komponente ['EVU-Kit']
2023-03-29 21:30:15: PID: 29797: modules.devices.openwb_evu_kit.device: Start device reading {'componentNone': <modules.devices.openwb_evu_kit.counter.EvuKit object at 0x74e955b0>}
2023-03-29 21:30:15: PID: 29797: modules.devices.openwb_evu_kit.device: openWB Version: 2
2023-03-29 21:30:15: PID: 29797: legacy run server: Received command ["modules.devices.openwb_evu_kit.device","counter","2"]
requests.exceptions.ConnectTimeout: HTTPConnectionPool(host='192.168.2.33', port=80): Max retries exceeded with url: /measurements.xml (Caused by ConnectTimeoutError(<requests.packages.urllib3.connection.HTTPConnection object at 0x74e954d0>, 'Connection to 192.168.2.33 timed out. (connect timeout=2)'))
raise ConnectTimeout(e, request=request)
File "/usr/lib/python3/dist-packages/requests/adapters.py", line 479, in send
r = adapter.send(request, **kwargs)
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 609, in send
resp = self.send(prep, **send_kwargs)
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 488, in request
return session.request(method=method, url=url, **kwargs)
File "/usr/lib/python3/dist-packages/requests/api.py", line 56, in request
return request('get', url, params=params, **kwargs)
File "/usr/lib/python3/dist-packages/requests/api.py", line 70, in get
measurements = requests.get("http://" + pv2ip + "/measurements.xml", timeout=2).text
File "/var/www/html/openWB/modules/wr2_kostalsteca/kostal_steca.py", line 29, in update
parser.set_defaults(RUN=lambda args: function(*[getattr(args, argument_name) for argument_name in arg_spec.args]))
File "/var/www/html/openWB/packages/helpermodules/cli/_run_using_positional_cli_args.py", line 19, in <lambda>
args.RUN(args)
File "/var/www/html/openWB/packages/helpermodules/cli/_run_using_positional_cli_args.py", line 34, in run_using_positional_cli_args
run_using_positional_cli_args(update, argv)
File "/var/www/html/openWB/modules/wr2_kostalsteca/kostal_steca.py", line 74, in main
importlib.import_module(parsed[0]).main(parsed[1:])
File "/var/www/html/openWB/packages/legacy_run_server.py", line 109, in handle_message
self.__callback(read_all_bytes(connection))
File "/var/www/html/openWB/packages/legacy_run_server.py", line 87, in handle_connection
yield
File "/var/www/html/openWB/packages/legacy_run_server.py", line 48, in redirect_stdout_stderr_exceptions_to_log
Traceback (most recent call last):

During handling of the above exception, another exception occurred:

requests.packages.urllib3.exceptions.MaxRetryError: HTTPConnectionPool(host='192.168.2.33', port=80): Max retries exceeded with url: /measurements.xml (Caused by ConnectTimeoutError(<requests.packages.urllib3.connection.HTTPConnection object at 0x74e954d0>, 'Connection to 192.168.2.33 timed out. (connect timeout=2)'))
raise MaxRetryError(_pool, url, error or ResponseError(cause))
File "/home/pi/.local/lib/python3.5/site-packages/urllib3/util/retry.py", line 592, in increment
method, url, error=e, _pool=self, _stacktrace=sys.exc_info()[2]
File "/home/pi/.local/lib/python3.5/site-packages/urllib3/connectionpool.py", line 786, in urlopen
timeout=timeout
File "/usr/lib/python3/dist-packages/requests/adapters.py", line 423, in send
Traceback (most recent call last):

During handling of the above exception, another exception occurred:

requests.packages.urllib3.exceptions.ConnectTimeoutError: (<requests.packages.urllib3.connection.HTTPConnection object at 0x74e954d0>, 'Connection to 192.168.2.33 timed out. (connect timeout=2)')
% (self.host, self.timeout),
File "/home/pi/.local/lib/python3.5/site-packages/urllib3/connection.py", line 182, in _new_conn
conn = self._new_conn()
File "/home/pi/.local/lib/python3.5/site-packages/urllib3/connection.py", line 205, in connect
self.connect()
File "/usr/lib/python3.5/http/client.py", line 877, in send
self.send(msg)
File "/usr/lib/python3.5/http/client.py", line 934, in _send_output
self._send_output(message_body)
File "/usr/lib/python3.5/http/client.py", line 1103, in endheaders
self.endheaders(body)
File "/usr/lib/python3.5/http/client.py", line 1152, in _send_request
self._send_request(method, url, body, headers)
File "/usr/lib/python3.5/http/client.py", line 1107, in request
super(HTTPConnection, self).request(method, url, body=body, headers=headers)
File "/home/pi/.local/lib/python3.5/site-packages/urllib3/connection.py", line 239, in request
conn.request(method, url, **httplib_request_kw)
File "/home/pi/.local/lib/python3.5/site-packages/urllib3/connectionpool.py", line 398, in _make_request
chunked=chunked,
File "/home/pi/.local/lib/python3.5/site-packages/urllib3/connectionpool.py", line 710, in urlopen
2023-03-29 21:30:14: PID: 26684: RET: 0 (LV2) at 19 main modules/wr2_kostalsteca/main.sh
Traceback (most recent call last):

During handling of the above exception, another exception occurred:

socket.timeout: timed out
sock.connect(sa)
File "/home/pi/.local/lib/python3.5/site-packages/urllib3/util/connection.py", line 85, in create_connection
raise err
File "/home/pi/.local/lib/python3.5/site-packages/urllib3/util/connection.py", line 95, in create_connection
(self._dns_host, self.port), self.timeout, **extra_kw
File "/home/pi/.local/lib/python3.5/site-packages/urllib3/connection.py", line 175, in _new_conn
Traceback (most recent call last):
2023-03-29 21:30:14: PID: 29797: legacy run server: Unhandled exception
2023-03-29 21:30:12: PID: 29797: requests.packages.urllib3.connectionpool: Starting new HTTP connection (1): 192.168.2.33:80
2023-03-29 21:30:12: PID: 29797: KostalSteca WR: PV Kostal Steca Variant: 1
2023-03-29 21:30:12: PID: 29797: KostalSteca WR: PV Kostal Steca IP: 192.168.2.33
2023-03-29 21:30:12: PID: 29797: legacy run server: Received command ["wr2_kostalsteca.kostal_steca","192.168.2.33","1"]
2023-03-29 21:30:12: PID: 26684: PV IP: 192.168.2.33 (LV2) at 14 main modules/wr2_kostalsteca/main.sh
2023-03-29 21:30:11: PID: 26523: **** Regulation loop start **** (LV1) at 77 main /var/www/html/openWB/regel.sh

Woran könnt's liegen?
Bin wieder auf 1.9.288 zurück, Werte kommen wieder rein.

Übrigens ist das Colors-Theme inzwischen richtig hübsch geworden!

Schönen Abend
Florian