### Firmware Version Reply - Example

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/terminal.md

An example of a device's reply to a firmware version request, showing the CMD_ACK_OK with the specific version '6.81' and date 'Apr 28 2015'.

```Network Protocol
packet(id=CMD_ACK_OK, data="Ver 6.81  Apr 28 2015\x00")
```

--------------------------------

### Example Reply Packet - Get Timezone Info

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/access.md

This hexadecimal dump illustrates a reply packet for the 'Get TZ Info' command. It shows the raw byte structure of the timezone definition, where specific byte sequences represent start and end hours/minutes for each day's timezone.

```Hex Dump
00000000: 50 50 82 7D 28 00 00 00  D0 07 2F A5 12 63 27 00  PP.}(...../..c'.
00000010: 30 00 11 0C 11 0D 11 25  11 25 11 25 11 25 11 25  0......%.%.%.%.%
00000020: 11 25 11 25 11 25 11 25  11 25 11 23 11 24 A7 1C  .%.%.%.%.%.#.$..
```

--------------------------------

### Example Regular Packet Structure (Hex Dump)

Source: https://github.com/adrobinoga/zk-protocol/blob/master/protocol.md

This snippet shows a full hexadecimal dump of a regular type packet, illustrating the 'start', 'payload size', and 'payload' fields as defined by the protocol. This type of packet is used for normal request and reply procedures between the PC and the ZKAccess terminal.

```Hexadecimal
00000000: 50 50 82 7D 0C 00 00 00  0B 00 58 EF C5 C0 05 00  PP.}......X.....
00000010: 7E 4F 53 00
```

--------------------------------

### Example Fingerprint Template Entry (Hexadecimal)

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/data-user.md

This hexadecimal dump provides a concrete example of the beginning of a fingerprint template entry. It illustrates the structure including the total size, user serial number, finger index, and fingerprint flag.

```Hexadecimal
00000000: C4 04 0E 00 04 01 4D FD  53 53 32 31 00 00 04 BE
00000010: BE 04 08 05 07 09 CE D0
```

--------------------------------

### Example Regular Packet Creation with Session ID

Source: https://github.com/adrobinoga/zk-protocol/blob/master/protocol.md

Demonstrates the extended packet notation by creating a CMD_ACK_OK packet with a specific 'session id' set to '0000'. This illustrates how to explicitly define non-payload fields.

```Protocol Notation
packet(id=CMD_ACK_OK, session id=0000)
```

--------------------------------

### Example Hexadecimal Reply for Get Unlock Combination

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/access.md

This hexadecimal dump illustrates a sample response for a CMD_ULG_RRQ command. It shows the raw byte data representing an unlock combination, specifically combination 7, which includes groups 1 and 2.

```Hexadecimal
00000000: 50 50 82 7D 10 00 00 00  D0 07 B5 93 12 63 5D 00  PP.}.........c].
00000010: 07 01 02 00 00 00 02 00                           ........
```

--------------------------------

### Starting 1-to-N Identification - ZKTeco Protocol

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/other.md

This command puts the machine into a 1-to-N comparison state, typically used for identifying a user from a database based on their fingerprint. It is also used internally during the enrollment procedure. The device confirms with CMD_ACK_OK.

```ZKTeco Protocol
> packet(id=CMD_STARTVERIFY)
		> packet(id=CMD_ACK_OK)
```

--------------------------------

### Packet Payload Data from Example (Hex)

Source: https://github.com/adrobinoga/zk-protocol/blob/master/protocol.md

This snippet presents the raw 'payload' data extracted from the example regular packet. The content of this payload varies depending on the specific protocol operation or command being executed.

```Hexadecimal
0B 00 58 EF C5 C0 05 00 7E 4F 53 00
```

--------------------------------

### Example Operation Record Entry - Hexadecimal

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/data-record.md

This hexadecimal dump provides a concrete example of a single operation record entry. It illustrates the byte-level representation of an entry with specific values for operation ID (6), encoded time (`0x23689BC2`), and four parameters (`0x0003`, `0x0000`, `0x0007`, `0x0502`), aligning with the `ops rec` structure definition.

```Hexadecimal
00000000: 00 00 06 2A C2 9B 68 23  03 00 00 00 07 00 02 05  ...*..h#........
```

--------------------------------

### Device State Reply - Example (Hex)

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/terminal.md

This hexadecimal dump shows an example reply for a device state request. The 'session id' field (bytes '02 00') indicates a state of '2' (Fingerprint identification state) in little-endian format.

```Hexadecimal
00000000: 50 50 82 7D 08 00 00 00  D0 07 F6 F7 02 00 37 00  PP.}..........7.
```

--------------------------------

### Getting Fingerprint Template (ZK Protocol Command)

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/data-user.md

This sequence of commands is used by the SDK to request a specific fingerprint template. It starts with CMD_USERTEMP_RRQ, followed by CMD_PREPARE_DATA, CMD_DATA (containing the template), and finally CMD_ACK_OK upon successful retrieval.

```ZK Protocol Command
> packet(id=CMD_USERTEMP_RRQ, data=<fp tmp req>, reply number=<rN>)
	> packet(id=CMD_PREPARE_DATA, data=<prep struct>, reply number=<rN>)
	> packet(id=CMD_DATA, data=<dataset>, reply number=<rN>)
	> packet(id=CMD_ACK_OK, reply number=<rN>)
```

--------------------------------

### Attendance Realtime Log Packet Example - Hex Dump

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/realtime.md

