This page last changed on Nov 04, 2009 by mredeker.

Hi guys,

I am currently in contact with the german distributor of Russound.
Russound is a major brand for producing distributed audio-video and multiroom entertainment systems.
The Russound devices support complete control through a RS232 port and I will implement the protocol for the OpenRemote controller.

Anybody here who already has a Russound device and can suggest what features to implement first?

--Marcus


This would be another awesome contribution from you into OR integration stack!

Posted by juha at Nov 05, 2009 01:14

The first implementation based on the current controller trunk source is done.
It supports turning all zones on/off, each zone separately can be turned on/off, you can select the input source for each zone and adjust the volume for each zone.
Currently only one controller with up to 6 zones is supported but we can easily extend to more controller and zones since all russound commands are stored in a property file.

Posted by mredeker at Nov 15, 2009 12:08

Very cool, thanks for working on this and contributing it Marcus.

Posted by juha at Nov 19, 2009 00:43

The code for this is currently available in /branches/feature/RussoundSupport-mredeker

Posted by juha at Nov 20, 2009 12:28

I have a Russound CAV6.6 with 4 additional A-Bus zones attached that I am looking to interface with via OpenRemote. My audio includes a Russound Tuner ST and a BARIX extreemer as a music streamer from my computer as 3rd Russound source. There is also a JDS Technologies Stargate Home Automation Controller that I want to interface with via RS232 but that will have to follow the Home Audio automation.

I have downloaded the /branches/feature/RussoundSupport-mredeker code, compiled and deployed. Now I am looking to configure a few panels from my iTouch to activate the system. I have created a basic screen with a button that does nothing except demo that I have a connection to my OR server (Debian linux on ancient Pentium computer). Now I am just staring at all this stuff wondering what to do next.

I would like to create a panel to do basic stuff on/off just to get a starting place. what are the sequence of actions to link iTouch button to OR action for the Russound? Which option for creating the interface? A: http://composer.openremote.org/1.0/ or B: http://composer.openremote.org/demo/Modeler.jsp?
I will start reviewing to code to see if I can figure out the nuts and bolts that drve this tool....

Posted by omikeneil at Apr 06, 2010 03:13

Michael,

the code from the "RussoundSupport-mredeker" branch is based on BOSS 1.0, but the composer for 1.0 does not support the russound commands yet.
You will have to modify controller.xml by hand to get the Russound commands working.

@Juha: Maybe you can create a 2_0_0_Alpha4 tag which has support for Russound?

Posted by mredeker at Apr 06, 2010 08:23

Can you guys port the Russound code from 1.0 to 2.0? I'm a tad busy right now. You can branch either from /trunk/UIDesigner or /branches/project/UIDesigner_2_0_0_Alphas. Both are regularly synced at the moment with the ongoing work. I'll merge back to release branch once you're done.

Posted by admin at Apr 06, 2010 18:39

I code for Weblogic and WebSphere using Eclipse in the corporate world. I just recently installed Tomcat on Debian at home and I will need to come up to speed on the code. I am somewhat unfamilier with the opensource nature of the project but I will see if I can dig in and see where this project is headed.

I downloaded OpenRemote-Boss-1.0.2.zip. is there a version 2.0? Reviewing what I have I am not sure that the Russound code is deployed.

I will review the code to see if I can contribute in any way. I would like to see if I can get one thing working before attempting something so cool as porting the code.....

Is there a sample controller.xml file that demos the russound features that I can hack?

Posted by omikeneil at Apr 08, 2010 02:28

You're half way there – you were able to compile and run Marcus' /branches/feature/RussoundSupport-mredeker

This is not included in the 1.0.2 binaries, I never had the time to integrate it back to the mainline (and it slipped my mind).

So work on the RussoundSupport-mredeker binaries you've compiled.

You will find a russound.properties file there with a configuration sample (WEB-INF/classes directory IIRC).

