Russound Plugin polling non-existent zones - killing response time

[kwaugh]

(I'm moving this to it's own thread, since I originally added it to the bottom of another discussion on the plugin which probably wasn't the right place)

I'm using the Russound plugin with my CAS44 amplifier. All of the functions that the CAS supports are working just fine; HOWEVER, since the CAS is a 4 zone amp, the plugin is constantly polling for status on the non existent zones. This is creating some pretty sizable delays and timeouts on commands. Here's a snippet of the traffic:

Serial: Russound RNET : Simple Receive: Data Code: 0
Serial: Russound RNET : Requesting Zone Info for 1 5
Serial: Russound RNET : Command queued: F0 00 00 7F 00 00 70 01 04 02 00 04 07 00 00 00 ð.....p......... at postion 1
Serial: Russound RNET : Simple Send: F0 00 00 7F 00 00 70 01 04 02 00 04 07 00 00 00 F7 ð.....p.........÷
Serial: Russound RNET : RUSS EVENT Plugin nil nil Master 0 Waiting Getting info zone 5 on controller 1
Serial: Russound RNET : RUSS EVENT Plugin nil nil Master 0 No Response from Russound controller #1
Serial: Russound RNET : Simple Receive: Data Code: 0
Serial: Russound RNET : Requesting Zone Info for 1 5
Serial: Russound RNET : Command queued: F0 00 00 7F 00 00 70 01 04 02 00 04 07 00 00 00 ð.....p......... at postion 1
Serial: Russound RNET : Simple Send: F0 00 00 7F 00 00 70 01 04 02 00 04 07 00 00 00 F7 ð.....p.........÷
Serial: Russound RNET : RUSS EVENT Plugin nil nil Master 0 Waiting Getting info zone 5 on controller 1
Serial: Russound RNET : RUSS EVENT Plugin nil nil Master 0 No Response from Russound controller #1
Serial: Russound RNET : Simple Receive: Data Code: 0
Serial: Russound RNET : Requesting Zone Info for 1 5
Serial: Russound RNET : Command queued: F0 00 00 7F 00 00 70 01 04 02 00 04 07 00 00 00 ð.....p......... at postion 1
Serial: Russound RNET : Simple Send: F0 00 00 7F 00 00 70 01 04 02 00 04 07 00 00 00 F7 ð.....p.........÷
Serial: Russound RNET : RUSS EVENT Plugin nil nil Master 0 Waiting Getting info zone 5 on controller 1
Serial: Russound RNET : RUSS EVENT Plugin nil nil Master 0 No Response from Russound controller #1

Is there anyway to control how many zones the plugin is polling?

Thanks,

K

[Rob H]

Only by editing the plugin code at the moment I think

[kwaugh]

I figured that would be the case. I'm getting delays of up to 10 seconds between issuing commands and seeing response when it doesn't time out completely. Makes it tough to see if my code is working!

My first thought on a good plugin based solution would be a check box by each zone on the component panel (where you name them), so you could select which ones were monitored.

In the meantime, does anyone have a Russound GML that doesn't rely on the plug in?

I'm very eager to get working on this...

Thanks!

K

[Rob H]

Can you try putting this file in the plugins\serial folder and then edit it to change NumZonesPerController to 4. Let me know if this works okay and I'll see what I can do to make this more easily configurable.

[kwaugh]

First, thanks for working with me on this!

I'm still testing, but the missing zone traffic is gone and response time is pretty snappy.

I'll report back if anything turns up, but I think this is definitely the fix...

Thanks again,

Kevin

[Rob H]

That's good to know - I'm also not sure about the number of controllers - the CAV6.6 appears to support 6 (or at least the plugin does), how about the 4.4? You may also want to adjust NumControllers if it supports fewer than 6.

[kwaugh]

The CAS44 supports two units, so I made the change and I think that sped things up a tiny bit more. No problems at all, so I think you've got a winner!

Related topic, I've been writing my own girder scripts to make the changes from NR since I'm way to dense to figure out how the flatstyle ccf uses the DM to link sliders/buttons to girder (all that looping and relative naming throws me off).

Could you give me the idiots version of how to call something in the action tree from NR? I've been searching the boards but can't seem to find the simple explanation...

Thanks!

K

[Rob H]

I'd recommend against doing things that way - use the functions from the DM support code instead.

ie make sure that you add
require 'DMSupport' to your CCF's .lua file and also add a call to DM.Init() e.g.

function OnCCFLoad()
DM.Init()
end
Once you've done this you can simply name your sliders and buttons with the full DM paths e.g. for my Denon it might be \\cordelia\Denon\Main\Power, then to toggle that you would give that button a Lua Event action of DM.AutoToggle. Sliders should function automatically for your Russound as DMSupport will register the relevant variable watches.

For more complex stuff you can indeed use DeviceManager actions in a GML, but I'd recommend the above method most of the time.

I would definitely recommend that you use a bit of relative naming though e.g. in the example above I would have a frame with the name '\\cordelia' and on it I would refer to the controls as e.g. <^>\Denon\Main\Power. That way if you move Girder to another PC or change the name of the PC then you only have to make the one change in your CCF rather than changing lots of buttons and frames. In fact I would go further and add another frame with the name <^>\Denon\Main and then place the buttons on that so that you can just copy the entire frame to create the controls for a second controller/zone.

[kwaugh]

So, once I require and do the initialization on DM, then when I manipulate the variable (say mypc\RussoundRNET\C1Z1\Volume), that will trigger Girder to make the appropriate plug in calls to change the volume?

I've been looking for something that triggers the actions...

I'll also have to give the relative naming a try, sounds too cool to pass up!

Thanks

K

[Rob H]

Yes, that's correct in the case of slider variables like the volume since there's already a NetRemote.RegisterVariableWatch set up for those, but does not apply to switches etc.

[Ron]

I have ordered a new Russound system for the office. Once that comes in we should be able to help you more effectively.

[kwaugh]

Cool! It's an awesome amp, but I'm not that impressed with the way the serial protocol is implemented.

I'll post some more info tonight when I'm home if I still can't get it to work, but I'm still not able to get a ccf to trigger the plug in in girder. It's probably just me, but I'm guessing I'll need some help!

Thanks,

K

[Rob H]

Post the CCF and I'll take a look. Preferably a cut-down one-page CCF that doesn't try to do too much.

[kwaugh]

Rob -

Attached is the test ccf I built to try out DM. It's pretty simple. The slider for Volume and Bass for C1Z1 works and I see the event in girder (example below)

LOG: Device Manager : 3 - Provider: RussoundRNET Action from device to provider: Action Path alienware\RussoundRNET\C1Z1\Volume 0

the rest of the sliders adjust the values on the ccf, so they are "linked", but there's nothing on the girder side...

Like most problems I have, the safe bet is that I'm the issue, but this one is definitely stumping me!

Thanks,

K

[Rob H]

Okay, if you adjust the volume in a DM action in your GML does the slider update in the CCF? If not then it's likely to be a naming issue.

Are any errors shown in NRD's Lua console? How about in Girder's Lua console?

One thing you can try is an empty CCF with the same .lua as you used for this CCF. Shut down NR and reset Girder then start NR with the new CCF and check the NetRemote variables for the name alienware\RussoundRNET\C1Z1\Volume

[kwaugh]

Ok, now it's even more confusing...

Changing the Volume from girder instead of the CCF, the Values update AND the sliders adjust to the proper position, so it looks like Girder -> NR is working just fine...

I also checked the LUA consoles in both - no errors.

The LUA for the ccf is just this:

require 'DMSupport'
function OnCCFLoad()
DM.Init()
end

That's it...

PS - speaking of LUA, I sent the folks at LUA.org an email saying that they should add Promixis Girder and NR to their list of big name sw that leverages LUA. Got an email back saying they would look into it...

[Rob H]

Can you try this replacement for DMCore.lua (it goes in the NetRemote\luascript folder)?

Thanks for sending that email - for some reason they dropped us from that list when they edited it a few months back

[kwaugh]

Rob -

Just swapped in the new file, restarted everything and am now getting a bunch of errors in the console. Since I can't seem to cut and paste from the console, I'll retype the lines that appear to be the ones that are different from the old version of DMCore below. I also swapped versions back and forth a few times to ensure that it was the new file that was causing the error. After loading, none of the values are transmitted in either direction. There may be some typos in this since I'm typing it vs. c/p, but hopefully it'll be close enough for you to see what's going on:

DM: C1Z1
DM: C1Z2
DM: C1Z3
DM: C1Z4
...rogram Files\Promixis\NetRemote/luascript/DMCore.lua:14 bad argument #1 to 'concat...
stack traceback:
...ram Files\Promixis\NetRemote/luascript/Protected.lua:49: in function <...ram FIles\Promi...
Locals
Level: 0
arg: table: 00D30FB8
[C]: in function 'concat'
Locals
zLIST: TABLE: 01e81060
Upvalues
ReceiverSetZone: function: 00CAF538
ZoneTypes: table: 00C67990
...rogram FIles\Promixis\NetRemote/luascript/DMCore.lua:14 in function 'Log'
Locals
firstPath: alienware\RussoundRNET\C1Z4
(for state): table: 00CABCA0
transaction: 2
(for generator): function: 00C61478
devices: table 00C66610
i:2
updater: function: 00D2BF90
host: alienware
ip: 192.168.1.2
Upvalues
AddDevice: function: 00CE8CC0
...m Files\Promisis\NetRemote/luascript/DM\Receiver.lua:300: in function 'updater'
...rogram Files\Promisis\NetRemote/luascript/DMCore.lua:87: in function>...rogram Files\...
... debug trace removed for clarity
Loading group HOME and page Home


Thanks,

K

[Rob H]

Oops, I left the logging set at the wrong level.

Change line 10 of DMCore.lua to


DM.LogLevel = 3

Sorry about that - I did notice something similar and fixed one of the occurences, but clearly missed another.

[kwaugh]

...and now it's back to the original behavior

girder -> NR works just fine

only C1Z1 works from NR

no errors in either log.

K

[Rob H]

Remind me, does the FlatStyle CCF work okay?

[kwaugh]

works like a champ. the problem seems to be swithcing from the relative reference to direct reference.

[Rob H]

Okay, let's try a different tack.

In your OnCCFLoad() after the call to DM.Init() try


DM.RegisterVariableWatch([[alienware\RussoundRNET\C1Z1\Volume]], DM.GetGirderInstance())

[kwaugh]

I'll check it out as soon as I can get out of here and get home!

Thanks!

K

[kwaugh]

Still the same result Girder -> NR ok, only C1Z1 works NR -> Girder.

One interesting item. I put the following code in the ccf lua:

function OnCCFLoad()
print("PRIOR TO DM CALLS")
DM.Init()
DM.RegisterVariableWatch([[alienware\RussoundRNET\C1Z1\Volume]], DM.GetGirderInstance())
DM.RegisterVariableWatch([[alienware\RussoundRNET\C1Z2\Volume]], DM.GetGirderInstance())
print("AFTER DM CALLS")

The first print shows up in the NR lua console, the second one does not. Bear with my typing again, but here's the NR lua console:

Loading GAC.lua
Loaded GAC.lua
Loading GirderReady.lua
Loaded GirderReady.lua
Loading PanelWatch.lua
Loaded PanelWatch.lua
Loading DMSupport version 0.1.0.6
Loading group HOME and page Home
PRIOR TO DM CALLS
>>>>>8
Monitoring device * and panel *
Immediate configure
DM: Registering with the DM
DM: Asking for devices
Looking for girder plugin
Got girder plugin
Got girder instances of typetable
Got instances
Trying instance -2101
Trying to query instance -2101
Trying instance -1
Trying instance -2401
Loading group HOME and page Home
Trying to update devices
DM: Devices updated
DM: Got a DM host alienware
DM: Trying lookup via IP address 192.168.1.2
DM: Adding device alienware\RussoundRNET\C1Z4
DM: Adding device alienware\RussoundRNET\C1Z3
DM: Adding device alienware\RussoundRNET\Master
DM: Adding device alienware\RussoundRNET\C1Z2
DM: Adding device alienware\RussoundRNET\C1Z1
DM: Got 0 security devices
OnPaint called
No device for 1
DM: No weather locations
Loading group HOME and page Home
Loading group HOME and page Home
Loading group HOME and page Home

[Rob H]

Wow! You typed all that in?

To save your fingers, download DebugView from www.sysinternals.com and use that. That will let you copy and paste the logged messages.

On to the actual problem. I suspect the reason that the second line didn't print was that the first one caused an error (which should show up in DebugView - some things don't show in the console).

