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

[Chris Horak]

We were just asked to service an all-GDC multiplex which in every auditorium uses MiT's IMC-2e to send (Ethernet) commands to Lutron's QSE-CI-NWK-E, which in turn trigger lighting scene changes in the auditoriums.

It works, but only if you wait ~2 minutes between commands from the MiT unit.

The Lutron device is controlled via Telnet, and requires login.

Every command on the IMC-2e starts with nwk\r\n to clear the login prompt, then the actual command.

It seems like what is happening is that the socket that's opened with the Lutron device isn't being closed after each command, and the 2 minute wait is the session timing out, at which point, new commands can be sent.

The venue has been operating fine with this by ensuring that every SPL has at least 2 minutes of content between lighting macros.

That's insane to me.

Does anyone have any ideas or know any undocumented tricks?

[Leo Enticknap]

Leo from MiT here.

Does the requirement to wait two minutes only apply if commands are being sent from the 2e? For example, if you were to open a Telnet terminal (e.g. PuTTY) and send two commands to the Lutron in quick succession, do they both execute? Or does the Lutron also lock up for a significant time after the first command is executed? I'm trying to figure out if the problem lies in the 2e, the Lutron, or the networking infrastructure in between.

There is a known issue with some MiT devices, the IMC-2e among them, whereby if there is intensive, high bandwidth traffic (e.g. multicast video over IP) on the management LAN, the device can lock up and require a reboot. But I haven't come across the symptom you describe before.

If you do suspect the IMC-2e as being the culprit, checking that the firmware is current (0.4.5-a) would be a good place to start. If you need this firmware or further assistance, please feel free to email service [at] movingimagetech.com.

[Steve Guttag]

I had one site with the QSE NWK-E. I was interfacing with an Eprad eCNA-5...so there is nothing snazzy there. I seem to recall just concanting the login response (nwk\r) with the command: #DEVICE,0xFFFFFFFF,141,7,1 \r

The last digit in that sequence is the scene recall...so in the example above, it would be scene 1.

So, the full command ended up being
nwk\r #DEVICE,0xFFFFFFFF,141,7,1 \r

(though with the eCNA, the non hex would be in curly brackets and instead of \r it would be 0d).

I never ran into issues, timing or otherwise. I did have the eCNA close the connection at the conclusion of the command.

[Chris Horak]

Leo from MiT here.

Does the requirement to wait two minutes only apply if commands are being sent from the 2e? For example, if you were to open a Telnet terminal (e.g. PuTTY) and send two commands to the Lutron in quick succession, do they both execute? Or does the Lutron also lock up for a significant time after the first command is executed? I'm trying to figure out if the problem lies in the 2e, the Lutron, or the networking infrastructure in between.

There is a known issue with some MiT devices, the IMC-2e among them, whereby if there is intensive, high bandwidth traffic (e.g. multicast video over IP) on the management LAN, the device can lock up and require a reboot. But I haven't come across the symptom you describe before.

If you do suspect the IMC-2e as being the culprit, checking that the firmware is current (0.4.5-a) would be a good place to start. If you need this firmware or further assistance, please feel free to email service [at] movingimagetech.com.

Hi Leo,

Yes, if I connect via telnet in a shell and send multiple commands, it works fine. If I try to trigger via the IMC-2e without waiting 2 minutes before the second command, the second command does nothing.

I will check out your recommend steps.

Thanks!

[Chris Horak]

I had one site with the QSE NWK-E. I was interfacing with an Eprad eCNA-5...so there is nothing snazzy there. I seem to recall just concanting the login response (nwk\r) with the command: #DEVICE,0xFFFFFFFF,141,7,1 \r

The last digit in that sequence is the scene recall...so in the example above, it would be scene 1.

So, the full command ended up being
nwk\r #DEVICE,0xFFFFFFFF,141,7,1 \r

(though with the eCNA, the non hex would be in curly brackets and instead of \r it would be 0d).

I never ran into issues, timing or otherwise. I did have the eCNA close the connection at the conclusion of the command.

Hi Steve,

Your memory is correct!

The commands look like this:

nwk\r\n#DEVICE,bda331,141,7,1\r\n

nwk\r\n#DEVICE,bda331,141,7,2\r\n

nwk\r\n#DEVICE,bda331,141,7,3\r\n

etc

I don't believe the IMC-2e allows you to specify to close the connection at the end, so that's my theory as well. I wondered if there were some undocumented escape sequences that might have such functionality...

[Steve Guttag]

FWIW, I didn't include the new line command so I'm guessing it is not required.

[Leo Enticknap]

I don't believe the IMC-2e allows you to specify to close the connection at the end, so that's my theory as well. I wondered if there were some undocumented escape sequences that might have such functionality...

I've asked our engineering department if any exist, and will be back when I receive a response.

[Chris Horak]

FWIW, I didn't include the new line command so I'm guessing it is not required.

Cool, will try that out and see if some bloat can be removed.

The Lutron docs suggest that they're required but it wouldn't be the first time that an API gave more leeway than indicated.

Command Termination
Each command is made up of fields, separated by commas, and terminated with a carriage return (ASCII dec 13/hex 0D) and a line feed (ASCII dec 10/hex 0A). Throughout this document, carriage return is shown as <CR> and line feed is shown as <LF>.

Command and Control Examples
1) This command sets a dimmer (1) level to 75% with a 1 minute and 30 second fade time.
#OUTPUT,1,1,75,01:30<CR><LF>

I've asked our engineering department if any exist, and will be back when I receive a response.

Thanks for your help!