Thanks for everyone's suggestions. A bunch of updates in bulk-
* Steve is right, the Lutron device happily accepts commands terminated with \r alone even though the documentation says \r\n. This change made the commands less bulky, but the issue remains.
* During the two-minute "cooldown," the MiT unit did seem to send commands to other devices with no issue, although I noticed that the status on the bottom left of the web GUI would often turn red and say something like "waiting for server," if you tried to do multiple light scene changes.
* During the two-minute "cooldown," the Lutron device happily accepted commands from other sources.
Anyway, I put in a workaround that the client is very happy with: I updated all of their cinema server's light cues to have two additional actions- After it sends the initial command to the IMC-2e to trigger the Lutron scene change, it then waits 1s, then sends "nwk\r" directly to the Lutron device. This exploits the fact that the Lutron device will close all other sessions if the same user logs in again. The MiT unit has been playing nicely with that.
This could potentially be cleaned up further by having the cinema server send the scene changes to the Lutron device directly, but I briefly tested that and it didn't work. (I'm not sure how to put mid-string carriage returns in GDC server automation cues. The servers let you specify if the command is terminated with CR, LF or CRLF, but escape sequences \r didn't work like they do on Doremi servers.)
Obviously this "logout command," solution works for the cinema server, but using the physical buttons on the IMC-2e will still be subjected to the two-minute timeout. They say that they rarely use the physical controls anyway, and are very relieved that the cinema server automation can do light changes more rapidly now.
* Steve is right, the Lutron device happily accepts commands terminated with \r alone even though the documentation says \r\n. This change made the commands less bulky, but the issue remains.
* During the two-minute "cooldown," the MiT unit did seem to send commands to other devices with no issue, although I noticed that the status on the bottom left of the web GUI would often turn red and say something like "waiting for server," if you tried to do multiple light scene changes.
* During the two-minute "cooldown," the Lutron device happily accepted commands from other sources.
Anyway, I put in a workaround that the client is very happy with: I updated all of their cinema server's light cues to have two additional actions- After it sends the initial command to the IMC-2e to trigger the Lutron scene change, it then waits 1s, then sends "nwk\r" directly to the Lutron device. This exploits the fact that the Lutron device will close all other sessions if the same user logs in again. The MiT unit has been playing nicely with that.
This could potentially be cleaned up further by having the cinema server send the scene changes to the Lutron device directly, but I briefly tested that and it didn't work. (I'm not sure how to put mid-string carriage returns in GDC server automation cues. The servers let you specify if the command is terminated with CR, LF or CRLF, but escape sequences \r didn't work like they do on Doremi servers.)
Obviously this "logout command," solution works for the cinema server, but using the physical buttons on the IMC-2e will still be subjected to the two-minute timeout. They say that they rarely use the physical controls anyway, and are very relieved that the cinema server automation can do light changes more rapidly now.
Comment