Trying Now.
@S-F that sucks!!! Did you buy it off eBay, or new?
POWER ON/OFF Works from within the device, but not on the front page for some reason.
Still a problem with Source Selection. Can only choose Radio, and then everything locks up. Have to delete plugin again.
Also want to note it’s constantly polling the device, and choking the system. Take a look at system log.
Maybe reduce the polling to every 2 minutes, or have an option to not poll automatically
Mem Available85912kilo bytes
CPU Load (1 minute)1.34
CPU Load (5 minute)1.09
CPU Load (15 minute)0.82@S-F: That does suck, sorry to hear that.
@big517:
That is really strange since those two power buttons map to the exact same action…there should be no difference between them at all.
As for the CPU issues, my guess is what the plugin is sending to the controller requesting status is what is causing the CPU issue as my CPU doesn’t get below 80% idle (0.11 0.20 0.22). It’s probably completely wrong for that implementation of RNET and it’s processing a bunch of junk coming back. You can likely alleviate that issue by commenting out all the status request commands but then, obviously, you’ll get no status. If you can find the proper commands and responses for that implementation of RNET (or ask Russound for them), I’m happy to make the change.
I’m baffled by the source issues. Only thing I can think of here is that this implementation now has two controller bytes, one for “controller” and one for “source controller”. This isn’t the case in the CA-series implementation (only one controller byte) and there is no description I can find for what “source controller” is. If you ping Russound support, ask for these descriptions, too.
Was that information not contained in one of the documents I posted? Maybe in the Zip file?
It isn’t included for the C-series implementation of RNET. The two documents that reference it are:
Russound_Controllers_Protocol_v1_00_04.pdf
Reading RNET V1_00_03.pdf
Both of which apply to the CA-series implementation (and what I used to develop my plugin). The C-series implementation appears to be RNET V1_00_07 based on that command document provided here (Russound RS232 hex codes v1_00_7.pdf).
If you can get a Russound_Controllers_Protocol_v1_00_07.pdf document, that is what I need.
Reaching out to Russound now.
Thanks Kabdalla! ;D
I wish I had good news but it looks like the only thing added/updated is the RIO command string list.
If you can get a Russound_Controllers_Protocol_v1_00_07.pdf document, that is what I need.
So that RNET Serial Hex 1_00_07.pdf is NOT helpful then?
It provides the “set” codes, which is what I used for my modified I_RNET file for you, but doesn’t offer any “get” codes. It also doesn’t provide the structure for controller responses to “get” codes. Look at the “Russound_Controllers_Protocol_v1_00_04.pdf” document for examples.
I’ve put in my own request to Russound so we’ll see what they respond with.
Just got off the phone with a Russound integration engineer who was extremely helpful. I think I can write a single I_RNET document that will work with all controllers. Once I confirm it’s working on my, I’ll upload it here for testing on an MCA controller.
Awesome! I’ve been impressed with Russound’s support. the ONE thing that still bothers me is the lack of “MUTE ON, and MUTE OFF” for RIO protocol. Someone I spoke with said they added it to their list to implement, but I didn’t see it in this last update…
What I found out is the legacy “70” version (my plugin) only works on CA-series but this new “71” version works on all controllers. The issues you were seeing are that it’s a much more “chatty” version. I sent one volume status request and got 5 responses of what the level is. That’s why your CPU was spiking and why buttons were sometimes working and sometimes not, the serial interface was busy.
Working on getting the status part working, though don’t know how long it will take. Hopefully have something up today.
Take your time… your efforts are appreciated. Interesting to know there is a less chatty version. Hopefully you don’t have to re-work the entire plugin.
Ok, I’ve got a file for you to test @big517. I have to say, understanding this new version of RNET is making this much easier. I’ve got status coming back based on any change in state, volume, or source, whether its from Vera, keypad, or remote, without having to explicitly request.
The one gotcha I have is that I don’t have the exact structure for these responses. I built the updates based on my logs and analysis so I hope they hold true on the C-series.
Please test out all the buttons, I’m particularly interested in the “All On” command. Good luck!
That is interesting… so it “listens” instead of queries?
This rapid development is stupendous. This is shaping up to be a grade A plugin.
Yeah eBay. New though and from a Russound dealer so I can RMA it through Russound. Looks like it will be a while until I can play with you guys.
@big517: That is what’s confusing me. I understand the new “set” commands can also prompt the controller to respond with a status but that doesn’t explain how the controller also sends this status when controlled by keypad or remote. I could have swore during my initial plugin development that when I changed volume or state from the keypad, the log showed nothing. It could just be that I overlooked something. It’s not that there is “listening” going on, it’s the controller is sending status whenever something is changed, regardless of what is changing it.
I remember in RIO you had to initialize the zone to broadcast that info.
Not sure about RNET, but the “Reading RNET” documents leads me to beleive this as well.
Maybe you should call to that Russound person again?
[code]
Tech Tip
Reading Real-Time RNET Display and Status Messages:
This document is a supplement to the Russound_Controllers_Protocol_V1_00_03.doc. While the
RNET protocol document describes methods of controlling and polling the CAV 6.6, this
document concentrates on processing real-time RNET display and status messages. You will
need to read the standard protocol document to understand some of the concepts used.
- How To Determine That A Message Should be Read
- Handling Locally Rendered Display Messages
- Handling Pre-formatted Display Messages
- Handling Special Status / Display Element Messages
- Handling Event Messages
- String ID Tables
There are four types of display/status messages used by RNET controllers and peripherals. These messages are
used to update text displays, display icons, and to other system states such as zone power state, etc. - Locally rendered display messages (Rendered by the display device).
- Pre-formatted display messages (Rendered by the CAV 6.6 or other peripheral RNET device).
- Status messages to update special values such as source sharing, party mode, etc.
- Event messages to change states of certain parameters such as zone power state[/code]