Try this in your OnCCFLoad() instead


DM.RegisterUpdater(function()
DM.RegisterVariableWatch([[alienware\RussoundRNET\C1Z1\Volume]], DM.GetGirderInstance())
DM.RegisterVariableWatch([[alienware\RussoundRNET\C1Z2\Volume]], DM.GetGirderInstance())
end)

That function will only be called once you've had a response from the DeviceManager.

The other thing that you could try as a test is to ensure that autodiscovery is disabled in NR and delete the extra Girder plugin instance. It's possible that that is interfering with things.

[kwaugh]

Had to take typing back in high school - it's definitely paid off over the years!

With the new code, Girder -> NR still works, but no zones are working in NR. Looks like there's more 'stuff' in the log from debugview. File attached...

Thanks!

K

[Rob H]

Okay, let's try this. Here's my current DM support code - unzip it to the NetRemote\luascript folder and restart NR.

[kwaugh]

...new log attached.

Just for grins, I'm going to do an complete uninstall of NR and reinstall. I'll let you know if anything changes...

Thanks,

K

[kwaugh]

Reinstall of NR and reapply of the files above got the same results...

Thanks,

K

[Rob H]

Let's just try to correct that error first in case it's causing a problem, so here's a replacement for luascript\DM\Security.lua

[kwaugh]

