geekabit

G2 (generation 2) charger modules can be recognized by the blue 3-pin LED connector. G3 has a 4-pin connector. A stand-alone charger module has different firmware and no CP module.

PublicLine uses the same charger modules as HomeLine. BusinessLine uses different hardware, but might use the same protocol.

Elvi G4 combines both charger and CP modules into a single (non potted) board. There is a version with metering and cellular modem, and a version without.

G5+ stations, such as Livo and Liviqo, use entirely different hardware and software.

The EV-Box ChargeStaton Tool is a software / hardware bundle to configure your own ChargePoint modules. It only works with the supplied (proprietary) USB to RS-485 adapter.

Connectors are pluggable terminal blocks, 4 pins, by Phoenix Contact.

Charger modules have male MSTBVA 2,5/ 4-G-5,08 1x4 PCB header.

CP modules have a female ICV 2,5/ 4-G-5,08 1x4 PCB header.

CP and charger module(s) communicate over an RS-485 bus. The bus is terminated on the CP module, but not on the charger module. On such a short bus this should not be a problem, and on a longer bus termination can be added at the last module. There is no bias. The bus is in multi master mode, so each module can transmit messages on the bus.

The CP module RS-485 driver uses 3V levels, while the charger module RS-485 driver uses 5V levels.

Serial baud rate is 38400bps 8N1, half-duplex.

Notes:
• EVBox supports a maximum of 20 charger modules + 1 CP module per bus.
• Maximum bus length is 1200m, using shielded twisted-pair cabling.

Except the frame start and end markers, all values are ASCII strings, containing only numbers and capital letters.

Checksum and parity values are hex encoded. Example: frame bytes 0x3341 → ASCII string "3A" → value 0x3a (hex) = 58 (decimal).

The first byte in a frame is the start of frame marker. Anything before SoF is ignored.

Value: 0x02.

Next bytes are payload. Length is flexible, between 6 and 132 bytes.

Value: ASCII-encoded string, containing only numbers and capital letters. This is described in more detail in the network layer.

Next 2 bytes are payload checksum. This is the sum of all payload bytes, discarding overflow.

Value: 2 ASCII-encoded characters, forming a hex pair, resulting in a 1 byte value.

Example code:
checksum = sum(self._payload) % 256
checksum_enc = f"{checksum:02X}".encode("ascii")


Next 2 bytes are payload parity. This is XOR over all payload bytes.

Value: 2 ASCII-encoded characters, forming a hex pair, resulting in a 1 byte value.

Example code:
parity = 0
for payload_byte in self._payload:
    parity = parity ^ payload_byte
parity_enc = f"{parity:02X}".encode("ascii")


The last 2 bytes of a frame are the end of frame marker.

Value: 0x03FF, but the Max protocol specification defines this as a single byte with value 0x03.

Notes:
• Frames with incorrect checksum or parity are ignored.
• Frames do not contain sequence numbers.
• Frames do not contain payload length.
• Shortest possible frame has a length of 13 bytes.
• Longest observed frame has a length of 145 bytes.
• Flow control is implemented as keeping the bus idle for at least 100ms between messages.

The entire packet is a string, containing only numbers and capital letters.

Addresses are hex encoded. Example: string "3A" → address 0x3a (hex) = 58 (decimal).

The first 2 characters of a packet are packet destination address.

Value: hex pair, resulting in a 1 byte destination address.

Next 2 characters are packet source address.

Value: hex pair, resulting in a 1 byte source address.

The remaining characters are application data. This is described in more detail in the application layer.

Every module has unique address.

The first 2 characters of application data are command. Some documentation refers to these as "action".

Value: hex pair, resulting in a 1 byte command.

Similar commands are grouped, indexes are 1-based. Commands 11-1F are initialization, 21-2F are initiated by charger, 31-3F are initiated by CP, 41-4F are hardware configuration, 61-6F are power management, E1-FF mostly deal with ChargeStation communication.

The remaining zero of more characters are parameters. Protocol Max documentation refers to these as "data".

