Issue with a Master, slave config
Jorde_V
Posts: 393
We run this config where I have a 4100 as master and a 3100 as a slave, the slave handels an autopatch precis ltd. However sometimes (unable to replicate it myself), it keeps ramping up the volume to 100% in different zones, (always 1 zone at a time) the port on the 3100 is constantly updating the system, even if I unhook the autopatch from it it'll keep sending information to the autopatch. If I reboot the 3100 it'll start again when it's back online.
If I reboot the 4100 however it'll reset and the 3100 will stop, but when the 4100 comes online it'll send out 2 final commands to the 3100.
This leads me to believe there's either something going wrong in the 4100 or between the 4100 and the communication with the slave.
Does anyone have similar experiences, or perhaps knows where to look?
Also note, the system has been running for more than a year. And this only occurs occasionally. (but when it happens it's very annoying of course)
Kudos
If I reboot the 4100 however it'll reset and the 3100 will stop, but when the 4100 comes online it'll send out 2 final commands to the 3100.
This leads me to believe there's either something going wrong in the 4100 or between the 4100 and the communication with the slave.
Does anyone have similar experiences, or perhaps knows where to look?
Also note, the system has been running for more than a year. And this only occurs occasionally. (but when it happens it's very annoying of course)
Kudos
0
Comments
Is there any code running on the 3100 or is it all on the 4100?
No, just normal modules. Nothing is running on the 3100.
But we might have located the issue.
It's using a zigbee remote, (r4) and it might be an issue where the release command isn't received, hence the volume up locking up. That's at least what I heard from my colleague who had a similar issue with another client. Did anyone else experience this?
Does anyone know if they had the issue if zigbee pro fixed the issue?
This is still pretty much speculation though.
I always include a DO_RELEASE in the HOLD event of a button PUSH. This will catch the runaway volumes.
[code]
BUTTON_EVENT [dvR4,nVolume]
{
PUSH:
{
fnRaiseVolume()
}
HOLD [20]:
{
DO_RELEASE (BUTTON.INPUT.DEVICE,BUTTON.INPUT.CHANNEL)
}
RELEASE:
}
I always include a DO_RELEASE in the HOLD event of a button PUSH. This will catch the runaway volumes.
This will stop the volume ramp at two seconds (from the HOLD parameter of 20)
Ah, that's actually far more suitable than what I came up with myself! Thanks for your reply Turnip
(wanted to use a wait and cancel wait to achieve the same)