This hex dump provides a concrete example of a realtime packet representing an attendance event. It showcases the raw byte structure of such a packet, from which specific details like the user ID '999111333', the verification method (fingerprint), and the exact attendance timestamp '2018/06/25 17:41:05' can be extracted and interpreted.

```Hex Dump
00000000: 50 50 82 7D 28 00 00 00  F4 01 AC 12 01 00 00 00  PP.}(...........
00000010: 39 39 39 31 31 31 33 33  33 00 00 00 00 00 00 00  999111333.......
00000020: 00 00 00 00 00 00 00 00  01 00 12 06 19 11 29 05  ..............).
```

--------------------------------

### Setting Lock On Timer - Example (Hex)

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/terminal.md

This hexadecimal dump illustrates setting the 'LockOn' parameter to '5'. The data payload '4C 6F 63 6B 4F 6E 3D 35 00' translates to 'LockOn=5\x00'. The machine may reply with CMD_ACK_OK.

```Hexadecimal
00000000: 50 50 82 7D 11 00 00 00  0C 00 EB BB 84 C5 47 00  PP.}..........G.
00000010: 4C 6F 63 6B 4F 6E 3D 35  00                       LockOn=5.
```

--------------------------------

### Reply Packet for Get Group Info Command - Hex Dump

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/access.md

This hex dump represents a reply packet for a 'get group info' command. It illustrates the structure of the data returned, indicating that group 77 has timezones 8, 7, and 6, a 'FP&RF+PIN' verification style, and the holiday flag set. This serves as an example of the data format for group information.

```Hex Dump
00000000: 50 50 82 7D 10 00 00 00  D0 07 79 F1 12 63 56 00
00000010: 4D 08 00 07 00 06 00 8E
```

--------------------------------

### Example Hex Dump for Setting User Information

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/data-user.md

This hexadecimal dump represents a 'new entry' structure for user information. It shows user index 0x000E, admin permissions 0x06, password '123456', name 'Nuevo', card number 6543, group 1, and ID '11224488'.

```Hexadecimal
00000000: 50 50 82 7D 50 00 00 00  08 00 FC 57 9D 8A 5C 00
00000010: 0E 00 06 31 32 33 34 35  36 00 7C 4E 75 65 76 6F
00000020: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
00000030: 00 00 00 8F 19 00 00 01  00 00 00 00 00 00 00 00
00000040: 31 31 32 32 34 34 38 38  00 00 00 00 00 00 00 00
00000050: 00 00 00 00 00 00 00 00
```

--------------------------------

### Decomposing Regular Packet Payload Hex Example

Source: https://github.com/adrobinoga/zk-protocol/blob/master/protocol.md

This snippet provides a hexadecimal representation of a regular packet payload, demonstrating how the fields (command id, checksum, session id, reply number, and data) are arranged according to the defined structure. The example shows the raw hex string before decomposition.

```Hexadecimal
0B 00 58 EF C5 C0 05 00 7E 4F 53 00
```

--------------------------------

### Setting Anti-Passback Flag - Example (Hex)

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/terminal.md

This hexadecimal dump demonstrates setting the 'AntiPassbackOn' parameter to '0' (false). The data payload '41 6E 74 69 50 61 73 73 62 61 63 6B 4F 6E 3D 30 00' translates to 'AntiPassbackOn=0\x00'. The machine may reply with CMD_ACK_OK.

```Hexadecimal
00000000: 50 50 82 7D 19 00 00 00  0C 00 60 22 84 C5 43 00  PP.}......`"..C.
00000010: 41 6E 74 69 50 61 73 73  62 61 63 6B 4F 6E 3D 30  AntiPassbackOn=0
00000020: 00                                                .
```

--------------------------------

### Completing Large Dataset Reception - Protocol Command

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/ex_data.md

This sequence details the full process of receiving large datasets after the initial request. It starts with `CMD_DATA_RDY` to prompt data transmission, followed by the device sending `CMD_PREPARE_DATA`, the actual `CMD_DATA` with the dataset, and a final `CMD_ACK_OK`. The process concludes by freeing the device's buffer with `CMD_FREE_DATA` and re-enabling the device with `CMD_ENABLEDEVICE`.

```Protocol Command
> packet(id=CMD_DATA_RDY, data=<rdy struct>, reply number=<rN>)
	> packet(id=CMD_PREPARE_DATA, data=<prep struct>, reply number=<rN>)
	> packet(id=CMD_DATA, data=<dataset>, reply number=<rN>)
	> packet(id=CMD_ACK_OK, reply number=<rN>)
> packet(id=CMD_FREE_DATA, reply number=<rN+1>)
	> packet(id=CMD_ACK_OK, reply number=<rN+1>)
> packet(id=CMD_ENABLEDEVICE, reply number=<rN+2>)
	> packet(id=CMD_ACK_OK, reply number=<rN+2>)
