openWB Forum

mrinas hat geschrieben: ↑Mo Jun 03, 2024 6:56 am Bitte in System > Fehlersuche das Loglevel auf Detail stellen und dann einen Durchlauf (ohne Zugangsdaten) aus dem SoC Log posten. Geht auch um die Meldungen vor dem Fehler, die könnten weitere Hinweise liefern was hier klemmt.

Ok, ich habe den Debuglevel auf Mode 2 gestellt und erhalte immer wieder die folgenden Meldungen: Ist es das, was Du brauchst?

Ja quasi. Das sind logs aus der 1.9er Software. Da kann ich leider nicht weiterhelfen, ich hab die evcc Integration in der 2er Software gebaut, die ist leider komplett anders.

Guten Morgen,

weiter oben sollten auch Logs von mir sein (Version 2.1.4. RC2) wo das Problem vorhanden (seit ca. 3 Wochen) ist.
Habe hier schon einiges probiert.
Leider immer ohne Erfolg.

Habe heute Morgen bei einem Fahrzeug das EVCC-Soc neu eingerichtet und das Log auf Details gestellt und werde das Ganze dann posten wenn es nicht mehr geht oder lieber dir direkt schicken?

[code
2024-06-05 08:24:20,303 - {modules.common.configurable_vehicle:56} - {DEBUG:fetch soc_ev5} - Vehicle Instance <class 'modules.vehicles.evcc.config.EVCCVehicleSoc'>
2024-06-05 08:24:20,305 - {modules.common.configurable_vehicle:57} - {DEBUG:fetch soc_ev5} - Calculated SoC-State CalculatedSocState(imported_start=3300503.91, manual_soc=None, soc_start=74.0)
2024-06-05 08:24:20,305 - {modules.common.configurable_vehicle:58} - {DEBUG:fetch soc_ev5} - Vehicle Update Data VehicleUpdateData(plug_state=True, charge_state=False, imported=3300503.91, battery_capacity=77000, efficiency=90, soc_from_cp=None, timestamp_soc_from_cp=None)
2024-06-05 08:24:20,306 - {modules.common.configurable_vehicle:59} - {DEBUG:fetch soc_ev5} - General Config GeneralVehicleConfig(use_soc_from_cp=False, request_interval_charging=300, request_interval_not_charging=3600, request_only_plugged=False)
2024-06-05 08:24:20,307 - {modules.common.component_context:25} - {DEBUG:fetch soc_ev5} - Update Komponente ['EVCC']
2024-06-05 08:24:20,308 - {modules.vehicles.evcc.api:52} - {DEBUG:fetch soc_ev5} - Fetching EVCC SOC
2024-06-05 08:24:20,313 - {modules.vehicles.evcc.api:64} - {DEBUG:fetch soc_ev5} - Vehicle id found in config: 479
2024-06-05 08:24:20,314 - {modules.vehicles.evcc.api:66} - {DEBUG:fetch soc_ev5} - Fetching SoC for vehicle id: 479
2024-06-05 08:24:21,510 - {modules.common.fault_state:49} - {ERROR:fetch soc_ev5} - EVCC: FaultState FaultStateLevel.ERROR, FaultStr <class 'grpc.RpcError'> (<_InactiveRpcError of RPC that terminated with:
status = StatusCode.UNKNOWN
details = "Get "https://emea.bff.cariad.digital/vehicle ... asurements": unexpected status: 500 (Internal Server Error)"
debug_error_string = "UNKNOWN:Error received from peer {created_time:"2024-06-05T08:24:21.49748373+02:00", grpc_status:2, grpc_message:"Get \"https://emea.bff.cariad.digital/vehicle ... asurements\": unexpected status: 500 (Internal Server Error)"}"
>,), Traceback:
Traceback (most recent call last):
File "/var/www/html/openWB/packages/modules/vehicles/evcc/api.py", line 71, in fetch_soc
response = stub.SoC(
File "/home/openwb/.local/lib/python3.9/site-packages/grpc/_channel.py", line 1160, in __call__
return _end_unary_response_blocking(state, call, False, None)
File "/home/openwb/.local/lib/python3.9/site-packages/grpc/_channel.py", line 1003, in _end_unary_response_blocking
raise _InactiveRpcError(state) # pytype: disable=not-instantiable
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
status = StatusCode.UNKNOWN
details = "Get "https://emea.bff.cariad.digital/vehicle ... asurements": unexpected status: 500 (Internal Server Error)"
debug_error_string = "UNKNOWN:Error received from peer {created_time:"2024-06-05T08:24:21.49748373+02:00", grpc_status:2, grpc_message:"Get \"https://emea.bff.cariad.digital/vehicle ... asurements\": unexpected status: 500 (Internal Server Error)"}"
>

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/var/www/html/openWB/packages/modules/common/configurable_vehicle.py", line 66, in update
car_state = self._get_carstate_by_source(vehicle_update_data, source)
File "/var/www/html/openWB/packages/modules/common/configurable_vehicle.py", line 110, in _get_carstate_by_source
return self.__component_updater(vehicle_update_data)
File "/var/www/html/openWB/packages/modules/vehicles/evcc/soc.py", line 16, in updater
return fetch_soc(vehicle_config.configuration, vehicle_update_data, vehicle)
File "/var/www/html/openWB/packages/modules/vehicles/evcc/api.py", line 86, in fetch_soc
raise grpc.RpcError(rpc_error)
grpc.RpcError: <_InactiveRpcError of RPC that terminated with:
status = StatusCode.UNKNOWN
details = "Get "https://emea.bff.cariad.digital/vehicle ... asurements": unexpected status: 500 (Internal Server Error)"
debug_error_string = "UNKNOWN:Error received from peer {created_time:"2024-06-05T08:24:21.49748373+02:00", grpc_status:2, grpc_message:"Get \"https://emea.bff.cariad.digital/vehicle ... asurements\": unexpected status: 500 (Internal Server Error)"}"
>

]

