Home AMX User Forum AMX Technical Discussion

RTI and AMX Integration via IP

For those that are interested, I was playing last night with a RTI XP6 controller, a T2x RTI remote and an AMX NI-4100 and wrote a basic RTI_IP_CONTROL module for AMX using some code that Vining helped me before to setup the AMX RTI Serial communications. The problem with the Serial communications is that the RF remotes communicate on a single bus and during ramping commands like volume ramping only one remote works at a time.

In this case, the RTI Wi-Fi remotes communicate wireless with the XP6 or any network capable RTI controller. In RTI you will need to use the Two Way Strings RTI driver and from any RTI remote send the string CHxxx%0D for the code below to work. Also you need to setup your RTI Two Way Strings driver to communicate with the AMX Master IP and assigned port. I haven't tested multiple RTI remotes yet, since I have only one T2x available, but by using a module, each remote will have its own TCPIP socket and port to communicate and theoretically it should work better. Also there is no need to connect cables between the RTI controller and the AMX controller. They only need to be on the same network subnet.

Few free to use the module, make comments and improve on it. Since this is my first TCPI exercise, I am not sure if there are needed error checking to make this a better module. Have fun and let me know if there is anything to add to improve it.

DEVICE DEFINITIONS
(***********************************************************)
(*          DEVICE NUMBER DEFINITIONS GO BELOW             *)
(***********************************************************)
DEFINE_DEVICE

vdvRemote1 	        =  0:7:0
vdvRemote2 	        =  0:8:0
vdvRemote3 	        =  0:9:0

//Virtual Devices////////////////////////////////////////////////////////// 
vdvRemote1_Family       =  33001:1:0   // Virtual
vdvRemote2_Office       =  33002:1:0   // Virtual
vdvRemote3_Master       =  33003:1:0   // Virtual

(***********************************************************)
(*               VARIABLE DEFINITIONS GO BELOW             *)
(***********************************************************)
DEFINE_VARIABLE

//Port for RTI Remotes IP Control
VOLATILE INTEGER svPORT1 = 81
VOLATILE INTEGER svPORT2 = 82
VOLATILE INTEGER svPORT3 = 83

(***********************************************************)
(*                STARTUP CODE GOES BELOW                  *)
(***********************************************************)
DEFINE_START

DEFINE_MODULE 'RTI_IP_Control' Remote_1 (vdvRemote1,vdvRemote1_Family,svPORT1)
DEFINE_MODULE 'RTI_IP_Control' Remote_2 (vdvRemote2,vdvRemote2_Office,svPORT2)
DEFINE_MODULE 'RTI_IP_Control' Remote_3 (vdvRemote3,vdvRemote3_Master,svPORT2)

Module
MODULE_NAME='RTI_IP_Control'(DEV vdvRemote, DEV dvRemote, INTEGER nPORT)

(***********************************************************)
(*          DEVICE NUMBER DEFINITIONS GO BELOW             *)
(***********************************************************)
DEFINE_DEVICE

dvMASTER = 0:1:0

(***********************************************************)
(*               VARIABLE DEFINITIONS GO BELOW             *)
(***********************************************************)
DEFINE_VARIABLE

INTEGER RTI_CMD

CHAR RTI_BUFFER[64] //Holds 5 Characters from String: CHxxx 

(***********************************************************)
(*                STARTUP CODE GOES BELOW                  *)
(***********************************************************)
DEFINE_START

CREATE_BUFFER vdvRemote, RTI_BUFFER

(***********************************************************)
(*                THE EVENTS GO BELOW                      *)
(***********************************************************)
DEFINE_EVENT

DATA_EVENT[dvMASTER]
{
    ONLINE :
    {
	IP_SERVER_OPEN(vdvRemote.PORT,nPORT,IP_TCP)
    }
}

DATA_EVENT[vdvRemote]
{
    ONLINE :
    {
	SEND_STRING dvMASTER,"'CONNECT',nPORT"
    }
    STRING:
    {
	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,"$0D",1))//delimiter.
	{
	    STACK_VAR INTEGER nFBS;
	    STACK_VAR CHAR cStr[64];
	       
	    cStr = REMOVE_STRING(RTI_BUFFER, "$0D",1);
	    SEND_STRING 0, "'RTI, Parsing Segment-[ ', cStr,' ]'";
	    //SET_LENGTH_STRING(cStr,length_string(cStr)-1);//get rid of $0D
	    nFBS = find_string(cStr,'CH',1);
	    if(nFBS)
	    {
		GET_BUFFER_STRING(cStr,2);//dump CH and anyting before it
		RTI_CMD  = atoi(GET_BUFFER_STRING(cStr,3));
		SEND_STRING 0, "'RTI, PARSED: CH-[ ', itoa(RTI_CMD),']'";
		//Process Command Received
		DO_PUSH_TIMED(dvRemote,RTI_CMD,1);//use timed, otherwise another push won't work for .5 seconds
		DO_RELEASE(dvRemote,RTI_CMD);//immediately release to allow next push
	    }
	    ELSE
	    {
		SEND_STRING 0, "'RTI, Parsing ERROR-[ No CH 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;
	    }
	}
    }
    OFFLINE:
    {
	SEND_STRING dvMASTER,"'DISCONNECT',nPORT"
	IP_SERVER_OPEN(vdvRemote.PORT,nPORT,IP_TCP)
    }
}

