System Sequence Diagram – How to Show Multiple Exit Conditions in a Loop Frame

Keep in mind that you are just drawing diagrams. This is not coding in some graphic language. If you use the timer-mechanism in all your communication with the device, just model it once (a suggestion for this can be found at the end of this answer). Leave out the timer in most diagrams. You should model at a specific level of abstraction. Don't leave this level or your diagram will get bloated and readers will miss the point you're trying to make. State clearly what case you are modelling. If communication failure does not matter to the situation, don't model it. If you want to explain behavior after a communication failure, don't model the error free case. If you want to model both, consider using multiple diagrams. And again, state clearly what case you are modelling.

For the actual timer I don't see much of a problem. I suggest you create one lifeline for your timer, one for the device and one for whoever talks to the device (let's call it controller) and the timer. Draw a message "reset" from the controller to the device followed by a message "countdown" from the controller to the timer. If you want to model the case of the answer received, draw a message "reset finished" from the device to the controller. Now the controller tells the timer to stop. In the no response case you can draw a message "time up" from the timer to the controller. You can combine both of these with an alt fragment and guards like "device not connected".

As the queue is an important component in the sequence you are presenting, it should most definitely be present with a lifeline.

As the consumer explicitly listens for events from the queue, I would start the diagram with the listen call from the consumer to the queue.
After that, the producer can insert its event into the queue (possibly with an indication that a considerable amount of time can elapse between the listen call and the insertion of the event). At this point, I would use two return arrows. One back to the producer to indicate completion of the insert call, and the other to the consumer to indicate completion of the listen call.
This is under the assumption that the producer and consumer execute asynchronously.

It would look like this:

+---+       +---+       +---+
| P |       | Q |       | C |
+---+       +---+       +---+
  |           |   listen  |
  |           | <|------- |
  |           |           |
  |  insert   |           |
  | -------|> ++          |
  | < - - - - ++  event   |
  |           ++ - - - - >++
  |           |           ++
  |           |           ++
  |           |   listen  ++
  |           | <|------- ++
  |           |           |

To indicate that the consumer is always listening, I have ended the diagram again with a listen call that hasn't returned.