```

--------------------------------

### Example Realtime Packet Hexadecimal Representation

Source: https://github.com/adrobinoga/zk-protocol/blob/master/protocol.md

Illustrates a realtime packet in hexadecimal format, corresponding to an EF_FPFTR event. It shows the raw byte sequence including the payload data 0x64 and highlights the reuse of the session ID field with a zero reply number.

```Hexadecimal
00000000: 50 50 82 7D 09 00 00 00  F4 01 A7 FC 00 01 00 00  PP.}............
00000010: 64
```

--------------------------------

### Payload Size Value from Example Packet (Hex)

Source: https://github.com/adrobinoga/zk-protocol/blob/master/protocol.md

This snippet extracts the 'payload size' field from the example regular packet, showing its little-endian hexadecimal value. This value, 0x0000000C, indicates that the subsequent payload data is 12 bytes long.

```Hexadecimal
0x0000000C
```

--------------------------------

### Example User Entry Hexadecimal Representation

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/data-user.md

This hexadecimal dump illustrates a typical 72-byte user entry structure. It shows the internal serial number (0x000D), password ('444'), name ('Ned'), card number (0x000000DE), group (2), timezone usage, and user ID ('555'). Note that bytes after the password's null terminator are ignored.

```Hex Dump
00000000: 0D 00 00 34 34 34 00 C6  9A 80 7C 4E 65 64 00 00  ...444....|Ned..
00000010: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
00000020: 00 00 00 DE 00 00 00 02  01 00 01 00 02 00 00 00  ................
00000030: 35 35 35 00 00 00 00 00  00 00 00 00 00 00 00 00  555.............
00000040: 00 00 00 00 00 00 00 00                           ........
```

--------------------------------

### Getting User Verification Mode - Protocol Command

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/data-user.md

This command retrieves the current verification style for a specified user. It uses the CMD_VERIFY_RRQ command ID along with the user's serial number. A successful response includes an CMD_ACK_OK and the 'verify info' data structure.

```Protocol Syntax
> packet(id=CMD_VERIFY_RRQ, <user sn>)
	> packet(id=CMD_ACK_OK, data=<verify info>)
```

--------------------------------

### Example Hex Dump for Setting User Verification Mode

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/data-user.md

This hexadecimal dump illustrates setting the user with internal serial number 0x000D to use the PIN&FP&PW verification style (value 0x8d). It shows the 24-byte 'verify info' structure embedded within a larger packet.

```Hexadecimal
00000000: 50 50 82 7D 20 00 00 00  4F 00 EA 79 E7 84 45 00
00000010: 0D 00 8D 00 00 00 00 00  00 00 00 00 00 00 00 00
00000020: 00 00 00 00 00 00 00 00
```

--------------------------------

### Retrieving Timezone Definition - ZK Protocol

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/access.md

This command requests the full definition of a specific timezone. The request packet includes the timezone index (4 bytes, little endian). The response packet provides detailed timezone information for each day of the week, including start and end times for each daily period.

```Protocol Description
> packet(id=CMD_TZ_RRQ, data=<timezone index>)
	> packet(id=CMD_ACK_OK, data=<timezone info>)
```

--------------------------------

### Prompting Fingerprint Placement (Enrollment Verification) - ZKTeco Protocol

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/other.md

This command, CMD_STARTVERIFY, prompts the user to place their fingerprints on the reader during the enrollment process. It puts the device into a state where it expects real-time fingerprint events. The device acknowledges with CMD_ACK_OK.

```ZKTeco Protocol
> packet(id=CMD_STARTVERIFY)
		> packet(id=CMD_ACK_OK)
```

--------------------------------

### Setting SDKBuild Parameter After Connection - Protocol Description

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/terminal.md

After a successful connection, send a 'CMD_OPTIONS_WRQ' command to set the 'SDKBuild' parameter to 1. The device is expected to acknowledge this operation with a 'CMD_ACK_OK' reply.

```Protocol Description
> packet(id=CMD_OPTIONS_WRQ, data="SDKBuild=1\x00")
		> packet(id=CMD_ACK_OK)
```

--------------------------------

### Initiating User Enrollment - ZKTeco Protocol

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/other.md

This command initiates the user enrollment process. A CMD_STARTENROLL packet is sent, including the <enroll data> payload which is a 26-byte structure containing user ID, finger index, and fingerprint flag. The device confirms with CMD_ACK_OK.

```ZKTeco Protocol
> packet(id=CMD_STARTENROLL, data=<enroll data>)
		> packet(id=CMD_ACK_OK)
```

--------------------------------

### Setting User Information - Protocol Commands

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/data-user.md

This sequence of commands is used to modify or create user information. It involves disabling the device, sending the new user entry via CMD_USER_WRQ, refreshing data, and finally enabling the device. Each step expects an CMD_ACK_OK acknowledgment.

```Protocol Syntax
> packet(id=CMD_DISABLEDEVICE)
	> packet(id=CMD_ACK_OK)
> packet(id=CMD_USER_WRQ, data=<new entry>)
	> packet(id=CMD_ACK_OK)
> packet(id=CMD_REFRESHDATA)
	> packet(id=CMD_ACK_OK)
> packet(id=CMD_ENABLEDEVICE)
	> packet(id=CMD_ACK_OK)
```

--------------------------------

### Requesting Device Platform Protocol

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/terminal.md

Procedure to request the device's platform name. The `~Platform` parameter is sent as data with `CMD_OPTIONS_RRQ`, and the device replies with the platform name as a string.

```Protocol Description
> packet(id=CMD_OPTIONS_RRQ, data="~Platform\x00")
	> packet(id=CMD_ACK_OK, data="~Platform=<platform name>\x00")
```

--------------------------------

### Basic Regular Packet Creation Notation

Source: https://github.com/adrobinoga/zk-protocol/blob/master/protocol.md

Defines a compact notation for creating standard protocol packets. It specifies the 'id' for command/reply code and 'data' for payload, with other fields like 'payload size', 'checksum', 'session id', and 'reply number' being contextually derived.

```Protocol Notation
packet(id=<command/reply code>, data=<payload data>)
```

--------------------------------

### Setting Group Information - Protocol Command

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/access.md

This command sequence is used to create or modify an existing group's settings. It involves sending a `CMD_GRPTZ_WRQ` command with the new group settings, followed by a `CMD_REFRESHDATA` command to ensure the changes are applied. Both commands expect a `CMD_ACK_OK` response.

```Protocol Command
> packet(id=CMD_GRPTZ_WRQ, <grp settings>)
	> packet(id=CMD_ACK_OK)