[/code]

Weiss jemand, was der Unterschied ist zwischen dem EVCC Modul "Ford" und "Ford-connect"?

installierte Version: 1.9.304.0 (2024-03-11 14:39:13 +0100 [5a6a1a6d] )

Moin,

machen mehr Logs noch Sinn? Habe das Problem mit unserem Skoda Citigo auch, seit ich von wenigen Wochen auf Version 2.0 umgestellt habe, gefühlt alle 5-6 Tage (Probleme wie beschrieben, SoC 0%, cannot create vehicle) erstelle ich einfach ein neues Fahrzeug und kopiere den Token und alles läuft wieder ... erstmal ...

Oeffy hat mir Logs geschickt, die Ursache ist gefunden, mögliche Abhilfe identifiziert. Es braucht ein wenig zusätzliche Fehlerbehandlung, dann sollte das nicht mehr auftreten.

Ich kann hier gern ein Update teilen sobald sich die Änderung in den nächsten Tagen auf den Weg macht.

Oha, heute mal eine neue Meldung:

Modulmeldung:

Bubbagump hat geschrieben: ↑Di Jun 11, 2024 8:30 pm Oha, heute mal eine neue Meldung:

Modulmeldung:

Code: Alles auswählen

<class 'grpc.RpcError'> (<_InactiveRpcError of RPC that terminated with: status = StatusCode.UNAVAILABLE details = "failed to connect to all addresses; 
last error: UNKNOWN: ipv4:66.241.124.2:8080: Ssl handshake failed: SSL_ERROR_SSL: error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED" 
debug_error_string = "UNKNOWN:Error received from peer {grpc_message:"failed to connect to all addresses; 
last error: UNKNOWN: ipv4:66.241.124.2:8080: Ssl handshake failed: SSL_ERROR_SSL: error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED", grpc_status:14, created_time:"2023-05-14T03:15:41.387425148+02:00"}" >,)

Welcher Zeitstempel steht in den Logzeilen unmittelbar vor diesem Fehler? Frage da der Zeitstempel in der Fehlermeldung selbst vom 14. Mai ist. Wenn da irgendwo das Datum nicht stimmt können durchaus mal SSL Fehler entstehen. Frage wäre nun ob die Uhrzeit auf der openWB stimmt.

Du hast Recht, das Datum ist auf den 14.05. gesprungen. Ich habe gerade ein Update auf den neuesten Master Release gemacht und nun ist die Zeit wieder synchronisiert und der SOC wird ausgelesen. Kurios.
Danke für den Hinweis!