View Single Post
Old December 3rd, 2018   #6
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 359
Default

IMO using NR_ACTION_NOT_SUPPORTED is a very bad idea.

That NACK Reason code was not defined until E1.37-2 in 2014. Many controllers (especially older controllers and those that have not implemented '37-2) will not recognize it.

It's best to stick with the NACK Reason Codes that are defined in the core E1.20 document. You should only use the NR Codes from E1.37-x when the PID explicitly requires it, or you have no other valid choice.

Changing the personality can potentially change everything in a responder. Most controllers understand that when you change personalities you need to forget almost everything you know about the responder and re-query it.

In the case where the personality has a zero slot footprint, the DMX Address PID is not supported in that personality. It may be supported when you change to another personality, but as long as it's in the original personality NR_UNKNOWN_PID is the appropriate response.




For your API, most controllers won't expect the slot footprint to change on the fly. If it's truly dynamic from minute to minute you may have problems.

When a controller sees the same Model ID and Personality, it's reasonable for it to expect the responder will have the same footprint. It's probably best to have a different Device Model ID for each config. You could have the Model ID passed in during init.

Last edited by ericthegeek; December 7th, 2018 at 01:49 PM. Reason: Wrote "responder" when I meant "controller"
ericthegeek is offline   Reply With Quote