I agree fully with what Erik has suggested regarding received address ID validation. I would like to comment further however that there is more to this that must be addressed as well. Please see my comments list:

- The packet communications in such system should be fully possible to make robust enough that it can run 24x7 without a real need for the hardware watchdog transmitter disable suggested by others. Instead utilize the a firmware protection watch dog timer that resets the MCU. Then design the MCU hardware such that a reset CPU places the RS485 chip into receive mode at the target MCUs. (On some designs I have done I relied on the fact that the MCU reset made the port pin normally used as an output to enable the transmitter back to an input pin and then an appropriate pullup/pulldown resistor set the transceiver into the input mode forcing it to disconnect from the bus.

- It is a fact of life that communications links will occasionally cause a wrong bit to be received during the serial transfer. Most likely caused by an electrical noise disturbance these events cause the receiving node to get an erroneous packet. For this reason it is necessary for be able to validate the integrity of the packets sent over the link. Erik mentioned using a checksum for this. It is my experience that a checksum is not reliable enough and would suggest instead the use of the CRC16. (There is a simple method of doing a CRC16 computation that uses a look up table of only 16 words and computes based upon a "nibble table lookup method" that it quite efficient and is very code space efficient. This method gets rid of the main reason may shy away from a CRC16 because of the standard byte mode lookup table scheme takes a table that is much much larger. The CRC16 should be validated on every packet received before _ANY_ action is taken or interpreted from the received packets. If the receiver sees a CRC error the device should simply ignore the packet and await the next transmission.

- The master / target protocol used should be designed such that for each packet sent out by the master there should be a reply expected back. The master end should implement a timeout logic in waiting for the reply to come back to make sure that it does not wait forever in a loop for a reply that does not come back. Resist the temptation to design in global broadcast type commands that break the single command / response protocol model. Also try to avoid unsolicited transmissions from target devices back to the master node as these also break the single command / response protocol. Avoiding these more advanced schemes makes it much more possible to anticipate a robust protocol implementation.

- Once a received packet is validated as GOOD CRC the packet ID should be checked. It it matches the local target address setting then the packet can be further processed and a reply back will be the corresponding result action no matter what is the rest of the packet content. If the ID does not match the setting for this particular target then this station must completely ignore the packet and return to the listening mode waiting for the next transmission.

- The addressed target should _FULLY_ validate the packet contents. This should include verification of any packet length byte, command OP codes and range checking any parameters passed. If any part of the validation fails then the target device should send a reply packet back that indicates a NACK type response telling the master that the packet was bad and that no action was taken as a result.

- If a command packet looks good then the target device should take action on the packet. If the process involved is one that does not require return of a data type reply then the reply should be a generic type ACK reply.

- If the command results in some data return to the master then the packet sent back will be the required reply and no additional type ACK would be needed.

- On a half duplex type of multi-drop interface it is essential that the packets flowing from a target device to master station include a master ID code in the packet address byte. This must _NOT_ match any of the known target addresses. This is so important so some target does not accidentally try to decode a master reply as a command packet.

Michael Karas