PDA

View Full Version : New Russound RNET code question



kwaugh
March 7th, 2010, 08:04 AM
(doing a fresh install...)

In the old version of the Russound_RNET.lua code I had there were two variables:

local NumControllers = 6
local NumZonesPerController = 6

That I could change to 4 and 4 to keep the code from polling/timing out on my CAS44 (4 zones).

In the new version of Russound_RNET.lua, I can't find a comparable variable.

Is it buried somewhere my limited lua skills can't find?

Thanks!

K

Rob H
March 7th, 2010, 09:01 AM
See this thread - http://www.promixis.com/forums/showthread.php?t=18070&highlight=russound+rnet

kwaugh
March 7th, 2010, 09:12 AM
Rob - that thread refers to the old code I mentioned in my post.

In this thread

http://www.promixis.com/forums/showthread.php?t=19754&highlight=russound&page=3

Ron sent me the new version of the RNET code. That's the code that doesn't have the variables mentioned. I'm keen to get the new code working with the CAS since I think Rob fixed the volume issue mentioned in a previous post in that version...

Thanks!

K

PS - tried installing the old code with no luck. it blows up on launch...

Rob H
March 7th, 2010, 02:04 PM
Ah, let's see what Ron says.

If I had a Russound here I'd be tempted to make some changes, but there's a lot of code to look through.

kwaugh
March 7th, 2010, 03:55 PM
You're telling me! Just reading it makes my head spin!

kwaugh
March 8th, 2010, 04:08 PM
just noticed that the new code doesn't add the Russound to the device manager either...

Thanks!

K

Rob H
March 9th, 2010, 03:24 PM
That's odd, I'll try to take a look tomorrow unless Ron comments first.

kwaugh
March 11th, 2010, 05:02 AM
Thought I'd do a bump on this as I've 'cleared my calendar' for the weekend to work on the rebuilt system and I'm stuck without Rob/Ron weighing in on this...

PS - have pity on me as my wife doesn't let me control my own weekend schedule very often!

Thanks!

Ron
March 11th, 2010, 07:28 AM
If you put it that way,.. let me see what I can do here :)

Ron
March 11th, 2010, 07:48 AM
Alright I merged version 1.2.2 with 1.2.3 to create 1.2.4 somehow your changes did not make it into our revision control system. Let me know how this goes.

kwaugh
March 11th, 2010, 05:02 PM
1st - thanks for helping me out!

2nd - here are the steps I took

1. Clean install
2. moved the 1.2.4 version into the plugins/serial directory, made the edits to change 6x6 to 4x4 and renamed it to Russound_RNET.lua
3. enabled simple serial plugin
4. on the settings/serial tab, selected Russound for the port (com1) that it's attached to. NOTE: the description still says v1.2.3
5. go to component manager/audio video/russound and select com1 shows initializing and polling zones

if I create the following callback:

RNET:Subscribe(function(...) print('EVENT:', unpack(arg)) end)

it shows continual polling of zone 5

also, the russound isn't listed in the DM.

If I click one of the actions under audio/video in the actions tree, the following error is generated:

TreeScript (golua): ... Files\Promixis\Girder5\/plugins/treescript/init.lua:50: bad argument #1 to `totable' (string expected, got nil)
stack traceback:
[C]: in function `totable'
... Files\Promixis\Girder5\/plugins/treescript/init.lua:50: in function `SetStringIndex'
...is\Girder5\/plugins/treescript/Device Manager UI.lua:3490: in function <...is\Girder5\/plugins/treescript/Device Manager UI.lua:3466>
TreeScript (golua): ... Files\Promixis\Girder5\/plugins/treescript/init.lua:50: bad argument #1 to `totable' (string expected, got nil)
stack traceback:
[C]: in function `totable'
... Files\Promixis\Girder5\/plugins/treescript/init.lua:50: in function `SetStringIndex'
...is\Girder5\/plugins/treescript/Device Manager UI.lua:3490: in function <...is\Girder5\/plugins/treescript/Device Manager UI.lua:3466>

Hope this provides some insight!

Thanks,
K

Ron
March 12th, 2010, 11:40 AM
For me the dialog does say 1.2.4, so something else is wrong for you there. Did you remove the old russound >>plugin<< ?

kwaugh
March 12th, 2010, 11:42 AM
it's a clean install, so I'm not sure there'd be anything to remove?

The steps above are literally every step taken...

Thanks!

K

Ron
March 12th, 2010, 11:51 AM
the russound plugin, a dll in the plugin directory.

kwaugh
March 12th, 2010, 11:54 AM
I'll doublecheck as soon as I can bail out of the office, but I'm pretty sure that unless it is something that is installed with the base install, it wouldn't be there.

Just to make sure I'm clear - there should be no .dll, just the new version of the .lua code in the plugins/serial directory, yes?

Thanks!

K

Ron
March 12th, 2010, 11:58 AM
That DLL is there in the base install. So yes remove the DLL we will only use the .Lua version. The DLL potentially overwrites stuff.

