Detailed questions on STATUS_MESSAGES

[eldoMS]

Hi

I have a question with regards to properly implementing and interpreting GET STATUS_MESSAGES.

I understand from the RDM2006 errata that there can be two types of RDM protocol support: either supporting or not supporting Status Type _CLEARED responses.

From a responder point of view, when I have a malfunction of some sort, e.g. a too low bus voltage or a too high temperature I can report this in a GET STATUS_MESSAGES reply with message(s) of a certain type and data values.

Several questions I have then from a responder viewpoint:
- how do I know _CLEARED is supported in the controller, or are most controllers already on that level? A controller without the support just ignores gracefully?
- do I only report once a certain failure (when it arises)? Or consistently with each STATUS_MESSAGE when _CLEARED is not supported? And if I need to report it consistently, how often?
- in the case of _CLEARED I only report ONCE that a certain condition was cleared?
- the PID CLEAR_STATUS_ID, what does it exactly do in this case? Is it a reset of the condition, that in a sticky example immediately comes again with a voltage or temp error and there will be another reporting of this in the next STATUS_MESSAGES (one time only?). Is this the controllers method to clear conditions and create a fresh list? How often could a controller do this? The _CLEARED method is used to remove a warning/error from the controller as soon as it is cleared instead of going via CLEAR_STATUS_ID?

Thanx

Marc

[ericthegeek]

Originally Posted by eldoMS

- how do I know _CLEARED is supported in the controller, or are most controllers already on that level? A controller without the support just ignores gracefully?

A responder has no way to know if the controller supports the _CLEARED messages. All you can do is send the _CLEARED response and hope the controller handles it gracefully. There's really no other option.

Originally Posted by eldoMS

- do I only report once a certain failure (when it arises)? Or consistently with each STATUS_MESSAGE when _CLEARED is not supported? And if I need to report it consistently, how often?

This has always been unclear in the standard, and the 2010 revision doesn't address it.

If you report a failure that is still occurring with every status message response, the user will be flooded with messages. But, if you only send it once, if the message gets lost for some reason, there's no way to know that it's there.

My opinion is that a responder should re-send status messages that are still occurring in proportion to how serious the error is. You might want to re-send a "Dimmer on Fire" status every 30 seconds, but "Gel String getting old" would only need to be sent once a day or so. To be clear, this is not based on the standard. It's merely my way of working around what I see as a limitation in the standard. What is really needed is a "resend all currently occurring status conditions". CLEAR_STATUS_ID *might* be able to serve this purpose, but the text isn't really very clear on exactly what CLEAR_STATUS_ID should do.

Originally Posted by eldoMS

- in the case of _CLEARED I only report ONCE that a certain condition was cleared?

Yes, I agree with this, provided you follow the rules for STATUS_GET_LAST_MESSAGE so that a controller has a way to re-request a _CLEARED message that gets lost or corrupt.

Originally Posted by eldoMS

- the PID CLEAR_STATUS_ID, what does it exactly do in this case? Is it a reset of the condition, that in a sticky example immediately comes again with a voltage or temp error and there will be another reporting of this in the next STATUS_MESSAGES (one time only?). Is this the controllers method to clear conditions and create a fresh list? How often could a controller do this? The _CLEARED method is used to remove a warning/error from the controller as soon as it is cleared instead of going via CLEAR_STATUS_ID?

I have no idea what CLEAR_STATUS_ID is supposed to do. There simply isn't enough information in the standard. One interpretation is that if you have a ton of old status message that are queued up and waiting to be delivered, this PID can flush the queue and allow you to get newer messages.

A second interpretation is that it tells the responder to forget what it has already sent, and re-deliver any status conditions that are still occurring.

As I said earlier, I prefer the second interpretation since it's a feature the standard really needs, but I don't think the text is clear enough.

[sblair]

Originally Posted by ericthegeek

I have no idea what CLEAR_STATUS_ID is supposed to do. There simply isn't enough information in the standard. One interpretation is that if you have a ton of old status message that are queued up and waiting to be delivered, this PID can flush the queue and allow you to get newer messages.

A second interpretation is that it tells the responder to forget what it has already sent, and re-deliver any status conditions that are still occurring.

As I said earlier, I prefer the second interpretation since it's a feature the standard really needs, but I don't think the text is clear enough.

Yes, that description is a bit terse. What is interesting is that it has been in since the original document and questions/issues have never come up about it before.

It is intended to pretty much do what it says which is to flush the status queue in the device. This is a SET message only with no other parameter data. So when a device receives this message it should flush all pending status messages it has queued.