Value: variable length and encoding, depending on the command. Most parameters are encoded as hex pair, but a few as string. Each command has a fixed number of parameters, with fixed encoding and length. The only way to know the correct parameter type and length is to know the protocol. Some string parameters are preceded by used length.

The first 2 or 4 bytes are usually status. Some universal states are AA00: ack, 0055: nack, 01: success.

When a parameter value is shorter than the predetermined length, it is padded with zeroes.

The number of parameter bytes sent is not included in the message. There is also no validation on the number of parameter bytes received. When too little parameter bytes are sent, the next bytes in the frame are interpreted as parameter bytes.

Most communication follows the form: request - response, but there are a few exceptions.

Response messages have the same command byte as the request message, but (usually) different parameters. There is no way of knowing if an individual message is request or response without knowing the protocol. If multiple messages with the same command byte are sent, only the last one can be responded to.

When a response is required, but not received, the request is repeated every 2 seconds.

The first thing a charger module does after boot is request an address. All charger modules start at address 0x00, and send command 11 requests to the CP, containing their serial number. The CP then sends a response containing charger module serial number and assigned bus address. From that point, normal communication can start.

All decision making is done in the CP.

This is an example of command 23 (start metering) request parameters, sent from charger to CP.

0E01 2345 6789 ABCD EF00 0000 00FF 30F2

The first 2 bytes are hex-encoded length of charge card number: 0E resulting in a length of 14 characters.

The next 22 bytes are a string, containing charge card number value, padded with zeroes: 0123456789ABCD00000000, resulting in card number 0123456789ABCD.

Last 8 bytes are hex-encoded meter value: 00FF30F2, resulting in raw value 1672421, resulting in a meter value of 16724.21kWh.

Request: sent by charger (from address 00), 15 bytes.

Response: broadcast, 11 bytes.

Example:

dst: 80 (CP)
src: 00 (new)
cmd: 11 request (register), length: 15
dat: 1917911 0125 00 03 (serial number: 1917911, firmware version: 0125, hardware generation: 03)

dst: BC (broadcast)
src: 80 (CP)
cmd: 11 response (register), length: 11
dat: 1917911 01 03 (serial number: 1917911, address: 01, gen: 03)

Notes:
• Requesting to register an address is the first thing a charger does after boot.
• No other messages are accepted by the charger until an address is assigned. Command 42 set address is accepted.
• I assume all modules initialize at address 00.
• Request without parameters results in CP sending a response with invalid checksum and parity, followed by command 13 (get meter info) request.
• Response does not need to be broadcast. Direct addressing can be used as well.
• No Response parameters can be left out, but setting last 2 bytes to 00 is accepted by charger.
• The only observed firmware version is 0125, the only observed hardware generation is 03

Request: sent by CP, 0 bytes.

Response: 64 bytes.

Example:

dst: 01 (charger)
src: 80 (CP)
cmd: 13 request (get meter info), length: 0

dst: 80 (CP)
src: 01 (charger)
cmd: 13 response (get meter info), length: 64
dat: AA00 0216 0000 0000 0000 000B ALD1 D5FS 00A0 0000 364D 3341 0000 0000 1388 2001 (model name: ALD1D5FS00A, mains frequency: 50.0Hz)

Notes:
• Value 0055 (nack) is treated as not received, so request is repeated.

Request: sent by CP, 2 bytes.

Response: none.

Example:

dst: 01 (charger)
src: 80 (CP)
cmd: 18 request (request message), length: 2
dat: 02 ()

dst: 80 (CP)
src: 01 (charger)
cmd: 26 request (charger update), length: 132
dat: 0215 0000 0000 0012 AD00 FF30 F200 000A 2EB8 2F03 F078 0008 0008 00DC 6400 0000 0000 00E2 0000 0000 0000 0000 0000 0000 03E8 0000 0000 0000 0000 0000 0000 0384 1388 (charger: idle, meter value: 16724.21kWh, temperature: 22.0°C, session: 0, voltage: 226/0/0V, current: 0.0/0.0/0.0A, power factor: 1.0/0.0/0.0, current limit: 90.0A, frequency: 50.0Hz)

