Info Message

When designing wireless sensor networks, the first thing to do is to define the message format. Our application only does one thing (sending sensor data) so we only have one message, type, the Info Message. For more advanced deployments we will have multiple message types. It is best to first define these in a common document that all members of the development team can reference. Be sure to specify not just the order of fields, but also the Endianness, as this may be different on different platforms. The Info Message will be used to send sensor data about one device to another. The Info Message contains a header (defined above), a deviceType (one sensor may be one deviceType, and another sensor a different deviceType) and a number of parameters (see infoMessage.h). The parameters depend on how the build is configured; currently the Router transmits the IR temperature and the End Device transmits the Color but these can be easily modified using compile options.

These parameters consist of an Object Identifier and a value. This allows for flexible parsing and does not rely on the order of the values in the message. If you're really fancy you could even send them in key-length-value [tuples]. Since the default Zigbee messages are not very long we usually use the key-value approach, with predefined lengths for each OID. For very long fields with variable length then we may also use Extended Parameters, which are sent as a key-length-value tuple. For simplicity, the Sample Applications use a fixed length of 2 bytes for each parameter. If you would like to maintain compatibility with our products, please only use OIDs between 0x01 and 0x7F. OIDs above that are reserved for other use. Contact us for a full list of OIDs.

Values are always sent Little Endian (LSB first).

All messages use a common interface; for example in infoMessage these methods are: Using consistent names for the commands (printXMessage, serializeXMessage, etc. makes life easier when dealing with multiple messages. Also makes you wish you were using an object-oriented programming language.
 * printInfoMessage - display the message in a human readable format
 * serializeInfoMessage - Serialize the message struct into a stream of bytes
 * deserializeInfoMessage - convert a stream of bytes to the message struct
 * getSizeOfInfoMessage - get the size of the message. While this could be a macro or a #define on simpler messages, the length computation will be more complex if using variable length fields. We usually implement this as a function since a good compiler should in-line this code when optimizing anyway.