[RELEASE] Russound Multi-Zone Controller Integration

Here are a couple screenshots of the app in action, showing active/inactive zones, each zone has volume control, source control, loudness control and the ability to turn off all zones:

Thank you for this. I installed Smartthings a couple of months ago and just did a search on if I can somehow integrate my Russound system with it (and found your post). Yesterday I did a search to see if I could integrate my wired alarm system (I can) and am now following up on getting that up and running. Until yesterday, I had no idea that Smartthings had the ability to connect to these systems.

1 Like

@marx your welcome and let me know if you run into any issues…

@redloro I am not certain I can get this working for me. I would be running this on a Windows machine and I’ll have to look into it further. I do have Python installed (as it was required for the install I just completed for my alarm system), I now understand about authorization codes and secret keys, and it looks like I’d have to install Node for Windows. But, I am unsure on how to execute some of the commands in your documentation. In any case, I am going to try.

(As a side note, I see you have an integration set up with Envisalink and Honeywell Vista. This is a project I just completed using a different method. I was able to set it up and I am able to Arm / Disarm via the Smart Home Monitor. But the zones don’t always report back correctly with the method I use - which I believe is due to the nature of the Vista Panel).

@redloro, I installed Node and stated the process for Node Proxy installation. After issueing the command ‘npm install’ I got a string of errors. This was at the bottom:

npm ERR! serialport@1.7.4 install: node-pre-gyp install --fallback-to-build
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the serialport@1.7.4 install script ‘node-pre-gyp install --fallback-to-build’.
npm ERR! This is most likely a problem with the serialport package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! node-pre-gyp install --fallback-to-build
npm ERR! You can get information on how to open an issue for this project with:
npm ERR! npm bugs serialport
npm ERR! Or if that isn’t available, you can get their info via:
npm ERR!
npm ERR! npm owner ls serialport
npm ERR! There is likely additional logging output above.

Any advice on this?

Looking forward to the next step, I need edit config.json with an oauth code and secret key. Don’t I need to have a Smartapp installed first? If so, what Smartapp?

Sorry for my ignorance, and thank you

@marx no worries… we’ll get you setup and after that, you can take a look at the Honeywell connector I also built, which should resolve your issues with zones not reporting back correctly… [RELEASE] Honeywell / Ademco Vista 20P Integration

So I put in a dependency on the serialport package version 1.7.4 because there was an issue with the latest release that wouldn’t work right on OSX… but you can give the latest package a shot. Try the following and let me know how it goes:

  1. Edit package.json and remove the line "serialport": "^1.7.4"
  2. Manually install serialport by typing the following from the command line (in the same folder as the Node Proxy project): npm install serialport
  3. Re-run: npm install

Let me know how that goes…

Let’s first get SmartThings Node Proxy running and talking to the Russound;

  • Edit your config.json by first removing all the comments and then setting the relevant fields (this is just an example for a Russound only configuration):
{
  "port": 8080,
  "authCode": "secret-key",
  "rnet": {
    "serialPort": "/dev/usbser",
    "sources": [
      "Sonos",
      "Airplay",
      "Apple TV",
      "Source 4",
      "Source 5",
      "Source 6"
    ],
    "controllerConfig": {
      "type": "discover",
      "zones": [
        {"zone": 0, "name": "Family Room"},
        {"zone": 1, "name": "Kitchen"},
        {"zone": 2, "name": "Living Room"},
        {"zone": 3, "name": "Patio"},
        {"zone": 4, "name": "Dining Room"},
        {"zone": 5, "name": "Office"}
      ]
    }
  }
}
  • Set port to where you want SmartThings Node Proxy to listen
  • Set authCode to some value that you will set later to secure comms between SmartThings and the proxy
  • No OAUTH and secret key…
  • We’ll get the SmartApp and devices setup once you’ve got the proxy running

Let me know how it goes.

I think we’re looking good. I made the updates you mentioned and then tried to dissect the restart.me command. It took a while, but I finally figured out that on Windows I would just execute the command “Node Server.js”.

I confirmed access via the browser on another machine.

I went ahead and installed the Smartapp and Device Handler, though I am still waiting on the USB/Serial cable, so there is no connectivity between the server and Russound. I noticed an error and updated the Serial Port name to COM3 in the config file.

This is current output:

