Hmmm, I’m wondering if this isn’t related to the plugin. The only thing different between the two files is how the Vera parses incoming messages (none of which are queried). All outgoing commands to the Russound are exactly the same.
In verbose logging mode and same log directory as before, can you run the following command then try to get it to crash again:
tail -f LuaUPnP.log | grep ‘^01|^02’
This will show errors and warnings on the Vera and may catch a serial communications issue.
You’re right, it crashed on the old one when I try this from a specific zone that is in a “GROUP” setting. It’s like a loop is created. I can re-create it now. Stand by.
That command didn’t save anything to the log… I think you might want to call me if possible.
Check your PM
NEW LOG
[url=https://app.box.com/s/onaiyur2jfqcohfudwos]https://app.box.com/s/onaiyur2jfqcohfudwos[/url]
The error is re-created when I quickly click between 2 sources on a grouped zone. (2 zone changes in < 1 sec)
Relevant portion of the log file is on its way to Russound. Glad we narrowed down the issue for them. I’ll let you know what they come back with and if they don’t have anything, I’ll work in a delay after a source command is sent.
Heard back from Russound and they think it’s an issue on the MCA with the buffer getting full and crashing. He recommended what I thought he would (implementing a delay) as a temporary fix until their engineers have an opportunity to dig into it and fix it. I’ve attached an I_RNET file that has a 1.5 second delay after each source button push. I’ve tested rapid selections on my box with no issues, @big517 can you test on the MCA?
I will do my best to crash it again 
I haven’t had a chance to run with it yet, but I do recall only being able to show 6 zones. The MCA-C5 has 8 zones.
Can you add support for the 2 missing zones?
Thank you,
Done. Here is the updated I_RNET file.
Ok, still falls into that “loop” and crashes (ONLY ON LINKED ZONES)… Try doubling the delay.
One slight irritation… in the madness of clicking back and forth between zones on a single unlinked zone, the commands were executing in the order I clicked, but not in real time. so I click a string of buttons within a few seconds, but it takes 10 seconds before the last click is played out. Is it queuing the command on the Vera Side, or do you think that is the Russound controller?
I think it’s the Vera that queues up the commands and I doubt I can do anything about that. Doubling the delay won’t do anything as the queued up commands seem to execute faster than the delay states. It’s just going to have to be a known bug until Russound fixes it.
In my effort to publish v1.2 with the latest I_RNET file, I accidentally unpublished 1.1. Not sure how long 1.2 will take for approval (possibly until Monday) but my apologies for 1.1 disappearing until then.
Sounds like there is a bug on the Vera side as well.
Can you attach some sort of wait variable to the source command that Vera has to wait for, or require confirmation of status change the command?
Seems logical that it would avoid the issue if it was required to confirm status change before sending the next command.
I thought about that but I don’t know how to implement. There is no way to know which zones are part of the group so I wouldn’t know which zones to wait for. Like I said, I think it’s just something we’re going to have to wait for Russound to address. I also don’t see people rapidly selecting different sources (in grouped zones) being that common of an issue.
I agree, it’s not a major issue.
Version 1.2 has been approved and is available from the app store. Change log at the top of this thread.
@ kabdalla
Thank you for you persistent development of this plugin! My replacement unit arrived yesterday and so far I have three zones running. Hopefully I’ll get a chance to plug it into Vera tonight and start really using this weekend.
All On doesn’t work for me. All Off does though.
Need logs?
Yes, logs would definitely be helpful. Does everything else behave correctly?
I haven’t explored to extensively yet so I can’t say for sure. I’ll get a log to you tonight.
By the way, would it be possible for you to implement the ability to set specific volume levels during scene creation? Also is it possible to poll for the volume level? So, for example, one could have a PLEG scene not the level, change sources and volume and then go back?
If you don’t mind testing everything before sending the log, that will allow me to patch everything at once.
There shouldn’t be a need to poll the volume, it should update regardless of what is changing the volume…same with source and state.
Regarding a place to set the volume, that is actually why I wanted to implement the slider but I’m not a fan of the MCV slider only allowing 10% increments for changes. I can try to have the “Volume” variable watched and if it is set to a new value, issue the command to change the volume in that zone to that level. Not sure how exactly that is done so it will likely take some time.
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules