The third field in an INSTEON message, the Message Flags byte, not only signifies the Message Type but it also contains other information about the message. The three most-significant bits, the Broadcast/NAK Flag (bit 7), the ALL-Link Flag (bit 6), and the ACK Flag (bit 5) together indicate the Message Type. Message Types will be explained in more detail in the next section (see Message Type Flags42). Bit 4, the Extended Message Flag, is set to one if the message is an Extended-length message, i.e. contains 14 User Data bytes, or else it is set to zero if the message is a Standard-length message. The low nibble contains two two-bit fields, Hops Left (bits 3 and 2) and Max Hops (bits 1 and 0). These two fields control message retransmission as explained below (see Message Retransmission Flags43). The table below enumerates the meaning of the bit fields in the Message Flags byte. The Broadcast/NAK Flag (bit 7, the most-significant byte), the ALL-Link Flag (bit 6), and the ACK Flag (bit 5) together denote the eight possible Message Types.  Message Type Flags There are eight possible INSTEON Message Types given by the three Message Type Flag Bits. Message Types To fully understand the eight Message Types, consider that there are five basic classes of INSTEON messages: Broadcast, ALL-Link Broadcast, ALL-Link Cleanup, Direct, and Acknowledgement. Broadcast messages contain general information with no specific destination. Directed to the community of all devices within range, they are mainly used during device ALL-Linking (see SET Button Pressed Broadcast Messages84, below). Broadcast messages are not acknowledged. ALL-Link Broadcast messages are directed to a group of devices that have previously been ALL-Linked to the message originator (see INSTEON ALL-Link Groups93, below). ALL-Link Broadcast messages are a means for speeding up the response to a command intended for multiple devices. They are not acknowledged directly. Instead, after sending an ALL-Link Broadcast message to an ALL-Link Group of devices, the message originator then sends an ALL-Link Cleanup message addressed to each member of the ALL-Link Group individually, with the expectation of an acknowledgement back from each device in turn. Direct messages (sometimes referred to as Point-to-Point messages) are intended for a single specific recipient. The recipient responds to Direct messages by returning an Acknowledgement message. Acknowledgement messages (ACK or NAK) are messages from the recipient to the message originator in response to a Direct or ALL-Link Cleanup message. There is no acknowledgement to a Broadcast or ALL-Link Broadcast message. In some cases, when a Direct message specifically requests returned data, an ACK message may return one or two data bytes to the originator, or a NAK message may return an error code. Message Type Flag Bits The Broadcast/NAK Flag (bit 7) will be set whenever the message is a Broadcast message or an ALL-Link Broadcast message. In those two cases the Acknowledgement Flag (bit 5) will be clear. If the Acknowledgement Flag is set, the message is an Acknowledgement message. In that case the Broadcast/NAK Flag will be set when the Acknowledgement message is a NAK, and it will be clear when the Acknowledgement message is an ACK. The ALL-Link Flag (bit 6) will be set to indicate that the message is an ALL-Link Broadcast message or part of an ALL-Link Cleanup conversation. This flag will be clear for general Broadcast messages and Direct conversations. Now all eight Message Types can be enumerated as follows, where the three-bit field is given in the order Bit 7, Bit 6, Bit 5. • Broadcast messages are Message Type 100. • Direct messages are 000. • An ACK of a Direct message is 001 • A NAK of a Direct message is 101 • An ALL-Link Broadcast message is 110. • ALL-Link Broadcasts are followed up by a series of ALL-Link Cleanup messages of Message Type 010 to each member of the ALL-Link Group. • Each recipient of an ALL-Link Cleanup message will return an acknowledgement with an ALL-Link Cleanup ACK of Message Type 011 or an ALL-Link Cleanup NAK of Message Type 111. See the INSTEON Message Summary Table46 in the next section for a chart of all possible message types. Extended Message Flag Bit 4 is the Extended Message Flag. This flag is set for 24-byte Extended-length messages that contain a 14-byte User Data field, and the flag is clear for 10-byte Standard-length messages that do not contain User Data. Message Retransmission Flags The remaining two flag fields, Max Hops and Hops Left, manage message retransmission. As described above, all INSTEON devices are capable of repeating1 messages by receiving and retransmitting them. Without a mechanism for limiting the number of times a message can be retransmitted, an uncontrolled ‘data storm’ of endlessly repeated messages could saturate the network. To solve this problem, INSTEON message originators set the 2-bit Max Hops field to a value of 0, 1, 2, or 3, and they also set the 2-bit Hops Left field to the same value. The standard value of Max Hops for Broadcast and ALL-Link Broadcast messages is 3. For Direct and ALL-Link Cleanup messages, the standard initial value of Max Hops is 1. If INSTEON Message Retrying54 is necessary, INSTEON Engine firmware will automatically increment Max Hops for each retry, up to the maximum value of 3. A Max Hops value of zero tells other devices within range not to retransmit the message. A higher Max Hops value tells devices receiving the message to retransmit it depending on the Hops Left field. If the Hops Left value is one or more, the receiving device decrements the Hops Left value by one, then retransmits the message with the new Hops Left value. Devices that receive a message with a Hops Left value of zero will not retransmit that message. Also, a device that is the intended recipient of a message will not retransmit the message, no matter what the Hops Left value is. See INSTEON Message Hopping49 for more information. Note that the designator Max Hops really means maximum retransmissions allowed. All INSTEON messages ‘hop’ at least once, so the value in the Max Hops field is one less than the number of times a message actually hops from one device to another. Since the maximum value in this field is three, there can be four actual hops, consisting of the original transmission and three retransmissions. Four hops can span a chain of five devices. This situation is shown schematically below.  Command 1 and 2 The fourth field in an INSTEON message is a two-byte Command, made up of Command 1 and Command 2. The usage of this field depends on the Message Type as explained below (see INSTEON Message Summary Table46 and Chapter 8 — INSTEON Command Set114). User Data Only if the message is an Extended-length message, with the Extended Message Flag set to one, will it contain the fourteen-byte User Data field. Extended-length Direct Commands have a predefined User Data field, but developers may define their own User Data fields by employing so-called FX Commands (see User-Defined FX Commands121). If more than 14 bytes of User Data need to be transmitted, multiple INSTEON Extended-length messages will have to be sent using FX Commands. Users can define a packetizing method for their data so that a receiving device can reliably reassemble long messages. Encrypting User Data can provide private, secure communications for sensitive applications such as security systems. Message Integrity Byte The last field in an INSTEON message is a one-byte CRC, or Cyclic Redundancy Check. The INSTEON transmitting device computes the CRC over all the bytes in a message beginning with the From Address. INSTEON uses a software-implemented 7-bit linear-feedback shift register with taps at the two most-significant bits. The CRC covers 9 bytes for Standard-length messages and 23 bytes for Extended-length messages. An INSTEON receiving device computes its own CRC over the same message bytes as it receives them. If the message is corrupt, the receiver’s CRC will not match the transmitted CRC. Firmware in the INSTEON Engine handles the CRC byte automatically, appending it to messages that it sends, and comparing it within messages that it receives. Applications post messages to and receive messages from the INSTEON Engine without the CRC byte being appended. Detection of message integrity allows for highly reliable, verified communications. The INSTEON ACK/NAK (acknowledge, non-acknowledge) closed-loop messaging protocol based on this detection method is described below (see INSTEON Message Retrying54). |
|
|