(Sorry it took me a bit to respond, I've finally got fed up with having to manually copy ccfs, lua, fonts images etc I need for my stuff, so I wrote a bunch of code to retrieve things from an FTP server here in the house, now when I have updates, I just put them on the ftp server and the ccfs have the code to go fetch the new stuff. Beats the heck out of manually keeping track of things!)

Here's the log:

[3760] 11:22:01.305] ScriptEngine] Creating CCF object
[3760] 11:22:01.337] ScriptEngine] Enabling callbacks
[3760] 11:22:01.337] ScriptEngine] Initializing lua
[3760] Loading GAC.lua
[3760]
[3760] Loaded GAC.lua
[3760]
[3760] Loading GirderReady.lua
[3760]
[3760] Loaded GirderReady.lua
[3760]
[3760] Loading PanelWatch.lua
[3760]
[3760] Loaded PanelWatch.lua
[3760]
[3760] Loading DMSupport version 0.1.0.6
[3760]
[3760] Loading group HOME and page Home
[3760]
[3760] 11:22:01.571] ScriptEngine] Total time : 0
[3760] 11:22:01.571] ScriptEngine] Calling OnCCFLoad
[3760] PRIOR TO DM CALLS
[3760]
[3760] AFTER DM CALLS
[3760]

I confirmed that the response is still the same:

