Announcement

Collapse
No announcement yet.

MiT IMC-2e & Lutron QSE-CI-NWK-E

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    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.

    Comment


    • #17
      I've just heard from our engineering department and programmer: they were not able to reproduce this fault, despite extensive testing. Our best guess is that there is an issue specific to the LAN traffic in this installation, which is interacting with the 2e to cause this fault. If you wanted to investigate it further, my suggestion would be to run a Wireshark capture (from a PC connected directly to the same switch as the 2e and the dimmer), attempt to send some commands during the two-minute lockup period, and then look at what happened in the Wireshark dump.

      Comment

      Working...
      X