Comments

You have to create a specific login for control. This is done in link 9, the ethernet link. The programming password (default = jetski) wil not work for control. You can connect, but nothing responds. You can verify proper connection by logging in with a regular Telnet session.

The standard login may establish a connection and allow commands to be sent and acted upon, but you won't get feedback. Need to setup user/pw with feedback that you want - Address Assignment tab, port 9 (Illuminations).

I will send to Jon P. in tech support my snippets of code, and to anyone else who would like it. Still needs prettying up, but I have control and LED tracking.

If given the option and your distance from Netlinxs processor to the HomeWorks processor was with in RS-232 specs would you opt for RS-232 or TCP/IP.

My personal peference would be RS232 despite the enormous speed difference, 1 because of the inherent problems TCP/IP pose, 2 the amount of chatter that would be imposed on the network (unless on it's own) and 3 the increased reliability factor that RS-232 has once properly connected.

I love TCP/IP but would opt for its use when required or has a significant benefit..

Now I don't have the experience in multiple installations and years of working with this stuff as alot of you forum members so I'd be interested in any one's thoughts on this subject.

I go for TCP whenever possible with Lutron control. You can specify exactly what feedback you want when you create the control login. Turning off dimming level feedback kills 95% of the chatter your basic Lutron system generates, and what's left will be no drain at all on your network bandwidth. Most jobs don't need more than keypad level feedback anyway ... the idea is to supplement the lighting control system, not replace it. Lutron's TCP implementation is rock solid (as I have come to expect from Lutron) and the connection itself offers no difficulties. I have not ever experienced even a tiny bit of unreliabilty, lost data, nor lack of connectivity with Lutron TCP. I've even connected with those Powerline-ethernet adapters, with no probelm at all.

For the Lutron systems you've done with TCP have you had the Q96 shade interface with shades on them? We've been having problems just uploading and downloading just the Lutron File over the LAN connection when Shades were involved so I've been hesitant to try and control Lutron over the TCP if the Lutron program itself doesn't work over TCP.

Are you getting a warning about the installed QED's something about the QED version or firmware being newer than the version supported by this version of HomeWorks Illumination software. Please contact Lutron Tech support. I get that everytime when adding a shade to a current project but I ignore it and have never called tech support and everything works fine.

Dave,

In the HomeWorks file that I currently using I do enable dimmer monitoring and use that to update a floor plan with all the lights displayed. I use the dimmed percentage to change the displayed opacity values of my TP lights to mimic the lights actual intensity. (instead of using levels for every light).

I haven't tried TCP/IP with a P5 processor yet but I have used a TCP/IP - RS232 converter on a series 4 processor that seemed to work fine. But that was just playing around and testing to see how that converter worked and afterwards I went back to RS232.

I guess I'm just a little hesitant to run this stuff on a shared network where any device on the network (customer products, etc.) could kill the system, lock up the router, whatever. Of course if that happens on a shared network the masters also down which makes it a moot point. I know I'm probably just paranoid with out reason but my recent/current TCP/IP woes have left me somewhat jaded. Maybe when the Cisco engineers fix my subnetting issues with the forthcoming firmware revision I'll have a network that work's the way it's supposed to and can give this another shot.

Yes, I'm running 1.15 beta - I don't think the release version of Illumination supports TCP yet. I can't say I have done a lot of them, but I have definitely worked with some Q96 controllers and TCP connections, and I don't recall any special problems with it. The last one I worked with, I was even connecting via 802.11 in a rather busy environment (I could pick up over a dozen neighboring WAP's). But, I must add, I wasn't involved in the original installation, it didn't come to me until we needed to integrate it with a NetLinx. I only had to make some minor adjustments to a working program - I can't say if my installer had trouble getting it to work in the first place, and I just benefitted from his hair-pulling.

Even with dimming feedback turned on, I think it would have to be an extremely busy system to detriment the LAN. Lutron packets are tiny, and (for a computer) there is a lot of space between them. It's nothing like the load streaming media puts on a network, and I have seen a lot of that go on before it was noticable.

I have a customer who mirrors his office server array at his home. He has a half dozen Dell servers in a rack in the house, and is continuously routing all of his office traffic through them over a T1 line. I have seven NetLinx masters in the house, a dozen CV-12's and a half dozen MVP-8400/s which also stream video from two camera servers. In addition to all that, there are two MAX 900's. The original MAX installation was on the same network as all of the rest of this stuff, and I never noticed any degradation of the network itself - I only moved the MAX to sa partition when I noticed the MAX itself was having some packet degradation issue. But none of that traffic degraded the network itself, or caused any control problems.

Yet, on the other side of the argument, I also had a rather small installation - single NetLInx with one MVP-8400, and an iTunes server of some sort on a Mac network. His network was brought completely to it's knees by a runaway channel update on the MVP (not my program, I must point out - it was one of the very few times we hired an independant because I was swamped at the time). It was turning the same channel on and off probably hundreds of times a second; eventually the NetLInx fell off line, his iTunes stuttered like crazy, and he was having trouble with Internet connections. From one line of bad code.

The difference I think it how rapidly the packets are being deployed. As long as there is adequate time for them to be processed by everything that needs to, the network won't be affected. And by all accounts, even the chattiest Lutron system isn't really spitting out that much data in close sequence. It's limited by correspondance to a hardware device; you can't turn a light on and off a hundred times in one second, and it's not likely in most installations that you will be turning a hundred lights on in the same second. And even if you did, I think the Lutron paces them.

The problem with the shades I have is that during the upload process that screen that shows what's happening will say something to the effect that it's checking shades and then the download will fail and a message will pop up about a time out and the terminal window and download window will get closed. The Lutron system itself will still be in a download mode with the led's on the keypads cyclying so we would then have to go and do the download through a serial cable.

Now we're still using the latest production release of the Illumination software 1.05 so I suspect that maybe the culprit. I tend to think the TCP/IP was improved in the beta versions to support the web keypads and such.

The problem with the shades I have is that during the upload process that screen that shows what's happening will say something to the effect that it's checking shades and then the download will fail and a message will pop up about a time out and the terminal window and download window will get closed. The Lutron system itself will still be in a download mode with the led's on the keypads cyclying so we would then have to go and do the download through a serial cable.

Now we're still using the latest production release of the Illumination software 1.05 so I suspect that maybe the culprit. I tend to think the TCP/IP was improved in the beta versions to support the web keypads and such.

Andre

Yeah, I think that may be it too. The beta is stable, I would switch over. Just remember, there is no turning back, once a project is converted, everyone who has to access it has to switch to beta too.

The standard login may establish a connection and allow commands to be sent and acted upon, but you won't get feedback. Need to setup user/pw with feedback that you want - Address Assignment tab, port 9 (Illuminations).

I will send to Jon P. in tech support my snippets of code, and to anyone else who would like it. Still needs prettying up, but I have control and LED tracking.

Bill

I have the same problem, a really need help to stablish comunication with Lutron. I think that your code could help me so much, could you sent it to me. Thanks.

I'm trying to use the duet module found on the amx site to control a P5 processor via TCP/IP.
I defined a username/password on the homeworks but I can not figure out where/how to configure the module to indicate what login to use.

Any help would be greaty appreciated...

Also, when following the hyperlink in the post from Vincen above, I get a message saying I don't have enough priviledge to access the resource and I'm redirected to a login page.

Just a heads up to anyone that uses the Lutron to send commands to the AMX system... there is no current support within the Lutron software to allow this via IP. I just went through the process of updating my include file for lighting to use the duet IP comm module and everything was working well until I got to the part where I parse the responses for commands

Just a heads up to anyone that uses the Lutron to send commands to the AMX system... there is no current support within the Lutron software to allow this via IP. I just went through the process of updating my include file for lighting to use the duet IP comm module and everything was working well until I got to the part where I parse the responses for commands

Jeff

I'm not following - you mean in the Duet module? I have been using full IP control for Lutron for a long time now, but I have my own modules for it. The Lutron certainly supports it, as long as it's a P5.

I'm not following - you mean in the Duet module? I have been using full IP control for Lutron for a long time now, but I have my own modules for it. The Lutron certainly supports it, as long as it's a P5.

I am not refering to controlling the Lutron processor from AMX. I had that working via IP and it seemed stable and as responsive as 232 comms. What I am refering to is setting up commands in the Lutron processor that are sent to the AMX processor to drive events within the AMX program.

Now, I know I could just track button pushes, but, if I have conditional programming in the Lutron, I would have to check the current state of that button within my AMX code before acting on it. If I had the same button functionality on 5 keypads, I would have to monitor all of them. And, most importantly, if I handle everything in Lutron, one of our installers that deals only with Lutron programming can make changes to the Lutron programming without breaking my code.

If you have found a way to do this with IP communications, I would love to free up a serial port, but the people at Lutron tech support said it was not possible at this time (But we all know this doesn't always reflect the actual hardware/software capabilities )

So does anyone know if this login information needs to be entered somewhere in the Duet Module for Homeworks (v1_0_2_dr1_0_117)? I'm setting up the _UI, _Main, and duet module for the Homeworks, but I don't see anywhere in the sample UI that might send a login username and password. I also don't see it in the module documentation, so I'm wondering if it's even needed in the duet module for the P5 processor. Here's the sample UI code where you send the login address/port info to the vdv.

Bump to the msg about the user/pass on the AMX sample code. I see the module documentation mentions the user/pass; is this something we should send with an ONLINE EVENT?

On a side note, does the IP port drop off line frequently, and if so, at what frequency? I am considering jumping from RS232 module to IP, and was wondering if there was a primer or addtional documentation regarding
Dynamic Device Discovery
IP Communications for Lutron (the IP module documentation seems sparse)

I would love to save a bit on hardware by using the IP stuff, but am wary of the overhead (using Duet modules sure seems to take up a lot of memory and horsepower when compared to a simple Netlinx RS232 module).

It would be nice to see a document from AMX that would spell out everything to avoid confusion; perhaps that should be done in the module documentation.

If you're working with your own code previously used on RS232 you'll need to modify your strings. The RS-232 comms required 13 at the end of all strings and the IP comms require 13 10. It took me a while before I figure this out.

The connection may not drop frequently, but it can - notably if someone is updating the Homeworks program. So make sure you put in provisions for re-connecting in the event it does drop.

If you don't use a login, the connection will still be made, and happily provide you with an online event and everything. It will just ignore everything sent to it. You can't go by an online event in this case: you aren't really connected until you see the LNET prompt.

One thing about the Dynamic Device Discovery. There's a beacon you need to turn on in the Homeworks panel to make it work. I can't remember what the command was exactly, but if you telnet into the Homeworks processor, and type a question mark at the LNET prompt (?), you should see a command listed for turning on the AMX beacon.

I never got the module to work and didn't get the Dynamic Device Discovery to work. I ended up writing my own limited function module just to get it going quickly.

Bump to the msg about the user/pass on the AMX sample code. I see the module documentation mentions the user/pass; is this something we should send with an ONLINE EVENT?

Looking at the documentation, there appears to be a Property key (which wasn't in the documentation prior to 10/29/07 when it was updated) for the username and password. The module should log you in during a device Online: event.

The docs call for a Login name as the <value>, but it should probably be the login string which would be your username and password together. If you're sending the login info as a command to the virtual device, then it should be in the online event for the virtual device. The _comm module will then have the info when it needs to log in to the actual device.

With this new (to me) information about the login key, I would think it would have to look like this:

and one more thing ...
If I remember correctly, the space after the comma was important for logging into the processor. In other words it should be "Username, password" with a space after the comma and before the password.

I loaded the test program to a TP and to a master.
I tired with Discovery, the test program on the TP didn't work.
Removed the Discovery and tried the direct way (all you need to do is to comment and uncomment few lines in the code ) - don't work too.

I didn't understand what I need to do with the user?
I read full documentation and not a word about it, the word login is not mention not there and not in the code...

Looking at the documentation, there appears to be a Property key (which wasn't in the documentation prior to 10/29/07 when it was updated) for the username and password. The module should log you in during a device Online: event.

The docs call for a Login name as the <value>, but it should probably be the login string which would be your username and password together. If you're sending the login info as a command to the virtual device, then it should be in the online event for the virtual device. The _comm module will then have the info when it needs to log in to the actual device.

With this new (to me) information about the login key, I would think it would have to look like this: