Just for Info…
It is still the problem, that the actual 4.1.2.xxxx - Bindings don’t work with audi at all.
No Errors, Things come online but get not data…
With 4.1.1.XXX build of the binding, most things work (no doors, no windows) but overall state of lock-state…and some data like km, oil, service…
Please follow the community rules and don’t paste screenshots. Those are hard to read on mobile devices and we cannot quote.
Post your logs in code fences
I think guys from HA made it work with FordPass new API:
The question is, can somebody make similar changes for this binding and test it with FordPass? I may try to figure it out (don’t have experience with developing custom bindings or Java though), but seems like Marcus’s initial version is a little outdated, and newer versions were shared as built jar, not source.
sorry for asking, but I am a bit confused, I am driving a ID.4 North America version, more specific the Canada version and I recognized that ID.4 do use different services in Canada and Europe. Does this binding only work with the European versions? And if the work in Canada, what connection configuration do I have to use in the GUI when configuring the binding?
I had my CC running on openHAB 4.2.1 (Release Build) on my Raspi, everything was fine until today, no changes on my side, but since today, I am getting the following WARN/Exception whenever I put the connectedcar.things file in the things folder. I tried to elaborate by removing the car thing out of the file, so I only had the WeConnect account as a bridge, but also this gives the error:
2024-08-28 15:40:14.717 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.ClassCastException: class com.google.gson.JsonNull cannot be cast to class com.google.gson.JsonObject (com.google.gson.JsonNull and com.google.gson.JsonObject are in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @6db14287)
at com.google.gson.JsonObject.getAsJsonObject(JsonObject.java:221) ~[?:?]
at org.openhab.binding.connectedcar.internal.api.weconnect.BrandWeConnectAudi.getVehicles(BrandWeConnectAudi.java:151) ~[?:?]
at org.openhab.binding.connectedcar.internal.handler.AccountHandler.initializeThing(AccountHandler.java:199) ~[?:?]
at org.openhab.binding.connectedcar.internal.handler.AccountHandler.lambda$2(AccountHandler.java:158) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
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) [?:?]
May be interesting for Ford/Lincoln owners. As few of posters in this thread already discovered, Ford changed authorisation for FordPass and this binding stopped working some time ago.
I couldn’t figure out how to work with custom binding and how to contribute to the work already done on this one, so I went different direction.
I use node-red as rule engine for my openhab installation and I’m more familiar with JavaScript, so I made a couple of custom nodes that allowed me to successfully get vehicle details:
There are a lot more of the API to explore, so contributions are welcome.
What’s missing to get the binding to the normal route? Is it the complexity of different edge cases, which seems to be higher than with other bindings? Would be great to offer this functionality to more users, since manual jar installations and testing of different versions without any documentations might be difficult if not impossible for many.
