Russound CAM6; Itach flex with serial cable.

[William Olsen]

As of the recent PG#3 v3.2.2 the Russound NS in my case no longer populates nor does it allow control of any features (excluding zone off and on) for any of my zones. Most items operated correctly prior to the PG# update. I can still control all features of the CAM from my Elk M1. (since the early 2000's)

I am also unable to find in Programs an "and" command that has anything to do with my CAM although I have been able to use the "if".

And I'm having a devil of a time with DHCP reservation and I've had to place my Eisy in the dreaded "DMZ zone" to be able to communicate with any of my NS's

[bpwwer]

Always check the log files.  Most node servers don't try to report errors to the UI and rely on the log files as the main method to report any issues they encounter.

If possible, always download a log package and include it when reporting node server issues.  Unless the issue is obvious the node server author, they will almost always request the log package.

From the description, it sounds like the node server is unable to connect to the CAM (or itach).

I don't understand what you are trying to report about programs.  A program condition can be an "and" or an "or", there isn't an "if" option.

[William Olsen]

Thanks for the prompt reply Bob, I will post a copy of the NS tomorrow morning, I have to be brief as my dinner bell (spouse) just shouted down the stairs that dinner is ready, I've been at my desk since 7 this morning. Shall I PM or Post a copy of the Russound NS? BTW I did mention that "Zone OFF & ON" both work from the admin screen so a comm issue seems unlikely.

[William Olsen]

Log, not NS

[bpwwer]

Post here or PM, doesn't matter to me.

[William Olsen]

I hope this helps B.

Russound_8-29-2023_80055_PM.zip

[bpwwer]

Based on what I'm seeing the log I'll have to do some investigation.  It almost seems like the CAM is slower at providing the initial info than my CAV is and that's causing some issues.

[bpwwer]

Yes, comparing the times between your CAM and my CAV, your CAM is sending packets at a much slower rate.  I suspect this is related to the baud rate setting.  I'm using 19200.

In your case, it was timing out while trying to get the config data which explains why most things didn't work.  I've increased the timeout so it should work now.

The downside to increasing the timeout is that it now takes more time to determine how many controllers are connected. As the only way to detect is a controller is to attempt to get the config data.  If it times out trying to get the config data, then it assumes there isn't a controller at that controller ID.

Version 2.1.1 has the increased timeout and is in the store now.

[William Olsen]

I will re-load it, thanks for the quick response just please see below.

[William Olsen]

Bob, does this mean anything to you?

Quote

2023-08-30 18:03:19,893 Thread-5 udi_interface INFO russound:start: RussoundCtl_1 started

2023-08-30 18:03:19,893 Thread-5 udi_interface ERROR udi_interface:write: Exception in thread

2023-08-30 18:03:19,893 Thread-5 udi_interface ERROR udi_interface:write: Thread-5

2023-08-30 18:03:19,894 Thread-5 udi_interface ERROR udi_interface:write: :

2023-08-30 18:03:19,894 Thread-5 udi_interface ERROR udi_interface:write: Traceback (most recent call last):

2023-08-30 18:03:19,894 Thread-5 udi_interface ERROR udi_interface:write: File "/usr/local/lib/python3.9/threading.py", line 980, in _bootstrap_inner

2023-08-30 18:03:19,895 Thread-5 udi_interface ERROR udi_interface:write: self.run()

2023-08-30 18:03:19,895 Thread-5 udi_interface ERROR udi_interface:write: File "/usr/local/lib/python3.9/threading.py", line 917, in run

2023-08-30 18:03:19,895 Thread-5 udi_interface ERROR udi_interface:write: self._target(*self._args, **self._kwargs)

2023-08-30 18:03:19,895 Thread-5 udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/0021b9025f6f_3/nodes/russound.py", line 93, in start

2023-08-30 18:03:19,896 Thread-5 udi_interface ERROR udi_interface:write: sleep(30)

2023-08-30 18:03:19,896 Thread-5 udi_interface ERROR udi_interface:write: NameError

2023-08-30 18:03:19,896 Thread-5 udi_interface ERROR udi_interface:write: :

2023-08-30 18:03:19,896 Thread-5 udi_interface ERROR udi_interface:write: name 'sleep' is not defined

2023-08-30 18:03:19,969 Thread-6 udi_interface DEBUG russound_main:__russound_loop_tcp: recv: f0 00 00 7b 00 00 7f 00 03 03 00 02 03 03 00 02 3d 01 59 01 1e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 64

2023-08-30 18:03:19,970 Thread-6 udi_interface DEBUG russound:RNETProcessCommand: Got packet 317 of 345

 

[William Olsen]

You should probably see this

Russound_8-30-2023_62520_PM.zip

[bpwwer]

Should be fixed in 2.1.2 that's in the store now.

[William Olsen]

Bob: I hate being a problem child but;