> packet(id=CMD_REFRESHDATA)
	> packet(id=CMD_ACK_OK)
```

--------------------------------

### Generic Parameter Request Protocol

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/terminal.md

Describes the general protocol for requesting device parameters using `CMD_OPTIONS_RRQ`. The request includes the parameter name, and a successful response (`CMD_ACK_OK`) returns the parameter name and its string value. Error responses (`CMD_ACK_ERROR`) indicate the parameter is not present on the machine.

```Protocol Description
> packet(id=CMD_OPTIONS_RRQ, data="<param name>\x00")
	> packet(id=CMD_ACK_OK, data="<param name>=<param value>\x00")
```

--------------------------------

### Requesting Device Product Code Protocol

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/terminal.md

Protocol for requesting the device's product code, which is referred to as `~DeviceName`. The device responds with its product name as a string.

```Protocol Description
> packet(id=CMD_OPTIONS_RRQ, data="~DeviceName\x00")
	> packet(id=CMD_ACK_OK, data="~DeviceName=<device name>\x00")
```

--------------------------------

### Reading Small Datasets - Protocol Command

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/ex_data.md

This sequence describes the protocol for reading small datasets (approximately less than 1KB) from a device. It involves disabling the device, requesting data with `CMD_DATA_WRRQ`, receiving the dataset via `CMD_DATA`, and finally enabling the device. The `dataset` and `data id` fields are specific to each procedure.

```Protocol Command
> packet(id=CMD_DISABLEDEVICE)
	> packet(id=CMD_ACK_OK)
> packet(id=CMD_DATA_WRRQ, data=<data id>)
	> packet(id=CMD_DATA, data=<dataset>)
> packet(id=CMD_ENABLEDEVICE)
	> packet(id=CMD_ACK_OK)
```

--------------------------------

### Enabling Device - ZK Protocol

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/other.md

Enables the device, making fingerprint, keyboard, and RFID modules available. This command is typically used after reading parameters or uploading data. It expects an 'ACK_OK' response.

```Custom Protocol
> packet(id=CMD_ENABLEDEVICE)
		> packet(id=CMD_ACK_OK)
```

--------------------------------

### Acknowledging Connection Establishment - Protocol Description

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/terminal.md

Upon receiving the 'CMD_CONNECT' packet, the device should reply with 'CMD_ACK_OK'. The client must parse and store the session ID provided in this reply packet, while the reply number should match the sent packet (zero).

```Protocol Description
packet(id=CMD_ACK_OK)
```

--------------------------------

### Initiating Connection Without Communication Key - Protocol Description

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/terminal.md

To establish a connection with a ZK device via TCP/IP, send a packet with the command 'CMD_CONNECT'. The session ID and reply number must be initialized to zero, as the device has not yet assigned a session ID.

```Protocol Description
packet(id=CMD_CONNECT)
```

--------------------------------

### Requesting Device Vendor Name Protocol

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/terminal.md

Procedure to request the device's OEM vendor name. The `~OEMVendor` parameter is sent as data with `CMD_OPTIONS_RRQ`, and the device replies with the vendor's name as a string.

```Protocol Description
> packet(id=CMD_OPTIONS_RRQ, data="~OEMVendor\x00")
	> packet(id=CMD_ACK_OK, data="~OEMVendor=<vendor name>\x00")
```

--------------------------------

### Setting Unlock Combination via Protocol Command

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/access.md

This snippet details the process for setting an unlock combination. It involves sending a CMD_ULG_WRQ command with the new group combination data (<comb grps>), followed by a CMD_REFRESHDATA command to ensure the changes are applied. Both commands expect a CMD_ACK_OK response.

```Protocol Command
> packet(id=CMD_ULG_WRQ, <comb grps>)
	> packet(id=CMD_ACK_OK)
> packet(id=CMD_REFRESHDATA)
	> packet(id=CMD_ACK_OK)
```

--------------------------------

### Initiating Large Dataset Reception - Protocol Command

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/ex_data.md

This sequence outlines the initial steps for receiving large datasets (approximately more than 1KB). After disabling the device, a `CMD_DATA_WRRQ` command is sent. If the data is large, the device responds with `CMD_ACK_OK` and a `data stat` structure, indicating the total size of the data to be sent.

```Protocol Command
> packet(id=CMD_DISABLEDEVICE)
	> packet(id=CMD_ACK_OK)
> packet(id=CMD_DATA_WRRQ, data=<data id>)
	> packet(id=CMD_ACK_OK, data=<data stat>)
```

--------------------------------

### Enabling Realtime Packet Reception - Protocol

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/realtime.md

This snippet demonstrates the protocol sequence required to enable a device to send realtime packets. The client must send a 'CMD_REG_EVENT' packet with a fixed 4-byte data field set to 'ffff0000'. The device confirms successful registration by responding with a 'CMD_ACK_OK' packet.

```Protocol
> packet(id=CMD_REG_EVENT, data=ffff0000)
	> packet(id=CMD_ACK_OK)