On porting, there has been changes between 1.0: first the protocol API in the controller may need to be adjusted for 2.0. The 2.0 controller has not gone through QA yet but the branch to work from is /branches/feature/Controller-profile-service (that is the 2.0 controller implementation).

The second part of the porting is configuration mechanism has changed, it's driven by the online designer now where you use the web UI to set protocol specific properties, these are downloaded as an XML file to the controller. The Russound implementation would ideally follow the same model (though this is a secondary goal in the porting effort).

So yeah, get your stuff first working with the -mredeker Russound branch to ensure you have a working system to test against.

Then if you're so inclined, can look into 2.0 porting.

Sorry to hear about your second life with Weblogic/Websphere (just kidding... Just Kidding!!). Welcome to Open Source

Posted by juha at Apr 08, 2010 11:35

I already have the russound support ported to the 2.0 controller implementation.
It's just not in SVN in the moment.

Posted by mredeker at Apr 08, 2010 11:46

Great!

Posted by juha at Apr 08, 2010 11:55

pays the bills.....

Posted by omikeneil at Apr 09, 2010 02:05

Indeed it does

Posted by admin at Apr 09, 2010 04:25

IT DONT WORK... for me. There was no sample configuration file to hack so I am running a sample I created to see what the code does with it. I am making progress. There are no errors in the controller.log file and I suspect I may not be getting any output on the serial port to the Russound controller.