I don't know what this represents. I've attached the log from 2.12, there are a couple of errors that may help and I've lost my 5th source "Tivo". For a reason unknown to me "Inactive" appears as my 1st choice of sources, "Tuner 1" as my 2nd, "Tuner 2" as my 3rd, "SonosName6 as my 4th and Verizonme2 my 5th. My actual sources start physically as "Tuner 1" being the 1st source then "Tuner 2", "Sonos", "Verizon" and finally "Tivo". The text that I've emboldened has no business being there as it doesn't show up on any of my keypads.

Russound_8-31-2023_122058_PM.zip

[bpwwer]

The list of sources (and other names) in the config data is just a fixed size array of characters.  Russound does not provide any documentation on what or how data is stored in the config data block.  I've had to reverse engineer that my self.  When the node server looks at the names, it just reads the characters from that fix size array until it sees a null (value 0) character or it hits the size limit.   So if it's showing "SonosName6", that's what's in that field.  There might be something in that config data that says it should only use the first 5 characters, but I don't know how to get that info from the config if it exist.

Best I can offer is to make sure the fields are cleared out using the Russound config tool.

The TCP error usually happens when a command is sent to the node server but the IoX times out waiting for a response.  This will happen if 1) the node server isn't ready for the command or 2) the node server doesn't recognize the command

The errors in the log seem to be related to timing again.  It seems like the CAM is taking much longer to respond to command than my CAV does and thus, the node server is asking for stuff too quickly before the zones are fully configured. 

Looks like the source indexing is off by one.  

Version 2.1.3 fixes the source indexing and should delay some of the operations until the zone nodes are configured.

[William Olsen]

😁

[William Olsen]

I hope you find these document helpful.russound-rs-232-V01_00_01.pdf

[William Olsen]

Bob, my Russound NS became non-responsive sometime yesterday, this simple program failed

Bsmt TV  OFF - [ID 0002][Parent 0001]

If
        'RussoundCtl_1 / Back Yard' is switched Zone Off
 
Then
        Resource 'Sony Discreet Power Off'
 
Else
   - No Actions - (To add one, press 'Action')
 

I ran the "if manually and the Sony powered up, I then went to Russound>back Yard on admin console and the power state remained "ON" and selecting "Zone OFF" or operating the power button on the keypad had no effect. The source was also wrong and couldn't be changed by either means. I re-started the NS and everything started working again, First time this happened. I'm attaching a copy of the log. Regards BTW

Russound_10-1-2023_41116_PM.zip

[bpwwer]

The log doesn't help.  They are rotated every day so the current log just shows the current day's messages.  Whatever happened 'yesterday' isn't in the log.

I can't really diagnose anything without the seeing the log for that time period.  So if possible, try to download the log for during the same day when the issues happens. 

[William Olsen]

Bob, my Russound NS has locked up again, log stops at 2023-11-10 you might want to look at the last part of the attached logRussound_11-13-2023_33505_PM.zip

[William Olsen]

Here is a copy of the log after restarting the NS Russound_11-13-2023_33505_PM.zip

[bpwwer]

21 hours ago, William Olsen said:

Bob, my Russound NS has locked up again, log stops at 2023-11-10 you might want to look at the last part of the attached logRussound_11-13-2023_33505_PM.zip

Looks like a network issue of some kind.  The node server was disconnected from PG3 but it recovered.  So it probably also lost the connection to the Russound but that didn't recover.

[William Olsen]

Bob, my NS quit sometime this afternoon and I restarted it. Could you explain the couple of lines I extracted from the NS log. What exactly is the NS looking for here?

Quote

2023-11-16 15:39:55,305 MQTT udi_interface.interface INFO interface:_message: Successfully set key = customtypedparams

2023-11-16 15:40:29,580 Thread-7 udi_interface ERROR russound:RNETProcessCommand: Failed to get node for zone zone_127_1

2023-11-16 15:41:29,586 Thread-7 udi_interface ERROR russound:RNETProcessCommand: Failed to get node for zone zone_127_1

2023-11-16 15:42:29,681 Thread-7 udi_interface ERROR russound:RNETProcessCommand: Failed to get node for zone zone_127_1

Have you been able to figure out why my NS is having issues? As usual, thanks in advance for your help.

[bpwwer]

zone 127 is some special zone that the node server doesn't care about.    The error message is triggered when the node server sees a zone number that isn't an actual zone (1-6 or 1-8 depending on the controller).  But the controller uses these virtual or fake zones to send messages for keypads, etc.  

So, yes, the node server simply ignore those messages instead of logging an error, but i'm lazy and didn't bother to add a condition to check for that.

[William Olsen]

Lazy is perfectly fine as we get older! But what do you think causes my Russound NS to lock up? I was hoping you'd discover a cause from the logs I sent. Is there anything I can do from my side to help?

[bpwwer]

It seemed to be some type of network issue.  At the time it locked up, the node server was also disconnected from PG3. It was able to re-establish the connection to PG3, but the network connection to the Russound was never reported as disconnected so as far as the node server was concerned, it was still connected.