Older russound (rs232) control support

thanks so much i will try it out and let you know

1 Like

Did you ever try this or get it working?

I ported the driver, but don't have a unit to test it with. :slight_smile:

I was going to test it out but realized I needed another machine to run the node proxy and got scared off and forgot about it.

I have a spare raspberry pi I was going to load the node on it but not sure how much work that would be to get it all configured

I appreciate the effort to port the driver I hope to get around to testing

I tried but was unsuccessful. It seems close but I have no coding experience so it would take someone with that skillset and device to make it work.
It did work well on smart things.

Looks like there hasn't been a lot of movement on this. I'm surprised that the SmartThings driver is designed for RS232 instead of RIO. I was able to send simple commands via PuTTY to my Russound based on their RIO protocol - I would think that a driver based on that would be a lot easier than setting up an intermediate Proxy service. I am brand new to Hubitat and haven't done any coding in 25 years, but I may give it a go to get my 2 MCA-C5s onto my Hubitat.

1 Like

@Bullfrog, I would welcome any progress that you make. I have been looking all over for a way to control my Russound with/through Hubitat. I can easily control it with Putty commands as you have noted. I have tried every way possible to control it in a similar fashion with webcore. But that is UDP, not TCP/IP. I have never written a driver before but I cannot imagine that it would be that difficult to put something together to allow text commands (RIO) to be sent to the Russound via TCP/IP.

@adamkempenich, I would be happy to test your ported driver.

Ok! They are posted above :slight_smile:

Unfortunately, I didn't make it very far. I'm just not familiar enough with with the coding required and the setting up of a proxy in the ported driver isn't of huge interest to me. I think an RIO (Telnet) driver that is set to communicate directly with the Russound (as opposed to via a proxy, which I think was just a way for ST devices to communicate to local network devices, so not needed for Hubitat) is what's going to be required, so I'm sort of hoping that someone smarter than me eventually writes one. I'd be willing to compensate someone to some degree.

@Bullfrog, I believe this could be modified to do what you want. At least it would give you a framework to use as a starting point.

I recall looking at this at one point and not really understanding the "Optional Wired Ethernet Gateway." I have 2 MCA-C5s and they are hardwired into my network, but not with any sort of external gateway, just with the port on the actual unit (well, 1 of the units and then the units are chained together).

IIRC, when I was trying to get it to work I concluded that the Ethernet Gateway used must speak a different language than RIO. Maybe I'll play with it some more...

Yes, I think that one uses the RNET commands over RE232 (via the Ethernet Gateway), which are different from the RIO commands. I am looking to use RIO commands over TCP/IP but I am investigating using a RPi as the proxy. I just need someone to write the proxy for me. I would like to write it myself. But I have never written anything like that before.

Ok. This integration didn’t work for me, but I thought I would pass it on to you. We’ve got an MCA-66, MBX-PRE, XSource, and ST-1 tuner, but our control is via XTSPlus touchscreens.

1 Like

That looks like a great system!

It's interesting (to me) how I came to home automation and Hubitat. Two years ago, we bought this house. It had been built by the developer of our small gated community as his "dream home" for himself. The only "smart home" devices that worked were a single Amazon Echo, a couple of Lutron Caseta switches, some Hue Lightstrips, and a Wink hub. The rest of the stuff was very nice (5 Somfy Glydea drapery systems, the Russound equipment, LiftMaster garage door opener, Schlage locks, GE smart refrigerator, GE smart washer and dryer), but he decided to do all the installations himself, and never was able to make any of the integrations work, and the plumbing and electrical system was a bit of a mess. He threw up his hands, having only minimally lived in the house for a few weeks, and sold it "as is", with much of the smart stuff in piles, inoperative. Turns out, the reason none of the integrations worked was that, when he had cabled the house with CAT5E, he had used big construction horseshoe nails and had shorted out the CAT5E and speaker cables in multiple places. I pulled cables, re-wired a bunch of stuff, did a bunch of plumbing (I hate plumbing), and got everything working. Then Wink exploded, so I bought a SmartThings Hub, started migrating, and, after two weeks, saw the train wreck that was happening there, so migrated everything to Hubitat, and everything worked.

2 Likes

I'm confused at why we need the proxy. The Hubitat can communicate directly over TCP/IP as it does with Lutron and others, so I'm not sure what the purpose of the intermediate RPi proxy is - I thought its purpose in the ST driver was to get around ST being cloud-based and needing a path into a local network (I never had ST, so that was just a guess).

I use webcore to control most of my home automation, including controlling my Russound. It works very well. ST is my backbone. I am now transitioning to HE.

That was my hope, that using webcore through HE would be perfect. I tried every way that I could to communicate directly with my russound with webcore (GET/PUT/POST). I monitored with Wireshark. From what I can tell, and have been told in the webcore forum, webcore uses UDP, not TCP. I was so hoping that I could just do an http call to my Russound and send RIO text commands. I was hoping to eliminate the node.js/ST node proxy system that I currently use, and gain direct, local control. That's why I thought, maybe incorrectly, that I needed a proxy/tunnel to manage the UDP to TCP/IP communication.

It has been suggested that I look into the Raw Socket Interface, but I do not know the first thing about writing a driver.

I am certainly willing to pay someone to write a very basic, functioning driver that will allow me to send text commands from webcore to my russound.