ABB Terra AC wallbox EV charger
Register map(s) for this device, each at the trust rung it earned. Addresses are 0-based
as on the wire. Word order and scaling are confirmed at the hardware-verified rung and at no rung below it.
interop-verified
Read + decoded cleanly over a real network vs an independent third-party Modbus test server (transport and framing; reads are remapped into the server's register window, so the map's own addresses are NOT exercised). Does NOT prove word order/scaling against the actual device.
| point | address (0-based) | type | scale | unit |
| firmware_version | 16388 | U32BE | 1 | |
| user_settable_max_current | 16390 | U32BE | 0.001 | A |
| error_code | 16392 | U32BE | 1 | |
| socket_lock_state | 16394 | U32BE | 1 | |
| charging_state | 16396 | U32BE | 1 | |
| charging_current_limit | 16398 | U32BE | 0.001 | A |
| charging_current_l1 | 16400 | U32BE | 0.001 | A |
| charging_current_l2 | 16402 | U32BE | 0.001 | A |
| charging_current_l3 | 16404 | U32BE | 0.001 | A |
| voltage_l1 | 16406 | U32BE | 0.1 | V |
| voltage_l2 | 16408 | U32BE | 0.1 | V |
| voltage_l3 | 16410 | U32BE | 0.1 | V |
| active_power | 16412 | U32BE | 1 | W |
| energy_delivered | 16414 | U32BE | 1 | Wh |
| communication_timeout_read | 16416 | U16 | 1 | second |
| set_charging_current_limit | 16640 | U32BE | 0.001 | A |
| lock_unlock_socket_cable | 16643 | U16 | 1 | |
| start_stop_charging_session | 16645 | U16 | 1 | |
| communication_timeout_write | 16646 | U16 | 1 | second |
link settings as documented (unverified): RTU/TCP; baud 4800/9600/19200/38400/57600/115200; FC 03,06,16; Recommended polling interval for readable data is 30s~90s.
⚠ In case of unhealthy, charger could get into error state and stop the charging session. — Starkest reads only; we never write a control register.
bench facts as documented (unverified)
| connector | RS485 and TCP/IP |
| wiring notes | Many chargers could be daisy chained by wiring as a serial line. |
| protocol notes | Based on the polling operation (at least read a register) and configurable timeout period, charger could understand whether Modbus communication is healthy or not. |
| serial register | 4000h |
| firmware register | 4004h |
| certifications | IEC 61851-1 |
| doc revision | 1.7 |
field reports — community-sourced, unverified (checked 2026-06-11)
- Modbus TCP/IP is not supported over WiFi; the charger must be connected via a physical Ethernet cable to use Modbus TCP. [source]
- Modbus TCP/IP is not supported on basic CE models of the Terra AC wallbox that do not have an LCD display; these models only support Modbus RTU over RS485 directly. [source]
- Polling the charger too frequently (e.g., less than 5 seconds) can overload the charging station and cause it to reset itself. [source]
- A firmware bug previously caused the fallback limit to reset to a hardcoded 6A after triggering an invalid value. [source]
- When Modbus TCP/IP is enabled, the Ethernet port is dedicated to Modbus communication and cannot be used for general internet access (such as OCPP to ABB cloud). [source]
- If the charger does not receive Modbus messages within the configured 'Communication Timeout' period (default 60s), it will stop charging. Users must set this to a higher value or ensure periodic polling. [source]
- confirmed: Baud rates [4800, 9600, 19200, 38400, 57600, 115200] and framing [RTU, TCP] — confirmed by ABB installation manual and 'TAC Modbus Communication' document
- confirmed: Modbus register map (including firmware_version @ 16388, set_charging_current_limit @ 16640, and start_stop_charging_session @ 16645) — confirmed by ABB 'TAC Modbus Communication' document and Home Assistant integration repositories
- confirmed: Recommended polling interval of 30s~90s — confirmed by ABB 'TAC Modbus Communication' document
- confirmed: Quirks and control warning regarding unhealthy communication causing error state — confirmed by ABB 'TAC Modbus Communication' document
The trust ladder
Each rung states what it proved and what it did not. Gray until proven; green is earned by hardware only.
- generated — A prompt produced it. Unproven — anyone can regenerate this.
- structure-verified — Decode path is structurally sound (addresses, widths, finite values). Does NOT prove word order or scaling.
- interop-verified — Read + decoded cleanly over a real network vs an independent third-party Modbus test server (transport and framing; reads are remapped into the server's register window, so the map's own addresses are NOT exercised). Does NOT prove word order/scaling against the actual device.
- simulator-verified — Decoded correctly against a protocol emulator seeded with known-true values — catches word-order/scaling errors vs the emulator, not the physical device.
- hardware-verified x1 — Matched a real device with operator-attested readings as ground truth — the only rung that confirms word order + scaling on the wire.