Russound RNET Plugin v1.4

Other Devices & Integrations Home Theater & Smart Speakers
#1

v1.4
Changes in this version:

  1. Changed implementation to utilize more standard SwitchPower and RenderingControl services.

I’ve attached the relevant files here to be used until the plugin is approved in the App Store. The only things missing are the icon images which are unchanged from the previous version.

v1.2
Changes in this version:

  1. Support for C-series controllers (MCA-C5, MCA-C3)*.

  2. Changed incoming message parsing to allow for variable lengths.

  • A known issue with “grouped” zones on C-series controllers exists that will lock up the controller if sources are changes rapidly. Russound is working on this issue.

v1.1
Changes in this version:

  1. RNET commands have been updated to the latest version. Per Russound, these should work with all CA-series and C-series controllers, as long as they are on the latest firmware. There has been a report of issues with the “Source” buttons on a C-series controller but I’m unsure of the version of firmware that controller was running. Any feedback from C-series controller users would be appreciated.

  2. Mute toggle button added.

  3. Additional controller messages parsed for “Display” window.

  4. Status feedback parsing revamped with explicit status requests no longer being needed.

  5. New icon for audio zones.

v1.0
Intro
This plugin was created for personal use but I wanted to share with the community as I know this has been requested a number of times. I’m not a developer but with the help of a few people on this forum, I was able to put this together. Below are some key bits of information for installation and use.

Devices
The only controller that I can say with certainty that this will work with is the CAM6.6(T) as that is what I have. The “set” and “get” codes were retrieved from a Russound RNET protocol document that states support for the CAM, CAV, CAA, and CAS series controllers, so my assumption is it will work with those, as well. As for any other controller, my fingers are crossed but I can’t promise anything. I’ve asked big517 to do some testing on an MCA controller and it doesn’t appear to work properly. If I can get a complete protocol document for the MCA implementation of RNET, I’ll happily put together an I_RNET.xml file for those controllers.

Connectivity
This plugin only works with serially-connected Russound controllers. I am personally using a FTDI-chipped serial/USB adapter on the back of the Russound controller with a USB extension cable connected to the Vera and it worked right out of the box. Search for “Serial Device Compatibility” and you’ll find a page that talks about these devices. In UI5, the serial port configuration is set in “Apps” > “Develop Apps” > “Serial Port configuration”. The settings you will need for communication to the Russound controller are:

Baud: 19200
Parity: none
Data bits: 8
Stop bits: 1

Installation
During the plugin installation process, you’ll see a message scrolling in the message window asking you to choose the serial port. In a new window you need to go to the same “Serial Port configuration” page and in the “Used by device” drop-down menu, select the RNET Controller. It will complete the process by installing the parent “Controller” device, as well as two child “Zone” devices by default. To add (or remove) zones, go to the parent device’s “Advanced” tab, scroll down to the “ZoneIds” variable, and enter or remove the Russound zones you want to control through Vera. Zones are separated by commas with no spaces.

Use
This should be relatively straight forward as it should mimic the use of a keypad. A few potential issues here:

  1. I was hoping to use a slider for the volume control but the Vera slider will only allow changes in 10% increments. This isn’t granular enough for me so I went with volume up/down buttons. If the granularity of this changes in the future, I’ll likely change this to a slider.

  2. In the “Control” tab of each zone is a Source Display. This will display a broadcast from an RNET-compatible source to each zone that is set to that source. The protocol document I used stated this would be a 42 byte long status but I found this to actually be 39 bytes long on the tuner module of my CAM6.6. I don’t currently have any other RNET-compatible sources so I can’t test if this changes by source. If anyone out there has an iPod dock and/or SMS3 and it’s not displaying the information you get on your keypad, let me know and I’ll have you run a couple of tests to figure out the byte length.

3) This may be specific to the tuner module I have but both the “Play” and “Pause” buttons also function as mute…independently. If you mute with one and unmute with the other, the Source Display will still show Muted/Unmuted. I can’t think of a way to address this so just know that if you do this, you’ll have to click each of “Play” and “Pause” again to clear the display. This must have been an old issue from an old build, the uploaded version does not have this problem. “Play” changes band, “Pause” mutes/unmutes, “Stop” seeks.

  1. I have not figured out how I want to deploy Party Mode on this yet. Once I figure it out, I’ll upload a new version of the plugin.

Well that is all I have for now. Please feel free to share any feedback and I’ll do my best to address issues with the limited resources/knowledge that I have in plugin development.

#2