DM.Init() girder -> NR OK NR -> girder only C1Z1
Var watch girder -> NR OK NR -> no response

Thanks!

K

[Rob H]

Can you confirm that there's just one Girder plugin instance?

[kwaugh]

There were two as I'm doing the amp work on a dif. machine, so I deleted the one that wasn't connected to the amp - same result.

Is there limit of 1 girder plugin instance for a ccf?

Thanks!

K

[Rob H]

Not as such, but it simplifies troubleshooting if there's just the one.

There's probably something really obvious that we're not seeing here.

Okay, load up the FlatStyle ccf, and see what happens in the logger when you adjust the volume, then try the same with your CCF and we'll compare the two.

[kwaugh]

after loading, both the flatstyle and the test generate no NR log entries when the volume is adjusted. For C1Z1 and all Flatstyle zones, there is an entry like the following in girder each time the volume is changed:

LOG: Device Manager : 3 - Provider: RussoundRNET Action from device to provider: Action Path alienware\RussoundRNET\C1Z2\Volume 14

The example above is from the flatstyle, changing the volume of zone 2. Here's one from changing the volume from the test in C1Z1:

LOG: Device Manager : 3 - Provider: RussoundRNET Action from device to provider: Action Path alienware\RussoundRNET\C1Z1\Volume 0

I assume that this is also normal, but each the I load another ccf, I have to restart the lua engine in girder to get either ccf recognized...

Thanks,

K

[Rob H]

