geekabit

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-20 are initialization, 21-30 are initiated by charger, 31-40 are initiated by CP, 61-70 are power management, E1-FF deal with addresses 70 and FD.

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.

Notes:
• Shorter values are padded with "0" to predetermined length.
• Identification numbers (charger serial number, card number) are usually sent as string.
• The first 2 or 4 bytes are usually status. Status AA00 = ack, 0055 = nack.
• Parameter length is not present in the packet.
• There is no validation on the number of parameter bytes or their contents.

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 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

All command 23 requests start with 0E, which I assume is a status byte.

The next 22 bytes are a string, containing charge card number: 0123456789ABCDEF000000.

Last 8 bytes are meter value: 00FF30F2. This is hex encoded value 1672421, which is value * 100, resulting in actual meter value of 16724.21kWh.

Request sent by: charger (from address 00).

Response: broadcast

Example:

dst: 80 (CP)
src: 00 (new)
cmd: 11 request (request for address), length: 15
dat: 1917911 0125 0003 (serial number: 1917911)

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

Notes:
• Requesting an address is the first thing a charger does after boot.
• No other messages are accepted by the charger until an address is assigned.
• 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 read some values 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.

Request sent by: CP, 0 bytes.

Response:

Example:

dst: 01 (charger)
src: 80 (CP)
cmd: 13 request (read some values), length: 0

dst: 80 (CP)
src: 01 (charger)
cmd: 13 response (read some values), length: 64
dat: AA00 0216 0000 0000 0000 000B ALD1 D5FS 00A0 0000 364D 3341 0000 0000 1388 2001 ()

Notes:
• Response has only observed parameter with non-hex characters.
• Value 1388 occurs in command 26 as well.

Request sent by: CP.

Response: none.

Example:

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

dst: 80 (CP)
src: 01 (charger)
cmd: 26 request (charger state update), length: 132
dat: 0215 0000 0000 0012 A800 FF30 F200 000A 2EB0 2F04 F078 0008 0008 0104 6400 0000 0000 00DE 0000 0000 0000 0000 0000 0000 03E8 0000 0000 0000 0000 0000 0000 0384 1388 (charger: idle, meter: 16724.21kWh, temperature: 26.0°C, session: 0, voltage: 222V, current: 0.0A, limit: 90.0A)

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

Request sent by: CP as broadcast.

Response: none.

Example:

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

Notes:
• Request is sent once CP has established backend connection.
• Request parameter could be baud rate.
• Request without parameters is accepted by charger.

Request sent by: CP as broadcast, 0 bytes.

Response: none.

Example:

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

dst: 80 (CP)
src: 00 (new)
cmd: 11 request (request for address), length: 15
dat: 1917911 0125 0003 (serial number: 1917911)

Notes:
• Request results in charger rebooting.
• 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 every 16 minutes.

Request sent by: charger.

Response:

Example:

dst: 80 (CP)
src: 01 (charger)
cmd: 22 request (card authentication request), length: 26
dat: 000E xxxx xxxx xxxx xxxx xxxx xx (authentication request, card: xxxxxxxxxxxxxxxxxxxxxx)

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

Notes:
• Request is sent after scanning RFID charge card.
• Request parameters can be left out. Response is state 1D.
• Response parameters can be truncated to 4 bytes, of which only first 2 bytes are used.
• Response card number is set to 0 when CP is not connected to backend.
• Response is followed by charger sending command 6A charging state.

Request sent by: charger.

Response:

Example:

