Bender AbstractEvseChargePointBender
The Bender AbstractEvseChargePointBender template targets AC EV charging stations and wallboxes built around Bender charge controllers such as the CC612 and CC613. These controllers act as the central brain of a charging point, communicating with the vehicle, the OCPP backend, and an energy management system via Modbus TCP. This template reads OCPP charge point status, vehicle connection state, cumulative session energy, and minimum and maximum current limits, plus the three-part firmware version. It gives facility managers and installers a live view of each charge point from the ModbusCloud portal without additional hardware.
- Protocol
- Modbus TCP
- Connection
- Ethernet, Modbus TCP
- Registers
- 8, read only
- Brand
- Bender
- Last updated
Registers (8)
8 read, 0 write
| Name | Unit | Access | Address (Hidden until you enter your email) | Function (hidden) | Type (hidden) |
|---|---|---|---|---|---|
| ocpp_cp_status | Read | ||||
| vehicle_state | Read | ||||
| software_version_major | Read | ||||
| software_version_minor | Read | ||||
| software_version_patch | Read | ||||
| active_production_energy | Wh | Read | |||
| min_current | A | Read | |||
| max_current | A | Read |
Loading registers…
Send your device list
If a device is not in the library yet, we build the template for free as soon as we have the register data.
Use cases
- Monitor OCPP charge point status in real time to detect unexpected fault or unavailable states across a site.
- Track cumulative session energy per charge point to verify billing accuracy and spot energy anomalies.
- Alert on vehicle_state changes to confirm a vehicle has connected or disconnected from an expected schedule.
- Compare min_current and max_current registers across charge points to verify consistent load management configuration.
- Log firmware version registers to confirm that all Bender controllers on a site run the same software release.
Installation
Enable the Modbus TCP server on the Bender charge controller by opening its web interface and navigating to the HEMS or Modbus section, then set the Modbus TCP server port to 502 and save the configuration.
Connect the Bender charge controller to the same LAN segment as the ModbusCloud Gateway using a standard Ethernet cable, and confirm the controller has a reachable static or DHCP-reserved IP address.
In your ModbusCloud portal, add a new device, import the Bender AbstractEvseChargePointBender template, enter the controller IP address and port 502, and assign unit ID 1 for the first connector.
Verify the connection by reading register 104 in the live data view and confirming the returned OCPP status code matches the charge point state shown on the controller web interface.
Things to watch for
Why does register 104 always return zero even when a vehicle is connected?
Register 104 reflects the OCPP charge point status as defined in the OCPP version the controller is running. If the controller is not yet connected to an OCPP backend or is still booting, the status may read zero. Confirm the controller has completed its boot sequence, the READY LED is active, and the OCPP backend connection is established before polling.
The gateway connects but all register values appear as 0xFFFF. What now?
A value of 0xFFFF (or 0xFFFFFFFF for 32-bit registers) indicates the controller cannot return a valid reading for that register, which is the documented unavailable sentinel. Check that a meter is configured and connected in the controller operator interface, and that the Modbus TCP server is enabled under the HEMS or Modbus section of the web interface.
Energy register 200 reads a value that seems too large. Is the scaling correct?
Register 200 is a 32-bit unsigned value and stores energy in Wh with no additional scaling factor. The two 16-bit words are ordered high word first, low word second. Ensure your Modbus client assembles the word pair as (register 200 high word) followed by (register 201 low word), then reads the result as a single uint32 in Wh.
The gateway cannot reach the Bender controller over TCP. How do I diagnose this?
Confirm the controller and the ModbusCloud Gateway are on the same LAN segment or that routing is in place. Verify the Modbus TCP server is set to port 502 in the controller HEMS settings. Check that no firewall rule on the network switch blocks port 502. If a second connector is present on the same master controller, it is accessible on port 503, not 502.
Want to see how it works?
