Russound rnet

Starting up a conversion about adding RNET to russound binding.

"You look like you are doing what I envisioned for RNET! Two notes:

You really need to wait until the PR goes through (should be any day [including today but probably overnight unless I messed up a rebase]). Some of those classes changed quite a bit (mainly the session and session listener ones). You may be better off dropping your code and recreating from the newest code rather than trying to figure out how to merge them.
I’d really think about defining different session implementations for different transports. I could see two different ones - direct/native serial and ip2serial that would be really handy. If you don’t have an ip2serial, I could test on my system (I do have one [not connected to russound but I can do that for testing]).
Note: you can find my tree at tmrobert8/openhab2-addons…

Feel free to ask me any questions about the code…

Note: can we move this conversation over to a new thread in the bindings forum (maybe a new “Russound RNET” rather than my old “Russound RIO” one)? This subforum is for habpanel…


1 Like

Following with great interest.


Wanted to dive into one of your suggestions to make sure I understand and we are on same page.

You said:
“I’d really think about defining different session implementations for different transports. I could see two different ones - direct/native serial and ip2serial that would be really handy. If you don’t have an ip2serial, I could test on my system (I do have one [not connected to russound but I can do that for testing]”

I’m relatively new to nio so I am not sure how things change from the previous ways…let me explain.

I have worked on a few bindings which would like to use the serial port. For various reasons I have always preferred ser2sock over direct serial port access, because I am not tied to having that usb cable into my openhab box. That doesn’t matter, just a little background.

In the past, I have been able to modify bindings which expect the serial access pretty easily. Really just a matter of dropping in a ‘Connection Manager’ which handles connect, disconnect, reconnect, and shares the input/output stream.

This allows the stream reading/command dispatching in a polymorphic way, not caring if it is a serial port connection or a tcp connection. (I haven’t done NIO with serial connection, so this is where I could definitely be off base.)

My impression when I saw the SocketChannelSession, is that we could break out the TCP or serial connecting into specific implementations. And then also, to handle the different protocols (RIO and RNET) we could break out ResponseReader class. I see the existing ResponseReader as a String/Text (crlf) Reader inmplementation as opposed to what we would need for RNET which is a binary protocol.

So maybe we end up with a ConnectionProvider interface which supports, connect, disconnect etc, things to handle the connection to the russounds.

What are your thoughts and suggestions on all this?


Here’s my thoughts:

  1. Edit the title of this thread - you mispelled russound making it hard to search on :slight_smile:
  2. ser2sock may work for you but won’t work for others (windows based or direct cable or in my case, itach ip2serial). What my point was that you should think of those other transports when designing and make ser2sock just one possible implementation. Don’t necessarily have to do the other implementation (although I could test an ip2serial one) - just make sure you can plug other ones in to support native or ip2serial easily (I’d think ip2serial would be a popular choice and is similar to ser2sock).

Personally - I’d leave SocketChannelSession alone, copy it and create your own version/wrapper for ser2sock that still abides the SocketSession interface and modify the responsereader as needed. That way you can eventually have a NativeSerialSession, Ip2SerialSession and your Ser2SockSession implementations that can easily be swapped.

I’m not familiar with the Ip2Serial, but how do you think the implementation would be different than Ser2Sock? I ask because when I did that prototype code which retrieves RNET messages from my russounds with your existing code, I just entered the ip and port that ser2sock exposes. Is that any different than ip2serial? I didn’t have to make any changes for the actual connection, it is just a tcp connection.

The serial connection would be different, it would open the serial port.

Ah - I see what you are saying (I think). So you are saying you have some device (probably a pi) that has a serial port and is running ser2sock - then the socketchannelsession simply connects to it and ser2sock will simply relay the binary you send it to the serial port? Interesting - does it support bidirectional communication (which you’ll need to get the feedback from the cav)?

When I say IP2Serial - I really mean the itach or global cache or simple blaster units that you can buy that support serial communication via IP. The Protocol can be found at and you could look at the GC100 binding [which implements that protocol]). Works with it’s own API however and is much more flexible (each unit support up to 3 different 'thing’s - IP2IR, IP2Serial, IP2CC, etc) - although it’s essentially the same concept.

So it looks like your ser2sock solution would be fairly easy to implement with the existing SocketChannelSession! However - keep in mind that there could be other types of implementations (like the itach units) - so don’t write anything outside of the SocketSession interface (which probably should be renamed to CommSession) that assumes ser2sock.

Actually - would be kinda interesting to do this. Write it up and make sure it works with ser2sock - after you have it working - let me know and I’ll write a itachsession and plug it into your work. Then we’ll see if there is any modifications that need to happen…

The GC100 OH1 binding doesn’t support serial. The globalcache OH2 binding I wrote supports serial, IR, and contact closure.

I wrote some rules to control my CAA66 using the globalcache binding and an iTach Flex configured with a serial cable, but what you propose above sounds like a better solution. :+1:

I’m not familiar with the CAV, but I assume the RNET protocol is used across both the CAV and CAA66???

The CAA66 does support two-way communication, but I haven’t yet implemented two-way support in the globalcache binding. I have a prototype of it, but it’s not ready to merge.

Edit: If you’re interested, I’ll post one of my rules so you can see what I did.

Yes with ser2sock you get bi-directional communication. It really just remotes the serial connection via tcp. Yes, I have a pi which has the usb-serial cable on it which connects to my russounds. then my openhab server connects via tcp to the port which ser2sock exposes on the pi.

the insteonplm binding support both tcp and serial connections to the device it uses. Basically what it comes down to, is you either connect to the device using a tcp connection, or a serial connection. Then you plug in the input stream and output stream of either of those to the code that reads or writes info to the device.

Once the pr is merged I’ll put together that code again to read the binary messages from my russounds via RNET and I think it will be clearer what overlaps we have.

Hey Mark! Love the OH2 binding btw - use it all the time! I have pretty much every configuration and it’s working fine with them all (the wired and wireless IR, CC and I’m just getting the serial).

RNET is supported on the ACA, CAV, CAM and CAA units I believe.

Note: I already had a conversation with Kai if this binding could somehow reference your binding to build the implementation using your code. The answer was no - each binding must be independent but he did say mention that if there was interest - could potentially be implemented as transports (in the io.transport package).

Sound good - I just pinged them as to when it will be merged. Assuming Kai is at the openhab foundation meeting so it may be delayed a bit…

FYI - Kai just merged the code.

saw that. I’ll update my bindings fork and take a look.

This is a bit off-topic for this thread, but I’m curious how well you know the RNET protocol? One thing I noticed when implementing two-way serial support in the globalcache binding… The RNET responses from my CAA back to OH2 are variable length, which makes it difficult for the binding to detect when one message ends and the next message begins in a protocol-independent way. I suppose the binding could allow the definition of an end-of-message value (probably using an Item) that the binding would use to break the input stream into logical messages. In the case of RNET, I think that’s a 0xF7. Wondering if you have any thoughts on other/better ways to do this?

Hi Mark,

I did RNET work awhile ago for 1.x, so I am a little rusty, and I’m no expert on binary protocols, or REGEX, so I am pretty sure my protocol handling could be improved.

That being said, if I remember correctly I watch the stream for the the 0xF7s, and then with those create byte arrays representing possible messages. Then I look for messages which match the message format that I ‘know’ how to parse, i.e. volume change message, source change message, etc. This sounds similar to what you are describing.

I’ll hook in this RNET protocol to the russound binding and maybe then I’ll have a clearer picture to be of assistance.


Attached is the RNET controller protocol - you can find your answers in it. Russound_Controllers_Protocol.pdf (553.2 KB)


Here is a build of the russound binding with limited RNet support. (Zone status/volume/source). I believe the only changes I made within existing code is limited to the Manifest, the HandlerFactory, and the thing-types.

Would you be able to drop this jar into your adding folder and make sure the RIO stuff works as before?

Also, if anyone who has RNet devices, please give this a go. I have only tested it with the ser2net (ser2sock) utility (i.e. no direct serial port connection) at this time. Discovery has not been implemented yet. You will have to add the RNet system thing, and then you can add zones.

Here is the jar located on my build server.

1 Like

Thanks Craigh,

I would love to test it, but being so new and non-coder I am having a tough time getting set up in Openhab without being spoon fed. As noted, i have your prior Rnet binding working via IP2SL (thank you). As I learn more in my free time, I will test this out.

I get the following in the console:

15:01:33.745 [ERROR] [org.openhab.binding.russound ] - FrameworkEvent ERROR - org.openhab.binding.russound
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.russound [194]
Unresolved requirement: Import-Package:

    at org.eclipse.osgi.container.Module.start([org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel([org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel([org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel([org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent([org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
    at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent([org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
    at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent([org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
    at org.eclipse.osgi.framework.eventmgr.EventManager$[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]

I just put up a new build which should have that fixed. I had the binding working within the IDE but messed up testing on my ‘production’ copy of openhab. It is now working for me.

Sorry about the inconvenience.


Ok - the latest installs but strangely doesn’t appear in paperui (ie trying to add [via Inbox->+ ] brings up a blank ‘Choose Binding’ screen)