```

--------------------------------

### Extended Regular Packet Creation Notation

Source: https://github.com/adrobinoga/zk-protocol/blob/master/protocol.md

Provides an extended notation for regular packet creation, allowing explicit specification of additional packet fields like 'session id' or 'reply number' beyond the basic 'id' and 'data' parameters. This is useful for clarity when specific field values are important.

```Protocol Notation
packet(id=<command/reply code>, data=<payload data>, <field>=<value>)
```

--------------------------------

### Firmware Version Reply - Structure

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/terminal.md

The device replies to a firmware version request with a CMD_ACK_OK and a data structure containing the version tag and date. This structure provides the firmware details.

```Network Protocol
packet(id=CMD_ACK_OK, data="Ver <version tag>  <date>\x00")
```

--------------------------------

### Requesting Device Product Time Protocol

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/terminal.md

Procedure to request the device's product time. The `~ProductTime` parameter is sent as data with `CMD_OPTIONS_RRQ`, and the device replies with the time in `yyyy-mm-dd HH:MM:SS` format (24-hour format).

```Protocol Description
> packet(id=CMD_OPTIONS_RRQ, data="~ProductTime\x00")
	> packet(id=CMD_ACK_OK, data="~ProductTime=yyyy-mm-dd HH:MM:SS\x00")
```

--------------------------------

### Handling User Verification Result - Protocol Syntax

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/realtime.md

When a user attempts verification, this `rtpacket` is sent to the client, containing verification information. The `verify info` structure includes the user's serial number and a fixed byte. If the user cannot be identified, the `user sn` field will be `ffffffff`.

```Protocol Syntax
rtpacket(event=EF_VERIFY, data=<verify info>)
```

--------------------------------

### Enabling Device - Packet Protocol

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/data-record.md

This snippet shows the command sequence to re-enable the device, returning it to normal operation. It sends a `CMD_ENABLEDEVICE` packet and expects a `CMD_ACK_OK` acknowledgment, typically performed after completing data retrieval or configuration tasks.

```Packet Protocol
> packet(id=CMD_ENABLEDEVICE)
		> packet(id=CMD_ACK_OK)
```

--------------------------------

### Requesting Group Parameters via Protocol Command

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/access.md

This snippet describes how to retrieve parameters for a specific group, such as timezones, verification style, and holiday flag. It involves sending a CMD_GRPTZ_RRQ command with the group number (<grp req>), and the device responds with CMD_ACK_OK and the group settings (<grp settings>).

```Protocol Command
> packet(id=CMD_GRPTZ_RRQ, <grp req>)
	> packet(id=CMD_ACK_OK, <grp settings>)
```

--------------------------------

### Uploading Fingerprint Template - Packet Protocol

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/data-user.md

This sequence of commands is used to upload a fingerprint template. It involves preparing data, sending the template, calculating a checksum, writing the temporary buffer to the final location, and freeing data. The 'prep struct' and 'tmp wreq' define the data format.

```Packet Protocol
> packet(id=CMD_PREPARE_DATA, data=<prep struct>)
	> packet(id=CMD_ACK_OK)
> packet(id=CMD_DATA, data=<fp template>)
	> packet(id=CMD_ACK_OK)
> packet(id=CMD_CHECKSUM_BUFFER)
	> packet(id=CMD_ACK_OK, data=<checksum>)
> packet(id=CMD_TMP_WRITE, data=<tmp wreq>)
	> packet(id=CMD_ACK_OK)
> packet(id=CMD_FREE_DATA)
	> packet(id=CMD_ACK_OK)
```

--------------------------------

### Setting Device Parameters - Request Packet

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/terminal.md

This snippet shows the sequence of packets required to change a device parameter. It involves sending a CMD_OPTIONS_WRQ with the parameter name and new value, followed by a CMD_REFRESHOPTION to apply the changes. Both commands expect a CMD_ACK_OK reply.

```Network Protocol
packet(id=CMD_OPTIONS_WRQ, data="<parameter name>=<new value>\x00")
		> packet(id=CMD_ACK_OK)
	> packet(id=CMD_REFRESHOPTION)
		> packet(id=CMD_ACK_OK)
```

--------------------------------

### Retrieving Device Status - Protocol Syntax

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/terminal.md

This sequence of commands is used to request status information from the device. It involves disabling the device, sending a request for free sizes, and then re-enabling the device. The device is expected to acknowledge each command with 'CMD_ACK_OK' and provide a 92-byte data structure for the status.

```Protocol Syntax
> packet(id=CMD_DISABLEDEVICE)
	> packet(id=CMD_ACK_OK)
> packet(id=CMD_GET_FREE_SIZES)
	> packet(id=CMD_ACK_OK, data=<status>)
> packet(id=CMD_ENABLEDEVICE)
	> packet(id=CMD_ACK_OK)
```

--------------------------------

### Requesting Door State - Protocol Command

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/access.md

This command requests the current state of the door. It sends `CMD_DOORSTATE_RRQ` and expects a `CMD_ACK_OK` response. The `data` field in the response will be a single byte (`door flag`), where 1 indicates the door is open and 0 indicates it is closed.

```Protocol Command
> packet(id=CMD_DOORSTATE_RRQ)
	> packet(id=CMD_ACK_OK, data=<door flag>)
```

--------------------------------

### Setting User Verification Mode - Protocol Command

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/data-user.md

This command is used to change the verification style for a specific user. It requires the CMD_VERIFY_WRQ command ID and a 'verify info' data structure. Upon successful execution, an CMD_ACK_OK acknowledgment is expected.

```Protocol Syntax
> packet(id=CMD_VERIFY_WRQ, data=<verify info>)
	> packet(id=CMD_ACK_OK)
