sensor.charger_current_offered at 6 A

[T-Bienert]

The Setup:
Wallbox: abb terra ac w11-g5-rd-pc-0
Homeassiatant OS
ocpp verson: v0.10.15

Charging works fine in general, but the value for sensor.charger_current_offered is set to 6 A, so the box is only charging at 6 A.
I don’t understand why.

here is a short debug log.
what I noticed "ChargePointMaxProfile not accepted (Rejected); will continue"

2026-07-20 13:17:03.086 DEBUG (MainThread) [custom_components.ocpp] Connection latency from 'central' to 'TACW1141421G0419': ping=0.0 ms, pong=390.0 ms
2026-07-20 13:17:16.445 DEBUG (MainThread) [custom_components.ocpp] Get Configuration for ChargingScheduleAllowedChargingRateUnit: Current,Power
2026-07-20 13:17:16.770 DEBUG (MainThread) [custom_components.ocpp] Get Configuration for ChargeProfileMaxStackLevel: 3
2026-07-20 13:17:17.087 DEBUG (MainThread) [custom_components.ocpp] ChargePointMaxProfile not accepted (Rejected); will continue.
2026-07-20 13:17:18.816 DEBUG (MainThread) [custom_components.ocpp] Get Configuration for ChargingScheduleAllowedChargingRateUnit: Current,Power
2026-07-20 13:17:19.143 DEBUG (MainThread) [custom_components.ocpp] Get Configuration for ChargeProfileMaxStackLevel: 3
2026-07-20 13:17:19.464 DEBUG (MainThread) [custom_components.ocpp] ChargePointMaxProfile not accepted (Rejected); will continue.
2026-07-20 13:17:21.561 INFO (MainThread) [custom_components.ocpp] Start transaction with remote ID tag: 9EIK20966ZALBFCUEK4M
2026-07-20 13:17:23.248 DEBUG (MainThread) [custom_components.ocpp] Connection latency from 'central' to 'TACW1141421G0419': ping=0.0 ms, pong=160.0 ms
2026-07-20 13:17:31.953 WARNING (SyncWorker_2) [PyViCare.PyViCareCachedService] API error, returning stale cache: (PyViCareInternalServerError(...), 'Request failed with status code 0 and message "('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))". ViCare ErrorId: n/a')
2026-07-20 13:17:43.501 DEBUG (MainThread) [custom_components.ocpp] Connection latency from 'central' to 'TACW1141421G0419': ping=0.0 ms, pong=252.0 ms
2026-07-20 13:18:03.688 DEBUG (MainThread) [custom_components.ocpp] Connection latency from 'central' to 'TACW1141421G0419': ping=0.0 ms, pong=186.0 ms
2026-07-20 13:18:23.877 DEBUG (MainThread) [custom_components.ocpp] Connection latency from 'central' to 'TACW1141421G0419': ping=0.0 ms, pong=188.0 ms
2026-07-20 13:18:44.089 DEBUG (MainThread) [custom_components.ocpp] Connection latency from 'central' to 'TACW1141421G0419': ping=0.0 ms, pong=211.0 ms
2026-07-20 13:18:51.599 INFO (MainThread) [custom_components.ocpp] Start transaction with remote ID tag: 9EIK20966ZALBFCUEK4M
2026-07-20 13:19:16.466 DEBUG (MainThread) [custom_components.ocpp] monitor_connection stopping due to exception: no close frame received or sent
2026-07-20 13:19:16.467 DEBUG (MainThread) [custom_components.ocpp] Connection closed to 'TACW1141421G0419': no close frame received or sent
2026-07-20 13:19:18.534 WARNING (MainThread) [homeassistant.helpers.service] Referenced entities switch.charger_charge_control are missing or not currently available
2026-07-20 13:19:18.716 ERROR (MainThread) [websockets.server] opening handshake failed
Traceback (most recent call last):
File "/usr/local/lib/python3.14/site-packages/websockets/http11.py", line 138, in parse
request_line = yield from parse_line(read_line)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.14/site-packages/websockets/http11.py", line 309, in parse_line
line = yield from read_line(MAX_LINE_LENGTH)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.14/site-packages/websockets/streams.py", line 46, in read_line
raise EOFError(f"stream ends after {p} bytes, before end of line")
EOFError: stream ends after 0 bytes, before end of line

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "/usr/local/lib/python3.14/site-packages/websockets/server.py", line 545, in parse
request = yield from Request.parse(
^^^^^^^^^^^^^^^^^^^^^^^^^
self.reader.read_line,
^^^^^^^^^^^^^^^^^^^^^^
)
^
File "/usr/local/lib/python3.14/site-packages/websockets/http11.py", line 140, in parse
raise EOFError("connection closed while reading HTTP request line") from exc
EOFError: connection closed while reading HTTP request line

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "/usr/local/lib/python3.14/site-packages/websockets/asyncio/server.py", line 356, in conn_handler
await connection.handshake(
...<3 lines>...
)
File "/usr/local/lib/python3.14/site-packages/websockets/asyncio/server.py", line 207, in handshake
raise self.protocol.handshake_exc
websockets.exceptions.InvalidMessage: did not receive a valid HTTP request
2026-07-20 13:19:20.163 INFO (MainThread) [custom_components.ocpp] Websocket Subprotocol matched: ocpp1.6
2026-07-20 13:19:20.163 INFO (MainThread) [custom_components.ocpp] Charger websocket path=/TACW1141421G0419
2026-07-20 13:19:20.163 INFO (MainThread) [custom_components.ocpp] Charger TACW1141421G0419 reconnected to 0.0.0.0:9000.
2026-07-20 13:19:20.163 DEBUG (MainThread) [custom_components.ocpp] Reconnect websocket to TACW1141421G0419
2026-07-20 13:19:20.742 DEBUG (MainThread) [custom_components.ocpp] Received boot notification for TACW1141421G0419: {'charge_point_model': 'CDT_TACW11::NET_WIFI', 'charge_point_vendor': 'ABB', 'charge_box_serial_number': 'TACW1141421G0419', 'charge_point_serial_number': 'TACW1141421G0419', 'firmware_version': 'TAC3Z9119006710273::V1.8.37', 'meter_type': 'V1'}
2026-07-20 13:19:20.742 DEBUG (MainThread) [custom_components.ocpp] Updating device info charger: {'charge_point_model': 'CDT_TACW11::NET_WIFI', 'charge_point_vendor': 'ABB', 'charge_box_serial_number': 'TACW1141421G0419', 'charge_point_serial_number': 'TACW1141421G0419', 'firmware_version': 'TAC3Z9119006710273::V1.8.37', 'meter_type': 'V1'}
2026-07-20 13:19:21.808 INFO (MainThread) [custom_components.ocpp] Security event notification received: StartupOfTheDevice at 2026-07-20T11:19:12.000Z [techinfo: none]
2026-07-20 13:19:22.086 INFO (MainThread) [custom_components.ocpp] Security event notification received: SettingSystemTime at 2026-07-20T11:19:20.000Z [techinfo: ocppBoot]
2026-07-20 13:19:23.823 INFO (MainThread) [custom_components.ocpp] Start transaction with remote ID tag: 9EIK20966ZALBFCUEK4M
2026-07-20 13:19:50.322 DEBUG (MainThread) [custom_components.ocpp] Connection latency from 'central' to 'TACW1141421G0419': ping=0.0 ms, pong=156.0 ms
2026-07-20 13:20:10.525 DEBUG (MainThread) [custom_components.ocpp] Connection latency from 'central' to 'TACW1141421G0419': ping=0.0 ms, pong=201.0 ms