Correct me if I am wrong: I created an openremote.zip file using the online creator tool. from this it really does not matter what the iTouch screens are since the ButtonCommandRESTServelet.java only reads the command button ID and looks this up in the controller.xml which then supplies the actual command processed. Yes? NO? (don't beat me up Warf...)

I am up to the point where I am viewing the actual command received from the iTouch in the ButtonCommandRESTServelet.java. I am going to follow this through - to my guess is reading the controller.xml file in the buttonCommandServiceImll.java for the russound.propeties property to get the zone1.on command string. Then follow that to see why nothing is getting dumped to the device.

I do see in the code (somewhere when I was looking) that the Russound commands are dumped into the serial port (not udp, actual RS232 hardware...as configured in the russound.property file) - Task over. There is no dialog with the controller in this release. I am pretty excited to hopefully get Zone 1 to turn on - if I can only get more than a few hours a week to look at this.

Once I get zone 1 working (ON/OFF -MAX VOLUME to announce to my local world of my triumph) I would like to begin looking into starting up a thread that monitors COM1 I/O picking up traffic and begining dialog with the unit there.
I am also interested in getting a separate web app to be able to send/receive data to this device via a web service or direct link.

Markus have you had any updates on the dialog with Russound? In the documentation that I have gotten from there web site I understand the RNET "dialog" used. However, they have a directory structure for saving data on the various devices. the directories are numeric values and data can be placed there - for example the bass setting is in a directory structure on the zone controller and it has a value placed there. I have not found documents the tell me what the directories are for, for example directory 0,4,3,4 (4 levels deep) holds the Bass value of 4 (out of possible 10). When I monitor the RNET traffic in a basic com port reader pgm I can see all this detail but I am still deciphering what these directories represent.

I'll keep hacking at it...
Mike
RED WINE = VERBOSE

Posted by omikeneil at Apr 13, 2010 04:05

Correct me if I am wrong: I created an openremote.zip file using the online creator tool. from this it really does not matter what the iTouch screens are since the ButtonCommandRESTServelet.java only reads the command button ID and looks this up in the controller.xml which then supplies the actual command processed. Yes? NO? (don't beat me up Warf...)

That's correct. The controller is decoupled from clients, you can invoke the REST interface directly (from your browser if you want to). iTouch is not necessary.

Posted by juha at Apr 13, 2010 05:33

Now that you mention it - DUH! I really do not need my iTouch, just a link on a web page that performs the same thing. I do like that! But controlling on the iTouch makes that purchase so much more justified....

I did find the RussoundEvent.java was using a different RS232 port configuration than I use when monitoring the port in my utility. So I updated that in the code. Still no luck. I am debugging this event to see if I am hitting the udp or RS232 code and what is the command I am sending.

I really feel a eureka moment is near...

Posted by omikeneil at Apr 14, 2010 03:49

aghh! the moment passed....
The port WAS 19200, my udp WAS back into the props, my environment is chaotic... do I look like I am going bald?

NOW I think I have it right and I still get no response from the Russound controller. Next step is to hook up the laptop to the com port and monitor the port to see if I get any DC on the port.

This is more of a challenge then I expected....

Posted by omikeneil at Apr 14, 2010 05:17

OK I have tracked my issue to the rxtxComm. The error is in the tomcat/logs/localhost.log: java.lang.NoClassDefFoundError: Could not initialize class gnu.io.CommPortIdentifier

It is apparently not in the classpath. I have the Sun comm.jar in my classpath on tomcat (I use this to read the serial port in my crude port reader pgm). But my program includes this at run time and tomcat apparently is not finding even after adding to the tomcat/bin/setenv.sh

I see RXTXcomm-2.2-pre2.jar file in the Russound tar file, but it does not seem to be found by tomcat/controller when attempting a call to the port. (the error is: java.lang.NoClassDefFoundError: Could not initialize class gnu.io.CommPortIdentifier)

I am new to tomcat. Anyone familier will adding this to the classpath? Which file is required? Sun or rxtx?

I am going to continue to find out if I can use the Sun version, change my controller to use the sun jar file I know works on my model T computer....

Posted by omikeneil at Apr 19, 2010 03:16

You need the RXTX implementation. This comes with a jar and a shared library. You need the jar in your classpath (controller/WEB-INF/lib/classes) and the shared library in your windows or linux library path.

Posted by mredeker at Apr 19, 2010 08:01

You need the RXTX implementation. This comes with a jar and a shared library. You need the jar in your classpath (controller/WEB-INF/lib/classes) and the shared library in your windows or linux library path.

Posted by mredeker at Apr 19, 2010 08:01

EUREKA! Finally!
OK now this is cool .. thanks!
Now to get all the existing commands to work from the property file.

Posted by omikeneil at Apr 20, 2010 02:18

I have a CAV 6.6 installation in my home so naturally i am interested in your work on the Russound serial protocol. Now I wonder, since the designer does not support Russound, would it be possible to check in a sample controller.xml on the Russound branch? Some kind of mini-tutorial covering the necessary configuration would be helpful. Then I am interested in patches for the Controller 2.0, if it would be possible to produce any.

What is your thoughts about the future of the Russound solution you have started? Is it worth continue on it as it is now? I have experience as a Java developer so I might be able to help bring things a bit forward.

As an alternative solution I thought about creating a standalone application for controlling Russound providing a web-interface that could be integrated in the Openremote solution using HTTP. That would simplify the integration in the Designer but with no immediate support status updates. What do you think about such a solution?

Posted by toesterdahl at Mar 16, 2011 16:37

I am currently working on a new implementation which supports all kinds of control and also read feedback from the device.

Posted by mredeker at Mar 16, 2011 20:29

Another feature I thought about was to have a daemon listening for keypresses on the Russound keypads and feed them back to use them as input of Openremote. 

Anyway, it would be cool to be able to share that code on some new branch. I started migrating the 1.0 Russound code into my 2.0 system and it does not seem to overwelming.

Posted by toesterdahl at Mar 17, 2011 21:59

Well. This is a key feature to me and I wanted to learn a bit about support for RS232 in OR so I got the code migrated to version 2.0.0 Alpha 11 of the controller. The results are at https://openremote.svn.sourceforge.net/svnroot/openremote/workspace/toesterdahl/Controller_2_0_0_Alpha11_Russound/. Works for the functions operating on a Russound Zone implemented by Marcus.
Right now I see that the following features could be added to the Russound solution;
1. Support in Designer for Russound protocol.  
2. Feedback through the StatusCommand.  
3. Have keypresses of Russound keypads operating on Sources (Devices in OR lingua) fed back into the OR system.
4. Support for all Russound commands operating on a Zone.
5. Reconciling with othere RS232 protocols of OR.
My opinion is that 1. is vital, manual configuration is a real pain. 2. is mostly sugar but nice if it works. 3. Would clearly be expected in Russound installations but is conceptually a bit alien to OR. 4. Probably does not add much, vital commands is already supported.
I would be interested in Marcus' opinion about what to do next??

Posted by toesterdahl at Mar 29, 2011 15:47

Regarding #3, are you able to provide some generic model of what you mean here to someone not familiar with Russound (keypads operating on sources fed back into OpenRemote?)

May be alien for OR now but if we can understand it, we may be able to bring it to the next major version in some generalized form. Use case description would help.

Thanks for the contribs in SVN,

– Juha

Posted by juha at Mar 29, 2011 21:12

The russound system have six listening zones. Each zone have a keypad and is at any moment in time assigned to one audio/video (AV) source. The keypad allows different operations on the system (as a whole), on the zone or one the source.
The most essential operations on the system and zone level are implemented namely source select, volume up/down and power on/off.
For the purpose of controlling source devices each keypad have the buttons 'Pause', 'Stop', 'Play', 'Fwd', 'Back', 'Next' and 'Previous' as well as the macro buttions 'F1' and 'F2'.
From a configuration point of view you would expect to se that your device (the Russound device) could generate the event 'Play' for any of six sources. You would want to map this to commands on source-devices. The mapping could be the same that is currently done for button keypresses in the Designer.
I am unsure, perhaps the event of my description is exactly what signals do?

Posted by toesterdahl at Mar 29, 2011 22:05

My current testing is also aiming in this direction. All RNET commands and feedbacks could be supported. It's just a hack and I am still testing but a new version of the Russound support will go in this direction.

Posted by mredeker at Apr 01, 2011 22:39

I gave it another thought while I browsed other protocol implementations. I see some space for adding a protocol to provide generic support for RS232. This could work very similar to generic support for protocols such as http and telnet. Right now these protocols is not much more then transport mechanisms for messages which could be hex-based or ascii. If they would be improved beyond that for say, interpreting responses, it would make sense to keep the implementation consistent across these protocols. I would categorize these protocols as transport oriented and device-independent. Such a generic RS232 support could easily replace the Russound support as it currently stands. Are there any place for a dedicated Russound protocol then? Well only if the protocol API exposes enough features that actually makes a difference at configuration time. The events discussed in my previous post would be one such feature, though. However it only makes sense to add new features to the protocol if they can be used by other parts of the system, say the designer and the panels.

Take this example. I am also looking into supporting the Denon AVR's over RS232. They have commands for navigating an IPOD, commands that sometimes would return a selection list of songs. However unless there are configurable components to do something with this playlist I would just as well expose the commands and forget about the response, something that can be achieved in a very generic fashion.

At the moment I am hacking some support for my Denon AVR system. It uses some rather readable Ascii messages and it appears that it should be rather painless to make it work. A slight challenge might be to make things generic for various Denon AVR models. Similar to Russound, another challenge is to do something sensible with responses so that they can actually be used by the Openremote system.

Posted by toesterdahl at Apr 02, 2011 14:37

1) Generic RS232 support would be very interesting, similar to generic HTTP, TCP/IP, Telnet and UDP

2) Yes the protocol (and event) level scripting is coming along, it is being implemented as we speak

