Rückmeldungen Nightly 1.9.274

[rkaeufl]

Reboote Deine Box mal. Sieht für mich so aus, als ob der Legacy run server nicht neu gestartet wurde und noch die alten Python Dateien genutzt werden.

Auch ein Ausschalten und Neustart produziert die selben Einträge im Log (1.9.274 (2022-08-24 15:04:39 +0200 [4863094e] )):

Code: Alles auswählen

KeyError: 'port'
type = arg_spec.annotations[argument_name]
File "/var/www/html/openWB/packages/helpermodules/cli/_run_using_positional_cli_args.py", line 11, in _add_positional_parser_args
_add_positional_parser_args(sub_parsers.add_parser(command_name), function)
File "/var/www/html/openWB/packages/helpermodules/cli/_run_using_positional_cli_args.py", line 29, in run_using_positional_cli_args
{"bat": read_legacy_bat, "counter": read_legacy_counter, "inverter": read_legacy_inverter}, argv
File "/var/www/html/openWB/packages/modules/sungrow/device.py", line 103, 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
2022-08-25 20:29:43: PID: 4875: EVU RET: 0 (LV2) at 16 main modules/bezug_sungrow/main.sh
Traceback (most recent call last):
2022-08-25 20:29:43: PID: 2019: legacy run server: Unhandled exception
2022-08-25 20:29:43: PID: 2019: legacy run server: Received command ["modules.sungrow.device","counter","192.168.111.71","502","1","0"]
2022-08-25 20:29:43: PID: 4845: BAT RET: 0 (LV2) at 16 main modules/speicher_sungrow/main.sh
KeyError: 'port'
type = arg_spec.annotations[argument_name]
File "/var/www/html/openWB/packages/helpermodules/cli/_run_using_positional_cli_args.py", line 11, in _add_positional_parser_args
_add_positional_parser_args(sub_parsers.add_parser(command_name), function)
File "/var/www/html/openWB/packages/helpermodules/cli/_run_using_positional_cli_args.py", line 29, in run_using_positional_cli_args
{"bat": read_legacy_bat, "counter": read_legacy_counter, "inverter": read_legacy_inverter}, argv
File "/var/www/html/openWB/packages/modules/sungrow/device.py", line 103, 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):
2022-08-25 20:29:43: PID: 2019: legacy run server: Unhandled exception
2022-08-25 20:29:43: PID: 2019: legacy run server: Received command ["modules.sungrow.device","bat","192.168.111.71","502","1"]
KeyError: 'port'
type = arg_spec.annotations[argument_name]
File "/var/www/html/openWB/packages/helpermodules/cli/_run_using_positional_cli_args.py", line 11, in _add_positional_parser_args
_add_positional_parser_args(sub_parsers.add_parser(command_name), function)
File "/var/www/html/openWB/packages/helpermodules/cli/_run_using_positional_cli_args.py", line 29, in run_using_positional_cli_args
{"bat": read_legacy_bat, "counter": read_legacy_counter, "inverter": read_legacy_inverter}, argv
File "/var/www/html/openWB/packages/modules/sungrow/device.py", line 103, 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):
2022-08-25 20:29:43: PID: 2019: legacy run server: Unhandled exception
2022-08-25 20:29:43: PID: 2019: legacy run server: Received command ["modules.sungrow.device","inverter","192.168.111.71","502","1","1"]

Zur Konfiguration:
Jeder Wechselrichter hat eine eigene IP und Geräteadresse.
Die angehängten Geräte (EVU, PV und Batterie) sind nur über diese IP und Adresse zu erreichen. Natürlich mit den Modbusregistern.
Heißt in meinem Fall das am WR1 die EVU, die PV Module und die Batterie hängen und der 2 WR nur die PV-Module hat, ich also 192.168.xx.1:502 Adresse 1 für EVU, PV und die Batterie und 192.168.xx.2:502 Adresse 2 für die 2. PV verwende. Das mit den 2 Verbindungen wird sich bei 2 Sungrow Wechselrichtern nicht vermeiden lassen.

So wie es in der 2.0 alpha3 von heute umgesetzt wurde funktioniert es einwandfrei.

Danke und Gruß!

[LutzB]

Der WR2 ist mir bei den Anpassungen der 1.9 durchgegangen. Ich vermute, dass die Meldung davon kommt. Bitte zum Testen mal PV2 nicht konfigurieren. Dann sollten die Meldungen verschwinden. Die Einstellungen reiche ich noch nach, wenn der nächste Absatz geklärt ist.

Inzwischen habe ich mich gefragt, wo die Geräteadresse für 2.0 am Besten aufgehoben ist. Das Konzept mit den Geräten und Komponenten kennst Du ja, wenn Du das schon eingerichtet hast. Ein Gerät wird immer für die Verbindung genutzt. Heißt in diesem Fall, dass alles, was unter identischem IP:Port erreicht werden kann, über ein Gerät abgebildet werden kann. Die Geräteadresse ist aktuell auch im Gerät hinterlegt, obwohl er nicht zwingend etwas mit der TCP-Verbindung zu tun hat. Macht es Sinn, die Geräteadresse in die Komponente zu verschieben? Können also bei Sungrow WR, oder Speicher über eine IP mit verschiedenen Geräteadressen angesprochen werden? Warum haben die überhaupt verschiedene Geräteadressen? Sind die intern miteinander verbunden?

