openWB Forum

Verfasst: **Di Feb 20, 2024 11:42 am**

Die Ankündigung findet Ihr hier: https://forum.openwb.de/viewtopic.php?t=8349

Mit Problemen bei Inbetriebnahme / Anschluss oder Hardwareproblemen mit openWB-Hardware bitte direkt über die Support-Funktion unter System -> Support an openWB wenden (Notfalls auch per Mail an support@openwb.de).
Im Forum kann durchaus mal etwas untergehen. Das führt zu Frust und soll nicht sein.

Bitte keine Mehrfach-Meldung per Mail, Support-Ticket und Forum.
Das spart auf unserer Seite Supportzeit und bringt erfahrungsgemäß keine Beschleunigung des Vorgangs.

Bitte bei Problemen immer einen Logauszug posten:

Dazu unter System->Fehlersuche das Debuglevel auf Details stellen und mindestens zwei komplette Durchläufe von # ***Start*** bis # ***Start*** aus dem Main-Log kopieren, während das Problem auftritt. Sensible Daten wie Benutzernamen und Kennwörter unkenntlich machen.
Logauszüge bitte als Codeblock posten (Schaltfläche "</>" über dem Editor-Fenster).
Bei Problemen mit dem internen Ladepunkt zusätzlich einen Auszug aus dem Log des internen Ladepunkts, bei Problemen mit dem Soc aus dem Soc-Log posten.
Bei Problemen mit dem UI/Darstellung bitte ein Theme verwenden, das von openWB gepflegt wird (wird bei der Themeauswahl angezeigt).

Screenshots ersetzen keinen Logauszug!
Für Beiträge wie "Funktion XY geht nicht mehr! Woran kann das liegen?" ohne Logs gibt es von uns keine Hilfestellung.

Verfasst: **Di Feb 20, 2024 12:16 pm**

OpenWB Series2 standard+ mit Entwicklungszwei Beta (2024-02-20 12:30:40 +0100 [1561b0d01])

Beim Speichervorrang mit Rundown_Power kommt es mitunter zu abruptem heftigem Hochregeln.

