Support a given PID with a GET but not a SET

[LarryDew]

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]

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]

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_]

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]

Originally Posted by este_

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