Notes:
• When no charger modules have been registered at CP, request is sent as broadcast. Otherwise direct addressing is used.
• The only observed value is 02. Other values are found by experimenting.

Request: sent by CP as broadcast, 10 bytes.

Response: none.

Example:

dst: BC (broadcast)
src: 80 (CP)
cmd: 1B request (connection state changed), length: 10
dat: 0000 0384 00 ()

dst: 80 (CP)
src: 01 (charger)
cmd: 26 request (charger state update), length: 132
dat: 0215 0000 0000 0012 B000 FF30 F200 000A 2EB0 2F04 F078 0008 0008 0104 6400 0000 0000 00E2 0000 0000 0000 0000 0000 0000 03E8 0000 0000 0000 0000 0000 0000 0384 1388 (charger: idle, meter value: 16724.21kWh, temperature: 26.0°C, session: 0, voltage: 226/0/0V, current: 0.0/0.0/0.0A, power factor: 1.0/0.0/0.0, current limit: 90.0A, frequency: 50.0Hz)

Notes:
• Request is sent once CP has established backend connection.
• Request without parameters is accepted by charger.
• Request is followed by charger sending command 26 charger status update request.

Request: sent by CP as broadcast, 0 bytes.

Response: none.

Example:

dst: BC (broadcast)
src: 80 (CP)
cmd: 1E request (restart registration), length: 0

dst: 80 (CP)
src: 00 (new)
cmd: 11 request (register), length: 15
dat: 1917911 0125 00 03 (serial number: 1917911, firmware version: 0125, hardware generation: 03)

Notes:
• Request results in charger setting it's address to 00 and sending an command 11 register request. All settings are preserved.
• Request is the first message CP sends after boot.
• Request does not need to be broadcast. Direct addressing can be used as well.

Request: sent by charger, 0 bytes.

Response: 0 bytes.

Example:

dst: 80 (CP)
src: 01 (charger)
cmd: 21 request (heartbeat), length: 0

dst: 01 (charger)
src: 80 (CP)
cmd: 21 response (heartbeat), length: 0

Notes:
• Request is sent at 16 minute interval.

Request: sent by charger, 26 bytes.

Response: 30 bytes.

Example:

dst: 80 (CP)
src: 01 (charger)
cmd: 22 request (card authentication request), length: 26
dat: 000E xxxx xxxx xxxx xx00 0000 00 (authentication request, card number: xxxxxxxxxxxxxx)
dat: 0008 0000 00AS 0000 0000 0000 00 (authentication request, auto start)

dst: 01 (charger)
src: 80 (CP)
cmd: 22 response (card authentication request), length: 30
dat: 010E xxxx xxxx xxxx xx00 0000 00FF FF (access granted, card number: xxxxxxxxxxxxxx)
dat: 120E xxxx xxxx xxxx xx00 0000 00FF FF (access denied, card number: xxxxxxxxxxxxxx)
dat: 0300 0000 0000 0000 0000 0000 00FF FF (not connected to backend)

Notes:
• Request is sent after scanning RFID charge card or, when auto start is enabled, after plugging in EV.
• Auto start uses "card number" 000000AS.
• Response is followed by charger sending command 6A charging state.

Request: sent by charger, 32 bytes.

Response: 18 bytes.

Example:

dst: 80 (CP)
src: 01 (charger)
cmd: 23 request (metering start), length: 32
dat: 0Exx xxxx xxxx xxxx 0000 0000 00FF 30F2 (card number: xxxxxxxxxxxxx, meter value: 16724.21kWh)

dst: 01 (charger)
src: 80 (CP)
cmd: 23 response (metering start), length: 18
dat: 0100 0000 002E 7C41 F5 (session: 0, timestamp: 2024-09-17 13:34:45)

# a few seconds later

dst: 01 (charger)
src: 80 (CP)
cmd: 23 response (metering start), length: 18
dat: 0100 C079 EA2E 7C41 F9 (session: 12614122, timestamp: 2024-09-17 13:34:49)

Notes:
• Request follows on CP sending command 6B start charging.
• Request without parameters is accepted by CP.
• Request gets two responses. The first response has Session id 0, in the second response it has a value.
• Omitting the second response is accepted by charger.
• Response is followed by charger sending a command 26 status update request.

Request: sent by charger, 50 bytes.

Response: 2 bytes.

Example:

dst: 80 (CP)
src: 01 (charger)
cmd: 24 request (metering end), length: 50
dat: 0Exx xxxx xxxx xxxx 0000 0000 00FF 3156 00C0 79EA 392E 7C44 49 (card number: xxxxxxxxxxxxxx, meter value: 16724.31kWh, session: 12614122, timestamp: 2024-09-17 13:44:41)

dst: 01 (charger)
src: 80 (CP)
cmd: 24 response (metering end), length: 2
dat: 01 ()

Notes:
• Request is sent after unplugging EV.
• Request is sent after stopping session from charger (Harm Otten)
• Request without parameters is accepted by CP.
• Response without parameters is accepted by charger.
• Response results in charger sending command 6A charging state.

Request: sent by charger, 132 bytes.

States: 02 (idle) → 47 (starting) → 4A (not charging) → 48 (charging) → 4A (not charging) → 4B (finished) → 02 (idle)

Response: 16 bytes.

Example:

dst: 80 (CP)
src: 01 (charger)
cmd: 26 request (charger state update), length: 132
dat: 4815 0001 0401 2012 A900 FF5B 180C 1C0C 2E98 17D4 2F2F 0010 000F 0136 2100 C23E 5901 00DE 0000 0000 0532 0000 0000 0000 03E8 0000 0000 0000 0000 0000 0000 00C8 1388 (charger: charging, meter value: 16735.0kWh, temperature: 31.0°C, session: 12729945, voltage: 222/0/0V, current: 13.3/0.0/0.0A, power factor: 1.0/0.0/0.0, current limit: 20.0A, frequency: 50.0Hz)

dst: 01 (charger)
src: 80 (CP)
cmd: 26 response (charger state update), length: 16
dat: 00C2 3E59 2E84 3391 (session: 12729945, timestamp: 2024-09-23 14:11:29)

Notes:
• Response timestamp is set to 0 when CP is not connected to backend.
• Response with session set to 0 is accepted by charger.
• There does not seem to be a difference between the command 26 message sent after EV plugged in, but not authenticated yet, and authenticated, but not plugged in yet.
• During charging session (from metering start to metering end) command 26 update is sent at a configurable interval.

Request: sent by CP, 0 bytes.

Response: 74 bytes.

Example:

dst: 01 (charger)
src: 80 (CP)
cmd: 33 request (get configuration), length: 0

dst: 80 (CP)
src: 01 (charger)
cmd: 33 response (get configuration), length: 74
dat: 0000 003C 0000 0384 0000 0384 0300 0001 0100 1E01 0000 0000 0000 0000 0000 0000 0000 03E8 01 (led brightness: 30%, command 26 interval: 900s, auto start: 0, remote start: 0)

Notes:

Request: sent by CP, 86 bytes.

Response: 4 bytes.

Example:

dst: 01 (charger)
src: 80 (CP)
cmd: 34 request (set configuration), length: 86
dat: 03A3 F781 1E03 0000 0101 0001 0000 0000 0000 0000 0000 0000 3C00 0003 8400 0003 8400 0000 0000 03E8 0100 00 (led brightness: 30%, command 26 interval: 900s, auto start: 0, remote start: 0)

dst: 80 (CP)
src: 01 (charger)
cmd: 34 response (set configuration), length: 4
dat: AA00 (ack)

Notes:
• I assume the mask is to indicate which of the many values have been changed, and which have not.
• Values that would probably be in there are: default charging delay, amount of connectors, led idle state, led idle time on, led idle time off, external current loss, smart charge pause, accept remote start, auto start, auto stop, auto stop when offline, EV reconnect charge, and some others.
• Response without parameters results in CP sending a command 33 request.