I can’t thank you enough for this! My CAA66 is on its way. I still need to get a serial to USB adapter. I’ll tackle that one this weekend. Hopefully by next weekend I’ll be able to give you some input!

BTW, where is this plugin?

For future reference here’s the MCV wiki page on serial devices: http://wiki.micasaverde.com/index.php/Serial_Supported_Hardware

Here’s the one I ordered from Amazon: http://www.amazon.com/gp/product/B006PIU2KO/ref=ox_sc_act_title_1?ie=UTF8&psc=1&smid=A96BHCEI0V7QU

Hope it works.

#3

The plugin has been Pending Approval all day. Not sure if they don’t review on the weekends or what the holdup is. It should appear as soon as it is approved.

#4

They are not open on the weekends. You’ll have to wait until some time this week.

  • Garrett
#5

Can you post the plugin files in the meantime?

Thanks!

#6

Sure, here are the files. D_RNET is the parent device file.

#7

@ big517

How’s it working for you?

#8

It works, but not 100% because I have the newer units and some RNET functionality has changed. I found this out when using my ELK to control the unit.
What works for MCA-C5:
I have communications with the zones, seems to work with Volume up and down. I did have a strange issue when I chose a Source for one of the zones, it turned all the linked zones on and off every few seconds This is probably an incompatibility with my MCA-C5 system as there are other features on this such as zone source sharing and linking that are causing the problem. I don’t believe this will be an issue w/ your system.

I’ve disabled it in the meantime because of the traffic it produces, but it looks clean, child devices were created as expected and is pretty impressive.

#9

That’s disappointing. I actually added zones 7 and 8 for you and others with the MCA-C5. I haven’t been able to find the RNET protocol document for the MCA devices, as generating different commands based on the model wouldn’t be that big of a task. If you find it, let me know.

Also found out that the new RIO protocol operates over IP or RS232. If you find that command structure, I’d be curious to look at it. If it’s not completely different, I might be able to adapt the plugin and create a new one for RIO and have you do the testing. Let me know. Wow, just found the RIO protocol document and it is completely different. Would take a fresh rewrite and debugging/testing. My offer still stands on the MCA RNET command inclusion if you can find that document, though.

#10

This is amazing! Thank You.

Any way to make it run with a serial to ip? Like the wiznet.

Cheers

#11

Unfortunately I know nothing about how those devices receive commands and I don’t have one to test with. Someone else on here may be able to help modify my plugin to support that.

#12

I think the most updated RNET info is in that Box link I posted above, can you cross reference the “all on” and “all off” codes?

Out of curiousity does that RIO protocol make sense? So the plugin can “listen” and russound reports changes and keypad presses… Is there even capability to support that?

#13

It may be my advancing age but I don’t see a link anywhere above.

I didn’t delve much into the RIO protocol, I’m sure it would make sense if I took the time to understand it. The problem is the syntax, structure, everything about it is different. I wouldn’t think adapting this plugin would be the way to go for RIO, instead I would think it would be easier for someone to start from scratch on it. If someone wants to donate an MCA box, I’m happy to do it!! :slight_smile:

With RNET, the controller doesn’t send out status (other than connectivity) unless it is queried. I could have saved a lot of lines of code if RNET replied to a change of state/source/volume or periodically broadcast status. Does it broadcast this information on its own with RIO?

And if you’re asking if I could include a RIO “listener” in this plugin, I’m not sure it would help you as I believe you have to choose between RNET or RIO protocol on your controller. So if you set it to send RIO, you wouldn’t be able to control with RNET.

#14