tanks timo

[valexi7]

Possible workaround for ABB Terra AC current limiting

I ran into a very similar problem with an ABB Terra AC and did some testing with the newer OCPP integration.

The important part seems to be this message:
ChargePointMaxProfile not accepted (Rejected)

The ABB Terra appears to reject the station-wide ChargePointMaxProfile. In older OCPP integration versions this was less obvious because the integration continued with a fallback after the rejection. In newer versions this behaviour has been changed: Maximum Current is now explicitly a station-wide limit and the slider no longer falls back to transaction profiles when the charger rejects it. The current documentation confirms this behaviour.

I also tried the new option:
Send the station charging limit as an absolute schedule
but at least with my ABB Terra this still did not make ChargePointMaxProfile work.

What seems to work instead
Recent OCPP integration versions provide a separate:
number.charger_session_current_limit

This sends a TxProfile for the currently active charging transaction instead of trying to set the station-wide ChargePointMaxProfile. The Session Current Limit is only available while a transaction is active.

The ocpp.set_charge_rate action is also still available. On OCPP 1.6 it first tries ChargePointMaxProfile and, if the charger rejects it, retains the fallback to transaction/default profiles. The newer Maximum Current number entity no longer has that fallback.

@lbbrhzn Can you dig into this? As this breaks our evcc charging as the evcc sets first the Chargin Current and if this fails we never toggle the Charging State to On. As in current situation we need to have the Charging Session as active before trying to set the Charging Current

[Tomakava]

Look at #2195 I think it is the same problem that this charger does not support max value for profile stack level.