Response to GET:QUEUED MESSAGE when NACKing query - E1.20 RDM (Remote Device Management) Protocol Forums

ericthegeek · February 24th, 2016

I ran into this when I was implementing queued messages also.

My conclusion is that if you are NACK'ing the GET QM, then you should have the QM PID in the response.

If the controller sees another PID in the response (say IDENTIFY_DEVICE), then it will assume that it just retrieved a queued NACK for an Identify that it sent in the past, rather than realizing that it's actually a NACK for the GET QM.

A controller probably should accept STATUS_MESSAGES in the PID also, although in my implementation I only put the STATUS_MESSAGES PID in the response when I'm ACK'ing a GET:QM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
E1.37-1 RDM Message Extensions document in Public Review	sblair	RDM General Implementation Discussion	2	December 13th, 2010 03:11 PM
Status Message Markers	hamish	RDM General Implementation Discussion	4	December 9th, 2010 11:12 PM
Additional Status Message ID request?	berntd	RDM General Implementation Discussion	3	October 28th, 2009 07:28 PM

February 24th, 2016	#2
ericthegeek Task Group Member Join Date: Aug 2008 Posts: 390	I ran into this when I was implementing queued messages also. My conclusion is that if you are NACK'ing the GET QM, then you should have the QM PID in the response. If the controller sees another PID in the response (say IDENTIFY_DEVICE), then it will assume that it just retrieved a queued NACK for an Identify that it sent in the past, rather than realizing that it's actually a NACK for the GET QM. A controller probably should accept STATUS_MESSAGES in the PID also, although in my implementation I only put the STATUS_MESSAGES PID in the response when I'm ACK'ing a GET:QM.