View Single Post
Old May 24th, 2012   #2
Task Group Member
Join Date: Aug 2008
Posts: 362

Originally Posted by pkleissler View Post
Have a few questions on queued messages. If the status type is set to error, warning or advisory, should only those types of messages be returned?
Status Type only applies to Status Messages. Normal PIDs don't really have a Status Type associated with them.

The GET QUEUED_MESSAGE PID is unusual in that the responder can respond with a STATUS_MESSAGE response if there are no queued messages to send.

The "Status Type" field of a GET QUEUED_MESSAGE only applies in the case when the responder is sending status messages. If there is a queued message, the responder should send that instead regardless of the Status Type requested.

Originally Posted by pkleissler View Post
In the case of a proxy, should it forward the request to the end device even if it has a response in cue?
No, a proxy does not have to always forward the request to the end responder. If the proxy has a queued message in memory, it can respond with that message on behalf of the end device.

Originally Posted by pkleissler View Post
How would the proxy know that the queued message in it's cue is or is not one of those types?
Normal PIDs don't have a Status Type associated with them. The proxy can just pass them along to the controller in the order they were received from the responder. They don't even have to be in order, the proxy could rearrange the queued messages if it wanted to (although I'm not sure why you would do this).

The Status Type only matters for Status Messages. The packed structure returned in a STATUS_MESSAGES response has the Status Type contained within the data structure, so the proxy can look at the data and determine which status messages to return.

In general, I feel that a proxy should only collect status messages when asked by the controller. A proxy could collect status messages from its responders independently, and them pass them along to the controller when required. But then you run the risk of the proxy having to hold the status message indefinitely if the controller never asks for it, and you risk the possibility that the data may go out of date while it's sitting in memory.

If the proxy does collect status messages independently and buffer them until requested by the controller, it must be able to re-pack status messages dynamically. For example, the proxy is constantly collecting Advisory messages in the background, so it builds up a list of Advisory, Warning, and Error statuses in memory. When the controller requests Errors, the proxy will pull only the Status Type ERROR and ERROR_CLEARED from memory.

In general, the proxy should *not* reorder status messages, especially STATUS and STATUS_CLEARED. Receiving a "Dimmer on Fire" followed by "Dimmer on Fire Cleared" is very different then "Dimmer on Fire Cleared" followed by "Dimmer on Fire" (There's probably an Advisory Halon System Low message in there too).

Originally Posted by pkleissler View Post
Section 10.3.1 says to use type of GET_LAST_MESSAGE to retrieve the last queued message, but I believe that pertains to the controller already receiving it and wants it again. This same section also gives an example, but it uses the type ERROR, to retrieve a queued DMX address message, hardly an error.
GET_LAST_MESSAGE is used when there is a dropped or corrupt response to ensure that status and queued message don't get lost. The DMX address response is appropriate because it's a Queued Message and not a Status Message. Status Type Error only applies if the proxy and/or responder is sending Status Messages.
ericthegeek is offline   Reply With Quote