```

--------------------------------

### Receiving Small Operation Records - Packet Protocol

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/data-record.md

This sequence illustrates how the device responds when operation record structures are 'small'. After sending the `CMD_DATA_WRRQ` command, the device immediately returns the operation record data within a `CMD_DATA` packet. The `<ops rec>` placeholder represents the actual operation record structure.

```Packet Protocol
> packet(id=CMD_DATA_WRRQ, data=0122000000000000000000)
		> packet(id=CMD_DATA, data=<ops rec>)
```

--------------------------------

### Handling Fingerprint Enrollment Result - Protocol Syntax

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/realtime.md

This `rtpacket` is sent after a fingerprint enrollment process, indicating the procedure's outcome. It includes an error code, fingerprint template size, user ID, and finger index if successful. If the error code is non-zero, indicating an error, the data fields for size, user ID, and finger index are omitted.

```Protocol Syntax
rtpacket(event=EF_ENROLLFINGER, data=<enroll result>)
```

--------------------------------

### Requesting Firmware Version - Command

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/terminal.md

This command is used to request the device's firmware version. Sending CMD_GET_VERSION prompts the device to respond with its version information.

```Network Protocol
packet(id=CMD_GET_VERSION)
```

--------------------------------

### Realtime Event Conversation Flow - Protocol

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/realtime.md

This snippet illustrates the general conversation flow for realtime events. The device initiates by sending an 'rtpacket' containing event data and a reply number of '0000'. The client acknowledges this by sending a 'CMD_ACK_OK' packet, ensuring the session ID matches the connection's ID and mirroring the '0000' reply number from the incoming packet.

```Protocol
> rtpacket(event=EF_X, data=<...>, reply number=0000)
	> packet(id=CMD_ACK_OK, session id=<s>, reply number=0000)
```

--------------------------------

### Receiving Small Fingerprint Template Structure (ZK Protocol Command)

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/data-user.md

This snippet shows the device's immediate response when the total size of fingerprint templates is small enough to be sent in a single packet. The device directly replies with CMD_DATA containing the full 'fp templates' structure.

```ZK Protocol Command
> packet(id=CMD_DATA_WRRQ, data=0107000200000000000000)
	> packet(id=CMD_DATA, data=<fp templates>)
```

--------------------------------

### Realtime Packet Creation Notation

Source: https://github.com/adrobinoga/zk-protocol/blob/master/protocol.md

Introduces a specific notation for creating realtime packets, 'rtpacket', which differs from regular packets only in the 'session id' and 'reply number' fields. It uses 'event' for the event code and 'data' for the payload, with event codes in big endian.

```Protocol Notation
rtpacket(event=<event code>, data=<payload data>)
```

--------------------------------

### Receiving Fingerprint Sample Quality Score - Protocol Syntax

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/realtime.md

During the enrollment procedure, this `rtpacket` is sent after each fingerprint sample to provide a quality score. The `score` is a numerical value, typically 0 or 100 (0x64), indicating the sample's quality.

```Protocol Syntax
rtpacket(event=EF_FPFTR, data=<score>)
```

--------------------------------

### Requesting Operation Records - Packet Protocol

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/data-record.md

This command initiates the request to read operation records. It uses `CMD_DATA_WRRQ` with a fixed 11-byte payload (`0122000000000000000000`), whose specific field descriptions are currently unknown. This is the first step after disabling the device to retrieve operation logs.

```Packet Protocol
packet(id=CMD_DATA_WRRQ, data=0122000000000000000000)
```

--------------------------------

### Handling Missing Fingerprint Template (ZK Protocol Command)

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/data-user.md

This snippet illustrates the device's response when a requested fingerprint template does not exist. The device will reply with a CMD_ACK_ERROR to the CMD_USERTEMP_RRQ command.

```ZK Protocol Command
> packet(id=CMD_USERTEMP_RRQ, data=<fp tmp req>)
	> packet(id=CMD_ACK_ERROR)
```

--------------------------------

### Receiving Small User Data Structure - Protocol Commands

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/data-user.md

For smaller user information structures, the device immediately responds to the CMD_DATA_WRRQ command with a CMD_DATA packet containing the full user info payload. This is a direct response without further negotiation.

```Protocol Commands
packet(id=CMD_DATA_WRRQ, data=0109000500000000000000)
		> packet(id=CMD_DATA, data=<users info>)
```

--------------------------------

### Querying Alphanumeric PIN Support (IsABCPinEnable) - ZKTeco Protocol

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/other.md

This command checks if the device supports alphanumeric symbols for user ID values. A CMD_OPTIOS_RRQ packet is sent with ~IsABCPinEnable. The device's response (CMD_ACK_OK or CMD_ACK_ERROR) indicates support for alphanumeric PINs.

```ZKTeco Protocol
packet(id=CMD_OPTIOS_RRQ, data="~IsABCPinEnable\x00")
```

--------------------------------

### Detecting Finger Sensor Activation - Protocol Syntax

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/realtime.md

This `rtpacket` signals that a finger has been placed on the machine's reader. It occurs during both enrollment and normal operation, regardless of user registration status. This packet does not contain any additional data.

```Protocol Syntax
rtpacket(event=EF_FINGER)
```

--------------------------------

### Reading Attendance Records from ZK Protocol Device

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/data-record.md

This sequence outlines the complete process for reading attendance records from the device. It begins by disabling the device, sends a data read request with a fixed payload, and then expects an attendance record response (for small structures). The process concludes by re-enabling the device. For larger data structures, a different exchange mechanism is used.

```ZK Protocol Commands
> packet(id=CMD_DISABLEDEVICE)
	> packet(id=CMD_ACK_OK)
