Tesla Binding "'ID segment ‘null’ contains invalid characters" - since ~beginning of this year

Setup, Configuration and Use Runtime
1

Does anyone else also see this error in his logs from the Tesla binding:

2025-10-18 12:13:12.987 [ERROR] [internal.handler.TeslaAccountHandler] - An exception occurred while connecting to the Tesla back-end: 'ID segment 'null' contains invalid characters. Each se>
java.lang.IllegalArgumentException: ID segment 'null' contains invalid characters. Each segment of the ID must match the pattern [\w-]*.
        at org.openhab.core.common.AbstractUID.validateSegment(AbstractUID.java:105) ~[?:?]
        at org.openhab.core.common.AbstractUID.<init>(AbstractUID.java:76) ~[?:?]
        at org.openhab.core.common.AbstractUID.<init>(AbstractUID.java:59) ~[?:?]
        at org.openhab.core.thing.UID.<init>(UID.java:57) ~[?:?]
        at org.openhab.core.thing.ThingUID.<init>(ThingUID.java:58) ~[?:?]
        at org.openhab.binding.tesla.internal.discovery.TeslaVehicleDiscoveryService.vehicleFound(TeslaVehicleDiscoveryService.java:73) ~[?:?]
        at org.openhab.binding.tesla.internal.handler.TeslaAccountHandler.queryVehicles(TeslaAccountHandler.java:241) ~[?:?]
        at org.openhab.binding.tesla.internal.handler.TeslaAccountHandler.lambda$0(TeslaAccountHandler.java:391) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572) ~[?:?]
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:358) ~[?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) ~[?:?]
        at java.lang.Thread.run(Thread.java:1583) [?:?]

I am currently running on the latest version of openHAB 5.0.2-1 and still get this error.
The issue started beginning of the year when I was still on 4.5, but it continued when updating to 5.0 and in the meantime I even got a new car. Initially thought the new car fixed the issue, but after like 1 day or so it appeared again.
Since sporadically I seem to get updates of my car status (every x days/weeks) I wonder what this problem is and what is causing it.
I hope someone of you has seen this issue and found a way to fix it via configuration update or so.

2

Maybe @Kim_Andersen, who owns a Tesla I think, can have a look :smiling_face_with_three_hearts:

3

I should try take a look at this. I do use the Teslascope binding for my automations, but it would be nice to not get errors/warnings from the Tesla binding too.

4

https://smedley.id.au/tmp/org.openhab.binding.tesla-5.1.0-SNAPSHOT.jar ignores null vins and should fix this.

5

Thanks for the recommendation. I believe Teslascope requires me to have a subscription. I don’t see that I am so addicted to see some statistics of my car that I am willing to pay for it. If there is no way to get some essential data into my own installation like openHAB then … I just accept it.
Anyways thanks for the recommendation.
Maybe if the maintainer :wink: of the current Tesla Binding has an idea or some time to fix the issue, the issue will be resolved otherwise I may just live with it (or remove the Tesla binding … as the data collected is anyways very limited due to the frequent changes Tesla did in the past and the binding could not always keep up with (understandably). I know that Tesla tries to address this with a commercial API now, but as said before … I am not so addicted to my car to be willing to pay for data I create with my car. :blush:

6

I use the Tesla binding as well, but i have not seen this error at all. Im using openHAB 4.3.7.

7

I use Teslascope mainly for the commands. I’m on a dynamic electricity tariff, so with Teslascope I can start/stop charging :slight_smile:

8

I believe it must be something in my data returned from the Tesla call which makes the Binding fail as the data that I configured does not look to have any suspicious characters or so in it. The binding also is marked “green” and “Online” it just fails to process the data.
Unfortunately I could not convince the binding to reveal the data it gets from Tesla in a log to be able to identify the culprit.