E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM Interpretation Questions (http://www.rdmprotocol.org/forums/forumdisplay.php?f=5)
-   -   Sub-Device Status Threshold (http://www.rdmprotocol.org/forums/showthread.php?t=1102)

ericthegeek August 15th, 2011 02:49 PM

Sub-Device Status Threshold
 
The E1.20 document doesn't give much detail on the SUB_DEVICE_STATUS_REPORT_THRESHOLD PID other than that the Status Type argument comes from table A-4.

Of the 8 values in A-4, which are appropriate to use with this PID?

STATUS_NONE
STATUS_GET_LAST_ MESSAGE
STATUS_ADVISORY
STATUS_WARNING
STATUS_ERROR
STATUS_ADVISORY_CLEARED
STATUS_WARNING_CLEARED
STATUS_ERROR_CLEARED

What does each mean? Does setting the threshold to Warning mean the sub-device will report both warning and Errors, or does it only report errors?

I have my own opinion, but I'd like to see how others interpret it.

prwatE120 August 15th, 2011 05:02 PM

My interpretation is as follows : To be consistent with Table 10-1, if you set the threshold to Warning, you get Warning and Error, if you set to Error you get only error.

Unfortunately this is inconsistent with the text of 10.3.5 that states

"This feature is used to inhibit reports from, for example, a specific dimmer in a rack that is generating repeated errors"

as the only recourse to stopping errors would be to set the verbosity to STATUS_NONE, in which case you would also loose the warning and advisory messages

It is unfortunate that the text in 10.3.5 refers only to Table A-4, and not Table 10.1

"This parameter is used to set the verbosity of Sub-Device reporting using the Status Type codes as enumerated in Table A-4 "

I would not expect to see STATUS_ADVISORY_CLEARED as a valid argument to the
SUB_DEVICE_STATUS_REPORT_THRESHOLD PID, but yet the current document would appear to allow this.

Peter Willis

sblair August 15th, 2011 09:32 PM

I'll let you know what it means when someone decides to implement Sub-Devices ;)

The _CLEARED messages were not part of the original version as you know. We never looked at the _CLEARED messages in regards to use with this PID when we added them. That is an oversight.

These were intended to follow the same logic as Table 10-1. That table was not referenced in this section but it should have been. It was certainly the intent in our discussions that the same logic as Table 10-1 is used here. Such that, when setting the PID value for this to: ERROR, you would only get errors. Setting to WARNINGS would produce warning and error events. Setting to ADVISORY would get you all three and NONE would obviously mute all status messages for that sub-device.

We will need to clean the language up here in the next round to make these points clearer.

ericthegeek August 15th, 2011 11:29 PM

Thank you Peter and Scott. That matches my interpretation.

To summarize:
The following are valid arguments for GET SUB_DEVICE_STATUS_REPORT_THRESHOLD:

STATUS_ADVISORY = Report all status conditions from this sub-device

STATUS_WARNING = Report Warning and Error status conditions from this sub-device

STATUS_ERROR = Report only Error status conditions from this sub-device

STATUS_NONE = Don't report any status conditions from this sub-device

The following are *not* valid arguments:
STATUS_GET_LAST_ MESSAGE
STATUS_ADVISORY_CLEARED
STATUS_WARNING_CLEARED
STATUS_ERROR_CLEARED


All times are GMT -6. The time now is 01:02 AM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.