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

I tried to get the binding running for Ford, but to no avail. After reading a lot of posts it seems like a dumb question, but would it help if I create an account for login testing?

@gforums
seems the log only shows the login and vehicle detection. After that you should find the car in the Thing Inbox. Only after you add the car itself you get the channels.

The binding creates an “account thing” and one thing per vehicle.

Do you see that?

So after having my Cupra integrated I see another problem.

Items for it are not updated automatically. They are still for my Audi so I’m really wondering where the difference might be.
In the debug log I see the updated data is fetched:

2023-10-18 20:53:49.953 [DEBUG] [ernal.api.carnet.CarNetServiceStatus] - VSSZZZxxxxx: CHARGING_LEVEL_PERCENT=100% (channel charger#chargingLevel)
2023-10-18 20:53:49.954 [DEBUG] [ernal.api.carnet.CarNetServiceStatus] - Updating channel connectedcar:cnvehicle:ef8a630261:VSSZZZxxxxx:charger#chargingLevel with value 100
2023-10-18 20:53:49.955 [DEBUG] [ernal.api.carnet.CarNetServiceStatus] - VSSZZZxxxxx: Updating channel charger#chargingLevel with 100 %
2023-10-18 20:53:49.956 [DEBUG] [ar.internal.handler.ThingBaseHandler] - VSSZZZxxxxx: updateChannel -> charger#chargingLevel = 100 %

And I also find messages like:

2023-10-18 20:38:49.489 [DEBUG] [nectedcar.internal.util.ChannelCache] - VSSZZZxxxxx: Channel general#lastUpdate updated with 2023-10-18T20:38:49.000+0200 (type class org.openhab.core.library.types.DateTimeType).

(Those apparently only are logged if values changed which makes total sense.)

But those values do not arrive at the connected items (like also nothing in the events.log).

I’m inclined to not blame the binding at all since the log looks perfectly fine but on the other hand it works fine for the other car.

Just tried removing all items and relinking all channels back in shows the current data within the items again.

Any ideas?

unfortunately I have not the KnowHow to add the mileage/odometer for the Skoda Enyaq on my own to the binding. Is there anything I can provide that the implementation can be done?

I already found out that the mileage/odometer can be queried. E.g. the project https://github.com/evcc-io/evcc can this and uses a new API query for the Enyaq:

20231019-0627-001

If I can provide any useful information, just let me know.

A short update from my end:

Car thing was found. Information are displayed, lock and unlock works.

That’s great already! Thanks!
Regarding auto update, I’ll check if that works for me.

Best,
Christian

1 Like

@JoMatic
Can you set the binding loglevel to TRACE and share your logs somewhere?
From what I see in the binding the code to fetch the mileage seems to be there so it’s either not the code which is used or something is failing to fetch it. No promises but w/o the log or such a car it’s impossible (for me) to potentially help.

Thank you for your answer. Because I haven’t found any information regarding odometer & Enyaq in this binding, I didn’t have a deeper look at the logs. Now I have found the creation of the channel status#odometer in the logs and guess what, it is also available in the UI, but hidden behind the Show advanced checkbox :smile:

Sometimes it seems a bit much what’s “advanced”.

boolean advanced = CHANNEL_GROUP_STATUS.equals(group) || CHANNEL_GROUP_WINDOWS.equals(group)
                || CHANNEL_GROUP_DOORS.equals(group) || CHANNEL_GROUP_TIRES.equals(group);

Update of the car values also not working for me with the binding…

This is so weird. I created a new build and added just one debug log message to see if the actual OH updateState() method is called and reloaded the binding.
Now it updates the items again.
I’m almost sure it’s not the binding code but some cache topic. At least I typically neither restart OH when replacing the binding, nor recreate any Things. So I’m wondering if something within OH just gets stuck in certain situations.

Hi,

any chance someone can provide a new build for OH3 with the fix for Skoda?

I’d appreciate, thanks!

for Enyaq everything is currently working for me. After the outage at Skoda between yesterday and today in the morning I had to restart openhab, because the tokens were not valid anymore.

I added 3.4.x builds here: Release connectedcar_snapshot_20231017 · wrosenauer/openhab-addons · GitHub

I didn’t test those myself so be careful.

(Changes are not at all related to Skoda-E (Enyaq) but only for carnet vehicles. (Apparently all other Skoda models.)

Thanks Wolfgang, that works for me! :+1:

I cleaned openhab cache and currently updating works.
The only thing not working for me is the preheater from my Formentor. But this also doesn’t work with the python script.

Any idea how I could get it working?
It’s working from within the official cupra app… But probably users with openhab and a cupra with preheater are rare? :smile:

Edit: found this comment in another post:

”But for VW pre-heater to work we also need to add the change that I wrote of earlier in this long thread:

For the pre-heater and API Level Ventilation set to 2, the binding uses wrong endpoint:
bs/rs/v1/Audi/DE/vehicles/WAUZZZF40LA076714/climater/actions

The sendAction should use:
bs/rs/v1/{0}/{1}/vehicles/{2}/action
I guess that change is also compatible with other brands.”

Is that something, @Wolfgang_Rosenauer, you might know where to look at the binding?

Thanks,
Christian

@gforums Please try

I just reflected your description (the ventilation function also was using this before), just the preHeater was missing.
I could not test it myself since I have a PHEV which has a climater instead of a preHeater. But that one seems broken as well but does not work using a similar change either.

If anyone here knows a way how to spy into the official app network, please let me know.

Good evening everyone,

I am really sorry for the long silence, but a private issue prevented me to look at this binding. I will try to catch up and check it out tomorrow including all the fantastic suggestions posted so far.

Yves

// Update:

I found out a quite strange behaviour for the Cupra Formentor:

API Level Ventilation set to 1 let me turning ON the PreHeater but NOT turning off.
API Level Ventilation set to 2 let’s me turn OFF the PreHeater but not on

:smiley:

@Wolfgang_Rosenauer @HSorgYves:
Not sure if you can implement this somehow in the binding?!

For the time beeing I’ll try to add 2 bridges and 2 cars with the different API levels, but maybe you have an idea how to inlclude it :slight_smile:

Thanks @Wolfgang_Rosenauer,

while this fix didn’t work for me, I found those API Level settings in die Binding bridge.
I changed to API Level 1 and that seems to do the trick.

Power on the Preheater works well, powering didn’t work on 1st, but on 2nd attempt.
Will further test this.

Maybe for cars with API level 2, we can wait on feedback from other customers.

For me it now is a fully working binding, at least I couldn’t find other issues yet.

Thank for your work Wolfgang, happy to see that also @HSorgYves is back :slight_smile:

Thanks for the feedback. If you could provide debug logs somewhere it could be useful.
In general I just noticed that I made a mistake in my patch.
The change I did was supposed to be just for the API level 2 but I accidentally changed API level 1 as well.
To me this does not really explain what you are seeing though.

I made more changes which are only affecting API level 1 now. Would be interesting to see if that works better for you. Since it’s a real wild guess I haven’t pushed the change to github.
Please fetch the test package here:
https://drive.rosenauer.org/d/s/vj7c5WfccxhIWAPmnEwUwtT5Y4xbz7xV/kbA-Mn6VpdAzmSEZxNUkU10lYiKcbVbk-prRgBaJT2Ao
You need to ignore the certificate error though.

Not sure if the above really works. Here is an alternative link:
https://spideroak.com/share/O5XXE3Y/pub/home/wolfi/public/org.openhab.binding.connectedcar-4.0.3-SNAPSHOT.jar
which hopefully works.

// edit oct. 24th:
need some further testing. got an error with the first “corrected” version this morning as well.
will update my post later again…

@Wolfgang_Rosenauer:
Thanks for the updated jar file from October 22nd.

If it’s easier, you might reach out to me to christian*@gforum*s.de (remove *s) and I can share more of my logs or we can do some more trial and error.

For now, I tried out your latest build and couldn’t get it to work:

Running the lastest jar with API Level 1 results in:

2023-10-23 08:37:09.724 [INFO ] [ar.internal.handler.ThingBaseHandler] - VSSxxxxxxxxxxxxxx: Status from service rheating_v1.P_QSACT: API call failed POST https://fal-3a.prd.eu.dp.vwg-connect.com/fs-car/bs/rs/v1/VW/ES/vehicles/VSSxxxxxxxx/climater/actions (HTTP 400 null), result = {"error":{"errorCode":"gw.error.parameter","description":"Disallowed query parameters"}}

while the version from october 21st with API Level 1 works well and shows me:

2023-10-23 19:11:27.043 [DEBUG] [ar.internal.handler.ThingBaseHandler] - VSxxxxxxxxxxxxxxxxxxx: Remote Control Service rheating_v1 is available

2023-10-23 19:12:11.262 [DEBUG] [tedcar.internal.api.carnet.CarNetApi] - VSxxxxxxxxxxxxxxxxxxx: Sending action request for rheating_v1.P_QSACT, reqSecToken=true, contentType=application/vnd.vwg.mbb.RemoteStandheizung_v2_0_0+xml
2023-10-23 19:12:11.266 [DEBUG] [nectedcar.internal.api.ApiHttpClient] - VSxxxxxxxxxxxxxxxxxxx: HTTP GET https://mal-3a.prd.eu.dp.vwg-connect.com/api/rolesrights/authorization/v2/vehicles/VSxxxxxxxxxxxxxxxxxxx/services/rheating_v1/operations/P_QSACT/security-pin-auth-requested
2023-10-23 19:12:12.021 [DEBUG] [ar.internal.handler.ThingBaseHandler] - VSxxxxxxxxxxxxxxxxxxx: Action rheating_v1.P_QSACT sent, requestId=184562604
2023-10-23 19:12:12.022 [DEBUG] [ar.internal.handler.ThingBaseHandler] - VSxxxxxxxxxxxxxxxxxxx: updateChannel -> general#lastAction = rheating_v1.P_QSACT
2023-10-23 19:12:12.022 [DEBUG] [nectedcar.internal.util.ChannelCache] - VSxxxxxxxxxxxxxxxxxxx: Channel general#lastAction updated with rheating_v1.P_QSACT (type class org.openhab.core.library.types.StringType).
2023-10-23 19:12:12.029 [DEBUG] [ctedcar.internal.api.ApiRequestQueue] - VSxxxxxxxxxxxxxxxxxxx: Check request 184562604 status for action rheating_v1.P_QSACT; checkUrl=bs/rs/v1/{0}/{1}/vehicles/{2}/requests/184562604/status
2023-10-23 19:12:12.201 [DEBUG] [ar.internal.handler.ThingBaseHandler] - VSxxxxxxxxxxxxxxxxxxx: Update to action rheating_v1.P_QSACT (ID 184562604): New status=request_in_progress
2023-10-23 19:12:12.201 [DEBUG] [ar.internal.handler.ThingBaseHandler] - VSxxxxxxxxxxxxxxxxxxx: updateChannel -> general#lastAction = rheating_v1.P_QSACT
2023-10-23 19:12:12.202 [DEBUG] [nectedcar.internal.util.ChannelCache] - VSxxxxxxxxxxxxxxxxxxx: Channel general#lastAction updated with rheating_v1.P_QSACT (type class org.openhab.core.library.types.StringType).
2023-10-23 19:12:13.355 [DEBUG] [ctedcar.internal.api.ApiRequestQueue] - VSxxxxxxxxxxxxxxxxxxx: Check request 184562604 status for action rheating_v1.P_QSACT; checkUrl=bs/rs/v1/{0}/{1}/vehicles/{2}/requests/184562604/status
2023-10-23 19:12:13.606 [DEBUG] [ar.internal.handler.ThingBaseHandler] - VSxxxxxxxxxxxxxxxxxxx: Update to action rheating_v1.P_QSACT (ID 184562604): New status=request_in_progress
2023-10-23 19:12:13.606 [DEBUG] [ar.internal.handler.ThingBaseHandler] - VSxxxxxxxxxxxxxxxxxxx: updateChannel -> general#lastAction = rheating_v1.P_QSACT
2023-10-23 19:12:13.607 [DEBUG] [nectedcar.internal.util.ChannelCache] - VSxxxxxxxxxxxxxxxxxxx: Channel general#lastAction updated with rheating_v1.P_QSACT (type class org.openhab.core.library.types.StringType).
2023-10-23 19:12:28.612 [DEBUG] [ctedcar.internal.api.ApiRequestQueue] - VSxxxxxxxxxxxxxxxxxxx: Check request 184562604 status for action rheating_v1.P_QSACT; checkUrl=bs/rs/v1/{0}/{1}/vehicles/{2}/requests/184562604/status
2023-10-23 19:12:28.721 [DEBUG] [ar.internal.handler.ThingBaseHandler] - VSxxxxxxxxxxxxxxxxxxx: Update to action rheating_v1.P_QSACT (ID 184562604): New status=request_successful
2023-10-23 19:12:28.722 [DEBUG] [ar.internal.handler.ThingBaseHandler] - VSxxxxxxxxxxxxxxxxxxx: updateChannel -> general#lastAction = rheating_v1.P_QSACT
2023-10-23 19:12:28.722 [DEBUG] [nectedcar.internal.util.ChannelCache] - VSxxxxxxxxxxxxxxxxxxx: Channel general#lastAction updated with rheating_v1.P_QSACT (type class org.openhab.core.library.types.StringType).
2023-10-23 19:12:28.729 [DEBUG] [ctedcar.internal.api.ApiRequestQueue] - VSxxxxxxxxxxxxxxxxxxx: Remove request 184562604 for action rheating_v1.P_QSACT from queue, status is request_successful

The version from October 22nd with API level 2 fails with:


2023-10-23 19:21:45.903 [DEBUG] [tedcar.internal.api.carnet.CarNetApi] - VSxxxxxxxxxxxxxxxxxxx: Sending action request for rheating_v1.P_QSACT, reqSecToken=true, contentType=application/vnd.vwg.mbb.RemoteStandheizung_v2_0_2+json
2023-10-23 19:21:45.909 [DEBUG] [nectedcar.internal.api.ApiHttpClient] - VSxxxxxxxxxxxxxxxxxxx: HTTP GET https://mal-3a.prd.eu.dp.vwg-connect.com/api/rolesrights/authorization/v2/vehicles/VSxxxxxxxxxxxxxxxxxxx/services/rheating_v1/operations/P_QSACT/security-pin-auth-requested
2023-10-23 19:21:46.643 [INFO ] [ar.internal.handler.ThingBaseHandler] - VSxxxxxxxxxxxxxxxxxxx: Status from service rheating_v1.P_QSACT: API call failed POST https://fal-3a.prd.eu.dp.vwg-connect.com/fs-car/bs/rs/v1/VW/ES/vehicles/VSxxxxxxxxxxxxxxxxxxx/action (HTTP 429 null), result = {"error":{"errorCode":"RS.technical.9025","description":"MbbDispatcher responded: 429 -"}}

I did just include logs including “rheating”, but you can see that obviously the changes you made on API v1 in the build from October 21st makes it work in my case.

Powering OFF works with boths versions in API Level 2 with this log:

2023-10-23 19:25:07.438 [DEBUG] [tedcar.internal.api.carnet.CarNetApi] - VSxxxxxxxxxxxxxxxxxxx: Sending action request for rheating_v1.P_QSTOPACT, reqSecToken=true, contentType=application/vnd.vwg.mbb.RemoteStandheizung_v2_0_2+json
2023-10-23 19:25:07.447 [DEBUG] [nectedcar.internal.api.ApiHttpClient] - VSxxxxxxxxxxxxxxxxxxx: HTTP GET https://mal-3a.prd.eu.dp.vwg-connect.com/api/rolesrights/authorization/v2/vehicles/VSxxxxxxxxxxxxxxxxxxx/services/rheating_v1/operations/P_QSTOPACT/security-pin-auth-requested
2023-10-23 19:25:08.649 [DEBUG] [ar.internal.handler.ThingBaseHandler] - VSxxxxxxxxxxxxxxxxxxx: Action rheating_v1.P_QSTOPACT sent, requestId=184565324
2023-10-23 19:25:08.650 [DEBUG] [ar.internal.handler.ThingBaseHandler] - VSxxxxxxxxxxxxxxxxxxx: updateChannel -> general#lastAction = rheating_v1.P_QSTOPACT
2023-10-23 19:25:08.652 [DEBUG] [nectedcar.internal.util.ChannelCache] - VSxxxxxxxxxxxxxxxxxxx: Channel general#lastAction updated with rheating_v1.P_QSTOPACT (type class org.openhab.core.library.types.StringType).
2023-10-23 19:25:08.666 [DEBUG] [ctedcar.internal.api.ApiRequestQueue] - VSxxxxxxxxxxxxxxxxxxx: Check request 184565324 status for action rheating_v1.P_QSTOPACT; checkUrl=bs/rs/v1/{0}/{1}/vehicles/{2}/requests/184565324/status
2023-10-23 19:25:08.797 [DEBUG] [ar.internal.handler.ThingBaseHandler] - VSxxxxxxxxxxxxxxxxxxx: Update to action rheating_v1.P_QSTOPACT (ID 184565324): New status=request_in_progress
2023-10-23 19:25:08.798 [DEBUG] [ar.internal.handler.ThingBaseHandler] - VSxxxxxxxxxxxxxxxxxxx: updateChannel -> general#lastAction = rheating_v1.P_QSTOPACT
2023-10-23 19:25:14.939 [DEBUG] [ctedcar.internal.api.ApiRequestQueue] - VSxxxxxxxxxxxxxxxxxxx: Check request 184565324 status for action rheating_v1.P_QSTOPACT; checkUrl=bs/rs/v1/{0}/{1}/vehicles/{2}/requests/184565324/status
2023-10-23 19:25:15.082 [DEBUG] [ar.internal.handler.ThingBaseHandler] - VSxxxxxxxxxxxxxxxxxxx: Update to action rheating_v1.P_QSTOPACT (ID 184565324): New status=request_successful
2023-10-23 19:25:15.083 [DEBUG] [ar.internal.handler.ThingBaseHandler] - VSxxxxxxxxxxxxxxxxxxx: updateChannel -> general#lastAction = rheating_v1.P_QSTOPACT
2023-10-23 19:25:15.092 [DEBUG] [ctedcar.internal.api.ApiRequestQueue] - VSxxxxxxxxxxxxxxxxxxx: Remove request 184565324 for action rheating_v1.P_QSTOPACT from queue, status is request_successful

The log speaks from a “rheating_v1” - could that obviously be the API version / level 1, that is meant?
Could you try to stick with the changes in API V1, that you made by accident + change the part in API Level 1 that triggers off the preheater as it does in API V2?

Hope the parts of the logs do already help. And happy to exchange more in detail alternatively also by mail :slight_smile:

thanks,
Christian