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!

[Leo Enticknap]

Our engineering team are working on an answer as to whether the 2e holds a TCP port open by default, and/or if there is a string that can be appended to a Telnet command to force close it immediately afterwards. More news as soon as I have it.

There is actually a new firmware release that got past me - 0.4.8, which includes some changes to improve performance on LANs with high bandwidth traffic. Pleas email service [at] movingimagetech.com if you would like it.

[Leo Enticknap]

Our programmer reports that the 2e should not be holding any ports open after a TCP/Telnet command is sent.

Question: during the two-minute period when the Lutron is unresponsive, do TCP/Telnet commands sent from the 2e to other devices work OK?

[Chris Horak]

We'll have to make that possible to test.

The IMC-2e at this site is -only- being used with the Lutron device. I believe they wanted physical buttons for their lights.

Will update in a bit...

[Ryan Gallagher]

An alternative test that might be easier to test is try firing a command to the Lutron during the 2 minute window from the PC? This might point to something else on the Lutron's end if it also fails. (Because presumably it's not sharing the same connection as the 2e).

[Chris Horak]

We've tried that and it works (via Telnet in a shell).

We also tried setting up two different Telnet sessions, and when you log in to the second one, it logs out the first one. Which makes it doubly strange because all the IMC-2e commands start with nwk\r\n implying they're logging in every time. Based on the Telnet experiments, it should in theory "log out" any hanging sessions.

[Leo Enticknap]

We've tried that and it works (via Telnet in a shell).

This would imply that the problem is in the 2e.

The only suggestions I can come up with at this stage are (a) update the firmware to 0.4.8 if the affected units are running an earlier version, and (b) experiment with CR, LF, and CRLF as the termination strings, to see if one of those three persuades the 2e to close the session as soon as the command is sent. I'll ask Engineering to review this thread: this is starting to look like it could be a bug on our end.

[Harold Hallikainen]

Is it necessary to close the TCP connection right after the command? If a series of commands are sent, it seems like it would be faster in one TCP session. On TCP commands in general, as I recall, GDC servers open a connection on the first command to an IP address and then keep it open. Other servers tend to open and close the connection for each command. Doremi servers required us to put \w in front and in back of the command to keep the connection open long enough for the device to receive it. On stuff like the JSD-60 tcp_send, I used a single socket to send the commands, so it was set up before the command and torn down after the command was sent. This allowed the single socket to send commands to several IP addresses in sequence.