Lutron HWI with TCP/IP
wcravenel
Posts: 114
I've looked at all the threads. I know I am getting close.
I get a connection with online event visible in Studio, and then pass user comma password. Is there a definitive delay time for this to work best? Sending 'lutronGUI,jetski'.
My KBP command works in regular telnet session. Not from code. No feedback from HWI to device.
Web KP's , Illuminations , Telnet to HWI all work fine over LAN. NI-3000 otherwise fine.
Lutron tech support - two days last week have not been able to find the "right guy." AMX tech support says thumbs up but no preliminary code for for future Duet module to share.
Back on site today. Any help would be greatly appreciated.
Bill Ravenel
I get a connection with online event visible in Studio, and then pass user comma password. Is there a definitive delay time for this to work best? Sending 'lutronGUI,jetski'.
My KBP command works in regular telnet session. Not from code. No feedback from HWI to device.
Web KP's , Illuminations , Telnet to HWI all work fine over LAN. NI-3000 otherwise fine.
Lutron tech support - two days last week have not been able to find the "right guy." AMX tech support says thumbs up but no preliminary code for for future Duet module to share.
Back on site today. Any help would be greatly appreciated.
Bill Ravenel
0
Comments
OK, here it is, after, well, "much discussion":
Dave is correct (he knew this, of course...).
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
Thanks
Vince
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.
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.
Also are you using version 1.15 for Lutron?
Thanks
Andre
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.
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.
Heh, long response just to say this: I'd still go TCP.
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
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.
You can use piece of code posted here http://www.domedia.net/Fichiers/index.php?p=obj,/Protocols/Lutron/Homeworks+Interactive/AMX+NetLinx/
It works well, I use it for control of two Homeworks processor through IP connection with success
Vinc
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.
Thanks,
Eric
Here is the piece of code I posted link previously Hope it helps you
Vinc
Eric
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 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 )
Jeff
If you're having distance issues just use an IP/RS232 port server. Of course it would be nice if Lutron would just make the processors handle multiple sockets.
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.
Thanks.
--John
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.
Thx.
The connection does not drop.
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.
this is what I use, don't know about the duet mod.
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.
--John
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:
--John
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.
--John
I am having problems too to connect to lutron p5...
I am using the last module from the site -
Lutron_HomeWorksP5_v1_0_3_dr1_0_117.zip
LutronHomeWorksP5_dr1_0_117.jar
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...
and not even a single line about it in the code.
Thanks for any help.
Ady.
not event a word about this in the documentation.
are we talking about the P5 module?
I got that.
Ok, then what?
What I need to do in the code?
It not mention in the documentation at all.
This code will work for the P5?
ONLINE:
{
WAIT 50
{
SEND_COMMAND vdvLights, "'PROPERTY-IP_Address, ', cHomeworksIP_Address"
SEND_COMMAND vdvLights, "'PROPERTY-port, ', cHomeworksTelnetPort"
SEND_COMMAND vdvLights, "'PROPERTY-Login,"cHomeworksUsername,', ',cHomeworksPassword"
SEND_COMMAND vdvLights, 'REINIT'
}
}
Not even a single line about it, and the property login is not mention at all in the document or in the test program.
This is very strange, bottom line, I don't have a lutron driver to work with !