Home AMX User Forum AMXForums Archive Threads AMX Applications and Solutions

Lutron Homeworks Lighting Control

OK - I've done a lot with the Graphic Eye 3000, 4000, and the bigger 5000 systems, but have never run in to the Homeworks system. Is the control difficult. Any tips? I found a really old module on the inconcert site that loooks like it might work. has anybody used this?

I am really looking for some direction here.

I have the Protocol manual and it seems straight forward.
«1

Comments

  • DHawthorneDHawthorne Posts: 4,584
    I havemy own modules for Homeworks that have survived many updates and changes. The protocol is unchanged as near as I can tell, you can use the old modules just fine. The only update I have made to mine to to support IP control, otherwise they haven't changed in years.
  • alexanboalexanbo Posts: 282
    The one change that happened was the wireless link needs an extra parameter in the address but the last inconcert module has that in it.
  • ondrovicondrovic Posts: 217
    For our company we have a seperate person who programs the lutron, and in my experience ( which isnt that much lol ) but it depends on the equipment that is put in and how the lutron is programmed. But it some what simple. If you want to emulate scenes that are already present you just setup a call (or however you want to do it ) for the amx to do a push on the lutron.

    EX:
    Send_string dvLutron,"'KBP, [01:06:015], 1',13"
    
    

    KBP = Key Button Press if I am not mistaken other information .... drawing a blank right now lol

    Here is making a fade with a Fixture that doesnt have any scenes set up in the lutron
    Switch(nPush)
        {
    	Case 1:	{Send_String dvLutron,"'FADEDIM,80,2,0,[01:04:01:02:02]',13"}
    	Case 2:	{Send_String dvLutron,"'FADEDIM,50,2,0,[01:04:01:02:02]',13"}
    	Case 3:	{Send_String dvLutron,"'FADEDIM,0,2,0,[01:04:01:02:02]',13"}
        }
    

    not sure if this is helpful or if im 100% right on this
  • JohnMichnrJohnMichnr Posts: 279
    Thanks for the responce. That was helpful!

    I figured I would be doing keypad presses, then getting the status of the keypad for tally.

    There is a set of drapes and shades as well that are being controlled through this system.
  • ondrovicondrovic Posts: 217
    the drapes I think you can control with a relay from the master the just setup a call to close the drapes and set the light to the desired setting
  • DHawthorneDHawthorne Posts: 4,584
    If the drapes are Sivoia (the Lutron brand) there is a separate command for it.

    The keypad command listed is correct, but I would recommend doing it something like this:
    BUTTON_EVENT [dvLutron_TP, nLutronButtons]
    {
        PUSH :
        {
            SEND_STRING dvLutron, "'KBP, [01:06:', ITOA(BUTTONINPUT.CHANNEL, '], 1',13"
        }
        HOLD [5] :
        {
            SEND_STRING dvLutron, "'KBH, [01:06:', ITOA(BUTTONINPUT.CHANNEL, '], 1',13"
        }
        RELEASE:
        {
            SEND_STRING dvLutron, "'KBR, [01:06:', ITOA(BUTTON.INPUT.CHANNEL, '], 1',13"
        }
    }
    
    That will completely preserve the hold-to-dim functions on the Lutron keypads. My practice is to create a virtual keypad in the Lutron system, and reference that address with the AMX; that way it is completely independant, and you can make buttons with discrete scene selections without tying up real buttons. If the customer insists on running the entire system on the AMX, of course, you have a bit of tracking and housekeeping to do, and you can't use the virtuals (they take up the same address space as a real keypad, you would run out of addressing real fast). Another advantage of a virtual is that you can put all the fancy sequencing and programming available to the Lutron system on the virtual button and there is no need to maintain a separate program just for all that, and that includes special interface commands like RAISE and LOWER for drapes and motors. You only need PUSH, HOLD, and RELEASE.

    The feedback is pretty much the same as the outgoing command. If a keypad button is pressed anywhere, you get back the appropriate "KBP, <addresss>, <button>" response. Another advantage of using virtuals: you can progrm the type of feedback in your Lutron system, and just read it out of the feedback to turn on the same channels on your panel. If you track individual lighting loads, you are now processing a lot of strings from the Lutron system; I wouldn't do that. Stick to scenes or lights they are actually in the room for to see the level. It's all or nothing with feedback levels, a whole house of dimmer levels coming into your AMX can really bog things down if you are only interested in a dozen light switches.
  • JohnMichnrJohnMichnr Posts: 279
    Thanks - Yeah in my lighting I try to stick with the scene select only. Customers are not usually paying me to duplicate the Lutron control program!

    It is good to know about the virtual keypads. I read a little about that somewhere and was not sure if people used them or not.

    The room (and it is a single room that I need to control - Why they just didn't put in a graphic eye I will never know) has all of its own control keypads. Of course the room is 250 miles away from me, the lighting system provider saw no reason to show up while I was there to program the system, and the Sevioa drapes and shades were just ordered last week, so they are a month out. So now I have an additional trip that somebody has to pay for. and another post asked how projects don't get finished?...

    Is there a command or dip switch you have to engage to receive the keypad (KBP) pushes? or is that data just available on the bus?
  • GasHedGasHed Posts: 31
    We also do as Dave describes... setup 'phantom' keypads on the Lutron system to do the dirty work and then just send button presses and listen for LED status (KLS...) for feedback.

    Pat
  • Any ideas on how to control Lutron via IP using AMX Netlinx?

    Thanks,

    Ricardo
  • Spire_JeffSpire_Jeff Posts: 1,917
    If you get a system with a lot of see-touch keypads... the ones with up to 6 buttons plus a raise and lower button, you can use the hidden buttons for more specific control or reporting. I normally setup AMX specific control functions and reporting (such as room logic feedback) on the hidden buttons within a room to help me keep the stuff organized. But, I program both the AMX and Lutron systems. If you are working with someone else, you might want to develop a standard with that person.

    Also, make sure you enable status tracking of any keypads you interact with so that you will get the LED status info. (if you use the inconcert module) And I do use the inconcert comm module without problems.

    Jeff
  • JohnMichnrJohnMichnr Posts: 279
    did you modify the module (the documentation said the source code was available(?)) or just put in a data_event for the virtual?
  • Spire_JeffSpire_Jeff Posts: 1,917
    I added a DATA_EVENT for the physical device. As I recall, the virtual doesn't pass the strings from serial commands generated by the Lutron processor.
  • JohnMichnrJohnMichnr Posts: 279
    Great - thanks for all the info...
  • You might want to consider using hardware handshaking. This is an option in the Lutron processor. The reason being is that Lutron sends lot of data if you monitor LED status for many stations. Of course you will need to build the appropriate cable as well as configure the NetLinx port.

    I built my own Homeworks module years ago. I use an array of constants to define all the stations to control and monitor. You simply point to the array index to pick the station you want to control.
  • DHawthorneDHawthorne Posts: 4,584
    JohnMichnr wrote:
    Is there a command or dip switch you have to engage to receive the keypad (KBP) pushes? or is that data just available on the bus?
    Send the Lutron a "KBMON" command in your online event. You can set the monitoring in the port setup for the Lutron, but I prefer not to leave such things open to the possibility of something resetting it (like a lighting programmer who didn't understand why it was there and took it out).
  • GasHedGasHed Posts: 31
    Lutron Control via IP

    To initialize communication with the processor:
    IP_CLIENT_OPEN(dvHWI.PORT,'192.168.0.200',23,1)
    WAIT 20
    {
       SEND_COMMAND vdvHWI,"'lutron,jetski'" // Default username/password
    }
    
    Then, check out the RS232 protocol guide for parsing the communication strings. You have to enable monitoring in the Lutron software for the ethernet port as well.

    Pat
  • DHawthorneDHawthorne Posts: 4,584
    GasHed wrote:
    To initialize communication with the processor:
    IP_CLIENT_OPEN(dvHWI.PORT,'192.168.0.200',23,1)
    WAIT 20
    {
       SEND_COMMAND vdvHWI,"'lutron,jetski'" // Default username/password
    }
    
    Then, check out the RS232 protocol guide for parsing the communication strings. You have to enable monitoring in the Lutron software for the ethernet port as well.

    Pat
    My understanding is this won't work with the most recent versions (it sure as heck didn't work when I tried it!). You need to create a login specifically for your control device on link 9 (ethernet), set up a login there, and send that in response to the LOGIN prompt. The jetski password only works for the programing tool.
  • kennyannkennyann Posts: 113
    TCP with Lutron

    I just returned from Lutron training. I was told by the instructor after some investigation that I have to create my own account on the Lutron system and log into it through the AMX system. I have not tried doing that yet becuase I do not have a Lutron with TCP port. I hope to get one in soon.

    Thank you
  • I am able to control the Lutron P5 panel via IP, but the LED feedback doesn't work. However it works via RS-232. Here is my feedback ARRAY that works via serial connection, but not via IP. Any ideas or suggestions?
    DATA_EVENT[vdvHWI]
    {
        STRING:
        {
    	//Process RF link 1:8:2:? LEDs
    	IF (FIND_STRING(DATA.TEXT, "'K:L:[1:8:2:'", 1))
    	{
    	    REMOVE_STRING(DATA.TEXT, '[1:8:2:', 1)
    	    sHWI_KP = REMOVE_STRING(DATA.TEXT, ']:',1)
    	    SET_LENGTH_STRING(sHWI_KP, LENGTH_STRING(sHWI_KP)-2)
    	    sHWI_BUT = REMOVE_STRING(DATA.TEXT, ':',1)
    	    SET_LENGTH_STRING(sHWI_BUT, LENGTH_STRING(sHWI_BUT)-1)
    	    nHWI_BUTTONS[ATOI(sHWI_KP)] [ATOI(sHWI_BUT)] = ATOI
    	}
          }
    }
    

    When sending commands via IP, you will need to add CR, LF to the end of your command, it will also work for serial control, but without CR, LF at the end, it won't work for IP. Thanks DHawthorne for helping me with this part. Example:
    // Works under IP and RS-232
    SEND_COMMAND vdvHWI, "'K:P:[1:8:2:26]:1', 13, 10"
    
    // Works under RS-232 only
    SEND_COMMAND vdvHWI, 'K:P:[1:8:2:26]:1'
    

    Now, all I need is to adapt the feedback array above, which works under RS-232, to work under IP. I appreciate any help.

    Ricardo
  • By the way I am using the latest AMX Lutron HWI module v2.2. The module was designed for RS-232 control, but with the help of DHawthorne I am able to connect to the Lutron P5 panel via IP and send commands successfully, the only part that doesn't work is the feedback for the LEDs, which works fine via RS-232.

    I run a diagnostics on both IP and Serial connections using Windows telnet to the Netlinx Master/msg on, as well as turning the virtual device vdvHWI channel 3 on for extended debug messages using the "Emulate Device" option in Netlinx Studio. I noticed the following:

    Telnet (Serial/RS-232 Control):
    sending --> KBP, [1:8:2:1],1
    HWIparseCmd<>: KLS,[01:08:02:01], 100000000000000000000000
    HWIprocLED<>: KLS,[01:08:02:01], 100000000000000000000000
    HWIprocLED<>: sending notify string = K:L:[1:8:2:1]:1:1
    HWIprocLED<>: sending notify string = K:L:[1:8:2:1]:2:0


    Telnet (IP Control):
    sending --> KBP, [1:8:2:1],1
    LNET>
    HWIparseCmd<>:
    LNET>
    HWIparseCmd<>: command not supported
    LNET>
    KLS,[01:08:02:01], 100000000000000000000000


    Now I Think I know why my LED processing array from the above message doesn't work under IP. For some reason the AMX Comm Module interprets differently the same command when it is sent via IP, and never sends out a
    HWIprocLED<>: sending notify string.

    //Command below under RS-232 and IP, but feedback works only for RS-232
    SEND_COMMAND vdvHWI, "'K:P:[1:8:2:1]:1', 13, 10"

    I wish AMX would update the Comm module to work with either RS-232 or IP. This shouldn't be hard since they already have the H48 code done. I heard that the IP control works much faster, what is ideal for larger Lutron jobs with AMX control. Any ideas or suggestions?

    Thanks,

    Ricardo
  • Spire_JeffSpire_Jeff Posts: 1,917
    Don't quote me on this, but I vaguely recall hearing that the IP connection does not support all of the functionality of the RS232 port on the Lutron processor. Have you called Lutron tech support to verify if this is possible yet?

    Jeff
  • GasHedGasHed Posts: 31
    I haven't found any RS232 commands that don't work yet over IP. You do have to enable feedback for the various events (light level changes by dimmers, keypad press and releases) through the Illumination software for the ethernet port, but that seemed to be the only 'trick'. Here's some command parsing code I use for the LED feedback:
    DEFINE_CALL 'UPDATE_LEDS' (CHAR lclADDRESS[], CHAR lclSTATUS[])
    {
      FOR(I=1;I<=nKEYPAD;I++)
      {
        IF(COMPARE_STRING(lclADDRESS, kpKEYPAD[I].ADDRESS))
        {
          FOR(J=1;J<=24;J++)
          {
            kpKEYPAD[I].ledSTATUS[J] = lclSTATUS[J]-48
          }
        }
      }
    }
    
    The above call updates a keypad structure for a given keypad address and LED status string of 0's and 1's. Then, you need to listen for the KLS command from Lutron:
    ACTIVE(FIND_STRING(curFB,'KLS',1)):
    {
      REMOVE_STRING(curFB,'KLS, ',1)
      lclADD = REMOVE_STRING(curFB,'], ',1)
      lclADD = LEFT_STRING(lclADD, LENGTH_STRING(lclADD)-2)
      lclPARAM = REMOVE_STRING(curFB,"$0D,$0A",1)
      lclPARAM = LEFT_STRING(lclPARAM, LENGTH_STRING(lclPARAM)-2)
      CALL 'UPDATE_LEDS' (lclADD, lclPARAM)
    }
    

    Let me know if you have any questions,

    Pat
  • DHawthorneDHawthorne Posts: 4,584
    I almost forgot all about this: when you create a login for IP control in the Lutron, you specify the feedback you want there. It's entirely too easy to miss that, and could cause no feedback strings to be sent.
  • Yes, I do have monitor KEYPAD LEDS checked on the Link 9:(Ethernet). I do receive the KLS, but for some reason when connecting via IP the HWIparseCmd doesn't work as it works under RS-232. This command is internal to the HWI AMX module. The whole feedback structure of the RS-232 works based on K:L: notifications, which apparently are not sent via IP. I will study GasHed code and try implementing it. Did anybody get the AMX module K:L: notifications to work via IP?

    Thanks,

    Ricardo
  • DHawthorneDHawthorne Posts: 4,584
    I have never seen the whole K:L thing before, ever. Are you sure that isn't what the comm module pules out, not what the Lutron itself does?
  • I believe that the AMX Comm Module takes the KLS and converts it to a K:L: notification as below:

    Telnet (Serial/RS-232 Control):
    sending --> KBP, [1:8:2:1],1
    HWIparseCmd<>: KLS,[01:08:02:01], 100000000000000000000000
    HWIprocLED<>: KLS,[01:08:02:01], 100000000000000000000000
    HWIprocLED<>: sending notify string = K:L:[1:8:2:1]:1:1
    HWIprocLED<>: sending notify string = K:L:[1:8:2:1]:2:0

    I am wondering why via IP it doesn't do the same.
  • DHawthorneDHawthorne Posts: 4,584
    I believe that the AMX Comm Module takes the KLS and converts it to a K:L: notification as below:

    Telnet (Serial/RS-232 Control):
    sending --> KBP, [1:8:2:1],1
    HWIparseCmd<>: KLS,[01:08:02:01], 100000000000000000000000
    HWIprocLED<>: KLS,[01:08:02:01], 100000000000000000000000
    HWIprocLED<>: sending notify string = K:L:[1:8:2:1]:1:1
    HWIprocLED<>: sending notify string = K:L:[1:8:2:1]:2:0

    I am wondering why via IP it doesn't do the same.

    My point is that it does. The problem is not in the Lutron, but the AMX comm module. The only difference at all between IP and serial from the Lutron is that IP uses CR/LF, and serial only uses CR as a terminator. If I had to guess, I would say the comm module doesn't parse that correctly. Call AMX on it, I have had them send a module back to development for bugs (they are working on one for me as we speak, as a matter of fact).

    If you cannot wait on that, just override the KLS notification. Put a STRING event in your code for the IP port and parse it yourself. Use the module for everything else and do your own feedback.
  • thanks a lot!!!.....I was trying to understand what I'm doing wrong and.....is AMX Module not me!!!!

    As far as I can check AMX module have a problem with "K:N" command (is the basic command to led feedback). Even when I send one keypad, module do not process request because can not identify that keypad.

    COMM RECEIVED FROM MAIN : N:K:[ 01:05:25]
    HWIprocReq(): N:K:[ 01:05:25]$0D
    HWInotifyReq(): N:K:[ 01:05:25]$0D
    HWInotifyReq(): address already in notify list$0D
    COMM RECEIVED FROM MAIN : K:L:[ 01:05:25]:1:?
    HWIprocReq(): K:L:[ 01:05:25]:1:?$0D
    HWIkeypadReq(): K:L:[ 01:05:25]:1:?$0D
    HWIkeypadReq(): keypad not in notify list$0D
  • Lutron comm

    Try attached for parsing feedback. Module did not work for me. (neither are attachments her w/ Firefox).


    define_function TESTkp(char buff[])

    {
    stack_var char temp[30]

    stack_var char tProc[5]
    stack_var char tLink[5]
    stack_var char tKP [5]
    stack_var char tBtns [35]

    stack_var integer btn

    stack_var integer arr_proc
    stack_var integer arr_link
    stack_var integer arr_kp
    stack_var integer arr_btn
    stack_var integer arr_status

    temp = remove_string(buff, 'KLS, [', 1)

    // Only care about LED feedback
    if (!length_string(temp))
    {
    return
    }
    tProc = remove_string(buff, ':', 1) // get Processor #
    set_length_string(tProc, length_string(tProc) - 1)
    arr_proc = ATOI(tProc)

    tLink = remove_string(buff, ':', 1) // get Link #
    set_length_string(tLink, length_string(tLink) - 1)
    arr_link = ATOI(tLink)

    tKP = remove_string(buff, '], ', 1) // get KP #
    set_length_string(tKP, length_string(tKP) - 3)
    arr_kp = ATOI(tKP)

    tBtns = remove_string(buff, "$0D,$0A", 1) // get Btn string
    set_length_string(tBtns, length_string(tBtns) - 2)
    // can nest next section within loops for links and processors if required
    FOR(J=1;J<=24;J++) // buttons on KP
    {
    LEDS [1] [6] [arr_kp] [J] = ATOI(MID_STRING(tBtns,J,1)) // possible states of lutron buttons
    }

    }
  • dafranrodafranro Posts: 7
    Pass
    Yes, I do have monitor KEYPAD LEDS checked on the Link 9:(Ethernet). I do receive the KLS, but for some reason when connecting via IP the HWIparseCmd doesn't work as it works under RS-232. This command is internal to the HWI AMX module. The whole feedback structure of the RS-232 works based on K:L: notifications, which apparently are not sent via IP. I will study GasHed code and try implementing it. Did anybody get the AMX module K:L: notifications to work via IP?

    Thanks,

    Ricardo


    Ricardo, I have problems to stablish conection with Lutron, Could you sent me some part of your code, I think the problem is the password, but I dont understand how can I creat one. Thanks
Sign In or Register to comment.