Rückmeldungen software2 2.1.8-Alpha 2

[seaspotter]

Ich kann nur einen Log von meinem Testsystem (Rasbpi) liefern, wo kein Ladepunkt eingerichtet ist. Das Verhalten war beim Produktivsystem aber dasselbe:

MQTT-Log: https://paste.openwb.de/gMhCD8asO35Fs3T
Main-Log: https://paste.openwb.de/IMlFkJhMCEOMsZr

Ich habe mir den PR nicht näher angeschaut, aber es war das einzige, was in der letzten Woche am Kostal Modul geändert wurde.

Jo das "Problem" ist die DC Power im Inverter Moduls welche Andreas letzte Woche eingebaut hat. Dann stimmt die Kostal Sunspec Modbus Beschreibung wohl nicht, dass nicht alle WR diesen Wert liefern, obwohl er klar ausgewiesen ist: https://www.kostal-solar-electric.com/f ... ontrol.pdf

Muss dann optional rein oder wieder raus Oder deine Firmware ist so alt bzw dein WR

[therobbot]

Ich habe noch einen Plenticore Plus 8.5 in der ersten Version. Ich habe jetzt mal die Firmware auf den aktuellsten Stand gebracht und damit scheint es tatsächlich zu funktionieren. Das wird aber dann vermutlich auch bei anderen Benutzern ein Problem werden. Ich habe bisher noch nie eine Veranlassung gesehen, die Firmware des WR zu aktualisieren, da ja alles funktioniert hat.

[seaspotter]

Ich habe noch einen Plenticore Plus 8.5 in der ersten Version. Ich habe jetzt mal die Firmware auf den aktuellsten Stand gebracht und damit scheint es tatsächlich zu funktionieren. Das wird aber dann vermutlich auch bei anderen Benutzern ein Problem werden. Ich habe bisher noch nie eine Veranlassung gesehen, die Firmware des WR zu aktualisieren, da ja alles funktioniert hat.

Ja das Problem ist ja aber immer das man die Modbus-Anbindung von Geräten nach aktuellen Registerbeschreibungen programmiert, wenn dann Altgeräte über FW Update neue Funktionen bzw neue Register bekommen, ist es schwer auch bis ins unendliche alte Geräte bzw. alte FW-Stände weiter zu supporten
Ich hab trotzdem mal n Fix gemacht, der noch gemergt werden muss, wenn die dc_power nicht abgerufen werden kann, dass das dann einfach ignoriert wird und trotzdem weiter läuft https://github.com/openWB/core/pull/2618

[therobbot]

Ja, ist schon klar, dass man nicht unendlich alte Stände supporten kann. Aber vielleicht könnte dann zumindest in die Info-Meldung, wenn die Zählerwerte nicht abgerufen werden kann, der Hinweis, dass man ein Firmware-Update des Wechselrichters durchführen soll.

Das wäre vielleicht sogar besser, als ein Workaround.

[seaspotter]

Es gibt ja nicht nur die eine Fehlermeldung sondern es könnten ja theoretisch auch noch andere Fehler auftauchen, das die Modbus Kommunikation gar nicht funktioniert gerade zum Beispiel. Nicht immer ist es ja nur ein FW Update, was das Problem behebt.

[LenaK]

Der manuelle SoC von 0% wurde tatsächlich nicht richtig weiter verarbeitet. Der SoC von der Pro sollte nun auch übernommen werden, wenn er nicht direkt beim Anstecken ermittelt wurde.
Die SoC-Module nutzen alle die gleiche Logik und bei den SoC-Modulen, die die API der Fahrzeuge nutzen, wird der SoC auch nach dem Abstecken weiter abgefragt, damit man jederzeit den aktuellen SoC in der openWB hat.

Danke, ich werde es beobachten und berichten... Und das andere ist klar, aber nutzt man die Pro und will den SoC von dieser beim anstecken nutzen, dann erwartet, dass dieses reibungslos funktioniert, da kein fremdes Produkt beteiligt ist. Aber es scheint als wenn der manuelle SoC nicht oft verwendet wird...