smartthings-nodeproxy>node server.js
SmartThings Node Proxy listening at http://:::8080
** NOTICE ** Envisalink settings not set in config file!
Loaded plugin: envisalink
Loaded plugin: rnet
Connected to RNET: COM3
Detected serial ports: [“COM3”]
** NOTICE ** Envisalink settings not set in config file!
::ffff:192.168.0.35 GET /subscribe/192.168.0.35:39500
::ffff:192.168.0.35 GET /plugins/rnet/discover
{“type”:“discover”,“zones”:[{“zone”:0,“name”:“Kitchen”},{“zone”:1,“name”:“Master Bedroom”},{“zone”:2,“name”:“Living Room”},{“zone”:3,“name”:“Dining Room”},{“zone”:4,“name”:“Office”},{“zone”:5,“name”:“Master Bath”}]}
Completed controller discovery
::ffff:192.168.0.35 GET /subscribe/192.168.0.35:39500
::ffff:192.168.0.35 GET /plugins/rnet/zones/4
::ffff:192.168.0.35 GET /plugins/rnet/zones/0
::ffff:192.168.0.35 GET /plugins/rnet/zones/5
::ffff:192.168.0.35 GET /plugins/rnet/discover
{“type”:“discover”,“zones”:[{“zone”:0,“name”:“Kitchen”},{“zone”:1,“name”:“Master Bedroom”},{“zone”:2,“name”:“Living Room”},{“zone”:3,“name”:“Dining Room”},{“zone”:4,“name”:“Office”},{“zone”:5,“name”:“Master Bath”}]}
Completed controller discovery
::ffff:192.168.0.35 GET /plugins/rnet/zones/2
::ffff:192.168.0.35 GET /plugins/rnet/zones/3
::ffff:192.168.0.35 GET /plugins/rnet/zones/1
::ffff:192.168.0.35 GET /plugins/rnet/zones/4
::ffff:192.168.0.35 GET /plugins/rnet/zones/0
::ffff:192.168.0.35 GET /plugins/rnet/zones/5
::ffff:192.168.0.35 GET /plugins/rnet/zones/2
::ffff:192.168.0.35 GET /plugins/rnet/zones/3
::ffff:192.168.0.35 GET /plugins/rnet/zones/1
** NOTICE ** Envisalink settings not set in config file!

Zones did not appear, but I removed/re-configured the app and then they all popped up! (Maybe I had a setting wrong). The sources just show up a source1, source2, etc…

When I turn Zones on/off in the app I see that reflected on the server.

I’ll update my progress after installing the cable on Wednesday.

Thanks again!!! This is great!

Great to hear… you’ll want to make sure that you configure the right serial port and drivers when your USB/serial cable arrives.

Yeah sometimes they don’t appear the first time around, and you have to wait 5-10 seconds or go back into the App config and then they’ll show.

The sources are hardcoded as Source1, Source2, etc but you will see the source name (as defined in your config.json) in the red box in the image below once SmartThings fixes a bug they introduced in the last version… this is something that worked before and broke in the last version. They’ve acknowledged this and will be fixed in the next version.

Another thing you can do, is actually change the hardcoded values for the Source names in the Device Handler code… these will be the label for each state… this is something I did… for instance change lines 74-77 from:

    standardTile("0", "device.source0", decoration: "flat", width: 2, height: 2) {
      state("off", label:"Source 1", action:"source0", icon:"https://raw.githubusercontent.com/redloro/smartthings/master/images/indicator-dot-gray.png", backgroundColor:"#ffffff")
      state("on", label:"Source 1", action:"source0", icon:"https://raw.githubusercontent.com/redloro/smartthings/master/images/indicator-dot-green.png", backgroundColor:"#ffffff")
    }

To:

    standardTile("0", "device.source0", decoration: "flat", width: 2, height: 2) {
      state("off", label:"Sonos", action:"source0", icon:"https://raw.githubusercontent.com/redloro/smartthings/master/images/indicator-dot-gray.png", backgroundColor:"#ffffff")
      state("on", label:"Sonos", action:"source0", icon:"https://raw.githubusercontent.com/redloro/smartthings/master/images/indicator-dot-green.png", backgroundColor:"#ffffff")
    }

Let me know how it goes when you get your cable!

1 Like

Thanks again @redloro for all the work you did on this! Unfortunately for me, the (old) laptop I planned on running Node Proxy on is dead. I was able to test the Russound integration using another laptop and it works perfectly! But, until I get a replacement laptop I need to place the Russound piece of my Smartthings integration on hold for now.

In the interim, I installed Node Proxy on my file server (which is nowhere near my Russound machine) and am running it to control the Honeywell system.