Comments

  • After playing with the T2x remote via Wi-Fi, I've noticed that the RTI remote takes about 8 to 10 seconds to wake up and reconnect to the Wi-Fi network when not docked/charging. This is a limitation as most end users will pick up the remote and start pushing buttons right away. I talked to RTI Tech support about it and they said that is the way these remotes behave while communication via Wi-Fi. This does not happen when RTI remotes are either 433Mhz or Zigbee. I am very disappointed as the RTI Wi-Fi communications doesn't reconnect instantaneous, making the Wi-Fi communications less desirable as you have to wait up to 10 seconds for the remote to reconnect to the Wi-Fi network before control is possible. I guess I am back to using RF/Zigbee, what a bummer, they advertise the power of the T2x and T3-V+ as being Wi-Fi capable, but this 10 second delay is not acceptable...
  • John NagyJohn Nagy Posts: 1,734
    I believe I read on their website that RTI suggests using the 433 for push information from the remote, and then use wifi for managing feedback to the remote. Seemed crazy until you described the delay. Now it just seems onerous.
  • Yes. They recommend using the RF to control and Wi-Fi for feedback. I was trying to overcome a limitation of using RF when you have multiple remotes in the same project. In this case, since the RF is a single bus network, when one remote is ramping volume, none of the other remotes will work until the ramping stops. This may not be an issue most of the time and it is a RTI limitation even when operating only RTI with no AMX integration. This issue was more noticeable on a job I serviced that had 10 RTI remotes. By using Wi-Fi only, each remote can have its own TCPIP socket to AMX via the RTI controller, breaking up the RF single bus dependency which operates in a FIFO mode (First IN first OUT). However, the wireless cards in the RTI remotes are not powerful enough and do take up to 10 seconds to reconnect if not docked. Most of our AMX installations have a Cisco Enterprise level network and I was thinking that I could use the RTI remotes Wi-Fi only as the Wi-Fi coverage is already excellent throughout the site. Anyways, I will have to go back to RF... I had high hopes to find a replacement solution to the AMX R4 remotes, but not yet...
  • CedricCedric Posts: 32
    10 sec any customer will become crazy
    You can keep the wifi connection up maybe?
    Doing some communication wifi the AMX.
    But the batterie might be down reall fast ?
  • The problem is not the TCPIP connection to AMX, but the Wi-Fi between the remote and the RTI controller. In this case, if the RTI remote is not docked/charging, it will go on standby and shut off the Wi-Fi to preserve battery. There is no way to prevent this from happen according to RTI, consequently the 10 seconds delay to wake up and re-authenticate the Wi-Fi when the remote is awaken. Reason why RTI recommends RF or Zigbee as the main communication between RTI remotes and RTI controllers, but then we have the occasional conflict when you are ramping volume in one RTI remote the others won't work until the ramping is finished. This is a RTI limitation as the RF and Zigbee works as a single communications bus for all remotes in the same single controller project.

    On my testing setup, I am going through a RTI XP6 controller first. In other words, The RTI remote communicates with the RTI controller (XP6) via Wi-Fi, which then communicates with AMX via TCPIP. Maybe someone can come up with a solution in which the RTI communicate straight to AMX, without the need for the RTI controller as the bridge, which uses the 2-WAY RTI string driver to send commands to AMX. Most of other Wi-Fi remotes that I've used take about a second to reconnect including (CRES$TRON) when operating via Wi-Fi, which is not noticeable by the end user as he/she picks up the remote. I wish AMX had a Wi-Fi remote with the looks of a RTI remote to fulfill the residential market need for an attractive Wi-Fi remote.
  • viningvining Posts: 4,368
    What triggers the wi-fi to shutdown when not docked? No remote movement/pushes or that plus no wi-fi feedback. It might be possible to send a dummy FB to the remote via wi-fi just to keep the wi-fi connection alive. If that works then see how that negatively impacts your battery life.
  • Per RTI Tech support all RTI Wi-Fi remotes (T2x and T3-V+) go to standby and turns off the Wi-Fi. I believe it is a couple minutes for this to happen when the remote is not docked. The dummy FB to the remote needs to be sent by the RTI controller as the remote is linked to it not to AMX. Here is the communications layout:

    RTI Remote (Wi-Fi) --> RTI Controller(TCPIP) --> AMX Controller
  • viningvining Posts: 4,368
    But will it go to sleep in a couple of minutes if there was feedback a few seconds ago or does feedback reset the timeout timer. If you send a toggle to the RTI controller, alternating the state from on to off on a dummy button will it still time out?
  • The dummy feedback has to go from RTI Controller to RTI remote, not remote to controller as the remote will most of the time be undocked by most users. They dock only when battery is low.
  • viningvining Posts: 4,368
    Yeah send FB to the RTI controller so it in turn sends FB to the remote. Using the middle man shouldn't make any difference.
Sign In or Register to comment.