Home AMX User Forum AMXForums Archive Threads AMX Hardware

R4 hard button issue

Has anyone had any type of issues with the hard buttons with the R4?

Here’s my problem:

I have a channel code assigned to the power button.

There is also a page flip assigned to that button.

When the button is pushed the page flip happens and the push shows up in the push message status bar display, however, nothing shows up in the Notifications window and my code doesn’t run.

How is it possible for the push message status bar to show the push but not show up in the the notifications window?

Other hard buttons show up fine in both spots but not the power button. If the channel up button is pushed the push message status bar shows the push and the push shows up in notifications so I know it’s not my notification settings (which is setup to show everything.)

The only thing I can tell that is different with the hard power button is that there is a page flip assigned to it aside from the channel code. The other hard buttons for that page just spit out channel codes and they seem to work fine.

The Zigbee gateway was rebooted and the first time the power button was pushed after the reboot the push shows up and code runs as it should. But that’s it, after that no notifications and code doesn’t run.

The Zigbee gateway, the R4remotes, and the NI-3100 all have the latest firmware

Has anyone experienced this before? Any ideas on what is going on?

TIA

Comments

  • John NagyJohn Nagy Posts: 1,740
    We use the power button with expected results. We don't have a page flip on it however. I suggest you remove the page flip and reload and see if that's in fact having an influence.... rather than wonder about it. Simplify, divide, substitute...
  • I reported this issue to AMX a long time ago but I don't think they really looked into it.

    Here's my post about it.

    http://www.amxforums.com/showthread.php?3495-Odd-R4-code-problem

    AMX ended up replacing the R4 but the problem still remained. I believe it to be a bug in the firmware.

    The solution for me was to put a DO_RELEASE() in the buttons PUSH: event. The R4 for some reason never sends the release when the button is pressed then released.
    How is it possible for the push message status bar to show the push but not show up in the the notifications window?

    Edited to add: The Push notifications "sees" the button push as does the master but if there was a previous PUSH and no RELEASE it handles the PUSH differently. For example it is probably testing to see if it should fire a HOLD event but doesn't do the PUSH event because that already happened and was never cleared by a RELEASE due to the R4 firmware bug.
  • Joe HebertJoe Hebert Posts: 2,159
    Bigsquatch wrote: »
    I reported this issue to AMX a long time ago but I don't think they really looked into it.

    Here's my post about it.

    http://www.amxforums.com/showthread.php?3495-Odd-R4-code-problem

    AMX ended up replacing the R4 but the problem still remained. I believe it to be a bug in the firmware.
    Thanks for the response and link Bigsquatch.

    I’m seeing the same exact problem that you reported over 3 years ago.

    The hard power button works once after a Zigbee gateway reboot or after the R4 is rebooted. After that the push shows up in the push message status bar display but not in the notifications window which really has me scratching my head.

    If I put the same channel code and page flip on a soft button on the same page then it works every time without issue.

    Smells like a firmware bug to me. Ugh.
  • John NagyJohn Nagy Posts: 1,740
    Bigsquatch wrote: »
    I reported this issue to AMX a long time ago but I don't think they really looked into it.

    Did you have a page flip on the button too? We don't and it works as it should.
    An old commonly warned item about presses/releases on popups may apply here for some reason:
    If you put a page flip on a button such that the page with the button is removed before you release the button, the system is never informed that the button is released. It's not there when you take your finger off, so THAT button is still "pushed" per the system. It can see more pushes, but until released, which it never can do, it can't be processed by other routines... It can work occasionally, pending the hardware and communication timing, as in if you get your finger off before the panel gets around to flipping itself, you win.

    This was apparently fixed some years back in G4 firmware. It persists in G3, and may be in R4 now.
    Don't link a flip to this button and it may be fine. Have your code do the flip or, yes, use the forced release in your code. Oh the fun of corner cases.
  • TurnipTruckTurnipTruck Posts: 1,485
    If your hard button has a different channel code on the page you flip to, the realease event will occur on the chanel code of the destination page.
  • Joe HebertJoe Hebert Posts: 2,159
    If your hard button has a different channel code on the page you flip to, the realease event will occur on the chanel code of the destination page.
    Ding ding ding. We have a winner! You nailed the problem right on the head TurnipTruck.

    The destination page did not have a channel code assigned to it so the channel wasn’t getting released.

    I wonder if AMX is considering this a bug or if this is just going to be the way it is?

    Thanks for the feedback everyone. Problem solved.
  • viningvining Posts: 4,368
    Joe Hebert wrote: »
    I wonder if AMX is considering this a bug or if this is just going to be the way it is?
    How can that not be a bug.

    I can't imagine how many ghost problems this is causing by pushed channels not being released and subsequently not working.

    Just another reason to avoid using R4's.
  • Yes there was a page flip on the button. No channel code on the button on the page that is flipped to.
  • cmacma Posts: 94
    In regards to Release issues and R4s, I am having the same issue with no page flips involved. I have the cursor buttons and volume buttons coded as press, hold, release and I get runaways where the system does not see the release quite often, all while the remote stays on one page.
  • DHawthorneDHawthorne Posts: 4,584
    cma wrote: »
    In regards to Release issues and R4s, I am having the same issue with no page flips involved. I have the cursor buttons and volume buttons coded as press, hold, release and I get runaways where the system does not see the release quite often, all while the remote stays on one page.

    That might simply be an RF issue. You tend not to notice flaky RF on a push, because you just push the button again, but release is another story because it often signals a stop-action of some sort, and when stuff starts but doesn't stop, you tend to notice. That's why they recommend a timeout on HOLDs for R4s.
  • viningvining Posts: 4,368
    DHawthorne wrote: »
    That might simply be an RF issue. You tend not to notice flaky RF on a push, because you just push the button again, but release is another story because it often signals a stop-action of some sort, and when stuff starts but doesn't stop, you tend to notice. That's why they recommend a timeout on HOLDs for R4s.
    I like to add a do_release in holds for R4 since if a release isn't seen by the master the next subsequent push won't work since the master still sees that button as being pushed. I actually like doing that even if were not talking R4's just cuz you never know what's causing a push. Could be a cat standing on the panel ramping volume.
Sign In or Register to comment.