Evcc Binding [5.0.0.0;6.0.0.0)

Hi, yeah there is a fix for it already in Snapshot and Milestone. Unfortunately Becca changed its API again.
You may need to wait until a new version gets released or build your own jar file. Or you could utilize the http binding to get the needed values from evcc.

Not yet, but I think in Milestone it’s already fixed. If not I will look up for a solution.

I’m not sure when/why exactly it went missing but I’m missing the current charge power now.

It used to be there as a channel of the wallbox thing evcc:loadpoint:evcc:wallbox:loadpoint-charge-power but it’s gone now.
OH 5.1.3, latest EVCC 0.304.2
Any idea? Is it possibly only visible when EVCC is up? Only when the wallbox IP is correct? (mine currently isn’t)

I think they changed the API again…

Edit:
That’s not the reason. I’ll have a deeper look soon.

FWIW this is the thing config

Bridge evcc:server:evcc "EVCC server" [scheme="http", host="localhost", port=7070, refreshInterval=10] {
    // This thing will only exist once per evcc instance
    Thing site Zuhause "Zuhause"
    // You can define as many Loadpoint things as you have loadpoints configured in your evcc instance
    //Thing loadpoint demo-loadpoint-carport "Loadpoint - evcc Demo Loadpoint 1"[index=0]
    Thing loadpoint wallbox "Wallbox"[index=0]
    // You can define as many Vehicle things as you have vehicles configured in your evcc instance
    //Thing vehicle demo-vehicle1 "Vehicle - evcc Demo Vehicle 1"[id="vehicle_1"]
}

And I’m getting the error below. Increasing the index didn’t help.

2026-04-09 12:25:51.579 [ERROR] [org.openhab.core.internal.common.AbstractInvocationHandler       ] - An error occurred while calling method 'ThingHandler.initialize()' on 'org.openhab.binding.evcc.internal.handler.EvccLoadpointHandler@6e819548': Index 0 out of bounds for length 0
java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0
        at jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100) ~[?:?]
        at jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106) ~[?:?]
        at jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302) ~[?:?]
        at java.util.Objects.checkIndex(Objects.java:385) ~[?:?]
        at java.util.ArrayList.get(ArrayList.java:427) ~[?:?]
        at com.google.gson.JsonArray.get(JsonArray.java:232) ~[?:?]
        at org.openhab.binding.evcc.internal.handler.EvccLoadpointHandler.lambda$0(EvccLoadpointHandler.java:83) ~[?:?]
        at java.util.Optional.ifPresent(Optional.java:178) ~[?:?]
        at org.openhab.binding.evcc.internal.handler.EvccLoadpointHandler.initialize(EvccLoadpointHandler.java:71) ~[?:?]
        at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:580) ~[?:?]
        at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:149) ~[?:?]
        at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) ~[?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:317) ~[?:?]
        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) [?:?]
2026-04-09 12:25:51.589 [ERROR] [org.openhab.core.thing.internal.ThingManagerImpl                 ] - Exception occurred while initializing handler of thing 'evcc:loadpoint:evcc:wallbox': Index 0 out of bounds for length 0
java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0
        at jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100) ~[?:?]
        at jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106) ~[?:?]
        at jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302) ~[?:?]
        at java.util.Objects.checkIndex(Objects.java:385) ~[?:?]
        at java.util.ArrayList.get(ArrayList.java:427) ~[?:?]
        at com.google.gson.JsonArray.get(JsonArray.java:232) ~[?:?]
        at org.openhab.binding.evcc.internal.handler.EvccLoadpointHandler.lambda$0(EvccLoadpointHandler.java:83) ~[?:?]
        at java.util.Optional.ifPresent(Optional.java:178) ~[?:?]
        at org.openhab.binding.evcc.internal.handler.EvccLoadpointHandler.initialize(EvccLoadpointHandler.java:71) ~[?:?]
        at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:580) ~[?:?]
        at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:149) ~[?:?]
        at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) ~[?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:317) ~[?:?]
        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) [?:?]

thanks

PS I hope you don’t mind I changed the thread title so it’s now obvious this applies to OH>5.0 too

