QUEUED_MESSAGE & Status Types

[pkleissler]

H All,

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?

In the case of a proxy, should it forward the request to the end device even if it has a response in cue?

How would the proxy know that the queued message in it's cue is or is not one of those types?

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.

I have seen one controller use GET_LAST_MESSAGE and another use ADVISORY. So far both work, only because my proxy does not check and returns the message in its cue if there is one.

Thoughts?

Paul

[ericthegeek]

Originally Posted by pkleissler

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

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

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

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.

[pkleissler]

Thanks Eric,

To confirm, the status type in the Get QUEUED_MESSAGE only applies when the responder has no queued message to send, in which case it would send a status message reply response. This response should then follow table 10.1 for the type requested in the GET.

Paul

[ericthegeek]

Correct, that matches my interpretation.

[sblair]

Everything that has been said so far matches with my interpretations and our intent when writing it.

[zano_villa]

Hello,

I need an explanation, please.

Point 10.3.1. of the standard seems to state that a receiver must always respond with a STATUS MESSAGE with PDL = 0 when it receives a GET QUEUED MESSAGE with no messages pending (MESSAGE COUNT = 0)

But this seems to be an incorrect interpretation.

In fact if I don't support GET_STATUS_MESSAGES, then I MUST respond with a
STATUS_MESSAGE with PDL of 0x00 (I must respond in this way even if I don't
support STATUS MESSAGES PID and this does not imply a STATUS MESSAGES
support as it is reported in the text)

But If I support GET_STATUS_MESSAGES, then I must respond with a STATUS
MESSAGE with STATUS TYPE requested.

A STATUS MESSAGE response with PDL = 0 doesn't mean that there are no
messages pending, this information simply is supplied by MESSAGE COUNT = 0.

Am I right?

Thank you

[sblair]

Zano,

I believe you have most everything correct.

If there are no Queued Messages (Message Count = 0) then you must respond to the GET:QUEUED_MESSAGES with a STATUS_MESSAGES response. If you don't support status messages then you would still respond with that PID, but with a PDL of 0x00. This is the same response that would go back if you did support Status Messages, but just didn't have any to report.

If you do support Status Messages, then you would use Table 10-1 to determine what Status Messages to return based on the Status Type Requested.

Let me know if there's still any questions here or if I missed something.

Thanks.
Scott

[nomis52]

This is how I would implement a responder. On receiving a GET QUEUED_MESSAGE:

- if the requested status type is STATUS_GET_LAST_MESSAGE, return the same response as last time.
- otherwise, if there are queued messages, decrement the pending message count and return the most urgent one
- otherwise, if there are status messages at or above the requested level (see table 10-1) that have not been collected, return one or more status messages.
- otherwise return a status message response with a PDL of 0

It's important that a controller be able to send GET QUEUED_MESSAGE and eventually receive an empty status message response. This tells the controller it's up-to-date.

How many times to try this depends on the number of proxies on the line and the number of status messages that are pending on the responder. The RDM tests try up to 25 times to get an empty status message response.

Simon

[zano_villa]

The issue is the third line:

- otherwise, if there are status messages at or above the requested level (see table 10-1) that have not been collected, return one or more status messages.

In my implementation I have DMX status situation regarded as an ADVISORY STATUS and it is always present. So, if I have not pending messages, and I still receive GET_QUEUED_MESSAGEs with ADVISORY_STATUS, must I send it only once and then return a status message response with PDL of 0 ?

I don't think so.

Thank you

Zano_villa

[nomis52]

Originally Posted by zano_villa

The issue is the third line:

- otherwise, if there are status messages at or above the requested level (see table 10-1) that have not been collected, return one or more status messages.

In my implementation I have DMX status situation regarded as an ADVISORY STATUS and it is always present. So, if I have not pending messages, and I still receive GET_QUEUED_MESSAGEs with ADVISORY_STATUS, must I send it only once and then return a status message response with PDL of 0 ?

I don't think so.

My interpretation (and from all but one device with the gear I've tested with) is that status messages are asserted when the condition occurs and then, once the message is collected by the controller, the responder no longer has the message. Therefore always returning an advisory status message breaks this model. It effectively tells the controller "I always have this condition and there is nothing you can do to clear it".

When we reopen E1.20 I'll be pushing to clarify this behavior.

In E1.33 always returning an advisory message may generate a lot of traffic on the device -> controller and controller to controller links. This is another reason why it should be avoided.

Simon

[sblair]

Zano,

Can you explain the purpose and use of the DMX status advisory message? I'd like to understand it better to see if maybe there is a better solution we can propose.

Simon is correct in that once the messages are collected, they are purged and the message count = 0, UNLESS the condition occurs again and then a new status message gets queued up. One could implement a sensor that generates a status message every time the temperature changes by 1/10th of a degree, but in most situations that would just be viewed as noise and waste the network bandwidth.

At least as an advisory a controller can choose to not collect it, but it would be useful to understand your use case.

Thanks.
Scott

[zano_villa]

Hello,

Actually the issue is resolved if status messages are asserted ONLY when the condition occurs and then, once the message is collected by the controller, the responder no longer has the message.

So STATUS MESSAGE is not generated as a result of a GET_QUEUED_MESSAGE or STATUS_MESSAGE request, but it's generated when the condition occurs and then queued, waiting for a controller request, and purged after been sent. Therefore it's in effect a queued message.

Is this a correct interpretation?

As further explanation I would ask if it is correct to write the last 2 indents of page 50 of the standard applied to QUEUED MESSAGES, namely:

"The responder shall maintain reported QUEUE information until it has been successfully delivered to the controller. QUEUED MESSAGE is considered successfully delivered when the responder receives a Status Type Requested other than STATUS_GET_LAST_MESSAGE.
The previously delivered QUEUED messages shall be cleared from the reporting queue once they have been successfully delivered to the Controller."

And a last question, please: if I have an queued ADVISORY status message and controller ask me for a ERROR type (so I respond with PDL of 0), shall I consider the status message sent?

Probably 10.3 chapter of the standard is the most unclear!

Thank you very much for your regard and accuracy in answers.

Zano_villa

[sblair]

Originally Posted by zano_villa

Hello,

Actually the issue is resolved if status messages are asserted ONLY when the condition occurs and then, once the message is collected by the controller, the responder no longer has the message.

So STATUS MESSAGE is not generated as a result of a GET_QUEUED_MESSAGE or STATUS_MESSAGE request, but it's generated when the condition occurs and then queued, waiting for a controller request, and purged after been sent. Therefore it's in effect a queued message.

Is this a correct interpretation?

Yes. It is not technically called a "queued message" because that term has other specific meanings, but yes you generally keep some type of internal queue for status message events as they occur so that you can report them later when requested.

Originally Posted by zano_villa

As further explanation I would ask if it is correct to write the last 2 indents of page 50 of the standard applied to QUEUED MESSAGES, namely:

"The responder shall maintain reported QUEUE information until it has been successfully delivered to the controller. QUEUED MESSAGE is considered successfully delivered when the responder receives a Status Type Requested other than STATUS_GET_LAST_MESSAGE.
The previously delivered QUEUED messages shall be cleared from the reporting queue once they have been successfully delivered to the Controller."

If the message being returned back as part of a QUEUED_MESSAGE is a STATUS_MESSAGE then yes that still applies. The device needs to cache the status of the previous status message so it can resend if a STATUS_GET_LAST_MESSAGE is sent. It's basically there to cover the case of a lost response.

Originally Posted by zano_villa

And a last question, please: if I have an queued ADVISORY status message and controller ask me for a ERROR type (so I respond with PDL of 0), shall I consider the status message sent?

Probably 10.3 chapter of the standard is the most unclear!

Thank you very much for your regard and accuracy in answers.

Zano_villa

In that case I would not consider the status message sent because it was never actually collected. A reasonable controller implementation might frequently poll for higher priority status messages but only infrequently request Advisory level messages. In your implementation that could cause them to frequently get trashed before they were requested.

10.3 is a complicated section with lots of possible corner cases that you can see have been discussed on here previously. Your questions help as we go back and review these when we do revisions to the standard in order to clarify more and remove ambiguity.

[prwatE120]

Originally Posted by pkleissler

H All,

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.

I have seen one controller use GET_LAST_MESSAGE and another use ADVISORY. So far both work, only because my proxy does not check and returns the message in its cue if there is one.

Thoughts?

Paul

I have the same conundrum - I have a controller that uses GET_LAST_MESSAGE as the very first request to a GET:QM.

But my responder has NO previous message to return, so returns an empty STATUS_MESSAGE, since it cannot NACK the request as ACTION NOT SUPPORTED.

By my reading the standard requires a Controller to use STATUS_TYPE of
ERROR/WARNING/ADVISORY when requesting a GET:QM.

I think we are now all agreed this SHOULD have been STATUS_TYPE on None, but it sadly wasn't.

Can we agrree that the use of STATUS_TYPE of GET_LAST_MESSAGE should ONLY be used for a retry/recovery situation and not for regular GET:QM requests ?

Peter