Gestern Abend habe ich angesteckt, diekte nach dem ich auf die neuste Version aktualisiert hatte. So sieht die SoC Kurve vom Tavascan aus:

Screenshot 2025-07-20 095114.jpg

Der manuelle SoC war "0", dann angesteckt und er hat sich wieder an den vorherigen SoC "erinnert" und dann erstmal diesen angenommen.

Kann mir mal jemand erklären, was für ein Vorteil das haben sollte? Mir fallen nur Nachteile und Probleme ein, aber kein einziger Vorteil...

Dann einen Moment später hat die Standalone dann auch den SoC der Pro verarbeitet und übernommen. Das Problem tritt dann wieder auf, wenn der SoC mal wieder nicht übernommen wird, dann bleibt er auf dem hohen SoC stehen und lädt nicht. Ob wohl er zuvor mal auf "0" gesetzt wurde.

Main-Log: https://paste.openwb.de/CqNTKS0917q0iAt
SoC-Log: https://paste.openwb.de/7tpJB3ofvYT2X0U
MQTT-Log: https://paste.openwb.de/QVpfjmsMPqgL66e

Der Teil, wo Du den manuellen SoC setzt, fehlt im Log. Ich habe einen Bug bei manual_soc = 0% gefunden. Den habe ich behoben.

[LenaK]

Danke, ich werde es beobachten und berichten... Und das andere ist klar, aber nutzt man die Pro und will den SoC von dieser beim anstecken nutzen, dann erwartet, dass dieses reibungslos funktioniert, da kein fremdes Produkt beteiligt ist. Aber es scheint als wenn der manuelle SoC nicht oft verwendet wird...

Der manuelle SoC war "0", dann angesteckt und er hat sich wieder an den vorherigen SoC "erinnert" und dann erstmal diesen angenommen.

Kann mir mal jemand erklären, was für ein Vorteil das haben sollte? Mir fallen nur Nachteile und Probleme ein, aber kein einziger Vorteil...

Und nun schon wieder, ich habe vor knapp einer Stunden den PKW wieder angesteckt, aber der SoC wurde noch nicht übernommen, hier das Log:

Code: Alles auswählen