Is there a wallbox configured in your evcc instance? Without it can’t work.

Not sure. It is configured but the IP is wrong (no I don’t know the right one it’s not my system) so I get

Apr 09 19:21:46 smarthouse evcc[2316038]: [lp-1  ] ERROR 2026/04/09 19:21:46 charger enabled: Get "http://192.168.178.17/status": dial tcp 192.168.178.17:80: connect: no route to host

Okay, I understand. I have never tested what will be the response when the configuration is not working.

Ah. I scanned the net and found the charger IP. Now it’s working. The channel appeared.
Strictly speaking the config was working in terms of being a valid evcc config … just the charger (wallbox) IP was wrong. If then the power channel is missing (and others), it feels a little strange…

We need to give an info to the user that there is something wrong.

Hi, I’m a little confused right now. Which plugin can I use to connect to EVCC version greater than 0.302.1?

thanks

I tried to revive my evcc integration yesterday by installing the Marketplace plugin. Is this still the recommended one for evcc v0.305.1?

The evcc server Thing shows as online, but no additional evcc Things appear in the Inbox. From the documentation, I would expect these to be discovered automatically. Is that correct, or am I missing a step?

evcc binding keeps discovering and generating log messages like

2026-04-23 15:49:48.928 [DEBUG] [org.openhab.binding.evcc.internal.discovery.EvccDiscoveryService ] - Starting evcc Discover

How can I disable discovery?

It’s a real nuisance to have channels missing when the charger IP is wrong.
Even happens when the configured IP right but temporarily unreachable, I’ve just hit that case, too.

FWIW, it’s a known but apparently unsolved problem in evcc Startup if not all wallboxes, meters, integrations are reachable · Issue #14496 · evcc-io/evcc · GitHub
Does anyone know if it’s possible to work around that evcc behavior?

I created this issues because of the warning during discovery.

Cou you change the log level of the evcc binding from DEBUG to INFO in your case to get rid of the messages?

I guess but what’s the point in that?

I have installed the marketplace binding on 5.1.4 and the bridge goes online but no things added.

In the log I see:
‘’
Logger Class
org.openhab.core.internal.common.WrappedScheduledExecutorService
Message
Scheduled runnable ended with an exception:
Stack Trace
java.lang.ClassCastException: class com.google.gson.JsonNull cannot be cast to class com.google.gson.JsonArray (com.google.gson.JsonNull and com.google.gson.JsonArray are in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @71ccd81f)
at com.google.gson.JsonObject.getAsJsonArray(JsonObject.java:211)
at org.openhab.binding.evcc.internal.discovery.mapper.BatteryDiscoveryMapper.discover(BatteryDiscoveryMapper.java:46)
at org.openhab.binding.evcc.internal.discovery.EvccDiscoveryService.startScan(EvccDiscoveryService.java:69)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.base/java.util.concurrent.FutureTask.runAndReset(Unknown Source)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
‘’

I have the same issue. I am using the Marketplace binding. The server Thing is shown as online, but no further Things are discovered. In the log file, I see the following:

2026-05-25 14:40:39.142 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 
java.lang.ClassCastException: class com.google.gson.JsonObject cannot be cast to class com.google.gson.JsonArray (com.google.gson.JsonObject and com.google.gson.JsonArray are in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @6cd36174)
	at com.google.gson.JsonObject.getAsJsonArray(JsonObject.java:211) ~[?:?]
	at org.openhab.binding.evcc.internal.discovery.mapper.BatteryDiscoveryMapper.discover(BatteryDiscoveryMapper.java:46) ~[?:?]
	at org.openhab.binding.evcc.internal.discovery.EvccDiscoveryService.startScan(EvccDiscoveryService.java:69) ~[?:?]
	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) [?:?]

Maybe it is related to the fact that there was also a breaking change to the battery structure in the evcc API earlier this year?

I’m a little confused right now, too. I think the API has changed twice recently.

The first change has been implemented, but the second one hasn’t yet. (But that’s probably not the reason; see above.)

It hasn’t worked for me since the first change, but that’s also because I don’t know where to download the latest version; the battery issue was the first thing that stopped working.