packet(id=CMD_DATA_WRRQ, data=010d000000000000000000)
# Expected immediate response for small structures:
# > packet(id=CMD_DATA, data=<att rec>)
> packet(id=CMD_ENABLEDEVICE)
	> packet(id=CMD_ACK_OK)
```

--------------------------------

### Unlocking Door - Protocol Command

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/access.md

This command sends `CMD_UNLOCK` to open a door for a specified duration. The `data` field contains the delay in seconds, provided as a 4-byte little-endian number. A `CMD_ACK_OK` response is expected upon successful execution.

```Protocol Command
> packet(id=CMD_UNLOCK, data=<delay>)
	> packet(id=CMD_ACK_OK)
```

--------------------------------

### Requesting Card Functionality Status Protocol

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/terminal.md

Protocol to determine the device's card functionality. It involves two sequential requests: `~IsOnlyRFMachine` and `~RFCardOn`. The boolean results from these two parameters are used to calculate the overall card function status (e.g., only RF, RF and fingerprints, or no RF).

```Protocol Description
> packet(id=CMD_OPTIONS_RRQ, data="~IsOnlyRFMachine\x00")
	> packet(id=CMD_ACK_OK, data="~IsOnlyRFMachine=<is_rf>\x00")
> packet(id=CMD_OPTIONS_RRQ, data="~RFCardOn\x00")
	> packet(id=CMD_ACK_OK, data="~RFCardOn=<card_on>\x00")
```

--------------------------------

### Setting Device Time - Protocol Syntax

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/terminal.md

To update the device's time, send the 'CMD_SET_TIME' command with the new encoded time ('enc_t'). After receiving 'CMD_ACK_OK', a 'CMD_REFRESHDATA' command must be sent to apply the changes, which should also be acknowledged with 'CMD_ACK_OK'.

```Protocol Syntax
> packet(id=CMD_SET_TIME, data=<enc_t>)
	> packet(id=CMD_ACK_OK)
> packet(id=CMD_REFRESHDATA)
	> packet(id=CMD_ACK_OK)
```

--------------------------------

### Restarting Device - ZK Protocol

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/other.md

Restarts the device. The machine does not acknowledge this command; the connection should be closed immediately after sending and a new connection can be established after a short delay.

```Custom Protocol
packet(id=CMD_RESTART)
```

--------------------------------

### Enabling Device After User Data Retrieval - Protocol Commands

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/data-user.md

After completing the user data retrieval process, the device must be re-enabled to resume normal operations. This command sends a CMD_ENABLEDEVICE packet and expects an CMD_ACK_OK acknowledgment.

```Protocol Commands
packet(id=CMD_ENABLEDEVICE)
		> packet(id=CMD_ACK_OK)
```

--------------------------------

### Requesting Unlock Combination via Protocol Command

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/access.md

This snippet outlines the command to retrieve a specific unlock combination. A CMD_ULG_RRQ command is sent with the requested combination number (<comb req>), and the device responds with CMD_ACK_OK and the combination's group details (<comb grps>).

```Protocol Command
> packet(id=CMD_ULG_RRQ, <comb req>)
	> packet(id=CMD_ACK_OK, <comb grps>)
```

--------------------------------

### Requesting Device Time - Protocol Syntax

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/terminal.md

To obtain the current time from the device, send the 'CMD_GET_TIME' command. The device will respond with 'CMD_ACK_OK' and a 4-byte integer representing the encoded device time in little endian format.

```Protocol Syntax
	packet(id=CMD_GET_TIME)
```

--------------------------------

### Requesting All Fingerprint Templates (ZK Protocol Command)

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/data-user.md

After disabling the device, this command initiates the process of reading all fingerprint templates. It uses CMD_DATA_WRRQ with a fixed payload, whose specific field descriptions are currently unknown.

```ZK Protocol Command
packet(id=CMD_DATA_WRRQ, data=0107000200000000000000)
```

--------------------------------

### Setting Timezone Information via Protocol Command

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/access.md

This snippet describes the protocol commands required to update timezone definitions. It involves sending a CMD_TZ_WRQ command with the new timezone data, followed by a CMD_REFRESHDATA command to apply the changes. Both commands expect a CMD_ACK_OK response.

```Protocol Command
> packet(id=CMD_TZ_WRQ, data=<new timezone info>)
	> packet(id=CMD_ACK_OK)
> packet(id=CMD_REFRESHDATA)
	> packet(id=CMD_ACK_OK)
```

--------------------------------

### Packet Conversation Flow Notation

Source: https://github.com/adrobinoga/zk-protocol/blob/master/protocol.md

Defines a standardized notation for illustrating the flow of packets in a conversation between a client and a machine. Client messages are prefixed with '>' and machine replies are indented with a tab and prefixed with '>'.

```Protocol Notation
> "message from client to machine"
	> "message from machine to client"
> "message from client to machine"
	> "message from machine to client"