2025-07-20 18:35:25,217 - {modules.common.configurable_vehicle:66} - {DEBUG:fetch soc_ev2} - Vehicle Instance <class 'modules.vehicles.manual.config.ManualSoc'>
2025-07-20 18:35:25,219 - {modules.common.configurable_vehicle:67} - {DEBUG:fetch soc_ev2} - Calculated SoC-State CalculatedSocState(imported_start=4120926, manual_soc=None, soc_start=64)
2025-07-20 18:35:25,220 - {modules.common.configurable_vehicle:68} - {DEBUG:fetch soc_ev2} - Vehicle Update Data VehicleUpdateData(plug_state=True, charge_state=False, imported=4126494, battery_capacity=77000, efficiency=90, soc_from_cp=None, timestamp_soc_from_cp=None, soc_timestamp=1753009765.439719)
2025-07-20 18:35:25,221 - {modules.common.configurable_vehicle:69} - {DEBUG:fetch soc_ev2} - General Config GeneralVehicleConfig(use_soc_from_cp=True, request_interval_charging=300, request_interval_not_charging=43200, request_only_plugged=True)
2025-07-20 18:35:25,221 - {modules.common.component_context:29} - {DEBUG:fetch soc_ev2} - Update Komponente ['Manueller SoC']
2025-07-20 18:35:25,222 - {modules.vehicles.common.calc_soc.calc_soc:17} - {DEBUG:fetch soc_ev2} - SoC-Gain: ((5.568kWh charged * 90% efficiency) / 77.0kWh battery-size) * 100 = 6.508051948051947%
2025-07-20 18:35:25,237 - {modules.vehicles.common.calc_soc.calc_soc:21} - {DEBUG:fetch soc_ev2} - 64% + 5.0112kWh = 70.50805194805194%
2025-07-20 18:35:25,239 - {modules.common.configurable_vehicle:80} - {DEBUG:fetch soc_ev2} - Requested start soc from calculation: 70.50805194805194%
2025-07-20 18:35:25,239 - {modules.common.store._api:26} - {DEBUG:fetch soc_ev2} - Raw data CarState(soc=70.50805194805194, range=None, soc_timestamp=1753029325.239184)
2025-07-20 18:35:25,890 - {modules.common.store._api:31} - {INFO:store soc_ev2} - Saving CarState(soc=70.50805194805194, range=None, soc_timestamp=1753029325.239184)
2025-07-20 18:35:35,271 - {modules.common.configurable_vehicle:66} - {DEBUG:fetch soc_ev2} - Vehicle Instance <class 'modules.vehicles.manual.config.ManualSoc'>
2025-07-20 18:35:35,271 - {modules.common.configurable_vehicle:67} - {DEBUG:fetch soc_ev2} - Calculated SoC-State CalculatedSocState(imported_start=4120926, manual_soc=None, soc_start=64)
2025-07-20 18:35:35,272 - {modules.common.configurable_vehicle:68} - {DEBUG:fetch soc_ev2} - Vehicle Update Data VehicleUpdateData(plug_state=True, charge_state=False, imported=4126494, battery_capacity=77000, efficiency=90, soc_from_cp=54, timestamp_soc_from_cp=1753029324, soc_timestamp=1753029325.239184)
2025-07-20 18:35:35,272 - {modules.common.configurable_vehicle:69} - {DEBUG:fetch soc_ev2} - General Config GeneralVehicleConfig(use_soc_from_cp=True, request_interval_charging=300, request_interval_not_charging=43200, request_only_plugged=True)
2025-07-20 18:35:35,272 - {modules.common.component_context:29} - {DEBUG:fetch soc_ev2} - Update Komponente ['Manueller SoC']
2025-07-20 18:35:35,273 - {modules.common.configurable_vehicle:80} - {DEBUG:fetch soc_ev2} - Requested start soc from chargepoint: 54%
2025-07-20 18:35:35,288 - {modules.common.configurable_vehicle:97} - {DEBUG:fetch soc_ev2} - Not updating SoC, because timestamp is older.

Der SoC wurde ausgelesen: Requested start soc from chargepoint: 54%
Aber: Not updating SoC, because timestamp is older.

In der GUI steht nach wie vor 70,51%

Der Zeitstempel des ausgelesenen SoC ist nun länger gültig.

[spooky82]

Wann verlässt die 2.1.8 eigentlich den Alpha-Status?

[ChristophR]

Hast Du ein externes System, dass Werte für den manuellen SoC published? Hast Du das abgeschaltet?

Das published weiter, die Daten werden aber nicht mehr angenommen, daher habe ich das so gelassen.

Welches Theme hast Du verwendet? force_soc_update wurde im Koala gefixt.

Ich nutze zwar das Standard-Theme, die Auswahl erfolgt aber per RFID-Tag, nicht per manueller Auswahl.
Spielt dann das Theme trotzdem eine Rolle?
P.S: Ich habe gerade mit dem Update (2025-07-29 11:25:38 +0200 [23d338939]) das Fahrzeug angesteckt force habe ich im mqtt.log nicht gefunden.

Die Pro setzt None, wenn kein SoC aus dem Fahrzeug ausgelesen wird. Dann wird das ausgewählte Modul verwendet.

Ich habe ja keine Pro, was passiert denn, wenn man die Option aktiviert hat (Ist ja Quatsch ohne Pro) und keine Pro hat?

Wenn ich nochmal was testen soll, einfach Bescheid geben.

[ChristophR]

Aktueller Master von heute:

Bei gewähltem Modum "Zielladen" kann der gewählte Ladeplan nicht durch einfachen Klick auf aktiv gesetzt werden, sondern man muß immer in Ladeprofil, um den Ladeplan zu aktivieren.

Screenshot 2025-07-30 113601.jpg

Nachtrag bei mir: Deaktivieren klappt, nur nicht das aktivieren.