Timing out IDENTIFY_DEVICE

[owaits]

My feeling is that if Identify is expected to timeout there should be a parameter in the packet to specify the timeout. Without this parameter it should wait till the Off command is sent.

Otherwise we end up in a mess where some fixtures time out in 1 min, others in 5min and others will never time out. Specifying a timeout in the packet would remove ambiguity and give the controller control.

[daniel]

This bit me while working on a new product. I was trying out DF's RAD and did my addressing, then immediately pulled the wire and plugged it into a non-RDM capable DMX source. My fixture was now permanently stuck on (until I re-plugged the RAD), and I think this is a problem. I do not want to force Identify to expire if that is going to be unexpected behavior though.

Originally Posted by owaits

My feeling is that if Identify is expected to timeout there should be a parameter in the packet to specify the timeout. Without this parameter it should wait till the Off command is sent.

I realize adjusting existing commands can be dicey, but here is a possibility:
The present 8-bit parameter of IDENTIFY_DEVICE is only valid for 0 (off) or 1 (on). It might be possible to assign higher values to a series of time settings, ie 3 = 10s, 4 = 30s, 5 = 1m... or something...

If an RDM terminal is set by the user to issue expiring IDENTIFY_DEVICE commands, it can attempt to send IDENTIFY_DEVICE with a parameter other than 0 or 1. A device that does not support this will (or should) respond with NR_DATA_OUT_OF_RANGE. This will inform the controller that the device does not support timeout values. The controller can fall back to issuing IDENTIFY_DEVICE[1] (on) and working as it does now.

But for a fixture that DOES respond to those, the controller will periodically send out renewal messages for IDENTIFY_DEVICE. ie IDENTIFY_DEVICE[4] every 30 seconds.

In any case, when the controller is finished with the fixture, it will issue IDENTIFY_DEVICE[0] (off).