```

--------------------------------

### Receiving Device Parameter Information (ACK_OK)

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/terminal.md

This snippet shows the expected response from the device after a successful parameter read request. The CMD_ACK_OK command ID indicates success, and the data payload contains the parameter name and its corresponding value, null-terminated.

```Custom Protocol
packet(id=CMD_ACK_OK, data="<param name>=<param value>\x00")
```

--------------------------------

### Requesting Device Parameter Information (RRQ)

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/terminal.md

This snippet demonstrates how to send a request to the device to read a specific parameter. It uses the CMD_OPTIONS_RRQ command ID and includes the parameter name, null-terminated, in the data payload. This is part of a generic read operation.

```Custom Protocol
packet(id=CMD_OPTIONS_RRQ, data="<param name>\x00")
```

--------------------------------

### Handling Real-time Fingerprint Capture Events - ZKTeco Protocol

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/other.md

This sequence describes the real-time events received during fingerprint capture. An EF_FINGER event indicates a finger placement, followed by an EF_FPFTR event providing the fingerprint score. Each event is acknowledged with CMD_ACK_OK.

```ZKTeco Protocol
> rtpacket(event=EF_FINGER)
	> packet(id=CMD_ACK_OK)
		> rtpacket(event=EF_FPFTR, data=<score>)
	> packet(id=CMD_ACK_OK)
```

--------------------------------

### Refreshing Device Data - Packet Protocol

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/data-record.md

This snippet shows the command to refresh the device's internal data. It sends a `CMD_REFRESHDATA` packet and expects a `CMD_ACK_OK` acknowledgment. This command is crucial to ensure that any recent changes, such as uploaded fingerprints or updated user data, are applied and take effect on the device.

```Packet Protocol
> packet(id=CMD_REFRESHDATA)
		> packet(id=CMD_ACK_OK)
```

--------------------------------

### Requesting User Timezones - Protocol Command

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/access.md

This command sequence requests the timezones associated with a specific user. It sends a `CMD_USERTZ_RRQ` command with the user's internal index (`usertz req`). The expected response is `CMD_ACK_OK` containing the user's timezone data (`user tz`).

```Protocol Command
> packet(id=CMD_USERTZ_RRQ, <usertz req>)
	> packet(id=CMD_ACK_OK, <user tz>)
```

--------------------------------

### Requesting User ID Width (PIN2Width) - ZKTeco Protocol

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/other.md

This snippet demonstrates how to query the device for the maximum width of the user ID (PIN2Width). The initial request CMD_OPTIONS_RRQ with ~PIN2Width as data is sent, and the device responds with CMD_ACK_OK containing the user ID width, which should then be converted to an integer.

```ZKTeco Protocol
> packet(id=CMD_OPTIONS_RRQ, data="~PIN2Width\x00")
		> packet(id=CMD_ACK_OK, data="~PIN2Width=<user-id width>\x00")
```

--------------------------------

### Receiving Device Time - Protocol Syntax

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/terminal.md

After sending a 'CMD_GET_TIME' command, the device is expected to reply with a 'CMD_ACK_OK' code, accompanied by a 4-byte integer (`enc_t`) which represents the device's current time.

```Protocol Syntax
	packet(id=CMD_ACK_OK, data=<enc_t>)
```

--------------------------------

### Setting User Timezones - Protocol Command

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/access.md

This command sequence is used to set or modify a user's timezones. It involves sending a `CMD_USERTZ_WRQ` command with the new timezone structure (`new tz`), followed by a `CMD_REFRESHDATA` command to ensure the changes are applied. Both commands expect a `CMD_ACK_OK` response.

```Protocol Command
> packet(id=CMD_USERTZ_WRQ, <new tz>)
	> packet(id=CMD_ACK_OK)
> packet(id=CMD_REFRESHDATA)
	> packet(id=CMD_ACK_OK)
```

--------------------------------

### Requesting Device State - Command

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/terminal.md

This command is used to query the current operational state of the device. Sending CMD_STATE_RRQ will prompt the device to return its current status.

```Network Protocol
packet(id=CMD_STATE_RRQ)
```

--------------------------------

### Terminating Device Connection - Protocol Description

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/terminal.md

To gracefully terminate a connection with the device, send a 'CMD_EXIT' packet. Ensure that the session ID and reply number are consistent with the current communication state. The device will respond with 'CMD_ACK_OK', after which the socket connection can be closed.

```Protocol Description
> packet(id=CMD_EXIT)
		> packet(id=CMD_ACK_OK)
```

--------------------------------

### Receiving Enrollment Result Event - ZKTeco Protocol

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/other.md

After fingerprint samples are collected, the device sends an EF_ENROLLFINGER event containing the <enroll result> data structure. This event signifies the completion of the enrollment process for a single finger. The event is acknowledged with CMD_ACK_OK.

```ZKTeco Protocol
> rtpacket(event=EF_ENROLLFINGER, data=<enroll result>)
	> packet(id=CMD_ACK_OK)
```

--------------------------------

### Requesting All User IDs - Protocol Commands

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/data-user.md

After disabling the device, send a CMD_DATA_WRRQ command with a fixed 11-byte payload (0109000500000000000000) to initiate the user data transfer. The exact meaning of this payload is currently unknown.

```Protocol Commands
packet(id=CMD_DATA_WRRQ, data=0109000500000000000000)
```

--------------------------------

### Requesting Device Platform (Hexadecimal)

Source: https://github.com/adrobinoga/zk-protocol/blob/master/sections/terminal.md

Hexadecimal representation of the packet sent to request the device's platform name. The `~Platform` parameter is sent as data within the `CMD_OPTIONS_RRQ` command, terminated by a null byte.

```Hexadecimal Data
00000000: 50 50 82 7D 12 00 00 00  0B 00 B9 E6 F3 8D 0C 00
00000010: 7E 50 6C 61 74 66 6F 72  6D 00
```