QuercusVL Programming Manual
●
Type (2 bytes): type of message. All types of messages will be described further on.
●
Version (2 bytes): version of the message. In the messages that evolved (added extra
fields, modifying them, etc.), this field specifies the message version used. (see down
below).
●
Id (4 bytes): unique identifier of the conversation. The value will be the same for both
the request and response messages. Thus, we can know whether the response obtained
was the one expected or not. The value will be 1 for the first message sent by the units
to the central system and it will be increased in twos for each new message. In the case
of messages sent by the central system to the units, the first message will be 2 and all
others will also be increased in twos.
●
Message Data (variable): specific data of each message.
●
Bcc (1 byte): XOR of all bytes in the message from Stx to the last byte in the “Message
data”.
●
Etx (1 byte): signals the end of the message (ASCII character 3).
4.2. Message version
Messages contain a field “version” which notes the version of the message used, thus enabling
the communication protocol to be extended. Each version of a specific message can contain a
different number of fields, and their length can change, then it is important to evaluate this
field before working with the specific message fields.
In the following points, where all message structures are described, the version of each
message will only be indicated when it differs from 0. In that case, see 5. Communications
protocol (old versions) to know old version structures.
Units have a version negotiation system that makes them 100% compatible with any
previously released protocol version. When the unit sends an event message, at first sends the
highest known version of this message. If the central system answers with a NAK type 6
(Incorrect version), in the next try the unit will send a lower version of the message.
Quercus Technologies
127