MIO-R-4 Hold event

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.

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?

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_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.

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.

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.

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.