Lutron TCP/IP Comms

jwells

Hi,
I was wondering if anyone had managed to get sucesful reliable comunications with luton via TCP/IP

I've have managed to get a connection established and a responce back from the Lutron CPU and it enters the LOGIN: promt into the buffer. This also triggers the Active Find statment and the sends a string to the debug port 0. However, it just seems to hang when trying to send it the login details. I've cut the code right back to basics and still get this problem. I have also changed the IP address to open a connection to my PC with telnet and all seem to be in order, but I cannot get the system to comunicate with the Lutron CPU ? any ideads. I can also happily logonto the Lutron CPU via Telnet.

The diagnostics window seems to flash like it trying to tell me something.

I also noticed in the Diagnostics window a DDD statment saying it has found a dynamic device and its the Lutron Processor. Could this be conflicting with the manual IP connection I'm trying to establish ?

PROGRAM_NAME='IP Comms_Basic'

DEFINE_DEVICE
dvTP		=	205:1:5
dvLUTRON	=	0:6:5	// CLIENT CONNECTION - DEVICE BEING CONTROLLED

DEFINE_CONSTANT
TCP = 1
UDP = 2

DEFINE_VARIABLE
CHAR LUTRONBuff[2048]

DEFINE_MUTUALLY_EXCLUSIVE

DEFINE_START
CREATE_BUFFER dvLUTRON,LUTRONBuff

DEFINE_EVENT

BUTTON_EVENT [dvTP,1]		// OPEN COMMS TO IP DEVIVE
    {
    PUSH:
	{
	IP_CLIENT_OPEN (dvLUTRON.PORT,'192.168.10.70',23,TCP) 
	}
    }
    
BUTTON_EVENT [dvTP,2]		// CLOSE COMMS
{
    PUSH:
    {
    IP_CLIENT_CLOSE (dvLUTRON.PORT)
    }
}


BUTTON_EVENT [dvTP,4]
{
    PUSH:
    {
    SEND_STRING dvLUTRON, "'amx,password', $0D"
    }
}

BUTTON_EVENT [dvTP,5]
{
    PUSH:
    {
    SEND_STRING dvLUTRON, "$0D"
    }
}

DATA_EVENT[dvLUTRON]
    {
    STRING:
	{
	SEND_STRING 0,"'IH_Debug:  (via string debug) ',Data.Text"
	SELECT			// LOGIN REQUEST
	    {
	    ACTIVE (FIND_STRING(DATA.TEXT,'LOGIN:',1)):		// REQUEST FOR USER NAME
		{
		// SEND_STRING dvLUTRON, "'amx,password', $0D"		// SEND USER NAME
		SEND_STRING 0, "'IHDebug: Lutron Login: Prompt seen'"
		}
	    }
	}
    ONLINE:
	{
	// SEND_STRING 0,"'IH_Debug:  (via online debug)',Data.SourceIP,' online: client'"
	}	
    OFFLINE:
	{
	// SEND_STRING 0,"'IH_Debug:  (via offline debug)',Data.SourceIP,' offline: client'"
	}
    ONERROR:
	{
	// SEND_STRING 0,"'IH_Debug: LUTRON error: client=',ITOA(Data.Number)"
	}
    }

wcravenel

Hi Justin,

Check this thread: http://www.amxforums.com/showthread.php?t=1739&highlight=lutron+password

I can't speak to the DDD issue, but I have excellent results with IP & Lutron.

Tech support likely has the basics of the code I am using, and I would be happy to send same to you directly. LMK. I struggled for a long time with both Lutron and AMX to solve this login issue....

Bill Ravenel

vining

There is a different login for TCP/IP comms that there is with terminal using the "jetski" login. I believe its in the same area as the webservers login user name and password but I just ried looking and couldn't find and as I pressed for time I can't continue the search.

Are you using the beta 1.16? This version has the webserver built in for keypad control and multiple user/passwords.

This was also discussed recently on the forum so you should be able to find the thread.

DHawthorne

This didn't come up in our PM conversation, but the IP commmunications requires a CR/LF line end rather than just a CR (unlike the RS-232 port). Terminate your strings with $D, $A instead of just $D and see what that does for you.

I don't believe the DDD thing matters if you do not explicity hook to it in your code. There is a NetLinx command for using DDD (I forget the syntax off the top of my head); if you don't include it, your master will be aware of the DDD device, but won't do anything about it.

jwells

Cheers, it all working with the $0D, $0A. I didn't realise you needed a line feed for IP comms. Is this the case for all TCP/IP comms ?

Thanks for you help.

DHawthorne

jwells wrote:

Cheers, it all working with the $0D, $0A. I didn't realise you needed a line feed for IP comms. Is this the case for all TCP/IP comms ?

Thanks for you help.

No, I think it's a quirk of the Lutron firmware. This is the protocol itself, the transport shouldn't have anything to do with it. It's certainly not inherent to all TCP/IP communication.