dst: 80 (CP)
src: 01 (charger)
cmd: 23 request (metering start), length: 32
dat: 0Exx xxxx xxxx xxxx xxxx xxxx 00FF 30F2 (card: xxxxxxxxxxxxxxxxxxxxxx, meter: 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.

Response:

Example:

dst: 80 (CP)
src: 01 (charger)
cmd: 24 request (metering end), length: 50
dat: 0Exx xxxx xxxx xxxx xxxx xxxx 00FF 3156 00C0 79EA 392E 7C44 49 (card: xxxxxxxxxxxxxxxxxxxxxx, meter: 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.

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

Response:

Example:

dst: 80 (CP)
src: 01 (charger)
cmd: 26 request (charger state update)
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: 16735.0kWh, temperature: 31.0°C, session: 12729945, voltage: 222V, current: 13.3A, limit: 20.0A)

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

Notes:
• Request parameters could include: multi-phase voltage, current, cos phi.
• Response timestamp is set to 0 when CP is not connected to backend.
• Response with session set to 0 is accepted by charger.
• Value 1388 also occurs in command 13 (read some values).
• Value 03E8 also occurs in command 33 (get configuration) and 34 (set configuration).
• 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 every 15 minutes.

Request sent by: CP, 0 bytes.

Response:

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 ()

Notes:
• Parameters could include baud rate.
• Value 03E8 also occurs in command 26 (status update) and 34 (set configuration).

Request sent by: CP.

Parameters for dimming are: 3000 0000 vv, with vv is value in percent. (Harm Otten)

Other observed parameters: 0003 C000 0000 0001 0100 0000 0000 0000 (Harm Otten)

Response:

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 ()

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

Notes:
• Request without parameters is accepted by charger. I don't know what the effect of that is though.
• Response without parameters results in CP sending a command 33 request.
• Value 03E8 also occurs in command 26 (status update) and 34 (get configuration).
• Parameters could include baud rate.

Request sent by: SmartGrid.

Notes:
• Explained in Max protocol specification.

Request sent by: SmartGrid.

Notes:
• Explained in Max protocol specification.

Request sent by: charger.

Flow: A0 (idle) → EV plugged in + authenticated → A7 (starting) → 81 (charging) → C1 (finished) → EV unplugged → 80 (unplugged) → A0 (idle)

Response:

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.

Response: 0 bytes.

Example:

dst: 01 (charger)
src: 80 (CP)
cmd: 6B request (set current limit), length: 18
dat: 0100 3C00 C800 C800 C8 (current limit: 20.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 always 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.
• Initial current limit is only for the first 2 minutes of the charging session (Harm Otten).
• Request without parameters is accepted by charger.

Request sent by: CP as broadcast.

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.

Response:

Example:

dst: 01 (charger)
src: 80 (CP)
cmd: 31 request (remote start), length: 0

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

Notes:
• Found by experimenting, also mentioned by Harm Otten
• Request without parameters is accepted by charger.
• Request results in charger sending command 6A charging state.

Request sent by: CP, from back office.

Response:

Notes:
• Mentioned by Harm Otten

Request sent by: CP as broadcast.

Observed P1 values are 52 and 3F.

Response: none.

Example:

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

Notes:
• Request results in charger rebooting?
• Request follows on command FB.
• Found by experimenting, also mentioned by Harm Otten

Request sent by: charger.

Response: 132 bytes.

Example:

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

dst: 80 (CP)
src: 01 (charger)
cmd: 26 request (charger state update), length: 132
dat: 0215 0000 0100 0012 9D00 FF75 4400 000A 2EBA 2F00 F078 0008 0008 00BE 6400 0000 0000 00E6 0000 0000 0000 0000 0000 0000 03E8 0000 0000 0000 0000 0000 0000 0384 1388 (charger: idle, meter: 16741.7kWh, temperature: 19.0°C, session: 0, voltage: 230V, current: 0.0A, limit: 90.0A)

Notes:

Request sent by: CP and charger.

Response: ??

Example initiated by 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 ()

Example initiated by CP:

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

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

Notes:
• If request is sent by charger, CP sends request to address FD.

Request sent by: CP.

Response:

Example:

dst: 01 (charger)
src: 80 (CP)
cmd: 42 request (set serial number), length: 0

dst: 80 (CP)
src: 00 (new)
cmd: 42 response (set serial number), length: 7
dat: 2F0F?00 (serial number: 2F0F?00))

Notes:
• Request without parameters results in setting serial number 2F0F\x0300 (which is request checksum, parity, EoF, padded with 0). This could seriously ruin your day.
• Response is sent from address 00, but charger keeps its earlier address.

Request sent by: ??

Response: ??

Example:

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

start of frame marker not found in data: b"\x92\x1a\xc1276\x03\xff"

Notes:

Request sent by: charger.

Response:

Example:

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

dst: 80 (CP)
src: 01 (charger)
cmd: 66 request (unknown), length: 44
dat: 00E3 0000 0000 0000 0000 0000 03E8 0000 0000 00FF 7544 ()
dat: 00E4 0000 0000 0000 0000 0000 03E8 0000 0000 00FF 7544 ()
dat: 00E5 0000 0000 0000 0000 0000 03E8 0000 0000 00FF 7544 ()
dat: 00E6 0000 0000 0000 0000 0000 03E8 0000 0000 00FF 7544 ()

Notes:
• Response results in charger sending command 66 request.

Request sent by: charger.

Response: ??

Example:

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

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

Notes:

Request sent by: ??

Response: ??

Example:

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

start of frame marker not found in data: b"\xe10016C23A77D\x03\xff"

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.

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 (reset), 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.

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 (unknown FD)
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 address FD.
• 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 (unknown)
src: 80 (CP)
cmd: EC response (unknown), length: 0

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

Notes:
• Response is sent to address FD.
• Response is followed by CP sending command ED request to address FD.

Request sent by: CP.

Response: ??

Example:

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

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

Request sent by: address FD.

Response: 102 bytes.

Example initiated by charger:

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

dst: FD (unknown)
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 (unknown)
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 always sent to address FD.

Request sent by: address FD.

Response: 6 bytes.

Example initiated by CP:

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

dst: FD (unknown)
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 (unknown FD)
src: 80 (CP)
cmd: F1 response (unknown F1), length: 6
dat: 417D 30 ()

Notes:
• Response is always sent to address FD.

Request sent by: address FD.

Response: ??

Example:

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

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

Notes:
• Response is sent to address FD.

Request sent by: address FD.

Response: 10 bytes.

Example:

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

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

Notes:
• Response is sent to address FD.

Request sent by: address FD.

Response: 10 bytes.

Example:

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

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

Notes:
• Response is sent to address FD.

Request sent by: address FD.

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 address FD.

Request sent by: address FD??

Response: none.

Example:

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

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

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

Request sent by: address FD.

Response: ??

Example:

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

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

Notes:
• Response is sent to address FD.

Request sent by: address FD.

Response: 122 bytes.

Example:

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

dst: FD (unknown)
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 address FD.

Request sent by: address FD.

Response: 10 bytes.

Example:

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

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

Notes:
• Response is sent to address FD.

Request sent by: address FD.

Response: ??

Example:

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

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

Notes:
• Response is sent to address FD.

Request sent by: address FD.

Response: ??

Example:

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

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

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

Notes:
• Response is sent to address FD.
• Request results in CP broadcasting command 35 (soft reset) request.

Request sent by: address FD??

Response: none.

Example:

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

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

Notes:
• Request results in CP rebooting.