For real, I’m still shaking my head about this one. The details are weird but it’s a fun story.
The original email we received was similar to so many which have come in before. “We’re trying to control a handful of Grafik Eye 3500 wall panels via DMX. Can you help?”
We’ve done this before and it’s pretty standard stuff. By adding a QSE-CI-NWK-E interface to an existing Lutron system, it becomes easy to talk and listen to their control bus via RS-232. We’ve used this method for many years to easily control Lutron equipment via DMX.
The control syntax is nicely documented, human readable, and not difficult to implement. For example, the command #OUTPUT,1,3,75,0<CR><LF> sets dimmer #3 on device #1 to 75% with a zero second fade time. For ease of use, as per their documentation, <CR><LF> means each command is terminated with the carriage return and line feed characters. So that’s two bytes at the end of each command. No big deal.
In our normal firmware, we generate these commands easily on-the-fly as monitored DMX channels change their various states. Lutron does suggest that commands be sent with a 100mS delay between packets, and we definitely respect that that advice. Years ago we learned that some of their controllers would crash, hard, if we pointed a firehose of serial data at them.
Anyway, we emailed a firmware update file to the customer, in a different country several time zones away. And sadly, after the update, nothing worked. In these situations it’s not unusual to troubleshoot: Is the serial cable correct? Was a null cable installed by accident? Does a null cable need to be added? Are the baud rates equal? Did we get the Lutron device ID numbers correct? And so on and so forth. Usually after half an hour on the phone, or a couple emails back and forth, everything just works.
I suggested that if I were sitting on-site, I’d connect a laptop and serial cable to the QSE bridge and send some control strings manually, just to confirm the syntax was correct, etc. At that time, they didn’t have those tools nearby, but the Lutron system does accept the same commands over the network via Telnet. After an hour, the client replied replied that he could correctly control the lights using this syntax:
#DEVICE,5<CR><LF>,6,14,88 <— That is, dimmer/channel 6 on device #5 set to 88%. 14 is the command for ‘assign level’ in Lutron syntax.
Ok, no big deal. We sent new firmware which generated output like this:
That is, #Device,device ID, carriage return, line feed, then channel number, set value, value, time, carriage return, line feed. The terminal program, RealTerm, uses those micro-characters to represent non-printable characters. It’s a neat tool and makes it easy to tell if there’s non-ASCII garbage mixed in with a data stream.
No luck! The Lutron system only responded with random errors, which I forgot to screenshot as part of a TeamViewer session.
Finally, we went back to the notes the client took about their known-good control strings. Could it be that <CR><LF> is meant to be eight separate ASCII characters instead of the regular two bytes we’ve been using for years? This was such a strange idea, running counter to every set of Lutron firmware we’ve ever shipped, as well as all of their documentation. Ever. In the last ten years we’ve helped an awful lot of customers with this type of integration.
And thus, a new set of firmware was compiled and emailed. Check this out:
It works. No idea why, because it shouldn’t. We need to open a ticket with Lutron themselves to learn more. But until then, if you need help controlling their equipment with a DMX lighting console, please reach out. We’re always happy to help.