kwaugh
March 12th, 2010, 02:55 PM
...but there was a file in the treescript dir Russound UI.lua

I deleted it and the amp is back in the DM. I'll start checking things out ASAP and see if everything is working.

Thanks!

K

kwaugh
March 13th, 2010, 07:03 AM
the UI was a red herring, didn't need to delete it, just needed a restart.

Also, the problem with volume changes not updating the DM is still there.

If you update the volume via a ccf (on a different machine in my case), the DM doesn't trigger the change; however, it does trigger for bass, treble etc.

An easy way to see if this is happening is to open up the DM on girder and them make a bass change, you'll see the status change in the window that displays current settings.

If you make a volume change, the settings don't change.

Thanks!

K

kwaugh
April 3rd, 2010, 07:26 AM
I'm still stumped by the behavior of volume. Changes to the volume don't seem to be 'picked up' by the DM.

Here's the behavior I'm seeing that makes me pretty sure this is in the DM

1. I have a CCF that uses the DM Volume/Bass/Treble of the Russound amp
2. If I open DM on girder and change the bass, the bass level changes and that change is immediately shown on the ccf
3. If I try the same thing with volume, the volume changes, but the change doesn't show up in the CCF.

That makes me think that the issue is that the russound code isn't 'notifying' DM that it has changed the volume.

Help!

Thanks!

K

Rob H
April 4th, 2010, 02:56 AM
I can't see anything in either the provider or the plugin that would cause volume to be treated differently from bass.

I've forgotten if I'd asked you to try the FlatStyle CCF to see if that works correctly with this.

kwaugh
April 4th, 2010, 05:39 AM
Sorry, should have added that the first time - yes it's the same behavior with the Flatstyle.

Here's another 'test' I've done to confirm the behavior in case it helps, this one takes NR out of the equation...

If I change the volume of a zone via DM in girder, the volume changes, but the value that is stored in girder doesn't.

So, in my case RNET.Zones[3].Volume is the variable that the plugin uses for volume. if I change the volume via the DM in girder, the volume will change, but RNET.Zones[3].Volume stays the same.

I'm out of my league as to the cause, but perhaps the Russound code isn't updating itself internally, which would explain why the DM doesn't 'see' the change?

Hope this helps!

K

kwaugh
April 7th, 2010, 04:41 AM
Sorry to be a pest on this one, but it's becoming a bigger problem.

Since the value stored in RNET:Volume isn't reliable, it's making a mess of my home announcement logic.

Another 'test' to throw into the mix - I have a simple callback that is called for every Russound change - the callback is not fired off for Volume changes...

Thanks!

K

Rob H
April 9th, 2010, 02:17 AM
Not sure how much help I can be without the Russound hardware (Ron has it in his office) - if I get a chance I'll see what I can do by way of adding some tracing to the Russound scripts.

kwaugh
April 10th, 2010, 09:43 AM
Rob -

I was feeling adventurous, so I started looking at the RNET provider code. I changed the following code:

local VolumeCommand = function(value)
RNET:SetVolume(controllerid, zoneid, value)
--added by KW
RNET:RequestVolume(controllerid,zoneid)
--end
end

The RNET:RequestVolume request forces an update of the volume, which seems to be reflected in the DM.

I'll keep testing, but so far, this looks like it fixes the problem. Now I just need to remember that I put it there!

Thanks,

K

K

Rob H
April 10th, 2010, 01:19 PM
Cool, very interesting finding.

Once you're happy with it, perhaps you can send the modified code to Ron for inclusion in the next build of Girder.

kwaugh
April 10th, 2010, 01:25 PM
...and then I'll brag to my friends that I wrote code that is included in Girder!

Ron
April 12th, 2010, 08:15 AM
Is this working for you?

kwaugh
April 12th, 2010, 10:47 AM
Still working well.

My suspicion is that the fact that the RNET:RequestVolume function exists points to the amp not reporting volume changes by design (go figure).

The 1 line above forces the reporting of volume each time it changes.

Thanks!

K

watch
March 31st, 2012, 04:27 PM
I know this is an old thread but I appear to have a Russound problem that is related.

I have Girder 5.0.14 (build 551). This loaded v1.2.4 of the Russound lua.

I have an inconsistency in the way Zones are treated using the Webserver - a request via the webserver for Zone 1 appears to work but none of the other zones do.

Is there an update to v1.2.4 of the lua that I should be using?

kwaugh
April 3rd, 2012, 08:32 AM
watch -

I'm no expert, but if you post your web server code, I'll try to take a look and see if anything jumps out at me that might help...

kwaugh
April 3rd, 2012, 08:33 AM
watch -

I'm no expert, but if you post your web server code, I'll try to take a look and see if anything jumps out at me that might help...

watch
April 3rd, 2012, 04:10 PM
Thanks K.

I'm convinced it's not the Webserver - I just used it as a easy way to trigger the changes. If I disable the webserver and attempt to trigger the Power Event on a Russound Zone via the Generic treescript Action for different Russound Zones - the only ones that are recognised by Russound RNET are for Zone 1.

