RTI to AMX via Serial

cheekytigerapps

I am doing a job in-which we are using RTI remotes to control an AMX system. To do that I am planning on using an RTI XP-8 and connect it to the AMX master via RS232 and associate every button on the RTI remote with an RS232 command and send it to the master.

I was wondering if anyone has done this before and could share some tips. Has anyone made a driver/module to do this as I know that their is one available for RTI to ********.

P.S: I know you can do it over RF with AMX RF Ants but there are not enough RF codes and.

cheekytigerapps

I mean Cr8stron

TonyAngelo

I've done this and it works well.

The protocol I setup is as follows:

Header:Action:Zone

Where Header is something like PC (power control), VC (volume Control), SS (source select), BP (button push), etc.

So a command would look something like this:

PC:01:03

That would turn on zone three.

You can setup the protocol however you like though.

shr00m-dew

We've done it before. Keep in mind that the last I checked if it's not in a macro, simultaneous calls to the same port on RTI will result in one working/one not. We wound up using a one-to-one RS232 relationship AMX to RTI. That made it easy on both sides. RTI button repeatedly sends PUSH=## as the button is held, AMX strips everything up to = and does a DO_PUSH_TIMED(virtual_remote_x,##).

Use the virtual as you would any AMX device and have full push/hold/release control from RTI.

If we need to do it again, I would create an iP driver for RTI that did the same thing. Load up a driver for each remote you have. They loved the T1B's so much we wound up doing 12 of them around the house and that got expensive on both the RTI and AMX side port wise.

Kevin D.

cheekytigerapps

Thanks for that.

Just to simplify my burden. I was wondering if anyone could post some sample code.

Once i have finished this project with RS232 I may write an RTI driver to allow for IP control or at least simplify the procedure (or something more native).

RicardoSiqueira

Anybody out there whiling to share your solution for the RTI/AMX/Serial control. I've noticed that when you have 2 RTI remotes sending pushes at the same time one gets processed the other doesn't. I wonder if there is a better way to handle this. Either IP or by using an incoming string queue. Here is what I am trying:

DATA_EVENT[dvRTI]
{
    ONLINE:
    {
	SEND_COMMAND dvRTI, "'SET BAUD 9600,N,8,1, 485 DISABLE'"     
    }

    STRING:
    {
       
	//"RMxxCHxxx"  - RM = Room 01 and CH = Channel to push 001
	IF(FIND_STRING(RTI_BUFFER,'RM',1))
	{
	    RTI_ROOM = ATOI (MID_STRING(RTI_BUFFER,3,2))
	    RTI_CMD  = ATOI (MID_STRING(RTI_BUFFER,7,3))

	    send_string 0, "'String From RTI = ', RTI_BUFFER"
	    send_string 0, "'ROOM = ', RTI_ROOM"
	    send_string 0, "'CMD = ', RTI_CMD"

	    SWITCH(RTI_ROOM)
	    {
		CASE 1:
		{
		    DO_PUSH(vdvRemote1,RTI_CMD)
		}
		CASE 2:
		{
		    //DO_PUSH(vdvRemote2,RTI_CMD)
		}
	    }

	    WAIT 5
		CLEAR_BUFFER RTI_BUFFER 
	}
	ELSE
	{
	    CLEAR_BUFFER RTI_BUFFER 
	}
    }
}

Any suggestions or sample code? Thanks!

vining

One thing that might be causing a problem is the use of DO_PUSH. Once that fires it can't be used again for .5 seconds which is the time it takes for the automatic release so you could use DO_PUSH_TIMED for .1 seconds or follow with your own DO_RELEASE. In the code below I used the TIMED at .1 seconds but I included a commented out do_release.

Another problem might have bee your wait 5 clear buffer since when the wait expires it may fire just as data comes in prior to the data event triggering or maybe it fires and dumps the buffer before the you have a complete string although that's not really likely with these short strings but for that reason I always like to cancel the wait and then wait so that it doesn't dump until the data event handler has been idle for the wait period.

This code isn't tested or compiled so there might be error but this is sort of how would deal with it and might fix you issues with multiple room pushes at the same time.

