From a practical standpoint, it is possible to implement a responder that does not use queued messages at all. You'd have to design your firmware to ensure that all results are available within the 2ms timeout, and thus will never need to issue ACK_TIMER. Many simple responders behave this way.
But the controller effectively has to support queued messages if you want to achieve any level of interoperability. It needs to support them enough to retrieve the followup to an ACK_TIMER.
Doing this is not as scary as it seems. Any time you receive an ACK_TIMER, you can simply wait the requisite amount of time, then issue GET QUEUED_MESSAGES until you receive a response with the PID, Command Class, and Sub-Device ID that you are looking for. If you receive other Queued Message in the meantime you can simply discard them.
Obviously a more featurefull controller will handle every Queued Message is receives rather than discarding the PIDs it doesn't care about.
As a practical example, the DFD RAD supports Queued Messages. You won't find an RDM controller that's much simpler than the RAD...
|
February 16th, 2012
Similar Threads
Threaded Mode