Yamaha RX-V781 ip control NX-2200

Metso

We should control Yamaha RX-V781 receiver via ip. (power, volume, input). We have done this before successfully with a RX-A2010, but that concept (YMCA) does not work. There is no longer a rs-232 option left in this model. Can anybody help?

ericmedley

Looks like IP is the only way to go. (Or IR - if no feedback is needed). I don't think they changed the protocol. You might be able to reuse yiur rs232 code and just modify it to work on the IP port. You also might try the AMX module for the 671 model as I believe it's the same protocol. It'd be worth a try at least.

Metso

Thanks Eric. We tried to copy the code from our previous program that worked ok with RX-A2010 - which was ip control. The controller was then NI-series, should we perhaps change something to NX-series?

ericmedley

Metso wrote: »

Thanks Eric. We tried to copy the code from our previous program that worked ok with RX-A2010 - which was ip control. The controller was then NI-series, should we perhaps change something to NX-series?

That should not not make a difference. Do you have the protocol document?

Metso

Below are the parts of the program concerning Yamaha (=amplifier) control.
Yamaha is connected to the same switch as NX-2200 and touch panel. All have static ip addresses. This worked previously for the RX-A2010.


DEFINE_DEVICE

// NETLINX NX-2200, 192.168.0.50

AMPL = 0:1:1 // IP: Yamaha RX-V781; 192.168.0.70:50000

DEFINE_START

CREATE_BUFFER AMPL,cBuffer;

DATA_EVENT[AMPL]
{
ONLINE:
{
CANCEL_WAIT 'CONNECT'
bConnected = TRUE;

CANCEL_WAIT 'TRYING TO CONNECT'
bBusyConnecting = FALSE;
}
OFFLINE:
{
CANCEL_WAIT 'CONNECT'
bConnected = FALSE;

CANCEL_WAIT 'TRYING TO CONNECT'
bBusyConnecting = FALSE;
}
ONERROR:
{
CANCEL_WAIT 'CONNECT'
bConnected = FALSE;

CANCEL_WAIT 'TRYING TO CONNECT'
bBusyConnecting = FALSE;
}
STRING:
{
// PARSE XML - using cBuffer
}
}

DEFINE_PROGRAM

WAIT 100 'CONNECT'
{
IF (bConnected == FALSE && bBusyConnecting != TRUE)
{
bBusyConnecting = TRUE;

IP_CLIENT_OPEN(AMPL.PORT,'192.168.0.70',50000,IP_TCP);

WAIT 100 'TRYING TO CONNECT'
{
bBusyConnecting = FALSE;
}
}
}

PUSH[TP,101]
{
SEND_STRING AMPL,"'@MAIN:INP=AV1',13,10"
VOLUMELEVEL=60 //=-20.0 DB
CALL'SET_VOL_LEVEL'
}

MLaletas

Youve got a couple of problems here. Number 1 change the device ID of "AMPL" starting at 3 (i.e. AMP = 0:3:0)

Remove the whole named wait thing, especially from mainline. If you are going to keep it, at least get it out of mainline and use a while or something. What you should really do is use a timeline at a specified time to attempt to reconnect. Either try to connect once at start or start the timeline, using the ONLINE, OFFLINE, and ONERROR appropriately.

Jim Donachiue

The NX series is not supposed to have anything in DEFINE_PROGRAM.
- There is a tech note commenting on this, but I can't seem to find it.

Move this:
[code/]
WAIT 100 'CONNECT'
{
IF (bConnected == FALSE && bBusyConnecting != TRUE)
{
bBusyConnecting = TRUE;

IP_CLIENT_OPEN(AMPL.PORT,'192.168.0.70',50000,IP_T CP);

WAIT 100 'TRYING TO CONNECT'
{
bBusyConnecting = FALSE;
}
}
}
[/code]

into a TIMELINE_EVENT

and move this:

[code/]
PUSH[TP,101]
{
SEND_STRING AMPL,"'@MAIN:INP=AV1',13,10"
VOLUMELEVEL=60 //=-20.0 DB
CALL'SET_VOL_LEVEL'
}
[/code]

into a BUTTON_EVENT

Metso

Thank you for your help, we'll try these after the Easter

Metso

We got the documentation for this receiver from Yamaha and checked that the commands are ok.
There was a mistake in our previous post: Device id should be Ampl= 0:3:1.
We tried to modify the program as Jim told but that did not help.
With a browser the receiver controls ok and Putty shows the traffic, but NX-2200 seems to send nothing.
Also got an old NI-3100 and found out that our original program controls just fine the RX-V781, so there must be something different with the NX and NI controllers...

MLaletas

Metso wrote: »

Also got an old NI-3100 and found out that our original program controls just fine the RX-V781, so there must be something different with the NX and NI controllers...

If thats true then I would hedge my bet that its because of how your using the DEFINE_PROGRAM. Like we stated earlier that should be removed and place in an recurring timeline based on the feedback of the IP connection (ONLINE, ONERROR, OFFLINE).

Metso

Can you post a sample code?

MLaletas

The way I manage IP connections is a little more elaborate then this but it will get you started. Obviously you need to make this your own, but this is the basic principal, feel free to make it your own style as well.

DEFINE_CONSTANT
//Constants - Timeline
INTEGER TL_IP_CONNECT = 3;

DEFINE_VARIABLE

VOLATILE LONG lTLReconnect[1] = 15000;                //15 Seconds

DEFINE_FUNCTION IPConnectAttempt()
{
    sYourDevice.StatusIPControl = 0;
    IP_CLIENT_OPEN( dvYourDevice.port, sYourDevice.ControlIP, sYourDevice.ControlIPPort, IP_TCP );    //Open Connection
}

DATA_EVENT[dvYourDevice]
{
    ONLINE:
    {
        sYourDevice.StatusIPControl = 1;
        IF( TIMELINE_ACTIVE( TL_IP_CONNECT) )
            TIMELINE_KILL( TL_IP_CONNECT);
    }
    OFFLINE:
    {
        IF( !TIMELINE_ACTIVE( TL_IP_CONNECT) )
            TIMELINE_CREATE( TL_IP_CONNECT, lTLReconnect, MAX_LENGTH_ARRAY( lTLReconnect ), TIMELINE_RELATIVE, TIMELINE_REPEAT );
    }
    ONERROR:
    {
        IF( !TIMELINE_ACTIVE( TL_IP_CONNECT) )
            TIMELINE_CREATE( TL_IP_CONNECT, lTLReconnect, MAX_LENGTH_ARRAY( lTLReconnect ), TIMELINE_RELATIVE, TIMELINE_REPEAT );
    }
}

TIMELINE_EVENT[TL_IP_CONNECT]
{
    IPConnectAttempt();
}

fogled@mizzou

MLaletas wrote: »

The way I manage IP connections is a little more elaborate...

Thanks for the code post. My code, while written completely differently, achieves almost the exact same thing. The only 'extra' thing I've got going in my code is that it will try reconnecting 10 times relatively quickly (~5 sec), then bumps up the wait before retry to 15 minutes, then eventually bumps that up to 30 minutes if it still cant connect. Generally, if it doesn't reconnect right away, there's a network problem that may take some time to resolve. My experience is that I pound on unsuccessful IPConnect requests to hard for too long, it eventually locks up the controller's IP port and requires a reboot to recover.

MLaletas

That's great, I have a little of that with devices that i know can get a little screwy, like I said that post just has the nuts and bolts nothing elaborate. There's a lot of different thoughts on how to manage the IP socket, everyone has their own little way.'