ConnectedCar Binding myAudi, Volkswagen, VW ID, Skoda, Enyaq, Seat, Ford, WeCharge

Hi ID3 Owner,
I don’t get the channels control#targetChgLvl and control#targetTemperature to show anything (value remains NULL)… - how is your experience?

Thx, Dirk

I didn’t have a look at those yet, but i can see in the Debug that sometimes (definitely not every 15 mins) i am receiving a full http response 207 with all the data. That said I can see the car captured time stamp in that is not changing when it does download so perhaps the binding is ignoring those updates as there is no change to the data its downloading.

The two channels you mentioned are also Null for me. James

I can’t confirm that. I receive an update every 15 minutes but it is not propagated to the items. Channel gets update but not the items… crazy.
If I for example touch the item file, which foreces openhab to process it again, the items are updated immediately. So the channel values are there but why the hell it isn’t propagated to the items…

So I have had a longer look at this. It does seem now I am getting Http 207 responses every 15 mins, however in this case no data is changing, in car time remains the same (I assume that this is because the car is not on or charging, will test later) . So potentially the bug is just that the binding should update the latest update time with the most recent HTTP 207 response time, even if the in car time hasn’t changed.

James

please send me the log extract and I‘ll check
The binding does a poll every 15min, but updates only channels with changed data. Therefore it could be that an response with data is received, but since cached channel values have not changed the channels/items don‘t get an update again and again
In general the car has to send updates to the backend, this does not happy all the time. If you us the request update channel (set to ON) the car is requested to send an update, but don‘t do that to often, otherwise the API will throttle

I found a bug while computing the token refresh threshold. Currently the binding refreshes after 20% of the validity instead after 80%.

I saw 207 only for Geo location requests having no update. I need to check the log, if this could also happen in other situations I need to check if that is handled correctly

I hope to find some time next week to work on some issues

Hi,
I tried to connect a Skoda Superb iV 2021.
I was able to connect with the old Carnet binding in July. I did not care of it for quite some time and tried to switch to ConnectedCar yesterday.

With the Skoda Connect bridge I always get “Login failed, check credentials (Forbidden)”, while the same credentials are working fine with the Skoda Enyaq bridge and the VIN is found as additional thing. I tried many times, never entered the credentials manually and the first phase of authentication seems to work in the Skoda Connect case. It fails with the call “HTTP POST https://mbboauth-1d.prd.ece.vwg-connect.com/mbbcoauth/mobile/oauth2/v1/token” after log message “Login successful, grating API access”.

Does anyone have a hint or shall I provide the trace?

Thanks,
Matthias

Have sent you a log extract via PM - I assume the 207 is a result from trying to get the parking position of the ID vehicle, which is currently not supported by the We Connect ID App…

For the 2 channels not working so far there is a discrepancy between the channels in the binding and the channels which show up in the log:

  • Channel charger#targetChgLvl gets a value, but is not in channels generated from binding (there: control#targetChgLvl)
  • Channel climater#targetTemperature gets a value, but is not in channels generated from binding (there: control#targetTemperature)

Take time to have a look into this - your work is highly appreciated for this binding!

Hi @markus7017,

at first thank you very very much for this great binding. I‘m using it with OH3 and with a VW Touareg PHEV which works great!

But I have discovered a very special use case which could be interesting for you and other to track a vehicle order status:

In August I ordered a new VW van T6.1. Since this car does not have a VIN right now I only could add it to myvolkswagen.net with a commission number I got from the dealer. So the ordered car is visible in the portal next to the Touareg. Some parameters are available aswell e.g. color, engine, model year and the ordered configuration very detailed.

Now I was quite happy to add the new vehicle to openhab to monitor changes in the vin variable. Use case: As soon as production is started there will be a vin assigned to the empty field, and i would like to get a notification via rules about this very happy event when the parameter changes from null to the final vin :slight_smile:

But this is exactly the problem here. No vin, no thing in connectedcar binding as far as i understood, because thats mandatory.

The thing with the new T6.1 shows even up in the OH3 inbox, but throws an error as soon as I try to add it with the following message in the log. I guess it‘s because of the missing vin:

Thing connectedcar:idvehicle:3bdb3d167a: unable to be approved: No Thing with UID connectedcar:idvehicle:3bdb3d167a: in inbox

