Home AMX User Forum AMX General Discussion

Issue with a Master, slave config

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

Comments

  • Jimweir192Jimweir192 Posts: 502
    Is this using a duet module for controlling the AP?

    Is there any code running on the 3100 or is it all on the 4100?
  • Jorde_VJorde_V Posts: 393
    Hello Jim,

    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.
  • TurnipTruckTurnipTruck Posts: 1,485
    Nerieru wrote: »
    It's using a zigbee remote, (r4) and it might be an issue where the release command isn't received.

    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:

    }
  • TurnipTruckTurnipTruck Posts: 1,485
    Nerieru wrote: »
    It's using a zigbee remote, (r4) and it might be an issue where the release command isn't received.

    I always include a DO_RELEASE in the HOLD event of a button PUSH. This will catch the runaway volumes.
    BUTTON_EVENT [dvR4,nVolume]
    {
    PUSH:
      {
      fnRaiseVolume()
      }
    HOLD [20]:
      {
      DO_RELEASE (BUTTON.INPUT.DEVICE,BUTTON.INPUT.CHANNEL)
      }
    RELEASE:
      {
      fnStopRaisingVolume()
      }
    }
    
    This will stop the volume ramp at two seconds (from the HOLD parameter of 20)
  • Jorde_VJorde_V Posts: 393
    I always include a DO_RELEASE in the HOLD event of a button PUSH. This will catch the runaway volumes.
    BUTTON_EVENT [dvR4,nVolume]
    {
    PUSH:
      {
      fnRaiseVolume()
      }
    HOLD [20]:
      {
      DO_RELEASE (BUTTON.INPUT.DEVICE,BUTTON.INPUT.CHANNEL)
      }
    RELEASE:
      {
      fnStopRaisingVolume()
      }
    }
    
    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)
Sign In or Register to comment.