Request: sent by SmartGrid.

Notes:
• Explained in Max protocol specification.

Request: sent by SmartGrid.

Notes:
• Explained in Max protocol specification.

Request: sent by charger, 4 bytes.

States: A0 (idle) → A7 (starting) → 81 (started) → C1 (finished) → 80 (unplugged) → A0 (idle)

Response: 4 bytes.

Example:

dst: 80 (CP)
src: 01 (charger)
cmd: 6A request (charging mode), length: 4
dat: A03C (state: charger idle)

dst: 01 (charger)
src: 80 (CP)
cmd: 6A response (charging mode), length: 4
dat: AA00 (ack)

Notes:
• Request without parameters is accepted by CP.

Request: sent by CP, 18 bytes.

Response: 0 bytes.

Example:

dst: 01 (charger)
src: 80 (CP)
cmd: 6B request (set current limit), length: 18
dat: 0100 3C00 A000 A000 A0 (current min: 6.0A, current limit: 16.0/16.0/16.0A)

dst: 80 (CP)
src: 01 (charger)
cmd: 6B response (set current limit), length: 0

Notes:
• Request is sent when charging has started or ended.
• Request follows on command 6A charging state.
• Response is followed by charger sending a command 23 metering start request.
• This command also acts as "start charging".
• There might be 3 current limits for 3 phases, but command 23 only returns a single one.
• Request without parameters is accepted by charger.

Request: sent by CP as broadcast, 2 bytes.

Response: ??

Notes:
• Mentioned by Harm Otten
• LED ring dimming is possible using command 34 set configuration.

Request: sent by charger.

Response:

Example:

dst: 80 (CP)
src: 01 (charger)
cmd: 2A request (unknown), length: 0

dst: 02 (unknown)
src: 80 (CP)
cmd: 2A response (unknown), length: 0

Notes:

Request: sent by CP, from back office, 24 bytes.

Response: 2 bytes.

Example:

dst: 01 (charger)
src: 80 (CP)
cmd: 31 request (remote start), length: 24
dat: 0Exx xxxx xxxx xxxx 0000 0000 (card number: xxxxxxxxxxxxxx)

Notes:
• Mentioned by Harm Otten

Request: sent by CP, from back office, 8 bytes.

Response: 2 bytes.

Notes:
• Mentioned by Harm Otten

Request: sent by CP as broadcast, 2 bytes.

Observed status values are 52 and 3F.

Response: none.

Example:

dst: BC (broadcast)
src: 80 (CP)
cmd: 35 request (reboot), length: 2
dat: 52 (unknown)

Notes:
• Mentioned by to Harm Otten.
• Does not work for me.

Request: sent by CP, 0 bytes.

Response: 2 bytes.

Example:

dst: 01 (charger)
src: 80 (CP)
cmd: 36 request (unknown 36), length: 0

dst: 80 (CP)
src: 01 (charger)
cmd: 36 response (unknown 36), length: 2
dat: 23 ()

dst: 80 (CP)
src: 01 (charger)
cmd: 26 request (charger state update), length: 132
dat: 0215 0000 0100 0012 A000 FF75 4400 000A 2EB8 2F02 F078 0008 0008 00DC 6400 0000 0000 00E4 0000 0000 0000 0000 0000 0000 03E8 0000 0000 0000 0000 0000 0000 0384 1388 (charger: idle, meter value: 16741.7kWh, temperature: 22.0°C, session: 0, voltage: 228/0/0V, current: 0.0/0.0/0.0A, power factor: 1.0/0.0/0.0, current limit: 90.0A, frequency: 50.0Hz)

Notes:
• Response is followed by charger sending a command 26 status update.

Request: sent by CP, 0 bytes.

Response: 2 bytes.

Example:

dst: 01 (charger)
src: 80 (CP)
cmd: 37 request (unknown 37), length: 0

dst: 80 (CP)
src: 01 (charger)
cmd: 37 response (unknown 37), length: 2
dat: 16 (unknown)

Notes:

Request: sent by CP, 0 bytes.