So my question is: is there a possible workaround to add it with a temporary fake vin or a fix possible?
Other question: Is the vin property with every sync updated or fixed when you add the thing for the first time?

If you need further information, let me know :slight_smile:

Best Chris

Hi, to be honest: This is a very strrange use case. Why should I add monitoring for a thing to OH, which doesn’t exist yet. Beside that: the VIN is stored a thing property so you don’t get access using channels/items. Let me know if the T6 works when you have it in front of you :slight_smile:

I updated the DEV build (still no progress on the PR side)

  • Fix: Calc for token refresh threshold fixed (used 20% instead of 80% to trigger refresh)
  • WeConnect: Timing issue on thing initialization - also hanging Vehicle Refresh Switch, also missing updates after first one
  • WeConnect: Fix channel targetTemperature, targetChgLevel and climatizartionState
  • SEAT: Fix “Unknow Base URL”
  • WeChagre: Add totalEnergy also for Home Charging Records (ID.Charger Pro only)

Open:

  • Skoda support seems broken. They changed the client id and something during token creation

Hi Markus,
mit den beiden “target” Channels scheint es leider noch nicht zu funktionieren… (Log im Anhang, thing vor Aktualisierung des Bindings gelöscht etc.).
Das Binding erstellt die Channels “control#target…”, aber Werte bekommen die Channels “climarter#targetTemperature” bzw. “charger#targetChgLvl”.

Dirk
TargetChannelsLog20211006.txt (926 Bytes)

bist Du sicher, dass Du nicht eine alte Version am Wickel hast? Bei mir stehen die Werte drin

guck‘ mal mit bundle:list, ob 2 Instanzen gelistet werden, das jar in addons löschen, OH stoppen, openhab-cli clean-cache laufen lassen, OH starten, jar ins addons kopieren

Ich lade gleich noch einen neuen Build hoch, evsid channel habe ich in stationId umbenannt und steht bei home dann die S/N sind und ParkingPosition wird nur 1x gepollt, wenn das Fahrzeug das nicht unterstützt + die ApI-Fehlermeldungen werden hetzt korrekt geparst

Habe das neueste Build von 20211007 installiert; das Problem mit den “target” Channels ist offensichtlich gelöst und die Daten in den WeCharge Transactions sind auch gut!

Vielen Dank, Markus! :white_check_mark:

I upoloaded a new build
WeConnect:

  • The parking position is only read once if not supported by the vehicle (http 404/403 is returned of parkingPosition is not in the list of capabilities)
  • API errors with additional information will be parsed correctly

WeCharge:

  • ID.Charger Pro: new channel charger#chargingCycles and charger#chargingEngery include the total number of charging cycles and charged energy (new API endpoint will be polled on each poll cycle)
  • Channel transactionxx#chargingDuration indicates length of charging cycle in minutes
  • The channel transaction#totalEnergy is only created for ID.Charger Pro
  • Channels will be filled with UNDEF if data is not available
  • Channel control#engine renamed to control#restart. If set to ON the binding will restart the wallbox and turns off the switch. The binding doesn’t wait until the wallbox comes up again. Status will be refreshed on next poll cycle.

Please delete and re-discover the things.

Is you problem solved?

Hi Markus,
thanks for your efforts and support! I just tested with a fresh sandbox system but it’s still the same.

Hi Markus,

I just tried the latest snapshot version from yesterday of your “connectedcar” binding. Is the Skoda support supposed to work again? It fails for me with “Initialization failed: Login failed, check credentials (Forbidden)” using the “Skoda Connect Account (CarNet)” from my e-Citigo while I can successfully log into the website.

Thanks for your great work!

try the build I just uploaded a minute ago

Hi Markus,

if your latest post was for me, it still fails to get the API access. Here a few info from the trace:

2021-10-12 08:12:23.940 [DEBUG] [ctedcar.internal.api.IdentityManager] - VW: Login successful, grating API access

2021-10-12 08:12:24.119 [DEBUG] [nectedcar.internal.api.ApiHttpClient] - VW: HTTP 400 Response: {"error":"invalid_grant","error_description":"Audiences ([f9a2359a-b776-46d9-bd0c-db1904343117@apps_vw-dilab_com]) don't match issuer (VWGMBB01DELIV1)."}

Thanks!