Note that I have't writen any code (yet) - just configureed the items in Device Manager and Settings (that's why I was asking if v 1.2.4 of the Russound lua is the latest)

Here's a view of the Device Manager Log from startup - in the last few lines you can see that Zone 1 is the only one that results in an Event;


04/04/12 09:53:54 INFO Config file loaded
04/04/12 09:53:54 INFO Initialized
04/04/12 09:53:56 INFO Provider: Transport Initialized
04/04/12 09:54:02 INFO Provider: X10 Initialized
04/04/12 09:54:05 INFO Provider: USBUIRT Initialized
04/04/12 09:54:05 INFO Provider: USBUIRT Added Device USBUIRTRX Girder USBUIRT Receiver
04/04/12 09:54:05 INFO Provider: USBUIRT Added Device USBUIRTTX1 Girder USBUIRT Send Zone 1
04/04/12 09:54:05 INFO Provider: USBUIRT Added Device USBUIRTTX2 Girder USBUIRT Send Zone 2
04/04/12 09:54:05 INFO Provider: USBUIRT Added Device USBUIRTTX3 Girder USBUIRT Send Zone 3
04/04/12 09:54:05 INFO Provider: USBUIRT Added Device USBUIRTTXAll Girder USBUIRT Send Zone All
04/04/12 09:54:05 INFO Provider: IR Profiles Initialized
04/04/12 09:54:05 INFO Provider: IR Profiles Added Device 2 Data Rack Onkyo Receiver
04/04/12 09:54:05 INFO Provider: IR Profiles Added Device 3 Data Rack Panasonic PVR
04/04/12 09:54:05 INFO Provider: IR Profiles Added Device 4 Data Rack LG PVR
04/04/12 09:54:05 INFO Provider: IR Profiles Added Device 5 Data Rack Russound MCA-C5 via IR
04/04/12 09:54:05 INFO Provider: IR Profiles Added Device 7 Family Room Panasonic TV
04/04/12 09:54:05 INFO Provider: IR Profiles Added Device 9 Data Rack WD TV Live
04/04/12 09:54:09 INFO DM Event: LocationList
04/04/12 09:54:09 INFO Location List Update
04/04/12 09:54:09 INFO DM Event: TypeList
04/04/12 09:54:09 INFO Device Type List Update
04/04/12 09:54:09 INFO DM Event: Add automationpc\IR Profiles\7 automationpc\USBUIRT\USBUIRTTX2 automationpc\USBUIRT\USBUIRTRX automationpc\USBUIRT\USBUIRTTX1 automationpc\USBUIRT\USBUIRTTX3 automationpc\IR Profiles\3 automationpc\IR Profiles\9 automationpc\IR Profiles\4 automationpc\IR Profiles\5 automationpc\USBUIRT\USBUIRTTXAll automationpc\IR Profiles\2
04/04/12 09:54:13 INFO Provider: RussoundRNET Initialized
04/04/12 09:54:13 INFO Provider: RussoundRNET Added Device Master Data Rack Russound Z1-6
04/04/12 09:54:13 INFO Provider: RussoundRNET Added Device C1Z4 Data Rack Russound Garage
04/04/12 09:54:13 INFO Provider: RussoundRNET Added Device C1Z5 Data Rack Russound Main Bedroom
04/04/12 09:54:13 INFO Provider: RussoundRNET Added Device C1Z6 Data Rack Russound Ensuite
04/04/12 09:54:13 INFO Provider: RussoundRNET Added Device C1Z2 Data Rack Russound Pool Room
04/04/12 09:54:13 INFO Provider: RussoundRNET Added Device C1Z1 Data Rack Russound BBQ Area
04/04/12 09:54:13 INFO Provider: RussoundRNET Added Device C1Z3 Data Rack Russound Office
04/04/12 09:54:14 INFO DM Event: TypeList
04/04/12 09:54:14 INFO Device Type List Update
04/04/12 09:54:14 INFO DM Event: Add automationpc\RussoundRNET\C1Z3 automationpc\RussoundRNET\C1Z4 automationpc\RussoundRNET\Master automationpc\RussoundRNET\C1Z2 automationpc\RussoundRNET\C1Z5 automationpc\RussoundRNET\C1Z6 automationpc\RussoundRNET\C1Z1
04/04/12 09:56:26 INFO Provider: RussoundRNET Action from device to provider: Action Path automationpc\RussoundRNET\C1Z1\Power 1
04/04/12 09:56:26 INFO [B]Device Event: Condition automationpc\RussoundRNET\C1Z1 Power On
04/04/12 09:56:35 INFO Provider: RussoundRNET Action from device to provider: Action Path automationpc\RussoundRNET\C1Z6\Power 1
04/04/12 09:56:47 INFO Provider: RussoundRNET Action from device to provider: Action Path automationpc\RussoundRNET\C1Z2\Power 1