QUEUED_MESSAGE & Status Types

[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.