Response: 2 bytes.

Example:

dst: 01 (charger)
src: 80 (CP)
cmd: 38 unknown (unknown), length: 0

dst: 80 (CP)
src: 01 (charger)
cmd: 38 unknown (unknown), length: 2
dat: 02 (unknown)

Notes:

Request: sent by both CP and charger, 0 bytes.

Response: either 54 or 2 bytes.

Example sent to charger:

dst: 01 (charger)
src: 80 (CP)
cmd: 41 unknown (unknown 41), length: 0

dst: 80 (CP)
src: 01 (charger)
cmd: 41 unknown (unknown 41), length: 54
dat: 0100 0008 0008 2EBA 129A 08FC F87F 00BE 0375 4430 4203 3030 3032 45 ()
dat: 0100 0008 0008 2EB8 12A0 2F03 F078 00DC 0375 4430 4203 3237 4503 30 ()

Example sent to CP:

dst: 80 (CP)
src: 01 (charger)
cmd: 41 unknown (unknown), length: 0

dst: FD (ChargeStation)
src: 80 (CP)
cmd: 41 unknown (unknown), length: 2
dat: 37 ()

Notes:
• This is probably another system info / hardware info command.
• If request is sent by charger, CP sends request to ChargeStation.

Request: sent by CP, 7 bytes.

Response: 7 bytes.

Example:

dst: BC (broadcast)
src: 80 (CP)
cmd: 42 request (set serial number), length: 7
dat: 1917 911 (serial number: 1917911)

dst: 80 (CP)
src: 00 (new)
cmd: 42 response (set serial number), length: 7
dat: 1917 911 (serial number: 1917911)

Notes:
• Request without parameters is accepted by charger. This results in setting serial number 2F0F\x0300 (which is request checksum, parity, EoF, padded with 0).
• Request can be sent during address negotiation.
• Response is sent from address 00, but charger keeps its address.

Request: sent by ChargeStation, 0 bytes.

Response: 18 bytes.

Example:

dst: 01 (charger)
src: 80 (CP)
cmd: 43 request (hardware info), length: 0

dst: FD (ChargeStation)
src: 01 (charger)
cmd: 43 response (hardware info), length: 18
dat: 03 0125 01 004C 0D04 2C (hardware generation: 03, firmware version: 0125)

Notes:
• Response is sent to ChargeStation, regardless of source address.
• Remaining values might include number of phases, type of relay, type of cable, etc.

Request: sent by charger, 4 bytes.

Response: none

Example:

dst: 01 (charger)
src: 80 (CP)
cmd: 65 request (set meter update interval), length: 4
dat: 003C (interval: 60s)

dst: 80 (CP)
src: 01 (charger)
cmd: 66 request (meter value), length: 44
dat: 00E6 0000 0000 0000 0000 0000 03E8 0000 0000 00FF 7544 (voltage: 230/0/0V, current: 0.0/0.0/0.0A, power factor: 1.0/0.0/0.0, meter value: 16741.7kWh)

Notes:
• Value 0 disables update interval.

Request: sent by charger, 44 bytes.

Response: 0 bytes.

Example:

dst: 80 (CP)
src: 01 (charger)
cmd: 66 request (meter value), length: 44
dat: 00E6 0000 0000 0000 0000 0000 03E8 0000 0000 00FF 7544 (voltage: 230/0/0V, current: 0.0/0.0/0.0A, power factor: 1.0/0.0/0.0, meter value: 16741.7kWh)

dst: 01 (charger)
src: 80 (CP)
cmd: 66 response (meter value), length: 0

Notes:

Request: sent by CP.

Response: 2 bytes.

Example:

dst: 01 (charger)
src: 80 (CP)
cmd: 6C request (unknown 6C), length: 0

dst: 80 (CP)
src: 01 (charger)
cmd: 6C response (unknown 6C), length: 2
dat: 23 ()

Notes:

Request: sent by CP.

Response: none

Example:

dst: 01 (charger)
src: 80 (CP)
cmd: E0 unknown (unknown), length: 4
dat: 0100 (unknown)

