Ocular LTE Plus v3 - Unable to stop charging or adjust charge current

[dh99999]

Hi All,

I am having issues stopping charging on an Ocular LTE PLus v3..

I can start charging by turning on the "Charge Control" entity, but when attempting to stop the charging session by turning it off, I receive the below exception: idTag is too long (contains non-printable characters)
ocpp.exceptions.TypeConstraintViolationError: TypeConstraintViolationError: Payload for Action is syntactically correct but at least one of the fields violates data type constraints (e.g. “somestring”: 12), {'cause': "'DFQETM4PBP3E3JTNO8DA\\x10\\x0e' is too long", 'ocpp_message': <Call - unique_id=100000179, action=StopTransaction, payload={'meterStop': 2509, 'idTag': 'DFQETM4PBP3E3JTNO8DA\x10\x0e', 'transactionId': 1781579436, 'timestamp': '2026-06-16T03:40:36Z', 'reason': 'Remote'}>}�[0m

I am not sure if I am reading this correctly - is it the charger generating the invalid message or the ocpp integration?

Either way charging does not stop....

I am currently using the auto-population of measurands if that makes a difference...

Also having issues dynamially controlling max current - the process in https://github.com/lbbrhzn/ocpp/blob/main/docs/Charge_automation.md does not work for me (the charger returns "Rejected" for the command) - do we need to use custom profiles with this charger?

Any ideas would be appreciated!

`[36m2026-06-16 13:39:46.428 DEBUG (MainThread) [websockets.server] > PING 'gЗ[' [text, 4 bytes]�[0m
�[36m2026-06-16 13:39:46.451 DEBUG (MainThread) [websockets.server] < PONG 'gЗ[' [text, 4 bytes]�[0m
�[36m2026-06-16 13:39:46.451 DEBUG (MainThread) [custom_components.ocpp] Connection latency from 'central' to 'ocpp_garage': ping=1.0 ms, pong=23.0 ms�[0m
�[36m2026-06-16 13:39:54.991 DEBUG (MainThread) [websockets.server] > TEXT '[2,"848272f3-76f2-4150-93a0-3614c9650912","Remo...sactionId":1781579436}]' [95 bytes]�[0m
�[36m2026-06-16 13:39:55.122 DEBUG (MainThread) [websockets.server] < TEXT '[3,"848272f3-76f2-4150-93a0-3614c9650912",{"status":"Accepted"}]' [64 bytes]�[0m
�[36m2026-06-16 13:39:55.834 DEBUG (MainThread) [websockets.server] < TEXT '[2,"100000179","StopTransaction",{"meterStop":2...6Z","reason":"Remote"}]' [175 bytes]�[0m
�[31m2026-06-16 13:39:55.839 ERROR (MainThread) [ocpp] Error while handling request '<Call - unique_id=100000179, action=StopTransaction, payload={'meterStop': 2509, 'idTag': 'DFQETM4PBP3E3JTNO8DA\x10\x0e', 'transactionId': 1781579436, 'timestamp': '2026-06-16T03:40:36Z', 'reason': 'Remote'}>'
Traceback (most recent call last):
  File "/usr/local/lib/python3.14/site-packages/ocpp/messages.py", line 240, in _validate_payload
    validator.validate(message.payload)
    ~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.14/site-packages/jsonschema/validators.py", line 450, in validate
    raise error
jsonschema.exceptions.ValidationError: 'DFQETM4PBP3E3JTNO8DA\x10\x0e' is too long

Failed validating 'maxLength' in schema['properties']['idTag']:
    {'type': 'string', 'maxLength': 20}

On instance['idTag']:
    'DFQETM4PBP3E3JTNO8DA\x10\x0e'

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

Traceback (most recent call last):
  File "/usr/local/lib/python3.14/site-packages/ocpp/charge_point.py", line 272, in route_message
    await self._handle_call(msg)
  File "/config/custom_components/ocpp/chargepoint.py", line 534, in _handle_call
    await super()._handle_call(msg)
  File "/usr/local/lib/python3.14/site-packages/ocpp/charge_point.py", line 300, in _handle_call
    await validate_payload(msg, self._ocpp_version)
  File "/usr/local/lib/python3.14/site-packages/ocpp/messages.py", line 179, in validate_payload
    await asyncio.get_event_loop().run_in_executor(
        None, _validate_payload, message, ocpp_version
    )
  File "/usr/local/lib/python3.14/concurrent/futures/thread.py", line 86, in run
    result = ctx.run(self.task)
  File "/usr/local/lib/python3.14/concurrent/futures/thread.py", line 73, in run
    return fn(*args, **kwargs)
  File "/usr/local/lib/python3.14/site-packages/ocpp/messages.py", line 254, in _validate_payload
    raise TypeConstraintViolationError(
        details={"cause": e.message, "ocpp_message": message}
    ) from e
ocpp.exceptions.TypeConstraintViolationError: TypeConstraintViolationError: Payload for Action is syntactically correct but at least one of the fields violates data type constraints (e.g. “somestring”: 12),  {'cause': "'DFQETM4PBP3E3JTNO8DA\\x10\\x0e' is too long", 'ocpp_message': <Call - unique_id=100000179, action=StopTransaction, payload={'meterStop': 2509, 'idTag': 'DFQETM4PBP3E3JTNO8DA\x10\x0e', 'transactionId': 1781579436, 'timestamp': '2026-06-16T03:40:36Z', 'reason': 'Remote'}>}�[0m
�[36m2026-06-16 13:39:55.859 DEBUG (MainThread) [websockets.server] > TEXT '[4,"100000179","TypeConstraintViolation","Paylo...on\\":\\"Remote\\"}]"}]' [455 bytes]�[0m
�[36m2026-06-16 13:39:59.318 DEBUG (MainThread) [websockets.server] < TEXT '[2,"100000180","MeterValues",{"connectorId":1,"..."Sample.Periodic"}]}]}]' [997 bytes]�[0m
�[36m2026-06-16 13:39:59.349 DEBUG (MainThread) [websockets.server] > TEXT '[3,"100000180",{}]' [18 bytes]�[0m
�`

[dh99999]

As an update to the above:

• The charger is returning an invalid response to the RemoteStop (stop charging) request. I can get charging to stop by setting "Skip OCPP schema validation checkbox" during OCPP server configuration.

• For dynamic charge current control, I managed to change the current offered using a custom Tx Profiles in a similar way to https://github.com/lbbrhzn/ocpp/blob/main/docs/Charge_automation.md. I suspect it was not working previously as it appears only 2 charging profiles can be stored on the device, and HA attempts to set 3 (Max, TxDefault and then Tx). If I only set 1 it works as expected.

• I can set the current offerred to 0 to pause charging (eg: from solar) but immediately after moving to an EVSESuspended state the charger moves to a Short Circuit error and needs to be rebooted. This is very concerning.

• Dont bother manually configuring the measureands - any values set are ignored by the unit. The configuration can be saved, but ignores it.

• By far the biggest issue with this charger though is that it frequently drops off the network (to the point where it re-requests a DHCP lease) and subsequently drops its connection to HA. This makes it pretty useless for scheduling charging or charging from solar as many actions fail. I have tried multiple cables, shielded cables, connecting to a switch 50cm away and everything in between. I may have a defective unit, but at least one other person has reached out to me with exactly the same issue. He has given up on OCPP and uses the unit in "offline" mode only.

• I have reported the issues to the distributor in Australia (EVSE) and am awaiting a reply.... that was a week ago. I am still hopeful they will respond as I want to sort out these issues.... hopefully they can be solved with a firmware upgrade.

• If anyone has had any experience with this unit (good or bad) please reach out.

[rampage101]

For the network dropout, the following may fix it:
Edit the core.config_entries in the .storage directory of HA.
websocket_ping_interval: null
websocket_ping_timeout: 0
websocket_ping_tries: 0
websocket_close_timeout: 60

This has fixed it for at least 1 other person, however I'm still having issues. The difference so far is they have a 3-phase LTE, I only have the single phase.

[dh99999]

Hi Rampage,

Yeah, I changed the ping interval to 999999999999 and this has stopped the disconnects, but it also means that HA can't detect when the charger has disconnected.... this is easier than changing the code as it can be done from HA during the setup.

I have the 3 phase...

It hasn't fixed the issues with the invalid JSON on the StopTransaction, or the short circuit errors when pausing charging.

I am also seeing another issue periodically where after sending a command (eg: Start Charging), it starts responding again to every other command sent previously.... which is a pain as it changes the charging rates... sigh.

What other issues are you seeing?

[rampage101]

I was still getting the charger disconnecting/dropping out. Turns out I missed a step, needed to set HeartbeatInterval and WebsocketPingInterval to 60. So far that's stopped any issues. However restarting HA resets the Heartbeat.
I can't do much more testing yet though, as we're still waiting for our vehicle.

[matiebird]

After reverse engineering the web version of Charge HQ I found the profile for ocular chargers tested this on my Ocular LTE Plus V3 reporting:

• Model: BS-EV07
• Firmware: 405.3251.0Q03196
• OCPP: 1.6J over Ethernet/W5500
• Central system: Home Assistant with lbbrhzn/ocpp
• Charger connection path: Ocular -> handshake proxy :9000 -> HA OCPP :9001

The charger was repeatedly dropping its OCPP connection and reconnecting about 25 seconds later. Heartbeats and WebSocket pongs worked normally between drops.

What I tried

I first checked the separate timing layers:

• Home Assistant WebSocket ping interval: 20 seconds
• Home Assistant ping timeout: 20 seconds
• Allowed failed pings: 2
• Charger HeartbeatInterval
• Charger WebSocketPingInterval

Using ocpp.get_configuration and ocpp.configure, I set and read back:

• HeartbeatInterval = 60
• WebSocketPingInterval = 60

I also found that an OCPP Soft Reset changes HeartbeatInterval back to 3600 on this firmware, while WebSocketPingInterval remains at 60. After every Soft Reset, I had to set the heartbeat back to 60 and verify it again.

The charger also sends a malformed/non-standard WebSocket opening in some cases, so I placed a small constrained proxy in front of Home Assistant. The charger connects to port 9000, the proxy normalises the handshake, and valid traffic is forwarded to the Home Assistant OCPP listener on port 9001.

Result

The proxy fixed the malformed-handshake problem, and the charger remains usable after each automatic reconnect. Setting both charger intervals to 60 seconds did not eliminate the reconnects on this unit.

Observed over the most recent period:

• 14 reconnect increments in one hour
• 43 reconnect increments in three hours
• 95 reconnect increments in six hours
• 26 connector-unavailable events in six hours
• Median unavailable duration: about 25 seconds
• Longest observed unavailable duration: about 25.5 seconds

The connection currently recovers automatically and resumes fresh heartbeats and pongs, but the reconnect cycle is still present.

So, for firmware 405.3251.0Q03196, the 60/60 configuration is not a complete fix. It may improve liveness or recovery, but it does not resolve the underlying W5500/WebSocket disconnect behaviour.

Separately, command and transaction reliability required the 16-character remote-start ID-tag workaround and an Ocular-specific charging-profile path. Those changes fixed start/stop and current-control compatibility, but they did not affect the reconnect frequency.

If you want to replicate what I've done minus the proxy.

Open scripts and paste this into the yaml For a normal Home Assistant user, the easiest option is a Home Assistant script, not a shell script or API token.

1. Open Settings, Automations & Scenes → Scripts
2. Create a script
3. Open the three-dot menu and select Edit in YAML
4. Replace everything with this
5. Change ocular only if their OCPP device ID is different
6. Save and run it

alias: Ocular OCPP - set stable connection timing
description: >-
Sets the charger-side heartbeat and WebSocket ping intervals to 60 seconds,
reads them back, and shows the result as a Home Assistant notification.

variables:
ocpp_device_id: ocular

sequence:

• action: ocpp.configure
  data:
  devid: "{{ ocpp_device_id }}"
  ocpp_key: HeartbeatInterval
  value: "60"

• delay:
  seconds: 2

• action: ocpp.configure
  data:
  devid: "{{ ocpp_device_id }}"
  ocpp_key: WebSocketPingInterval
  value: "60"

• delay:
  seconds: 2

• action: ocpp.get_configuration
  data:
  devid: "{{ ocpp_device_id }}"
  ocpp_key: HeartbeatInterval
  response_variable: heartbeat_readback

• action: ocpp.get_configuration
  data:
  devid: "{{ ocpp_device_id }}"
  ocpp_key: WebSocketPingInterval
  response_variable: websocket_readback

• action: persistent_notification.create
  data:
  title: Ocular OCPP timing
  message: |-
  Charger timing has been configured.

  HeartbeatInterval:
  {{ heartbeat_readback.value | default(heartbeat_readback) }}
  
  WebSocketPingInterval:
  {{ websocket_readback.value | default(websocket_readback) }}
  
  Both values should report 60.
  

mode: single
icon: mdi:ev-station

Then run it while the charger is online. If either result does not show 60, the charger rejected the setting or the wrong OCPP device ID was used.

One important note

On our BS-EV07 firmware, an OCPP Soft Reset changed HeartbeatInterval back to 3600. Run this script again after a Soft Reset.

This is the simplest paste-and-run version. It sets the timing values, but it should not be presented as a complete reconnect fix: our charger continued experiencing short automatic reconnects even with both values at 60.