DATA_EVENT[dvRTI]
     
     {
     ONLINE:
	  {
	  SEND_COMMAND dvRTI, "'SET BAUD 9600,N,8,1, 485 DISABLE'"     
	  }
     
     STRING:
	  {
	  //"RMxxCHxxx"  - RM = Room 01 and CH = Channel to push 001
	  
	  send_string 0, "'RTI, RX-[ ', DATA.TEXT,' ]'";
	  
	  CANCEL_WAIT 'RTI_DUMP_BUFFER';//prevent dumping buffer if data is coming in, might dump data before data event fires
	  
	  WHILE(FIND_STRING(RTI_BUFFER,'CH',1))//having a delimiter would be nice but...
	       {
	       STACK_VAR INTEGER nFBS;
	       STACK_VAR CHAR cStr[128];//larger than needed in case there's junk
	       
	       nFBS = find_string(RTI_BUFFER,'CH',1);
	       if(length_string(RTI_BUFFER) >= nFBS + 4)//make sure we have at least 3 digits since no delimiter
		    {
		    cStr = GET_BUFFER_STRING(RTI_BUFFER,nFBS + 4);
		    
		    send_string 0, "'RTI, Parsing Segment-[ ', cStr,' ]'";
		    
		    REMOVE_STRING(cStr,'RM',1);//get rid of RM and any junk before it
		    RTI_ROOM = aoti(GET_BUFFER_STRING(cStr,2);
		    //RTI_CMD  = atoi(RIGHT_STRING(cStr,3);//
		    //or just
		    RTI_CMD  = atoi(cStr);
	      
		    send_string 0, "'RTI, ROOM = ', itoa(RTI_ROOM)"
		    send_string 0, "'RTI, CMD = ', itoa(RTI_CMD)"
	       
		    SWITCH(RTI_ROOM)
			 {
			 CASE 1:
			      {
			      DO_PUSH_TIMED(vdvRemote1,RTI_CMD,1);//use timed, otherwise another push won't work for .5 seconds
			      //DO_RELEASE(vdvRemote1,RTI_CMD);//if you need the release even faster
			      }
			 CASE 2:
			      {
			      DO_PUSH_TIMED(vdvRemote2,RTI_CMD,1);//used timed, otherwise another push won't work for .5 seconds
			      //DO_RELEASE(vdvRemote2,RTI_CMD);//if you need the release even faster
			      }
			 }
		    }
	       else
		    {
		    send_string 0, "'RTI, Parsing ERROR, Segment-[ ',RTI_BUFFER,' ]'";
		    WAIT 50 'RTI_DUMP_BUFFER'
			 {
			 CLEAR_BUFFER RTI_BUFFER;
			 }
		    }
	       }
	  WAIT 50 'RTI_DUMP_BUFFER'
	       {
	       if(length_string(RTI_BUFFER))
		    {
		    send_string 0, "'RTI, Dumping buffer remains, BUFFER-[ ',RTI_BUFFER,' ]'";
		    CLEAR_BUFFER RTI_BUFFER;
		    }
	       }
	  }
     }

Edit:
Looking at the code I posted there's a potential for the while loop to hang if there isn't 3 or more characters after the CH. If no more data comes in it will time out when the buffer dumps but that still locking up the processor for the duration of the dump wait. If you could add a delimiter like ; or $0d,$0a that would simplify things but you could try changing the while to this you can't:

WHILE(FIND_STRING(cJSON_Buffer,'CH',1) && (LENGTH_STRING(cJSON_Buffer) >= find_string(cJSON_Buffer,'CH',1) + 4))

this might work but again it's untested, then you could get rid of the if() that follows the while. Best thing would be to have the RTI strings sent with a delimiter.

RicardoSiqueira

Vining,

Thanks for taking the time to assist me on this. If I use a delimiter, what would be the best approach on the while loop and how would the code look like? I can format my RTI strings like this:

RM01CH001\r

or

01:001\r

RM01 = Room Number, always in 2 digits, like 01, 03, or 13

CH001 = Channel number, always in 3 digits, like 001, 056 or 999

\r = Carriage Return from RTI

vining

Ok if you can add that delimiter that makes it easier and more reliable and I would then try it like this.

DATA_EVENT[dvRTI]
     
     {
     ONLINE:
	  {
	  SEND_COMMAND dvRTI, "'SET BAUD 9600,N,8,1, 485 DISABLE'"     
	  }
     
     STRING:
	  {
	  //"RMxxCHxxx"  - RM = Room 01 and CH = Channel to push 001
	  
	  SEND_STRING 0, "'RTI, RX-[ ', DATA.TEXT,' ]'";
	  
	  CANCEL_WAIT 'RTI_DUMP_BUFFER';//prevent dumping buffer if data is coming in, might dump data before data event fires
	  
	  WHILE(FIND_STRING(RTI_BUFFER,'\r',1))//delimiter.
	       {
	       STACK_VAR INTEGER nFBS;
	       STACK_VAR CHAR cStr[64];
	       
	       cStr = REMOVE_STRING(RTI_BUFFER,'\r',1);
	       
	       SEND_STRING 0, "'RTI, Parsing Segment-[ ', cStr,' ]'";
	       
	       SET_LENGTH_STRING(cStr,length_string(cStr)-2);//get rid of \r
	       nFBS = find_string(cStr,'RM',1);
	       if(nFBS)
		    {
		    GET_BUFFER_STRING(nFBS+1);//dump RM and anyting before it
	            nFBS = find_string(cStr,'CH',1);
		    if(nFBS)
			 {
			 RTI_ROOM = atoi(GET_BUFFER_STRING(cStr,-1);
			 REMOVE_STRING(cStr,'CH',1);
			 RTI_CMD  = atoi(cStr);
			 
			 SEND_STRING 0, "'RTI, PARSED: ROOM-[ ', itoa(RTI_ROOM),' ], CMD-[ ',itoa(RTI_CMD),' ]'";
			 						 
			 SWITCH(RTI_ROOM)
			      {
			      CASE 1:
				   {
				   DO_PUSH_TIMED(vdvRemote1,RTI_CMD,1);//use timed, otherwise another push won't work for .5 seconds
				   DO_RELEASE(vdvRemote1,RTI_CMD);//immediately release to allow next push
				   }
			      CASE 2:
				   {
				   DO_PUSH_TIMED(vdvRemote2,RTI_CMD,1);//used timed, otherwise another push won't work for .5 seconds
				   DO_RELEASE(vdvRemote2,RTI_CMD);//immediately release to allow next push
				   }
			      }
			 }
		    else
			 {
			 SEND_STRING 0, "'RTI, Parsing ERROR-[ No CH Found ]'";
			 }
		    }
	       else
		    {
		    SEND_STRING 0, "'RTI, Parsing ERROR-[ No RM Found ]'";
		    WAIT 50 'RTI_DUMP_BUFFER'
			 {
			 CLEAR_BUFFER RTI_BUFFER;
			 }
		    }
	       }
	  WAIT 50 'RTI_DUMP_BUFFER'
	       {
	       if(length_string(RTI_BUFFER))
		    {
		    SEND_STRING 0, "'RTI, Dumping buffer remains, BUFFER-[ ',RTI_BUFFER,' ]'";
		    CLEAR_BUFFER RTI_BUFFER;
		    }
	       }
	  }
     }	  

RicardoSiqueira

Thanks again Vining.

I just ordered some RTI parts today to try this solution at home before I deploy it on the field. I will let you know if it works after I test it.

Again, I appreciate your help.

Ricardo

vining

RicardoSiqueira wrote: »

Thanks again Vining.

I just ordered some RTI parts today to try this solution at home before I deploy it on the field. I will let you know if it works after I test it.

Again, I appreciate your help.

Ricardo

No problem. I've been meaning to try this too since some RTI remotes have wi-fi for programming, image and I think soon video support, etc. I think it's time to retire the R4 and who knows what plans AMX has for future remotes. I doubt think you can count on them for filling our resi needs anymore although the S series TPs are a step in the right direction.

Krestron uses a URC remote so I wonder why AMX doesn't try and re-brand some RTI models and give up a trying to make there own.

RicardoSiqueira

I've been using RTI remotes in a couple AMX installs and they have been working good. The code that Vining provided on this tread works well. The only draw back to this approach is when multiple people are ramping volumes at the same time. In this case, the RTI controller processes the first command hold and the others don't work until the first room ramping stops and consequently the others. This doesn't happen too often, but it is a drawn back. Now, I have a new project which will be using only RTI Wi-Fi remotes. In this case, there will be no need to use the RTI RF 433Mhz receivers. The remotes will communicate Wi-Fi directly to the RTI XP6 controller, which is connected via RS-232 to one of the AMX NI Master Serial ports. This works ok with only the possible volume conflict. I wonder if I could eliminate the XP6 serial connection to AMX and use IP instead. Has anyone done any IP control from RTI to AMX? The RTI XP6 is capable of IP communications. Any ideas or sample code/module? Thanks!

vining

Is the IP port fixed or selectable in ID software? Reading their docs they don't recommend two way over wi-fi but control via rf and feedback via wi-fi. You would also need to create a server for each possible remote that will ever likely be used at the same time. Always having one listening and everytime a client (remote) connects opening up another server to listen. I wrote a SITREP server a few years back that does this so it's not difficult. If the remote can connect fast enough maybe initiated by the tilt switch it might be a good solution. R4's aren't that quick either but the ability have real feedback with out the zigbee through put limitations would be worth investigating.

John Nagy

vining wrote: »

I wonder why AMX doesn't try and re-brand some RTI models and give up a trying to make there own.

+1000 on this. But it would take a desire to sell in residential for this to make sense for AMX.

vining

John Nagy wrote: »

+1000 on this. But it would take a desire to sell in residential for this to make sense for AMX.

I hear ya, I've given up expecting any help from AMX as I try to maintain a predominantly resi business selling AMX gear and it ain't goin' so good. On the bright side I'm starting to have a life again and dropping some pounds as I'm not sitting on my a$$ 12+ hours a day anymore.