(Das folgende ist eine Zusammenfassung mit Findings aus dem Thread https://forum.openwb.de/viewtopic.php?t=7025)

Ich denke, mein angehaengtes Log vom 17. Februar 2017 ist da noch valide, denn es gab seitdem keine relevanten Aenderungen. In dieser main.log ist mir etwas aufgefallen. Dazu folgendes im Hinterkopf behalten: Bei der Aufzeichung war die Rundown Power auf 1000W gesetzt.

Solange der Betrag der Speicherleistung (openWB/set/bat/get/power Power) unter 1000 W liegt, wird die erlaubte Entladeleistung als Absolutwert in Richtung der 1000W bestimmt (ggf. auf ein Inkrement von 50W beschraenkt durch https://github.com/openWB/core/blob/958 ... ll.py#L149).

Wird der Speicher aber mit mehr als 1000W entladen, wird die erlaubte Entladeleistung stattdessen als Delta zu 1000W berechnet.

Je nachdem, auf welcher Seite der rundown_power von 1000W sich die Speicherentladung gerade befindet, ist die effektive Semantik des berechneten Wertes eine andere: Mal ist es ein Zielwert, mal ein Offset.

Code: Alles auswählen

11:13:11,379 - {helpermodules.changed_values_handler:120} - {DEBUG:MainThread} - Topic openWB/set/bat/get/power, Payload -1002.98, vorherige Payload: -1259.04
11:13:11,487 - {control.bat_all:205} - {DEBUG:MainThread} - Erlaubte Entlade-Leistung nutzen -2.980000000000018W
11:13:11,488 - {control.bat_all:171} - {INFO:MainThread} - -2.980000000000018W verbleibende Speicher-Leistung
[...]
11:13:31,023 - {helpermodules.changed_values_handler:120} - {DEBUG:MainThread} - Topic openWB/set/bat/get/power, Payload -796.18, vorherige Payload: -1002.98
11:13:31,125 - {control.bat_all:159} - {DEBUG:MainThread} - Verbleibende Speicher-Leistung durch maximale Ausgangsleistung auf 846.18W begrenzt.
11:13:31,126 - {control.bat_all:205} - {DEBUG:MainThread} - Erlaubte Entlade-Leistung nutzen 846.18W
11:13:31,126 - {control.bat_all:171} - {INFO:MainThread} - 846.18W verbleibende Speicher-Leistung
[...]
11:13:51,460 - {helpermodules.changed_values_handler:120} - {DEBUG:MainThread} - Topic openWB/set/bat/get/power, Payload -1124.88, vorherige Payload: -796.18
11:13:51,578 - {control.bat_all:205} - {DEBUG:MainThread} - Erlaubte Entlade-Leistung nutzen -124.88000000000011W
11:13:51,579 - {control.bat_all:171} - {INFO:MainThread} - -124.88000000000011W verbleibende Speicher-Leistung
[...]
11:14:10,969 - {helpermodules.changed_values_handler:120} - {DEBUG:MainThread} - Topic openWB/set/bat/get/power, Payload -975.24, vorherige Payload: -1124.88
11:14:11,092 - {control.bat_all:205} - {DEBUG:MainThread} - Erlaubte Entlade-Leistung nutzen 1000W
11:14:11,093 - {control.bat_all:171} - {INFO:MainThread} - 1000W verbleibende Speicher-Leistung
[...]
11:14:31,652 - {helpermodules.changed_values_handler:120} - {DEBUG:MainThread} - Topic openWB/set/bat/get/power, Payload -1416.25, vorherige Payload: -975.24
11:14:31,785 - {control.bat_all:205} - {DEBUG:MainThread} - Erlaubte Entlade-Leistung nutzen -416.25W
11:14:31,789 - {control.bat_all:171} - {INFO:MainThread} - -416.25W verbleibende Speicher-Leistung
[...]
11:14:51,326 - {helpermodules.changed_values_handler:120} - {DEBUG:MainThread} - Topic openWB/set/bat/get/power, Payload -970.08, vorherige Payload: -1416.25
11:14:51,450 - {control.bat_all:205} - {DEBUG:MainThread} - Erlaubte Entlade-Leistung nutzen 1000W
11:14:51,452 - {control.bat_all:171} - {INFO:MainThread} - 1000W verbleibende Speicher-Leistung
[...]
11:15:11,556 - {helpermodules.changed_values_handler:120} - {DEBUG:MainThread} - Topic openWB/set/bat/get/power, Payload -1403.22, vorherige Payload: -970.08
11:15:11,681 - {control.bat_all:205} - {DEBUG:MainThread} - Erlaubte Entlade-Leistung nutzen -403.22W
11:15:11,682 - {control.bat_all:171} - {INFO:MainThread} - -403.22W verbleibende Speicher-Leistung
[...]
11:15:31,125 - {helpermodules.changed_values_handler:120} - {DEBUG:MainThread} - Topic openWB/set/bat/get/power, Payload -1055.75, vorherige Payload: -1403.22
11:15:31,231 - {control.bat_all:205} - {DEBUG:MainThread} - Erlaubte Entlade-Leistung nutzen -55.75W
11:15:31,232 - {control.bat_all:171} - {INFO:MainThread} - -55.75W verbleibende Speicher-Leistung

Ich zitiere mal aus BatAll._get_charging_power_left() https://github.com/openWB/core/blob/958 ... ll.py#L198. Zeile 201 berechnet den Offset, Zeile 203 setzt den Absolutwert.

Code: Alles auswählen

198                     if self.data.get.power * -1 > config.rundown_power:
199                         # Wenn der Speicher mit mehr als der erlaubten Entladeleistung entladen wird, muss das vom
200                         # Überschuss subtrahiert werden.
201                         self.data.set.charging_power_left = config.rundown_power + self.data.get.power
202                     else:
203                         self.data.set.charging_power_left = self._limit_rundown_power(
204                             config.rundown_power)
205                     log.debug(f"Erlaubte Entlade-Leistung nutzen {self.data.set.charging_power_left}W")

Wenn ich Zeile 203 und 204 wie folgt aendere, tritt das pulsierende abrupte Hochregeln nicht mehr auf:

Code: Alles auswählen

203                         self.data.set.charging_power_left = self._limit_rundown_power(
204                             config.rundown_power + self.data.get.power)

Verfasst: **Di Feb 20, 2024 12:37 pm**

Ein Minor Bug von mir:
Meine Series 2 Standard+ läuft als Secondary und wird über Modbus TCP gesteuert. Das funktioniert auch einwandfrei. Es gibt lediglich einen kleinen Anzeigefehler auf der Status-Seite.
Und war wird die Ladeleistung sowie die Umschaltung durch evcc gemacht, das funktioniert auch einwandfrei. Allerdings fehlt in der Status-Anzeige die Vorgabe der Phasen ("phases_to_use"):

: Screenshot 2024-02-20 133202.png (54.29 KiB) 2526 mal betrachtet

In den Logs hingegen ist der Wert korrekt da:

Code: Alles auswählen

2024-02-20 13:22:22,955 - {modules.internal_chargepoint_handler.internal_chargepoint_handler:192} - {DEBUG:Internal Chargepoint} - {'cp0': InternalChargepoint(data=InternalChargepointData(cp_interruption_duration=0, parent_cp='0', phases_to_use=1, set_current=8.06, trigger_phase_switch=False), get=Get(charge_state=True, currents=[7.69, 0.0, 0.0], evse_current=8, exported=0, fault_str='Kein Fehler.', fault_state=0, imported=151470, phases_in_use=1, plug_state=True, power=1763.21, rfid_timestamp=None, rfid=None, voltages=[231.2, 232.4, 236.8])), 'cp1': InternalChargepoint(data=InternalChargepointData(cp_interruption_duration=0, parent_cp=None, phases_to_use=0, set_current=0, trigger_phase_switch=False), get=Get(charge_state=False, currents=[0.0, 0.0, 0.0], evse_current=0, exported=0, fault_str='Kein Fehler.', fault_state=0, imported=0, phases_in_use=0, plug_state=False, power=0, rfid_timestamp=None, rfid=None, voltages=[230.0, 230.0, 230.0])), 'global_data': GlobalHandlerData(heartbeat=1708431734.12735, parent_ip=None, configured=True), 'rfid_data': RfidData(last_tag='')}

Da fehlt vermutlich nur ein Mapping im UI.

Verfasst: **Di Feb 20, 2024 2:01 pm**

Hallo, ich habe eine smart WB die ich mit der Open WB steuere. In der Zuleitung kann ich entweder auf 1 phasig oder 3 phasig stellen. Bei der 1.9er erkannte es das System ob 1 oder 3 Phasen vorhanden waren. Bei der 2er Software muss ich das ja in der Ladepunktkonfiguration angeben. Wenn hier 3 Phasen steht aber nur 1 Phase da ist beginnt die Ladung nicht. Kann man das nicht aus den Werte ableiten. Hier werden ja die Spannungen aus der Wallbox ausgelesen. Und hier könnte man ja 1 oder 3 Phasen ableiten.

Verfasst: **Di Feb 20, 2024 2:03 pm**

Im aktuellen Master (heute 10.36 Uhr) ist trotz Changelog-Eintrag immer noch ein gewaltiger Peak bei Kontaktverlust zum Wechselrichter erkennbar.

Mainlog (leider nur Standarteinstellung:

Code: Alles auswählen

2024-02-20 14:46:53,328 - {pymodbus.client.sync:218} - {ERROR:device1} - Connection to (192.168.188.74, 502) failed: timed out
2024-02-20 14:46:55,350 - {modules.common.fault_state:49} - {ERROR:device9} - Hoymiles Wechselrichter: FaultState FaultStateLevel.ERROR, FaultStr Die Verbindung zum Server http://192.168.188.82/api/livedata/status 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)
socket.timeout: timed out

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 174, in _new_conn
    raise ConnectTimeoutError(
urllib3.exceptions.ConnectTimeoutError: (<urllib3.connection.HTTPConnection object at 0x71d20658>, 'Connection to 192.168.188.82 timed out. (connect timeout=5)')

Screenshot 2024-02-20 145817.png: (22.69 KiB) Noch nie heruntergeladen

Verfasst: **Di Feb 20, 2024 3:22 pm**

Frank-H hat geschrieben: ↑Di Feb 20, 2024 2:03 pm Im aktuellen Master (heute 10.36 Uhr) ist trotz Changelog-Eintrag immer noch ein gewaltiger Peak bei Kontaktverlust zum Wechselrichter erkennbar.
...

Ah, das könnte auch die Ursache für das Problem sein, welches ich hier https://forum.openwb.de/viewtopic.php?p=102829#p102829 gemeldet habe. Denn Verbindungsabbrüche beim Abruf meiner Powerwall habe ich weiterhin und meine Diagramme sehen auch so aus:

Unbenannt.png: (40.27 KiB) Noch nie heruntergeladen

Verfasst: **Di Feb 20, 2024 7:20 pm**

Hallo,

ich wollte heute meinen zweiten Inverter installieren, diesmal einer von deye , 3 Phasen SUN-12K-SG04LP3 incl. Speicher. Davor hatte ich den Inverter in Home Assistent implementiert , funktioniert einwandfrei. Folgende konfig habe ich genutzt:
inverter_host: 192.168.x.x
inverter_port: 8899
inverter_serial: 1720747149
inverter_mb_slaveid: 1
lookup_file: deye_hybrid.yaml

Leider bekomme ich nach der Eingabe der oben genannten konfig (ohne serial da kein Feld dafür) im Openwb Status folgende Fehlermeldung:
Modulmeldung:
<class 'Exception'> ("modules.common.modbus <class 'Exception'> modules.common.modbus Modbus Error: [Input/Output] No Response received from the remote unit/Unable to decode response",)

Log:
024-02-21 05:14:03,583 - {modules.common.fault_state:49} - {ERROR:device5} - Deye/Jinko Wechselrichter: FaultState FaultStateLevel.ERROR, FaultStr <class 'Exception'> ("modules.common.modbus <class 'Exception'> modules.common.modbus Modbus Error: [Input/Output] No Response received from the remote unit/Unable to decode response",), Traceback:
Traceback (most recent call last):
File "/var/www/html/openWB/packages/modules/common/modbus.py", line 91, in __read_registers
raise Exception(__name__+" "+str(response))
Exception: modules.common.modbus Modbus Error: [Input/Output] No Response received from the remote unit/Unable to decode response

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "/var/www/html/openWB/packages/modules/devices/deye/device.py", line 34, in update_components
component.update(c, DeviceType(device_config.configuration.device_type))
File "/var/www/html/openWB/packages/modules/devices/deye/inverter.py", line 28, in update
power = sum(client.read_holding_registers(672, [ModbusDataType.INT_16]*2, unit=unit)) * -1
File "/var/www/html/openWB/packages/modules/common/modbus.py", line 120, in read_holding_registers
return self.__read_registers(
File "/var/www/html/openWB/packages/modules/common/modbus.py", line 103, in __read_registers
raise Exception(__name__+" "+str(type(e))+" " + str(e)) from e
Exception: modules.common.modbus <class 'Exception'> modules.common.modbus Modbus Error: [Input/Output] No Response received from the remote unit/Unable to decode response

Ich nutze den neusten master Stand:
2024-02-20 13:04:40 +0100 [2a83a6338]

Ich hatte auch das Modul in Home-Assistent testweise deaktiviert, leider keine Veränderung.

Gruß

Christoph

Verfasst: **Mi Feb 21, 2024 8:18 am**

Gibt es eigentlich eine Möglichkeit, mißliebige Einträge im Ladelog zu korrigieren bzw. entfernen? Ich hab' da so einen, den ich gerne loswerden wollte:

: log.jpg (51.71 KiB) 2340 mal betrachtet

Verfasst: **Mi Feb 21, 2024 9:04 am**

LenaK hat geschrieben: ↑Di Feb 20, 2024 11:31 am
Peaks in den Diagrammen korrigiert

2.1.3-Beta.2
2024-02-20 13:04:40 +0100 [2a83a6338]

Kann ich für mich im "Tages Diagramm" leider nicht bestätigen

: peaks.png (14.25 KiB) 2325 mal betrachtet

Ich fange bei mir schon unplausible Werte ab bevor diese per MQTT raus gehen an "openWB/set/pv/7/get/power":

Code: Alles auswählen

var WR_gesammt		= 0;

var PV_WR1		= WR1_power - Battery;

WR_gesammt		= PV_WR1 + WR2_power + WR3_power;

WR_gesammt		= Math.round(WR_gesammt);

if (isNaN(WR_gesammt) || WR_gesammt < -20000 || WR_gesammt > 0) WR_gesammt = 0;

Wenn ich irgendwelche Daten noch liefern kann zur Fehlersuche, dann kurze Info. Meine Werte gehen alle zusammen raus, das passiert jede Sekunde.

Verfasst: **Do Feb 22, 2024 10:11 am**

LenaK hat geschrieben: ↑Di Feb 20, 2024 11:31 am
Peaks in den Diagrammen korrigiert

Bei mir ebenso. Nächtlicher Peak ist noch da.
2.1.3-Beta.2
Goodwe ET10 Plus und Lynx Batterie (Hybrid)
Die anderen Module Fronius und JSON haben diese Peaks nicht.
Ergänzung. Das passiert immer, wenn der Akku den niedrigsten Stand erreicht (SoC 5%).
Alles ist per LAN verbunden.
Im Protokoll meines Netzwerk-Controlleres (Unifi UDM) gibt es keine Auffäligkeiten (Ab-/Anmeldungen von Clients).

: IMG_3585.jpeg (184.21 KiB) 2208 mal betrachtet

openWB Forum

Rückmeldungen openWB software 2.1.3 Beta 2

Rückmeldungen openWB software 2.1.3 Beta 2

Re: Rückmeldungen openWB software 2.1.3 Beta 2

Re: Rückmeldungen openWB software 2.1.3 Beta 2

Re: Rückmeldungen openWB software 2.1.3 Beta 2

Re: Rückmeldungen openWB software 2.1.3 Beta 2

Re: Rückmeldungen openWB software 2.1.3 Beta 2

Re: Rückmeldungen openWB software 2.1.3 Beta 2

Re: Rückmeldungen openWB software 2.1.3 Beta 2

Re: Rückmeldungen openWB software 2.1.3 Beta 2

Re: Rückmeldungen openWB software 2.1.3 Beta 2