Notes:

Request: sent by CP.

Response:

Example:

dst: 80 (CP)
src: 01 (charger)
cmd: E1 response (unknown), length: 0

dst: 70 (unknown)
src: 80 (CP)
cmd: E6 request (unknown), length: 0

Notes:
• Response is followed by CP sending command E6 request to address 70, regardless of source address.

Request: sent by charger.

Response: none.

Example:

dst: 80 (CP)
src: 01 (charger)
cmd: E3 request (reboot), length: 0

dst: BC (broadcast)
src: 80 (CP)
cmd: 1E request (restart registration), length: 0

Notes:
• Request results in CP rebooting.

Request: sent by address 70.

Response: 4 bytes.

Example:

dst: 80 (CP)
src: 01 (charger)
cmd: E4 request (unknown), length: 0

dst: 70 (unknown)
src: 80 (CP)
cmd: E4 response (unknown), length: 4
dat: AA00 (ack)

Notes:
• Response is sent to address 70, regardless of source address.

Request: sent by CP.

Response:

Example:

dst: 80 (CP)
src: 01 (charger)
cmd: E1 response (unknown), length: 0

dst: 70 (unknown)
src: 80 (CP)
cmd: E6 request (unknown), length: 0

Notes:
• Request follows on E1 response.

Request: sent by charger.

Response: 8 bytes.

Example:

dst: 80 (CP)
src: 01 (charger)
cmd: EB request (unknown), length: 0

dst: FD (ChargeStation)
src: 80 (CP)
cmd: EB response (unknown), length: 8
dat: 0134 0125 (unknown)

dst: BC (broadcast)
src: 80 (CP)
cmd: 1B request (connection state changed), length: 10
dat: 0000 0384 00 ()

Notes:
• Response is sent to ChargeStation, regardless of source address.
• Response is followed by CP broadcasting command 1B connection state changed request.

Request: sent by charger.

Response:

Example:

dst: 80 (CP)
src: 01 (charger)
cmd: EC request (unknown), length: 0

dst: FD (ChargeStation)
src: 80 (CP)
cmd: EC response (unknown), length: 0

dst: FD (ChargeStation)
src: 80 (CP)
cmd: ED request (unknown), length: 2
dat: 08 (unknown)

Notes:
• Response is sent to ChargeStation, regardless of source address.
• Response is followed by CP sending command ED request to ChargeStation.

Request: sent by CP.

Response:

Example:

dst: FD (ChargeStation)
src: 80 (CP)
cmd: ED request (unknown), length: 2
dat: 08 (unknown)

Notes:
• Request follows on command EC response.
• Request is sent to ChargeStation.

Request: sent by ChargeStation.

Response: 102 bytes.

Example initiated by charger:

dst: 80 (CP)
src: 01 (charger)
cmd: F0 request (unknown), length: 0

dst: FD (ChargeStation)
src: 80 (CP)
cmd: F0 response (unknown), length: 102
dat: 407C 30FF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FF ()

Example initiated by CP:

dst: 01 (charger)
src: 80 (CP)
cmd: F0 request (unknown), length: 0

dst: FD (ChargeStation)
src: 01 (charger)
cmd: F0 response (unknown), length: 102
dat: 3F7F 30FF 2ABF 66E9 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FF (unknown)

Notes:
• Response is sent to ChargeStation, regardless of source address.

Request: sent by ChargeStation.

Response: 6 bytes.

Example initiated by CP:

dst: 01 (charger)
src: 80 (CP)
cmd: F1 request (unknown), length: 0

dst: FD (ChargeStation)
src: 01 (charger)
cmd: F1 response (unknown), length: 6
dat: 407E 30 (unknown)

Example initiated by charger:

dst: 80 (CP)
src: 01 (charger)
cmd: F1 request (unknown F1), length: 0

dst: FD (ChargeStation)
src: 80 (CP)
cmd: F1 response (unknown F1), length: 6
dat: 417D 30 ()

Notes:
• Response is sent to ChargeStation, regardless of source address.