[RunningMan]

Mir ist folgendes Phänomen erstmalig mit der Nightly 1.9.272 aufgefallen:
Im Lademodus "nur PV" hat die openWB bei fast voller Ladeleistung die Stromstärke nicht (ausreichend) reduziert, obwohl der Bezug aus dem Netz seit über einer halben Stunde bei >1kW lag (ab ca. 15:00 im angehängten Logbild) - und das, obwohl sogar die Abschaltbedingung auf +10W und 600s eingestellt ist, was normalerweise einwandfrei funktioniert.
Der von mir vermutete Auslöser für dieses Verhalten ist, dass zum o.a. Zeitpunkt die PV1 (incl. ~1.2kW Bezug aus der Batterie) bei ihrer max. AC-Leistung von 4.25kW lag und die PV2 aufgrund der aktuellen Einstrahlung "nur" bei ca. ~4.5kW. Meine Einstellung für den max. Bezug aus der Batterie ist jedoch 2kW. Damit war der tatsächliche Bezug aus der Batterie geringer als max. erlaubt, aber trotzdem fand Bezug aus dem Netz statt (aufgrund der "unglücklichen" Kombination von solarer Einstrahlung und Anlagensetup).
Ich weiß nicht, ob ich da einen Denkfehler mache, hätte aber erwartet, dass die openWB ob des längeren, hohen Bezugs aus dem öffentlichen Netz entweder die Ladestromstärke so angepasst hätte, dass kein (längerer) Netzbezug stattfindet oder sogar die Abschaltbedingung gegriffen hätte.

[rkaeufl]

Der WR2 ist mir bei den Anpassungen der 1.9 durchgegangen. Ich vermute, dass die Meldung davon kommt. Bitte zum Testen mal PV2 nicht konfigurieren. Dann sollten die Meldungen verschwinden. Die Einstellungen reiche ich noch nach, wenn der nächste Absatz geklärt ist.

Inzwischen habe ich mich gefragt, wo die Geräteadresse für 2.0 am Besten aufgehoben ist. Das Konzept mit den Geräten und Komponenten kennst Du ja, wenn Du das schon eingerichtet hast. Ein Gerät wird immer für die Verbindung genutzt. Heißt in diesem Fall, dass alles, was unter identischem IP:Port erreicht werden kann, über ein Gerät abgebildet werden kann. Die Geräteadresse ist aktuell auch im Gerät hinterlegt, obwohl er nicht zwingend etwas mit der TCP-Verbindung zu tun hat. Macht es Sinn, die Geräteadresse in die Komponente zu verschieben? Können also bei Sungrow WR, oder Speicher über eine IP mit verschiedenen Geräteadressen angesprochen werden? Warum haben die überhaupt verschiedene Geräteadressen? Sind die intern miteinander verbunden?

Die Geräteadresse ist am besten beim Wechselrichter aufgehoben, da die angebundenen Komponenten nur darüber erreichbar sind(Modbus Register).
Hier ein Bild zur Verdeutlichung:

B: Wechselrichter mit IP, Port und Geräteadresse
E: Batterie per DC angeschlossen (nur über die Modbus Register erreichbar)
C: EVU (auch nur über die Modbus Register erreichbar)
A: PV Leistung(das selbe)

NUR wenn ein 2. Wechselrichter im System ist, wird dieser mit seiner eigenen IP, Port und Geräteadresse angesprochen. Die dahinterliegenden Komponenten dann wieder über den WR und den entsprechenden Modbus Registern.

Das wäre alles kein Problem, wenn sich nicht die RS485 ID (die ja bei beiden WR unterschiedlich sein muss) auch auf die Modbus/TCP ID (Geräteadresse) auswirken würde.

In der 2.0 ist es genau richtig ausgeführt:

Den 2. Wechselrichter hatte ich vorsichtshalber noch nicht konfiguriert. Der Fehler muss noch von einer anderen Stelle kommen.

Gruß
Roland

[LutzB]

Bitte mit der aktuellen Nightly testen. Habe gerade noch ein Bugfix für das Modul eingestellt.
Deine Fehlermeldung sollte jetzt nicht mehr kommen und der zweite WR kann mit separatem Port und Geräte ID konfiguriert werden.

[rkaeufl]

Bitte mit der aktuellen Nightly testen. Habe gerade noch ein Bugfix für das Modul eingestellt.
Deine Fehlermeldung sollte jetzt nicht mehr kommen und der zweite WR kann mit separatem Port und Geräte ID konfiguriert werden.

Funktioniert einwandfrei.

Danke!

Gruß
Roland

[miel13]

Hallo, Entwicklerteam!
Ich wollte nur mitteilen, daß meine Probleme mit derm fehlenden Kummulationsstand bei Pv-Ertrag und Hausverbrauch dank der Unterstützung von HSC behoben sind. Weiter konnte die Ursache der Modbus-Fehlermeldungen des SDM 120 beseitigt werden. Danke
Gr miel13