Keba modbus template needs additional code to stop charging, when the charging is stopped by the car

[Postmann-x]

Description

I have an Keba P30 x-series with a Keba S10 and use the keba template with a Sponsor token.

I want to charge "offline cars". So the cars are not linked in EVCC and EVCC doesn`t know the SoC of the cars.

So when I am charging the cars, they stop the charging when the defined charging limit in the car is reached. EVCC doesn`t know to handle with this, when the car stops the charging. Charger Status B is shown, but EVCC maintains sending charge commands.

What is now happening:

The Keba wallbox wants to start the charging and emmidiatly the car says no. The Wallbox makes a loud clicking sound every few minutes: ON, OFF, ON, OFF..

Then I contacted the manufactor Keba what to do and Keba said, there is a problem with EVCC and gives me a Workaround.

Here is the log, while the car stops the charging:

lp-1 ] DEBUG 2026/06/18 15:11:06 charge power: 0W
[lp-1 ] DEBUG 2026/06/18 15:11:06 charge currents: [0 0 0]A
[site ] DEBUG 2026/06/18 15:11:06 grid power: -3470W
[site ] DEBUG 2026/06/18 15:11:06 grid powers: [-1450 -1000 -1010]W
[site ] DEBUG 2026/06/18 15:11:06 grid currents: [-6.52 -4.58 -4.84]A
[site ] DEBUG 2026/06/18 15:11:06 pv power: 3720W
[site ] DEBUG 2026/06/18 15:11:06 site power: -3220W
[lp-1 ] DEBUG 2026/06/18 15:11:06 session energy: 12.495kWh
[lp-1 ] DEBUG 2026/06/18 15:11:06 charge total import: 7544.030kWh
[lp-1 ] DEBUG 2026/06/18 15:11:06 charger status: B
[lp-1 ] DEBUG 2026/06/18 15:11:06 charge final energy: 12.495kWh
[lp-1 ] INFO 2026/06/18 15:11:06 stop charging <-
[lp-1 ] DEBUG 2026/06/18 15:11:06 charge total import: 7544.030kWh
[lp-1 ] DEBUG 2026/06/18 15:11:06 !! plan: plan time zero
[lp-1 ] DEBUG 2026/06/18 15:11:06 pv charge current: 14A = 0A + 14A (-3220W @ 1p)
[lp-1 ] DEBUG 2026/06/18 15:11:06 set charge current limit: 14A
[site ] DEBUG 2026/06/18 15:11:36 ----

And here is the answer from Keba:

"The wallbox itself has no setting to 'ignore Modbus commands once the vehicle has finished charging.' This behavior is by design: when an external energy manager takes control (with Modbus TCP active), the wallbox follows the commands. The solution must therefore be implemented on the EVCC side: EVCC should monitor the charger status. If the status switches to 'B' (vehicle connected but not charging), EVCC should stop sending charging commands. Your log clearly shows this sequence: charger status: B → stop charging → but then immediately pv charge current: 14A and set charge current limit: 14A. Check your EVCC configuration: EVCC allows you to configure behavior for status B. Check if you can set a parameter—such as minSoc or an enable/disable threshold—to prevent commands from being sent after the vehicle has stopped charging. Workaround using Modbus register 5004: You could incorporate a script into EVCC that writes a value of 0 to register 5004 when status B is detected and maintains that value until the vehicle requests charging again."

I hope you can include the workaround in the keba template:

Thx.

Steps to Reproduce