Request: sent by ChargeStation.

Response:

Example:

dst: 80 (CP)
src: 01 (charger)
cmd: F2 request (unknown), length: 0

dst: FD (ChargeStation)
src: 80 (CP)
cmd: F2 response (unknown), length: 0

Notes:
• Response is sent to ChargeStation, regardless of source address.

Request: sent by ChargeStation.

Response: 10 bytes.

Example:

dst: 80 (CP)
src: 01 (charger)
cmd: F3 request (unknown), length: 0

dst: FD (ChargeStation)
src: 80 (CP)
cmd: F3 response (unknown), length: 10
dat: 437F 3000 00 (unknown)

Notes:
• Response is sent to ChargeStation, regardless of source address.

Request: sent by ChargeStation.

Response: 10 bytes.

Example:

dst: 80 (CP)
src: 01 (charger)
cmd: F4 request (unknown), length: 0

dst: FD (ChargeStation)
src: 80 (CP)
cmd: F4 response (unknown), length: 10
dat: 4478 3000 00 (unknown)

Notes:
• Response is sent to ChargeStation, regardless of source address.

Request: sent by ChargeStation.

Response:

Example:

dst: 80 (CP)
src: 01 (charger)
cmd: F5 response (unknown), length: 0

dst: 80 (CP)
src: 01 (charger)
cmd: F6 request (unknown), length: 0

Notes:
• Response is followed by CP sending command F6 request to ChargeStation.

Request: sent by ChargeStation.

Response: none.

Example:

dst: 80 (CP)
src: 01 (charger)
cmd: F6 request (reboot), length: 0

dst: BC (broadcast)
src: 80 (CP)
cmd: 1E request (restart registration), length: 0

Notes:
• Request follows on command F5 response.
• Request results in CP rebooting.

Request: sent by ChargeStation.

Response:

Example:

dst: 80 (CP)
src: 01 (charger)
cmd: F7 request (unknown), length: 0

dst: FD (ChargeStation)
src: 80 (CP)
cmd: F7 response (unknown), length: 0

Notes:
• Response is sent to ChargeStation, regardless of source address.

Request: sent by ChargeStation.

Response: 122 bytes.

Example:

dst: 80 (CP)
src: 01 (charger)
cmd: F8 request (unknown), length: 0

dst: FD (ChargeStation)
src: 80 (CP)
cmd: F8 response (unknown), length: 122
dat: 4874 330D 38FF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FF (unknown)

Notes:
• Response is sent to ChargeStation, regardless of source address.

Request: sent by ChargeStation.

Response: 10 bytes.

Example:

dst: 80 (CP)
src: 01 (charger)
cmd: F9 request (unknown), length: 0

dst: FD (ChargeStation)
src: 80 (CP)
cmd: F9 response (unknown), length: 10
dat: 4975 330D 38 (unknown)

Notes:
• Response is sent to ChargeStation, regardless of source address.

Request: sent by ChargeStation.

Response:

Example:

dst: 80 (CP)
src: 01 (charger)
cmd: FA request (unknown), length: 0

dst: FD (ChargeStation)
src: 80 (CP)
cmd: FA response (unknown), length: 0

Notes:
• Response is sent to ChargeStation, regardless of source address.

Request: sent by ChargeStation.

Response:

Example:

dst: 80 (CP)
src: 01 (charger)
cmd: FB request (unknown), length: 0

dst: FD (ChargeStation)
src: 80 (CP)
cmd: FB response (unknown), length: 0

dst: BC (broadcast)
src: 80 (CP)
cmd: 35 request (reboot), length: 2
dat: 52 (unknown)

Notes:
• Response is sent to ChargeStation, regardless of source address.
• Request results in CP broadcasting command 35 (reboot) request.

Request: sent by ChargeStation.

Response: none.

Example:

dst: 80 (CP)
src: 01 (charger)
cmd: FD request (unknown), length: 0

dst: BC (broadcast)
src: 80 (CP)
cmd: 1E request (restart registration), length: 0

Notes:
• Request results in CP rebooting.