QUEUED_MESSAGE - ? - E1.20 RDM (Remote Device Management) Protocol Forums

prwatE120 · November 9th, 2009

Berntd

A reply to a GET:QUEUED_MESSAGES should normally be a STATUS_MESSAGE response, unless you actually have events (such as manual local change of DMX address) that you might be QUEUEING.

You are correct in thinking that if you have not declared support for QUEUED_MESSAGES, the controller has no needto be asking, although even your NACK can be used by a controller to keep track of the fact that you are indeed still on-line. So provided you did not have the QM PID in your list of supported PIDs, your use of NACK - NR_UNSUPPORTED_PID is correct.

In my mind, asking for SENSOR_VALUE (for sensor 0), without having asked for the definition is a symptom of an untested controller implementation.

regards

Peter Willis

November 9th, 2009	#3
prwatE120 Task Group Member Join Date: Jun 2006 Posts: 181	Berntd A reply to a GET:QUEUED_MESSAGES should normally be a STATUS_MESSAGE response, unless you actually have events (such as manual local change of DMX address) that you might be QUEUEING. You are correct in thinking that if you have not declared support for QUEUED_MESSAGES, the controller has no needto be asking, although even your NACK can be used by a controller to keep track of the fact that you are indeed still on-line. So provided you did not have the QM PID in your list of supported PIDs, your use of NACK - NR_UNSUPPORTED_PID is correct. In my mind, asking for SENSOR_VALUE (for sensor 0), without having asked for the definition is a symptom of an untested controller implementation. regards Peter Willis