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)
-   -   Support a given PID with a GET but not a SET (http://www.rdmprotocol.org/forums/showthread.php?t=1196)

LarryDew February 25th, 2014 02:58 PM

Support a given PID with a GET but not a SET
 
For a given PID, if I support the GET must I support the SET. Example IDENTIFY_MODE: GET returns QUITE but I don't not have a LOUD setting so setting it to LOUD does nothing. Should I return a NR_DATA_OUT_OF RANGE or NR_UNSUPPORTED_CC? In general, if I am testing for a supported PID is it required to support both GET and SET command classes?
Thanks

sblair February 25th, 2014 04:45 PM

You are not required to support the SET just because you support a GET. This is exactly what the NR_UNSUPPORTED_CC was created for.

ericthegeek February 26th, 2014 10:16 AM

Scott is correct, you can return NR_UNSUPPORTED_CC if you support GET but not SET.

However, in the specific example you give, it's really not a good idea. If you only have a single identify mode, there's no reason to declare support for the IDENTIFY_MODE PID. Just leave it out of your responder altogether.

This question come up more often in the context of PIDs such as DEVICE_HOURS where the GET gives you information about the responder, but there are reasons you want to prevent the user from sending a SET.

este_ March 2nd, 2014 12:56 PM

One of the the most obvious occurrences of this situation seems be the LOCK_PIN command. In this case, however, the standard (E1-37) makes it clear and says, "For devices that protect against the RDM Controller retrieving the current PIN code, any GET_COMMAND messages shall send a NACK with a NACK Reason of NR_UNSUPPORTED_COMMAND_CLASS".

The same should apply for all the examples above.

Note: Even if you do not support GET_LOCK_PIN, the OLA responders tests try a "GetLockPinWithData" and claim a

"Response: RDMResponse:, Get NACK Unsupported command class, PID: 0x0640"
as
"Failed: expected one of:
CC: Get, PID 0x0640, NACK Format Error
CC: Get, PID 0x0640, ACK, fieds [], values {}"

This may be misleading. You simply cannot generate any answer when you don't support that PID or command class.
It reminds me of the question:
"Which part of 'NO' don't you understand?" :)

nomis52 March 7th, 2014 10:51 AM

Quote:

Originally Posted by este_ (Post 2751)

Note: Even if you do not support GET_LOCK_PIN, the OLA responders tests try a "GetLockPinWithData" and claim a

"Response: RDMResponse:, Get NACK Unsupported command class, PID: 0x0640"
as
"Failed: expected one of:
CC: Get, PID 0x0640, NACK Format Error
CC: Get, PID 0x0640, ACK, fieds [], values {}"

This may be misleading. You simply cannot generate any answer when you don't support that PID or command class.
It reminds me of the question:
"Which part of 'NO' don't you understand?" :)


This has been fixed. In the future please report bugs like this on the rdm-testing@ mailing list or file issues in the tracker https://github.com/OpenLightingProject/ola/issues

Simon


All times are GMT -6. The time now is 05:04 PM.

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