1. start charging vehicle as "offline car"
2. The car stops itself the charging because of reaching charging limit in the car.
3. EVCC can`t handle the "stop charging" command an tries to charge
4. the wallbox is clicking ON, OFF, ON, OFF...

⚠️ RETURN TO EVCC TAB → COPY STEP 2 → PASTE HERE

Version

v0.311.0

System

linux/arm64, CEST +02:00

[andig]

The solution must therefore be implemented on the EVCC side: EVCC should monitor the charger status. If the status switches to 'B' (vehicle connected but not charging), EVCC should stop sending charging commands. Your log clearly shows this sequence: charger status: B → stop charging → but then immediately pv charge current: 14A and set charge current limit: 14A.

Happy to get in contact with KEBA but this is most probably wrong and opposed to what EVERY other charger does. Updating the current limit should not trigger the relay. If it does then that's a bug on the KEBA firmware side. Given this is the first report in >5 years of KEBA support I'd also assume they've only broken it recently.

Long story short: open ticket with KEBA, happy to join to conversation via email. Atm NOT and evcc issue.

/cc @premultiply

[TobiasHuber1980]

I have a similar setup: 2x Keba P30 x-series + 2x Keba P30 c-series, plenty offline vehicles - no Keba S10. Firmware 2.0.1 (x-series) & Firmwre 3.10.80 (c-series).

The logs look similar, but I can't hear any relay clicking in the wallbox like you described.

[lp-7 ] DEBUG 2026/07/13 09:06:02 charge power: 0W
[lp-7 ] DEBUG 2026/07/13 09:06:02 charge currents: [0 0 0]A
[site ] DEBUG 2026/07/13 09:06:02 pv 1 power: 46750W
[site ] DEBUG 2026/07/13 09:06:02 grid power: -7350W
[site ] DEBUG 2026/07/13 09:06:02 site power: -7250W
[lp-7 ] DEBUG 2026/07/13 09:06:02 charge total import: 976.032kWh
[lp-7 ] DEBUG 2026/07/13 09:06:02 charger status: B
[lp-7 ] DEBUG 2026/07/13 09:06:02 !! plan: plan time zero
[lp-7 ] DEBUG 2026/07/13 09:06:02 pv charge current: 10.5A = 0A + 10.5A (-7250W @ 3p)
[lp-7 ] DEBUG 2026/07/13 09:06:02 set charge current limit: 10.5A
[site ] DEBUG 2026/07/13 09:06:02 solar forecast: produced 59.288kWh, forecasted 69.821kWh, scale 0.849
[site ] DEBUG 2026/07/13 09:06:09 ----

[BenjaminHae]

I think I have the same issue with a Keba KeContact P40 and an offline vehicle.

After the car has finished charging and unplugging it, the wallbox changed into an error state (one red flash every five seconds) and the app has shown "Ladung ausgesetzt". Only powering off the wallbox fixed it.

On the next charge I've stopped the charging process in the keba app and everything went well.

Version: v0.311.1

[andig]

See #31680 (comment). I'd be happy if smbd from KEBA want to discuss this with info@evcc.io. ATM there is zero indication of any issue on the evcc side.

[andig]

Seems KEBA is not interested in making this work as intended :(

[Postmann-x]

KEBA answered :)

Thank you very much for the additional information and feedback from the EVCC developers. We have evaluated the wallbox logs for the described process in detail on 18.06.2026.
The wallbox correctly detects the end of the charging on the vehicle's side. At 15:10:32 the vehicle changes from the state of C charge to the state B. The P30 then immediately opens the power contactor and stops the power output. There is no contactor, FI/RCD or other hardware error message.
After this charging end, however, a positive charging current is still offered via the PWM signal. The specification is changed regularly, for example:
15:11:06 14,0 A
15:11:36 17,8 A
15:12:06 15,5 A
15:22:06 9,5 A
As long as a positive current is offered and the charge release is active, the vehicle can switch from B on C again and thus signal readiness for charging again. This is exactly what can be seen several times in the logs:
15:22:07 Schütz EIN
15:22:23 Schütz AUS
15:28:07 Schütz EIN
15:28:24 Schütz AUS
15:32:38 Schütz EIN
15:32:53 Schütz AUS
15:38:37 Schütz EIN
15:38:52 Schütz AUS
15:51:08 Schütz EIN
15:51:23 Schütz AUS
Each of these operations begins with a change in the Control Pilot state from B to C. The P30 thus closes the contactor in response to a renewed loading request of the vehicle. After about 15 to 16 seconds, the vehicle switches back up B, whereupon the P30 opens the contactor.
A hardware defect or an impermissible independent contactor actuation of the wallbox is not recognizable from the available logs.
An important point concerns the EVCC log message:
stop charging <-
According to our test, this message documents the transition of the vehicle from the state of charge detected by EVCC. It is not automatically proof that EVCC has sent an explicit deactivation command to the wallbox.
There are two functions for KEBA Modbus control:
Register 5004 determines the maximum charging current offered.
Register 5014 controls the actual charging release.
Writing a positive current value to register 5004 should not release a deactivated wallbox on its own. However, the prerequisite for this is that the charging release via register 5014 has actually been deactivated beforehand and remains on 0 .
The available EVCC and wallbox logs show that positive current specifications continue to apply after the vehicle's charging end. However, they do not provide clear evidence that Register 5014 was set to 0 at that time.
For the final distinction between EVCC and wallbox, we therefore need an EVCC Modbus TRACE for the period at 15:10:32. This should show:
Whether EVCC writes to the value 0 in stop charging <- register5014.
Which value is then read from register 5014 .
What other write accesses to registers 5004 are made.
If register 5014 is still on 1 , the wallbox has not been permanently deactivated. The observed behavior could then be explained by the still active charge release in conjunction with the delayed SoC information.
If, on the other hand, it is proven that the register 5014 is permanently open 0 and the P30 still closes the contactor exclusively by making changes to the register 5004 , we would further investigate the behavior as a possible firmware error.
An additional UDP setting, with which the P30 can be permanently locked until unplugged after a change to state B , is not provided. Condition B simply means "vehicle connected, currently no charging requirement". In addition to a full battery, it can also occur during a temporary charging break. The P30 knows neither the vehicle SoC nor the target charge level set in the vehicle.
In addition, we noticed the following deviation in the exported configuration:
ModbusFailsafeCurrent=32000
ModbusFailsafeTimeout=0
This means that a failsafe current of 32 A is stored and the communication timeout function is deactivated. The described setting "Charging current in case of communication failure = 0 A" is therefore not effective in the Diagnostics Log. This setting should be checked again in the web interface, saved and then verified with a new Diagnostics Log. However, it does not directly explain the observed cycles with active EVCC communication.
In summary, the P30 correctly detects the end of the loading on the vehicle side and opens the contactor. The renewed short switch-ons occur because the charge release or a positive PWM current remains active and the vehicle periodically signals status C again. For a clear assignment, we still need the write history of the Modbus registers 5004 and 5014 on the EVCC side.
Best regards,
Ihr KEBA eMobility Support Team

Freundliche Grüße | Best regards

Ihr | Your KEBA eMobility Support Team

[andig]

That's great support and clarifies that a trace log is needed.

The available EVCC and wallbox logs show that positive current specifications continue to apply after the vehicle's charging end. However, they do not provide clear evidence that Register 5014 was set to 0 at that time.

It seems as if KEBA is expecting evcc to send 0A intermittently which I'm sure we don't. But a trace log will tell.

[Postmann-x]

Hi andig,

I don´t know, if you can see anything in the tracelog, but here it is.

ca, 12:40 h stop charging
ca. 12:46 h Wallbox clicks ON OFF
ca. 12:54 h wallbox clicks ON OFF

I sent it to KEBA with a wallbox log.

evcc-20260731-125549-trace.log

[andig]

Analysed the trace log (10495 lines, 11:41:23–12:55:23).

Register 5014 is never written

Not once in the entire log. Frames sent to the wallbox:

frame	register	count
ff 03 ...	reads of 1000/1004/1008/1020/1036/1500/1552	~1500
ff 06 13 8c	write 5004	144
ff 06 13 96	write 5014	0
ff 06 13 9a	write 5018 (failsafe heartbeat)	0

So 5014 keeps whatever value it was given when charging started (before the log begins), i.e. 1. KEBA's first case applies: the charging release stays active.

Timeline

Register 1000 (charging state) as read by evcc:

• 3 (charging) until 12:40:23
• 2 (ready for charging, waiting for EV) from 12:40:53 — this is where the car pauses
• 1 at 12:54:53 — unplug, evcc reports status A

The stop charging <- line at 12:40:53 is the loadpoint logging the C→B transition it observed. It is not a Modbus command — KEBA's assumption about that message is correct.

What evcc writes after the car pauses

Setpoints written to 5004 from 12:40:53 onwards, in mA:

24065 24217 24282 24434 24347 24456 24347 24195 23391
12065 12282 11304 24608 13652 14108 11869 12413 12956
12826 11195 11543 11456 11521 10760 10217 10065 10195

27 writes, all positive, 10.1–24.6 A, one every 30 s. Charge power reads 0 W throughout, so the PV surplus stays high and the surplus controller recomputes a new current every cycle. The ~15 s contactor pulses are shorter than evcc's 30 s sampling interval, so they do not appear in the evcc log at all.

Why evcc does not disable

For the P30, Enabled() is derived from the charging state: !(s == 5 || s == 1). The state is 2, so evcc reads back "enabled", which matches its own intent — PV mode, ~11 kW surplus, vehicle connected. No state change, so Enable() is never called and 5014 is never touched. This is the intended behaviour and is identical for every other charger.

Answers to the three questions

1. Does evcc write 0 to 5014 on stop charging? — No. It never writes 5014 at all in this log.
2. Which value is read back from 5014? — evcc does not read 5014; it derives the enabled state from register 1000, which returns 2.
3. Other write accesses to 5004? — every 30 s, always positive, values listed above.

That matches KEBA's analysis: release active plus a positive PWM current, so the vehicle is free to request charging again and the contactor cycles.

Failsafe configuration

Also confirmed from the trace: register 1602 was read as 0 at startup, so evcc's failsafe heartbeat never started and there are no writes to 5018. The reported ModbusFailsafeTimeout=0 is real.

🤖 Generated with Claude Code

[Postmann-x]

Hi andig,

here the anwser from KEBA:

Afternoon,

How to permanently stop a charging session via Modbus TCP
To ensure that the KeContact P30 x-series does not resume charging once the vehicle has reached its target state of charge (e.g., when the car "wakes up" for battery conditioning), you must implement a control logic within your external Energy Management System (EMS) or Smart Home controller.
Relevant Modbus Registers

<style> </style>

Register	Access	Function
1000	Read	Charging State (current status of the wallbox)
1020	Read	Active Power in mW
5004	Write	Maximum charging current in mA (Range: 0–63000)
5014	Write	Enable/Disable bit

Recommended Implementation Logic
Since the wallbox cannot know the vehicle's internal State of Charge (SoC) via a standard Type 2 cable, the system must detect the end of the charging process based on power consumption:

1. Monitor Power Consumption: Cyclically read register 1020 (Active Power).
2. Threshold Detection: If the power drops below a specific threshold (e.g., < 100 W) for a defined period (e.g., 2 minutes), the vehicle has signaled that it is full.
3. Lock the Charging Session: Immediately write the value 0 to register 5004.
   o Register 5004 → 0 mA
   o This sets the available current to zero. Even if the vehicle requests power again later, the wallbox will not provide it.
4. Reset for Next Session: The logic should only reset register 5004 to a standard charging current (e.g., 16000 mA) once register 1000 indicates that the cable has been unplugged or a new session has been authorized.

⚠️ Important: Use Register 5004 instead of 5014
While register 5014 (Enable/Disable) can also stop the session, it is highly recommended to use Register 5004 (0 mA) for pausing/locking.
• Reason: Register 5004 is future-proof. On newer generations like the KEBA P40, register 5014 might terminate the session entirely (requiring new RFID authorization), whereas 5004 simply limits the current to zero, keeping the session "active but paused."

Failsafe Configuration
To prevent uncontrolled charging in case your controller loses connection to the wallbox, you should configure the Failsafe settings:
• Register 5016: Failsafe current (set to 0 to stop charging if the connection is lost).
• Register 5018: Failsafe timeout (e.g., 60 seconds). If the wallbox doesn't receive a Modbus command within this time, it triggers the failsafe current.

Summary of the Control Loop:
• IF Power (Reg 1020) < 100W for 120s THEN Write Reg 5004 = 0.
• IF Status (Reg 1000) == "Unplugged" THEN Write Reg 5004 = 16000 (prepare for next session).

Freundliche Grüße | Best regards

Ihr | Your KEBA eMobility Support Team