3) Does it leave space for Russound specific implementation – in the long run perhaps not, in the short run a device specific protocol implementation can be easier for users on the designer side with specific commands (play, stop, etc) rather than having to dig up the RS232 protocol specs and type things in.

Longer term, these should be something we store in the Beehive. With a combination of protocol scripting, generic transports and ability to share everything in the cloud, a lot of the need for specific protocol implementations disappear (to what extent depends on the quality of the scripting language, i.e. even KNX IP tunneling could be scripted instead of written in Java but how much that makes sense to do so depends on the use case).

So yeah, your intuition is correct. We need to get the controller up to speed regarding 2.0 release – the basics need to be solid otherwise the tooling makes little sense.

Posted by juha at Apr 05, 2011 14:34

The problem with Russound is that the RS232 protocol is a binary protocol You cannot just send ASCI strings which works with all other home entertainment devices. Also, you have to recalculate a checksum every time you change a value. Which means e.g. a volume slider which can go from 1-100 has 100 commands which are all different because of the value and the checksum. This is what I am currently working on.

Posted by mredeker at Apr 05, 2011 15:01

The problem with Russound is that the RS232 protocol is a binary protocol You cannot just send ASCI strings which works with all other home entertainment devices. Also, you have to recalculate a checksum every time you change a value. Which means e.g. a volume slider which can go from 1-100 has 100 commands which are all different because of the value and the checksum. This is what I am currently working on.

