cool. that is good to hear.
thanks for the feedback.
Hi Craig,
I came across this discussion just few days ago. I’ve been waiting for this binding for a long time!
I am running OpenHAB on a Windows 7 box and tried using the binding to connect to my CAV6.6 connected over COM1. To be honest I am not sure what the correct connection string is supposed to be and I’ve been trying to figure that out for the past two days 
just thought I would post the error I am getting as it does not seem to matter what I try for the connection string (ie. COM1), it gives me the same error below. I’ve confirmed that the system can “talk” to the amp using the Russounds PowerTools.
22:31:05.606 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'russound:rnet:91698e32' changed from UNINITIALIZED to INITIALIZING
22:31:05.559 [ERROR] [ome.core.thing.internal.ThingManager] - Exception occured while initializing handler of thing 'russound:rnet:91698e32': java.lang.NoClassDefFoundError: gn
/PortInUseException
java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError: gnu/io/PortInUseException
at java.util.concurrent.FutureTask.report(FutureTask.java:122)[:1.8.0_121]
at java.util.concurrent.FutureTask.get(FutureTask.java:206)[:1.8.0_121]
at org.eclipse.smarthome.core.common.SafeMethodCaller.callAsynchronous(SafeMethodCaller.java:194)[98:org.eclipse.smarthome.core:0.9.0.201702100936]
at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:83)[98:org.eclipse.smarthome.core:0.9.0.201702100936]
at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:67)[98:org.eclipse.smarthome.core:0.9.0.201702100936]
at org.eclipse.smarthome.core.thing.internal.ThingManager$9.run(ThingManager.java:698)[105:org.eclipse.smarthome.core.thing:0.9.0.201702100936]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_121]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_121]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)[:1.8.0_121]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.8.0_121]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_121]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_121]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_121]
Caused by: java.lang.NoClassDefFoundError: gnu/io/PortInUseException
at org.openhab.binding.russound.rnet.handler.RNetSystemHandler.initialize(RNetSystemHandler.java:213)
at org.eclipse.smarthome.core.thing.internal.ThingManager$9$1.call(ThingManager.java:701)
at org.eclipse.smarthome.core.thing.internal.ThingManager$9$1.call(ThingManager.java:1)
at org.eclipse.smarthome.core.common.SafeMethodCaller$CallableWrapper.call(SafeMethodCaller.java:181)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_121]
... 3 more
Caused by: java.lang.ClassNotFoundException: gnu.io.PortInUseException cannot be found by org.openhab.binding.russound_2.1.0.201706110121
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:439)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:352)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:344)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)[:1.8.0_121]
... 8 more
Hopefully you can shed some light on this for me.
Thank you,
Tom
Hi Tom,
This is a problem with general serial port handling.
I’m away travelling right now, but do a little searching around these
forums or on google for openhab 2 serial port. I don’t use serial ports
directly from openhab, but for openhab2 it might be as easy as installing a
serial binding or something, I’m just not sure.
Good luck,
Craig
Hi Craig,
That sounds good. I was just looking for some direction. I will put some more effort into it and see.
Thank you again,
Tom
Craig,
Finally got around to testing this. Here’s some comments:
- Was able to define the controller
- The controller went online and in my inbox I had a single zone discovered called ‘RNET Audio Zone (1_1)’. Didn’t know you supported discovery! At any rate, I have 6 zones on the controller - only discovered that 1 (and it had ‘unknown device’ as it’s type).
- I manually defined zone 6 - came online without any issues.
- I see you copied basically all the channels from the RNET and I’m sure most the channels don’t work. The status and source channels worked great. The mute didn’t work at all and the volume didn’t work as well (although it looks like you have code behind the volume one.
For the volume - here is the debug output when I changed volume:
10:27:47.393 [DEBUG] [d.rnet.internal.RNetProtocolCommands] - original command message: f0 00 00 7f 00 00 70 05 02 02 00 00 f1 21 00 12 00 00 00 01
10:27:47.393 [DEBUG] [d.rnet.internal.RNetProtocolCommands] - after copy command message: f0 00 00 7f 00 00 70 05 02 02 00 00 f1 21 00 12 00 00 00 01
10:27:47.394 [DEBUG] [d.rnet.internal.RNetProtocolCommands] - getCommandReturning zone: 6, controller: 1, value: 4
10:27:47.394 [DEBUG] [d.rnet.internal.RNetProtocolCommands] - Bytes: f0 00 00 7f 00 00 70 05 02 02 00 00 f1 21 00 04 00 05 00 01
10:27:47.394 [DEBUG] [internal.connection.DeviceConnection] - send command called with bytes: f0 00 00 7f 00 00 70 05 02 02 00 00 f1 21 00 04 00 05 00 01 18 f7 ,close socket:
10:27:47.394 [DEBUG] [internal.connection.DeviceConnection] - connect() returning: true
10:27:47.395 [DEBUG] [internal.connection.DeviceConnection] - Sending 22 bytes: f0 00 00 7f 00 00 70 05 02 02 00 00 f1 21 00 04 00 05 00 01 18 f7
10:27:47.395 [DEBUG] [sound.rnet.handler.RNetSystemHandler] - received connection notification: true
10:27:47.395 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'russound_rnetzone_0775a76e_volume' received command 9
10:27:47.397 [INFO ] [marthome.event.ItemStateChangedEvent] - russound_rnetzone_0775a76e_volume changed from 4 to 9
BTW - this was using an ITACH IP2SL
Hi Tim,
Could you download the latest and test with this build. I’ve done some more cleanup, etc. (Note have bumped it to 2.2.0)
https://s3-us-west-2.amazonaws.com/craigham-pub/org.openhab.binding.russound-2.2.0-SNAPSHOT.jar
As for the auto-discovery, when you created the rnet controller, there were fields for # of controllers, and # zones per. Those values are used to ‘auto-generate’ zones, no real discovery going on. 1/1 were the defaults, so you ended up with one zone.
That is odd re volume. It works for me. Do you have a remote for your russound? Maybe if you could switch volume around and send me the bytes detected on the bus I can see what might be going wrong.
Mute not implemented yet.
Thanks,
craig
Ok - tested with the 2.2 - same results (slider in paperui not affecting volume). Here’s some volume changes with the remote (both up and down)
11:10:38.490 [DEBUG] [nal.connection.RNetInputStreamParser] - Russound message: f0 00 05 7f 00 05 00 05 02 01 00 02 01 00 7f 00 00 00 00 00 01 19 f7
11:10:38.553 [DEBUG] [nal.connection.RNetInputStreamParser] - Russound message: f0 00 05 7d 00 00 7f 06 05 00 90 01 10 2a f7
11:10:39.616 [DEBUG] [nal.connection.RNetInputStreamParser] - Russound message: f0 00 05 7f 00 05 00 05 02 01 00 02 01 00 7f 00 00 00 00 00 01 19 f7
11:10:39.678 [DEBUG] [nal.connection.RNetInputStreamParser] - Russound message: f0 00 05 7d 00 00 7f 06 06 00 90 01 10 2b f7
11:10:40.856 [DEBUG] [nal.connection.RNetInputStreamParser] - Russound message: f0 00 05 7f 00 05 00 05 02 01 00 02 01 00 7f 00 00 00 00 00 01 19 f7
11:10:40.918 [DEBUG] [nal.connection.RNetInputStreamParser] - Russound message: f0 00 05 7d 00 00 7f 06 07 00 90 01 10 2c f7
11:10:42.231 [DEBUG] [nal.connection.RNetInputStreamParser] - Russound message: f0 00 05 7f 00 05 00 05 02 01 00 02 01 00 7f 00 00 00 00 00 01 19 f7
11:10:42.293 [DEBUG] [nal.connection.RNetInputStreamParser] - Russound message: f0 00 05 7d 00 00 7f 06 08 00 90 01 10 2d f7
11:10:44.043 [DEBUG] [nal.connection.RNetInputStreamParser] - Russound message: f0 00 05 7f 00 05 00 05 02 01 00 02 01 00 80 00 00 00 00 00 01 1a f7
11:10:44.043 [DEBUG] [nal.connection.RNetInputStreamParser] - Russound message: f0 00 05 7d 00 00 7f 06 07 00 90 01 10 2c f7
11:10:44.231 [DEBUG] [nal.connection.RNetInputStreamParser] - Russound message: f0 00 05 7f 00 05 00 05 02 01 00 02 01 00 80 00 00 00 00 00 01 1a f7
11:10:44.293 [DEBUG] [nal.connection.RNetInputStreamParser] - Russound message: f0 00 05 7d 00 00 7f 06 06 00 90 01 10 2b f7
11:10:44.606 [DEBUG] [nal.connection.RNetInputStreamParser] - Russound message: f0 00 05 7f 00 05 00 05 02 01 00 02 01 00 80 00 00 00 00 00 01 1a f7
11:10:44.668 [DEBUG] [nal.connection.RNetInputStreamParser] - Russound message: f0 00 05 7d 00 00 7f 06 05 00 90 01 10 2a f7
11:10:45.293 [DEBUG] [nal.connection.RNetInputStreamParser] - Russound message: f0 00 05 7f 00 05 00 05 02 01 00 02 01 00 80 00 00 00 00 00 01 1a f7
11:10:45.356 [DEBUG] [nal.connection.RNetInputStreamParser] - Russound message: f0 00 05 7d 00 00 7f 06 04 00 90 01 10 29 f7
Tim,
Would you mind getting the latest? I had a no-op path in the volume handling which may have being triggered?
Also, there is support for mute now.
Mute is indeed working now - volume however is not.
Craig - is your source on github or other server? If you can zip it and post it - I can step through it in debug and see if I see anything…
awesome, was trying to figure out a way I could debug this. Here is my GitHub, its the russound-rnet2 branch
craigh,
Line 72 in RNetProtocommands needs to be
new RNetProtocolCommands(volumeBytes, new int[] { 1, 4 }, new int[] { 5, 17 }, 15),
According to 8.3.1 in the RNET spec - you need to set bytes 6 and 18 to the zone number. You were only setting byte 18.
Thanks for finding that TIm. Latest build has the fix.
Just tested it and it all seems to be working (tried balance, treble, etc).
A few things did occur however:
- Go to the RNET device, change the port to something invalid, wait until the connection time’s out and the thing goes offline, then change the port back to the valid port. Should reconnect but the reconnect is failing with a time out - you are probably cach’ing some state somewhere that needs to be refreshed (haven’t looked at the code - so that’s a guess).
- You may have not gotten this far - but on startup, the item values are not updated from russound (ie the volume remains null until I reset it). Likewise if I use the keypad or remote and change something - the associated channel value never changes.
- I got the following NPE - can’t remember how I got that but it was part of changing the port number via paperui (actually - I think it was having an invalid port # at startup) - but you’ll see in the log messages that the zone id was null
2017-07-07 14:21:11.355 [ERROR] [nal.connection.TcpConnectionProvider] - Can't connect: connect timed out
2017-07-07 14:21:11.355 [DEBUG] [sound.rnet.handler.RNetSystemHandler] - received connection notification: false
2017-07-07 14:21:11.355 [DEBUG] [sound.rnet.handler.RNetSystemHandler] - received connection notification: false
2017-07-07 14:21:11.355 [DEBUG] [internal.connection.DeviceConnection] - connect() returning: false
2017-07-07 14:21:11.355 [ERROR] [internal.connection.DeviceConnection] - Error occured during message waiting
java.io.IOException: Not Connected to Receiver
at org.openhab.binding.russound.rnet.internal.connection.DeviceConnection.waitStateMessages(DeviceConnection.java:225)[182:org.openhab.binding.russound:2.2.0.201707071536]
at org.openhab.binding.russound.rnet.internal.connection.DeviceConnection.access$0(DeviceConnection.java:183)[182:org.openhab.binding.russound:2.2.0.201707071536]
at org.openhab.binding.russound.rnet.internal.connection.DeviceConnection$DataListener.run(DeviceConnection.java:252)[182:org.openhab.binding.russound:2.2.0.201707071536]
2017-07-07 14:21:11.355 [DEBUG] [sound.rnet.handler.RNetSystemHandler] - child handler initialized, child: org.eclipse.smarthome.core.thing.internal.ThingImpl@4b2c842f
2017-07-07 14:21:11.355 [DEBUG] [ussound.rnet.handler.RNetZoneHandler] - rnet zone channel linked: russound:rnetzone:0775a76e:status
2017-07-07 14:21:11.371 [DEBUG] [ussound.rnet.handler.RNetZoneHandler] - Requesting zone info, id: null
2017-07-07 14:21:11.371 [DEBUG] [ussound.rnet.handler.RNetZoneHandler] - rnet zone channel linked: russound:rnetzone:0775a76e:volume
2017-07-07 14:21:11.371 [DEBUG] [ussound.rnet.handler.RNetZoneHandler] - Did not request zone info as elapsed since last call is: 0
2017-07-07 14:21:11.371 [DEBUG] [ussound.rnet.handler.RNetZoneHandler] - rnet zone channel linked: russound:rnetzone:0775a76e:source
2017-07-07 14:21:11.371 [DEBUG] [ussound.rnet.handler.RNetZoneHandler] - Did not request zone info as elapsed since last call is: 0
2017-07-07 14:21:11.371 [DEBUG] [ussound.rnet.handler.RNetZoneHandler] - rnet zone channel linked: russound:rnetzone:0775a76e:mute
2017-07-07 14:21:11.371 [DEBUG] [ussound.rnet.handler.RNetZoneHandler] - Did not request zone info as elapsed since last call is: 0
2017-07-07 14:21:11.371 [DEBUG] [d.rnet.internal.RNetProtocolCommands] - getCommand called, command: ZONE_INFO, zoneId: null, value: 0
2017-07-07 14:21:11.371 [DEBUG] [d.rnet.internal.RNetProtocolCommands] - original command message: f0 00 00 7f 00 00 70 01 04 02 00 00 07 00 00
2017-07-07 14:21:11.371 [DEBUG] [d.rnet.internal.RNetProtocolCommands] - after copy command message: f0 00 00 7f 00 00 70 01 04 02 00 00 07 00 00
2017-07-07 14:21:13.355 [DEBUG] [internal.connection.DeviceConnection] - Reconnecting...
2017-07-07 14:21:17.105 [DEBUG] [d.rnet.internal.RNetProtocolCommands] - getCommand called, command: POWER_SET, zoneId: null, value: 1
2017-07-07 14:21:17.105 [DEBUG] [d.rnet.internal.RNetProtocolCommands] - original command message: f0 00 00 7f 00 00 70 05 02 02 00 00 f1 23 00 00 00 05 00 01
2017-07-07 14:21:17.105 [DEBUG] [d.rnet.internal.RNetProtocolCommands] - after copy command message: f0 00 00 7f 00 00 70 05 02 02 00 00 f1 23 00 00 00 05 00 01
2017-07-07 14:21:17.105 [ERROR] [ome.core.thing.internal.ThingManager] - Exception occurred while calling handler: java.lang.NullPointerException
java.util.concurrent.ExecutionException: java.lang.NullPointerException
at org.eclipse.smarthome.core.common.SafeMethodCaller.executeDirectly(SafeMethodCaller.java:220)[98:org.eclipse.smarthome.core:0.9.0.201706270841]
at org.eclipse.smarthome.core.common.SafeMethodCaller.callAsynchronous(SafeMethodCaller.java:189)[98:org.eclipse.smarthome.core:0.9.0.201706270841]
at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:83)[98:org.eclipse.smarthome.core:0.9.0.201706270841]
at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:67)[98:org.eclipse.smarthome.core:0.9.0.201706270841]
at org.eclipse.smarthome.core.thing.internal.ThingManager.receiveCommand(ThingManager.java:374)[105:org.eclipse.smarthome.core.thing:0.9.0.201706270841]
at org.eclipse.smarthome.core.items.events.AbstractItemEventSubscriber.receive(AbstractItemEventSubscriber.java:47)[98:org.eclipse.smarthome.core:0.9.0.201706270841]
at org.eclipse.smarthome.core.internal.events.OSGiEventManager$1.call(OSGiEventManager.java:192)[98:org.eclipse.smarthome.core:0.9.0.201706270841]
at org.eclipse.smarthome.core.internal.events.OSGiEventManager$1.call(OSGiEventManager.java:1)[98:org.eclipse.smarthome.core:0.9.0.201706270841]
at org.eclipse.smarthome.core.common.SafeMethodCaller$CallableWrapper.call(SafeMethodCaller.java:181)[98:org.eclipse.smarthome.core:0.9.0.201706270841]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_131]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_131]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_131]
at java.lang.Thread.run(Thread.java:748)[:1.8.0_131]
Caused by: java.lang.NullPointerException
at org.openhab.binding.russound.rnet.internal.RNetProtocolCommands.getCommand(RNetProtocolCommands.java:116)[182:org.openhab.binding.russound:2.2.0.201707071536]
at org.openhab.binding.russound.rnet.internal.RNetProtocolCommands.getCommand(RNetProtocolCommands.java:134)[182:org.openhab.binding.russound:2.2.0.201707071536]
at org.openhab.binding.russound.rnet.handler.RNetZoneHandler.handleCommand(RNetZoneHandler.java:143)[182:org.openhab.binding.russound:2.2.0.201707071536]
at org.eclipse.smarthome.core.thing.internal.ThingManager$4.call(ThingManager.java:377)[105:org.eclipse.smarthome.core.thing:0.9.0.201706270841]
at org.eclipse.smarthome.core.thing.internal.ThingManager$4.call(ThingManager.java:1)[105:org.eclipse.smarthome.core.thing:0.9.0.201706270841]
at org.eclipse.smarthome.core.common.SafeMethodCaller.executeDirectly(SafeMethodCaller.java:218)[98:org.eclipse.smarthome.core:0.9.0.201706270841]
... 12 more
Have you tried zone discovery by side effect (this is how I do it for rnet). To see if you can do something - send off a getstate for a controller/zone id that doesn’t exist (controller 3, zone 1 assuming you don’t have three controllers!). What kind of response do you get back and is there a way to tell if it was a valid or invalid controller/zone? If the response has something that can tell you than - you can do a simple 6 controller by 6 zone loop and determine what’s available and what’s not. I didn’t see anything in the spec but you might be able to observe something…
ya, I have to do a bit of lifecycle work with respect to clearing things out
I will give this a shot, maybe send the getzoneinfo command and see if I get results. I’ll poke around. thanks for the suggestion.
Hey craigh, what’s the status on this modification to the binding?
Well crap, I already built a serial binding for Russound. Didn’t realize this was being worked on. If y’all need any help I’m way too familiar w/ the serial protocol.
Check out my existing PR which I guess will go the way of the dodo:
It’s based on a simple library I wrote to generate serial codes for the different commands:
@tmrobert8, I haven’t had a chance to add auto-discovery by probing for different controller/zone combos yet.
The binding has been working very well using the tcp layering over the serial port.
I haven’t been able to test the direct serial port connection. I run openhab within docker on a different server than the russound serial connection, and the combination of that and getting the serial port jre setting correct has been too painful.
@holmes.j, If you could test the direct serial connection that would be great. The binding should just work once you get the serial port connection, all the code is the same as via the tcp connection.