Will this method work on my Russound MCA-C5 controller? If yes, is there a way to connect other than using a RS-232 serial connection (like telnet or ssh)? If not what piece of hardware can I buy to set up this proxy connection (like a raspberry Pi with a rs-232 serial connection or something similar other than a laptop)

Yes - it should… according to Russound their RNET protocol is backwards compatible. You may need to be on the latest firmware for the MCA-C5 and may need to configure some settings to allow it to talk RNET.

Technically yes - the MCA-C5 supports IP based comms, but this specific plugin was designed to communicate over a serial connection. If you want control over your existing IP connection, someone would need to update/replace this plugin such that it can communicate with the device over IP instead of serial and uses the RIO protocol instead of the RNET protocol.

Absolutely… the current version can be used with a Raspberry PI. Any piece of hardware that can run NodeJS, has a USB port and drivers for a USB-to-Serial cable should work. We’ve got this working with a Mac, Linux and Windows machines.

Let us know if you have any questions!

Thanks for this @redloro! I’m just starting out with SmartThings, and this was the first customization project I tackled. I’ve got this running on a Raspberry Pi connected to my CAM6.6, and it’s all running very well . It’s (slightly) integrated with my Sonos Connect, and I can now efficiently control the system automatically and/or remotely. I’ve been wanting something like this for my Russound for years!

One thing I’m running into is having the Smart App accurately report current zone status. My family is used to turning the system on or off from the control panels in each room. When they do that the power status isn’t updated in the Smart App. Do you know if it’s possible to have the current status automatically updated in the Smart App? It looks like there’s something in the device handler that’s supposed to do it, but if so then it doesn’t work for me.

Have you explored incorporating any of the other Russound capabilities (e.g. Bass, Treble, Balance, Party Mode, etc.)?

@ducttape glad to hear you’ve got things working… I was in the same boat and actually tried a bunch of other options including Vera and Indigo but did not like the platform or ecosystem.

To answer your questions… yes to all of them but let’s break them down.

The RNET plugin is designed to handle status updates from any source and notify SmartThings/SmartApp, but I didn’t have any panels to test so did not write the code to handle this in the plugin. What I’d need from you is a debug log from the ST Node Proxy showing a bunch of activity from the panels. I can use that to add the required code to the plugin so that current and accurate status is always captured in the SmartApp. Shoot me a PM and I’ll help you get the debug log, etc.

The RNET plugin supports all of the above, but I excluded them from the Device Handler on purpose just to keep it simple. I can share another version of the Device Handler with all these options present and let you tweak it as you like.

This looks like great stuff. I’m going to be forking it to work with the Monoprice 6-channel Amp. Hopefully I can apply a good amount of this work to my project.

@tcjennings great to hear… I would expect it to be similar? Wanted to play with one as it’s got a similar look to the Russound and also a RS232 port. Let me know if you’ve got any questions and keep us posted on your progress!

That was easier than I thought! The Monoprice amp’s control interface has nothing in common with RNET but I was able to get a plugin written for your SmartThings Node Proxy. The Device and SmartApp required mostly trivial changes. Overall I’m impressed with the STNP as a platform. I’ve got a Vista 20p alarm panel, so I might use STNP for that too instead of one of the other alarm server forks.

I have a few more tweaks to make, after which I’ll make a pull request, @redloro.

Cheers!

@tcjennings that’s awesome… glad to hear things worked out… looking forward to your contrib!

One question: You put an AllOff command on each zone, I’m guessing that’s just a convenience thing where RNET may have a “all off” command but you haven’t modeled the core chassis as a Device. So you’ve just put AllOff on each zone, where it’ll do the same thing regardless of from whence it’s called. Is that about right?

I’ve rearranged just a couple of things so the pull might take some merging depending on how much you want to keep:

  • Put plugins in ./avail_plugins/ with the expectation that user will copy (or better, link), needed plugins into ./plugins.
  • Rename config.json->config.json.sample and add config.json to .gitignore; since config.json doesn’t work without editing anyway + keeps personal configs out of repo.
  • Bumped node serialport req to 2.0.2 since 1.7.4 doesn’t build on RPi.

@tcjennings right on the AllOff command… it was just a convenience thing.

Yep - already saw your pull request come through and like the changes… i had originally loaded the repo from the machine that’s actually hooked up so just left the directory structure, but have since realized that it’s probably better to force a manual step.

On the serialport req… I’ll need to check that cause the latest version when I built this was 2.0.1 (maybe ?) and it was failing on OSX… which is why I forced the 1.7.4… but no biggie.

Thanks!!