Documentation sections
EDVADO / Developers
Description
Archived documentation. Technical definitions follow the protocol specification. Incomplete definitions and conflicting examples are marked for clarification.
Communication principles
| Source | Definition / value |
|---|---|
| Description!A3 | Bi-directional communication protocol: device -> server, server -> device. |
| Description!A5 | Each parcel (PACKAGE) from the device requires confirmation from the server (SERVER_COM) |
| Description!A7 | If there is no confirmation from the server, the device will duplicate packet until confirmation. |
| Description!A9 | Data transmission to the server is in continuous TCP session (GPRS). |
| Description!A11 | Data are transmitted in binary form, byte order little-endian. |
Transmission order
| Source | Definition / value |
|---|---|
| Description!A14 | The structure and procedure packs |
| Description!A15 | ORDER OF TRANSMISSION |
| Description!B15 | DEVICE >> |
| Description!D15 | << SERVER |
| Description!A16 | first connection with the server
transmitted HEADER - in response to confirmation HEADER
further
PACKAGE + SERVER_COM (confirmation) |
| Description!B17 | HEADER |
| Description!G17 | Heading |
| Description!D18 | SERVER_COM |
| Description!I18 | Server command |
| Description!B19 | PACKAGE |
| Description!G19 | Package |
| Description!C20 | PACKET_0 |
| Description!H20 | Package_0 |
| Description!C21 | ...... |
| Description!H21 | ...... |
| Description!C22 | PACKET_N |
| Description!H22 | Package_N |
| Description!D23 | SERVER_COM |
| Description!I23 | Server command |
| Description!A24 | subsequent packets
PACKAGE + SERVER_COM (confirmation) |
| Description!B26 | PACKAGE |
| Description!G26 | Package |
| Description!C27 | PACKET_0 |
| Description!H27 | Package_0 |
| Description!C28 | ..... |
| Description!H28 | ..... |
| Description!C29 | PACKET_N |
| Description!H29 | Package_N |
| Description!D30 | SERVER_COM |
| Description!I30 | Server command |
Source ambiguities
- Tags 80 and 155 each retain both source rows. No merged definitions.
- Some byte examples contain numeric cells such as 45.0 / 0.0 or a Cyrillic character in a HEX-like token ([U+0421]8). Literal values / Unicode code points are shown, not silently converted to HEX.
- Lengths, checksums and names in some examples conflict with the adjacent definitions (including TEXT and confirmation variants). Verify against the source; do not infer a correction.
- A raw value type is not a separate column in the Tags source. No additional types are invented.