Hmm... that looks okay (although you shouldn't really need to reset Girder when changing the CCF).

I wouldn't expect to see anything in the NR console, but you should see two events in Girder's logger.

However, they both appear to be working correctly so I don't understand why the FlatStyle one works but yours doesn't (or have I been labouring under a misapprehension all this time?).

[kwaugh]

Ok, don't know why I didn't think of this sooner - I took one of the direct control sliders from the test ccf and put it on the Receiver page of the flat ccf. It works. That means that there's something in the LUA of the flatstyle that's needed for this to work.

At this point, I think the balls in my court. I'll start striping down the flatstyle lua until I find out the magic code is...

I'll let you know if/what I find out!

Thanks,

K

[kwaugh]

Ok, so the direct named slider works, BUT only when the zone that it references is the current zone on the flatstyle page.

For example, if the C1Z1 zone is active on the flatstyle receiver page, then a slider that directly references C1Z2 won't work. Change the page to C1Z2 and the slider then works...

K

[Rob H]

That sounds weird. It makes me think that it's using the built-in variable watches rather than the ones that you've added yourself.

What does your CCF's .lua file look like?

[kwaugh]

For the test above, it's just the vanilla flatstyle lua with no changes. I just plopped a slider down on the receiver page with a slider that accesses C1Z2 by name (alienware\RussoundRNET\C1Z2\Volume) vs. the relative naming of the flatstyle...

Thanks,

K

[Rob H]

Okay, in DMCore.lua can you add the following at the start of the function DM.RegisterVariableWatch()


print('Feedback for '..varname)

[kwaugh]

Ok, This log covers opening the flatstyle ccf (the one with the extra direct reference slider), changing to the Receiver page, exercising the sliders for C1Z1, then changing to C1Z2 and exercising both sliders.

You can tell when I was doing the slider on C1Z2 as it goes -100 - 100 so there are some out of range messages...

Thanks,

K

[Rob H]

When Zone 1 is current type (or copy and paste)


DM.RegisterVariableWatch([[alienware\RussoundRNET\C1Z2\Volume]], DM.GetGirderInstance())
into NRD's Lua console. Does the Z2 volume slider work then?

[kwaugh]

That worked...

I guess that means it's some sort of timing issue on when the commands are generated since this approach didn't work when done at ccf load?

[Rob H]

Yes, most likely DM.GetGirderInstance() didn't actually have a Girder instance to return.

It should however work from an updater function ie


DM.RegisterUpdater(function()
DM.RegisterVariableWatch([[alienware\RussoundRNET\C1Z2\Volume]], DM.GetGirderInstance())
end)

[kwaugh]

...since I'm slow, could you give me the reader's digest version on what it's doing?

Thanks,

K

[Rob H]

Okay.

DM.RegisterUpdater() is a function that registers a callback function to be called later when a confirmed connection with a DeviceManager is established, ie when DM.GetGirderInstance() will return a valid result.

I'm passing it an anonymous function that calls DM.RegisterVariableWatch, passing the name of the volume control and a call to DM.GetGirderInstance().

This should work, since it's essentially the same thing that happens in each of the modules in the luascript\DM folder e.g. Receiver.lua

[kwaugh]

I'll check it out as soon as I can get out of the office and get home!

Thanks,

K

[kwaugh]

Adding the above code works like a champ as long as I reset the Lua engine in Girder each time the ccf is loaded. I confirmed that this isn't necessary with the flatstyle, only the ccfs that directly access the DM vars

I'm thinking I can work around this if I can:

1. Detect the connect of the client in girder
2. Get girder to reset the engine.

I'll start digging into that now, if you know of a short cut...

Thanks again for sticking with me on this one!

K

[Rob H]

That shouldn't be required - as long as you're calling DM.Init in OnCCFLoad it should be sending a DM.Query event to Girder which should cause Girder to send a device update and NR should then call the callback. Something is clearly not right and I need to fix it.

[kwaugh]

Not to sound like a broken record but this experience has strenghtened my favorable impression of Promixis...

As for the fix, I'll definitely take the fix when it comes, but I have two working work-arounds at this point, so since using DM this way seems to be pretty isolated, if there are other pressing issues, I can definitely wait for this one to get addressed...

PS - the workarounds are to 1 - reset the girder lua engine when I open the ccf or, 2 I've got variablewatches on the dm varialbes and when they change I just copy them into NR counterparts. The variable watches on DM variables don't seem to require the lua reset...

Thanks again,

K