Lutron QS Integration

bano

I?m having some communication/control/feedback issues with a Lutron QS standalone system. The original system consisted of 4-ALDH48 processors tied together with amx code. One of the ALDH48 processors failed and neither amx or Lutron could or would repair it necessitating an upgrade. Everything else is as it was. All the legacy Maestro dimmers/switches and keypads are being used, just switched out the boards (H48) and processor. Communication is via rs-232 using the QSE-CI-NWK-E network interface device. Baud rate is set at 9600, controlled via an NI-900 located inside the dimmer box with a 1 foot jumper between the serial ports, pins 2,3,5 straight through. Lutron programmer is having to use the latest (beta) software to communicate with thee legacy keypads/dimmers/switches. Amx communicates to dimmers/switches via #OUTPUT commands and feedback at the load level. Communication for keypads is handled via #DEVICE commands for push and LED feedback. The problem I?m having is that Amx communication with random dimmers/switches is freezing up control and feedback from time to time, and the only way to unfreeze is to go to the physical dimmer/switch and toggle it. Also there are issues with some of the Lutron keypad?s communication with loads outside of the Amx influence. Any thoughts, ideas suggestions?

vining

I normally used 115,200 for lutron serial comms, everything lately has been IP. when these dimmers/switches freeze can the Lutron installer control the load from the QS software, telnet window (QS?) or diagnostics verify load? If not it's likely a Lutron issue. I haven't done a new Lutron system for a while and the ability for a QS processor to be backwards compatible with Illumination stuff is new and probably quircky. If the QS bridge doesn't work out and you need I have a never used series 8 P5 w/ MI & H48 that I'd love to get rid of.

nicolau

I once had a problem with feedback on dimmers and switches from the old Homeworks. Everytime the system connected to the Lutron processor all dimmers and switches were ON and they needed to be pressed to get the real feedback (that also happened when we updated programming at the Lutron system). I was using the AMX module and what I did to solve this was to create a timeline to send two commands in sequence, first SEND_COMMAND vdvLights,"'PASSTHRU-STOPDIM, ,']'" and the other was SEND_COMMAND vdvLights,"'?LIGHTSTATE-',ITOA(nLOOP1)". The first command (PASSTHRU) seemed to restore communication on the module.