Home AMX User Forum NetLinx Studio

MIO-R-4 Hold event

Hello!

Noticed that on MIO-R-4 remote when I push and hold button for volume ramping, release event is invoked after about 1 second of holding button, and Volume ramping stopped.

I tried to use command TO[] in push event, but sometimes it causes multiple command sending while button pushed once.

How do you solve this problem?

Thank you!

Comments

  • John NagyJohn Nagy Posts: 1,734
    Best way to solve R4 problems is to pull the battery, put the battery in one drawer and the R4 in another, then forget where they are.

    Late firmware for the R4 imputes a RELEASE to prevent volume runaways. There are a variety of ways the R4 can "miss" a release, including going offline due to buffer full, range issues, or page flips before you release. These can and did cause major problems with starting the volume rise and no way to stop it. About the third time this happens in a customer site, they want to go with solution #1, above, ASAP.

    That said, your choices are limited by safety factors, and efforts to enable an uncontrolled volume ramp are heartily discouraged.
  • a_riot42a_riot42 Posts: 1,624
    deps wrote: »
    Hello!

    Noticed that on MIO-R-4 remote when I push and hold button for volume ramping, release event is invoked after about 1 second of holding button, and Volume ramping stopped.

    I tried to use command TO[] in push event, but sometimes it causes multiple command sending while button pushed once.

    How do you solve this problem?

    Thank you!

    Which firmware are you using for R4 and gateway? I have ramping working fine, but do my own runaway ramping short circuit.
    Paul
  • viningvining Posts: 4,368
    Why would AMX force a release and not allow us to simply deal with runaways ourselves.
     HOLD[3, REPEAT]:
    	  {
    	  STACK_VAR INTEGER nBtn;
            
    	  nBtn = BUTTON.INPUT.CHANNEL;
    	  //fnDevMod_DeBug("'BTN HOLDING: CHNL-',itoa(nBtn),' :DEBUG <',ITOA(__LINE__),'>'");
    	  SELECT
    	       {
    	       ACTIVE(nBtn == AVR_BTN_MAIN_VOL_UP || nBtn == AVR_BTN_MAIN_VOL_DN):
    		    {
    		    nBtnHold = 1; 
    		    if(BUTTON.HOLDTIME <= 8000)  
    			 {
    			 SWITCH(nBtn)
    			      {
    			      CASE AVR_BTN_MAIN_VOL_UP:{fnQueue_QCmd("AVR_CMD_MV,AVR_PARAM_MV[AVR_VAL_MV_UP]") 	}// Volume +
    			      CASE AVR_BTN_MAIN_VOL_DN:{fnQueue_QCmd("AVR_CMD_MV,AVR_PARAM_MV[AVR_VAL_MV_DN]") 	}// Volume -
    			      }
    			 }
    		    else
    			 {
    			 DO_RELEASE(vTPcom,nBtn); //nBtnArry[nBtn]);
    			 }
    		    }
    	       ACTIVE(nBtn == AVR_BTN_Z2_VOL_UP || nBtn == AVR_BTN_Z2_VOL_DN):
    		    {
    		    nBtnHold = 1; 
    		    if(BUTTON.HOLDTIME <= 8000)  
    			 {
    			 SWITCH(nBtn)
    			      {
    			      CASE AVR_BTN_Z2_VOL_UP:{fnQueue_QCmd("AVR_CMD_Z2,AVR_PARAM_Z2[AVR_VAL_Z2UP]")}  
    			      CASE AVR_BTN_Z2_VOL_DN:{fnQueue_QCmd("AVR_CMD_Z2,AVR_PARAM_Z2[AVR_VAL_Z2DN]")}
    			      }
    			 }
    		    else
    			 {
    			 DO_RELEASE(vTPcom,nBtn); //nBtnArry[nBtn]);
    			 }
    		    }
    

    That just makes the R4 a bigger, over priced piece of crap than it was before. Having a customer spend hundreds of thousands on a system and they can't even ramp volume or channels like a $20.00 remote is extremely pathetic.

    Was this change announced or just in the firmware release notes?
  • a_riot42a_riot42 Posts: 1,624
    Its just a bug in the firmware that was fixed. its not the end of civilization as we know it...although that's not far away, Jan 16 2015.
    Paul
  • vincenvincen Posts: 526
    John Nagy wrote: »
    Best way to solve R4 problems is to pull the battery, put the battery in one drawer and the R4 in another, then forget where they are.
    +1*, so many issues with R4 :(
  • a_riot42a_riot42 Posts: 1,624
    vincen wrote: »
    +1*, so many issues with R4 :(

    I haven't seen any of late. With the new hardware/firmware they are pretty solid. I prefer an R4 to a touch panel myself.
    Paul
  • DHawthorneDHawthorne Posts: 4,584
    a_riot42 wrote: »
    I haven't seen any of late. With the new hardware/firmware they are pretty solid. I prefer an R4 to a touch panel myself.
    Paul

    Yes, they are very solid now. I wasn't aware they fixed the HOLD issue though, I have straight-up been coding different to get around it.
  • a_riot42a_riot42 Posts: 1,624
    DHawthorne wrote: »
    Yes, they are very solid now. I wasn't aware they fixed the HOLD issue though, I have straight-up been coding different to get around it.

    It might require getting the hotfix firmware for the ZGW/R4. I can't recall which FW fixed it. So far I am not seeing any issues with R4s (knock on wood). Finally, after 6 years, they work, so in all likelihood they will be discontinued.
    Paul
  • We have 4 R4 running the same hotfix firmware v3.01.48 and only one of them presents the "release event after 1 second" (no hold) problem. External buttons are fine, no physical problem. Any idea how to solve? Force another firmware transfer? Different zigbee gateways are running the same firmware v3.01.13.
  • a_riot42a_riot42 Posts: 1,624
    nicolau wrote: »
    Different zigbee gateways are running the same firmware v3.01.13.

    I use 3.01.17. The issue was with the gateway FW not the remote FW I believe, so you[ll have to upgrade to 3.01.17. I"ve seen some wake issues with 3.01.48 so I've been using the previous FW 3.01.38. Nothing too serious, but I was noticing it would wake on its own once in a long while.
    Paul
  • Dear Paul, Thank you for the information. I was about to upgrade the gateway but now the one with the issue and FW 3.01.13 is working perfectly. But I read the notes for firmware 3.01.17 and it fixes that issue. On the remote I am using FW 3.01.48 because I was having issues transferring the TP4 to the Mio (error "Could not open file...") and with 3.01.48 I could transfer.
  • a_riot42a_riot42 Posts: 1,624
    a_riot42 wrote: »
    Finally, after 6 years, they work, so in all likelihood they will be discontinued.
    Paul

    Looks like I was correct. The R4 has been discontinued, although I never received one of the discontinued emails that I typically get when they do that. I went to the website to look up the part for the battery and noticed its no longer listed. There is no discontinued notice for the Zigbee gateway, but its likely it has been or will be and the website just hasn't been updated to reflect that.
    Paul
  • Paul, I show an April 20, 2017 notice of PDN Reference No. 170420-04 that removes R4, charging cradle, and Zigbee gateway. The last expected order date was 30 June 2017.
  • a_riot42a_riot42 Posts: 1,624
    AMX_Chris wrote: »
    Paul, I show an April 20, 2017 notice of PDN Reference No. 170420-04 that removes R4, charging cradle, and Zigbee gateway. The last expected order date was 30 June 2017.

    I might have missed it somehow. Shame that they've been discontinued. While I wouldn't argue against an update, I lived through all the issues we had with them, and now they are quite reliable with most bugs worked out, so its frustrating to deal with all that only to have them discontinued once they are stable. I reported a lot of bugs for both the R4 and ZGW so I was hoping to reap the benefits of that by having a reliable remote to sell. Oh well...
    Paul
Sign In or Register to comment.