Posted by mredeker at Apr 05, 2011 15:01

The problem with Russound is that the RS232 protocol is a binary protocol You cannot just send ASCI strings which works with all other home entertainment devices. Also, you have to recalculate a checksum every time you change a value. Which means e.g. a volume slider which can go from 1-100 has 100 commands which are all different because of the value and the checksum. This is what I am currently working on.

Posted by mredeker at Apr 05, 2011 15:01

Thanks. Good point. I guess it applies to anything where you have some parameter to the input; such as the slider in this case. For any pre-configured commands such as button presses the command including checksum can be prepared beforehand, which have been demonstrated. The checksum is indeed rather hairy and seem implementation specific.

This is the procedure for calculating the checksum.

Step #1 - Add the HEX value of every byte in the message that precedes the Checksum:
Example - 0xF0 + 0x00 + 0x67 + 0x7C + 0xF1 + 0x0F = 0x02D3
Step #2 - Count the number of bytes which precede the Checksum and convert that value from
DEC to HEX (byte count). Add the byte count in HEX to the previously calculated sum of
bytes:
Example - 0x02D3 + 6 (6 = Decimal value byte count) = 0x02D9
Step #3 - This value is then AND-ed with the HEX value 0x007F (7F is the highest BIN value
for 7 bits = 1111111). The Checksum itself and the End of Message Character are not
included in the calculation. Only the low 7 bits are used so overflow is discarded:
Example - 0x02D9 AND 0x007F = 0x59 = Checksum

(no copyright!)
Posted by toesterdahl at Apr 06, 2011 20:09

Thanks for information, in particular your view on adding configuration to Beehive. In fact that is what I wanted to do; although I was reluctant to take it on not knowing how good the support for this was in the project.

Posted by toesterdahl at Apr 06, 2011 20:13

I already have the checksum calculation implemented in the OpenRemote controller Currently I am working on a reader thread which translates RNET protocol data (e.g. keypad buttons) into OpenRemote sensor information.

Posted by mredeker at Apr 06, 2011 21:15

No problem. I thought so. But I thought someone else following the thread might be interested in what we were talking about.

Posted by toesterdahl at Apr 07, 2011 19:51

Hi Torbjörn,

I rewrote the Russound integration and the commands are not needed as hardcoded hex strings as before. Everything is dynamic now and the checksum is calculated by the controller. We don't need the russoundCommand.properties anymore and I integrated the russound.properties into the general config.properties.

In the designer you now have to specify a zone number (1-6), a controller numer (1-6) and a command.

I also implemented the new EventListener interface which means changes done by the keypads are recognized and displayed back in the UI through sensors.

It is now possible to use sliders for Volume, Balance, Treble and TurnOnVolume.

The changed protocol is currently beeing integrated by Juha into the new 2.0 release.

You can also find it in my branch: workspace/mredeker/Controller_EP_SNAP_20111102_NewProtocols

Here is a screenshot:

Posted by mredeker at Nov 16, 2011 09:10

1

Posted by pjmm at Dec 12, 2011 20:27
Document generated by Confluence on Jun 05, 2016 09:31