Yes,
Rio broadcasts everything, I watched it with a TCP socket program on my Android phone, pretty cool actually. The syntax is pretty easy, and I get how it works, I lack the ability to write the plugins however.
Here is the Box link that I posted in the other thread
[url=https://app.box.com/s/eoujz8t4d230ocwt4zzd]https://app.box.com/s/eoujz8t4d230ocwt4zzd[/url]

Regarding RIO;
I’ve wrtten 1-liners to manipulate the system with my ELK.
For Every MCA system you have they will be assigned a controller number. I only have 1 MCA-C5, i’m sure most folks are the same, but it’s like this;

If I wanted to tell my 1st MCA system to turn Zone 4 on, this is the text I send;
“EVENT C[1].Z[4]!ZoneOn”
i’m sure you can see the variables and how that works.
For anyone referencing ELK M1 Gold, the “text” is; “00AP4EVENT C[1].Z[4]!ZoneOn^M^J” ; see my sticky in the ELK Plugin forum for setting up TCP

other examples, you can probably guess at what they do
EVENT C[1].Z[3]!ZoneOn
EVENT C[1].Z[3]!ZoneOff
EVENT C[1].Z[5]!KeyPress Mute
EVENT C[1].Z[5]!KeyPress VolumeDown

You see how it works? Almost plain text control.

Now i’ve brought that BOX link I uploaded with all the RS232 and RIO docs that was given to me by Russound rep, it may help.

#15

Well RIO is much more straight forward but I’m going to leave that to someone else to play around with.

Looking at the latest RNET document in that batch, I’m surprised that my plugin works with the MCA at all. If you’re interested, I can put together a new I_RNET file for you using this syntax and send it to you sometime this week to test. What the updated doc doesn’t detail, though, is the structure of the responses when queried for status. If you’re not getting correct status back on the Vera tiles or Control tab, I’ll need to you provide a copy of your log for each command so I can see what is being returned.

#16

Give this I_RNET.xml file a shot for the MCA devices. I essentially guessed at the structure for the request status command and left the parsing of the reply from the controller as is since neither of those commands are listed in the MCA doc.

#17

Sure, i’ll gladly give it another run!
Are you noticing a lot of differences from the RNET doc I sent? Were you working off an older doc originally?

UPDATE:

All Off worked.
Specific Zone ON did not seem to work, but making a volume adjust does, and will turn the zone on.

Too early to test extensively without waking up the baby :wink:

Noticed this FULL BUFFER message in the log;

luup_log:596: Received full buffer from controller via serial F0 01 00 70 00 00 7F 00 00 04 02 00 00 07 00 00 01 00 0C 00 00 02 11 0A 0E 01 0A 00 01 00 00 00 51 F7 <0x2faa4680>
50	07/31/13 9:08:19.389	luup_log:596: Received full buffer from controller via serial F0 01 00 70 00 00 7F 00 00 04 02 00 00 07 00 00 01 00 0C 00 00 02 11 0A 0E 01 0A 00 01 00 00 00 51 F7 <0x2faa4680>
50	07/31/13 9:08:20.440	luup_log:596: Received full buffer from controller via serial F0 01 00 70 00 00 7F 00 00 04 02 00 00 07 00 00 01 00 0C 00 00 02 11 0A 0E 01 0A 00 01 00 00 00 51 F7 <0x2faa4680>
50	07/31/13 9:08:21.598	luup_log:596: Received full buffer from controller via serial F0 02 00 70 00 00 7F 00 00 04 02 00 00 07 00 00 01 00 0C 00 00 02 11 0A 0E 01 0A 00 01 00 00 00 52 F7 <0x2faa4680>
50	07/31/13 9:08:22.597	luup_log:596: Received full buffer from controller via serial F0 02 00 70 00 00 7F 00 00 04 02 00 00 07 00 00 01 00 0C 00 00 02 11 0A 0E 01 0A 00 01 00 00 00 52 F7 <0x2faa4680>
50	07/31/13 9:08:23.101	luup_log:596: Request returned in 0ms <0x2e663680>
50	07/31/13 9:08:23.102	luup_log:596: Request returned in 0ms <0x2e663680>
50	07/31/13 9:08:23.103	luup_log:596: Request returned in 0ms <0x2e663680>
50	07/31/13 9:08:23.192	luup_log:596: Received full buffer from controller via serial F0 00 01 71 00 00 7F 00 00 04 02 00 00 06 00 00 01 00 01 00 00 04 F7 <0x2faa4680>
#18

Pause Play Stop work as well.

Source Selection does NOT work with the exception of Source1 (RADIO).

#19

That’s what I get for trying this so late last night. This should fix zone power and source. Let me know how it handles the status (is the correct power on/off button staying lit? does the correct zone button stay lit?)

And to answer your questions, there are two sets of the RNET implementation for controllers apparently, one for CA-series (CAM, CAV, CAA, CAS) which is what my plugin supports, and another set for C-Series (MCA). The biggest difference is the location of the byte which specifies which zone you’re sending the command for. And what I missed in the first MCA-specific file I sent you yesterday, is for zone power and source there are two bytes in the string that specify it, I only caught one (which is what the CA-series implementation uses).

The gaps in the MCA RNET protocol document is there is no description of what string to send for status request, and no description of what the controller should return. On the files I’m sending you, I’m just guessing on those based on the structure of the commands they do detail.

#20

The suspense is killing me! My CAA66 came yesterday and it’s DOA!