I also have a cupra Born - as far as I know and understood, currently native integration into Openhab is not possible (let me know if someone knows better)
I integrated my Cupra following this workaround:
I have a Cupra Born, and I'd love to help make this. · Issue #26 · tillsteinbach/WeConnect-python · GitHub (see hint above as well) - see below in the github discussion, there is a HA Cupra We Connect integration meanwhile which can be used.
I also updated to org.openhab.binding.connectedcar-4.0.4-SNAPSHOT-20231223-2.jar today. I deleted the Thing representing the car and the bridge after unlinking the items first. I have an up to date geolocation on the channel location_parkingposition for my Audi A3 e-tron (2020). it is strange that we do not have the same results
Have some trouble to set the Climater target Temperature…
Switched already back and forth the climater api-version, but no luck.
also changing the TargetTemperatur Item wasn’t successful
2024-01-14 16:02:31.457 [DEBUG] [ar.internal.handler.ThingBaseHandler] - PassatGTE2021: Channel targetTemperature received command 24 °C
2024-01-14 16:02:31.457 [WARN ] [ar.internal.handler.ThingBaseHandler] - PassatGTE2021: General Error: class org.openhab.core.library.types.QuantityType cannot be cast to class org.openhab.core.library.types.DecimalType (org.openhab.core.library.types.QuantityType and org.openhab.core.library.types.DecimalType are in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @2fd5f531)
java.lang.ClassCastException: class org.openhab.core.library.types.QuantityType cannot be cast to class org.openhab.core.library.types.DecimalType (org.openhab.core.library.types.QuantityType and org.openhab.core.library.types.DecimalType are in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @2fd5f531)
at org.openhab.binding.connectedcar.internal.handler.CarNetVehicleHandler.handleBrandCommand(CarNetVehicleHandler.java:97) ~[bundleFile:?]
at org.openhab.binding.connectedcar.internal.handler.ThingBaseHandler.handleCommand(ThingBaseHandler.java:322) [bundleFile:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:147) [bundleFile:?]
at org.openhab.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
at jdk.proxy33391.$Proxy33520.handleCommand(Unknown Source) [?:?]
at org.openhab.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:95) [bundleFile:?]
at org.openhab.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:49) [bundleFile:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:147) [bundleFile:?]
at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
at java.lang.Thread.run(Thread.java:840) [?:?]
Is somebody able to set the TargetTemperature in there cars and can give me a hint?
Thanks in advance!
Odometer for my Skoda Enyaq 80 fails both with
org.openhab.binding.connectedcar-4.0.4-SNAPSHOT-20231223-2.jar
and version 4.0.2. SoC, position data, and many other data are ok. Did not try to write anything, like Set temperature. Any ideas?
May be a stupid question but when you added the channels die you activate the “show advanced” checkbox? I’m not actually sure what the thought was why that is advanced but it just is.
Sure, I used “show advanced”. I appreciate your efforts to keep this binding running. As SoC information got unreliable as well since some days, like @martin1338 in post 1301 I now switched to a solution where Home Assistant supplies a “binding” Skoda Connect and MQTT DiscoveryStream delivers sensor data to my OpenHAB broker.This approach seems especially attractive. Now, both HA and OH can complement each other.
Hello,
I am also trying to get my Skoda Enyak into openHAB.
But it looks like, that the binding dioes not update at all.
Based on the data it did an update when I installed it.
This is how my Things look like
both are online, but no update on the channels-
Any idea what could go wrong during the installation of the binding?
I use the binding version
org.openhab.binding.connectedcar-4.0.4-SNAPSHOT-20231223-2.jar
@OpenWan: at its current state, this binding is malfunctioning or unstable for Enyaq, at least. I propose to follow the path to Home Assistant and its “binding” Skoda Connect.
Or take a look at
https://github.com/tillsteinbach/WeConnect-mqtt
Till steinbach is willing to integrate other models like Seat and Skoda but has no testers. I’m using weconnect-mqtt through a docker container with great success (always worked flawless even if the connected car binding was broken due to changed on VW-side)
I’m a bit hesitant to give up on the native binding yet.
So what really would be helpful is - because Till Steinbach’s usage of the API is apparently superior or more up to date - to collaborate on the API knowledge.
I should have an Enyaq to experiment in a few weeks but right now I don’t have real life experience with it.
So as always what you can try is to enable TRACE logging for the bundle and look at your logs and if you like share them with the community or just me. Cannot promise to see anything from the logs though.
I’m also observing this behavior now. parkingPosition is missing. I had that in the past and people here said it still would work for them.
The reason why it’s missing for me is that parkingPosition is not listed in the accessStatus I’m getting back from the API. Therefore the binding is not fetching it.
WHY my user does not have access granted I have no idea. The myAudi app still shows the parking position.
Still searching for ideas.
EDIT (because stupid system doesn’t let me add more than 3 replies in a row):
I’ve prepared a new snapshot now based on 4.1.x.
Download area (for the moment) as before: Synology Drive
The main change is that I restored the old behavior for Audi so it’s not WeConnect/idvehicle but Carnet/cnvehicle again. This might (or even likely will) break full electric models from Audi but cannot test this.
So for Audi owners:
Please give that a try. For a normal Q5 TDI (2020) it seems to work quite nice.
Please note that all Things need to be removed and recreated.
Audi e-tron owners (in case there are any) please let me know
In general I also would like to maintain a list of car models which have been tested and what is supported or broken for them. Similar to the table in the initial post but I cannot edit it so I may try to add this information to github somehow. Will have a look at it.
EDIT2: Connectedcar binding · wrosenauer/openhab-addons Wiki · GitHub (more or less just a copy of the initial post
In case @HSorgYves is reading: I think the change for Audio to move it from carnet to weconnect was done by you? What was the rationale behind it?
Hi all, I just tested this binding with my Golf 8 Variant and the connection works fine. The only thing, that doesn’t work is tunring on the climate. In the App I need to enter my “S-Pin” once to do so, I think this is the reason why it won’t work with this binding? Any ideas on that?
Kind Regards
The S-PIN you can configure in the Thing configuration of the vehicle.
So this should be fine.
Climaters are in general a bit fragile. The connect Thing has a configuration for API
I cannot tell you what the right one might be for your car. AFAICS 1, 2 or 3 are valid API levels you could check out.
I don’t have these settings in the vehicle thing configuration:
Ah, okay, you use the “Volkswagen Account CarNet”. This isn’t working for me (I’m from Germany):
So what vehicle type do you have set up then for your Golf?
I have
SEAT Connect Account (Carnet) for my Cupra Leon PHEV
and
myAudi Account (CarNet) for my Audi Q5
And I’m in Germany.
So Volkswagen CarNet does not work at all anymore?
But on the other side the error message you posted suggests a solution. Not sure about the details but apparently there is just some sort of consent required being done somewhere?
Volkswagen CarNet is US only (https://carnet.vw.com/). I use “Volkswagen ID. Account (WeConnect)”. And there is no possibillity to enter the S-PIN.
Ok, please note that I never used a VW with the binding so I have no experience. “carnet” for me is just a name for the “API version”. As you can see Seat Connect and myAudi have carnet in the name and work quite well for my German cars. In earlier versions of the binding all Audis were switched to idvehicles and lost any remote functions which they had before. That is the reason why I reverted this change in my latest version of the binding to get those functions back. Also because my Q5 is surely no ID vehicle. But it’s good to know that Golf is working as ID vehicle (besides the control functions). Do you have any of them or none at all?
These are the control channels at the WeConnect Thing: