R4 Module

RicardoSiqueira

I haven't worked with a R4 remote in more than 3 years. Back then I used the AMX_R4_Comm_Mod module as suggested by AMX to queue commands and communications. My current project has 2 R4 remotes with their own Gateway for each. Is this module still needed to queue commands/communications or have they improved the R4 in a way that the module is no longer needed? Do you guys use the module or just program the R4 as any other AMX TP? Any suggestions? Thanks!

AMX explanation of the module use:
"The AMX_R4_Comm_Mod module is designed to "intercept" most communications to the R4 remotes (Data, Button, Channel and Level events) and queue them in the master, so that the message queue on the Gateway is not over-run. Level and Channel events are managed so that only changes to the current state are transmitted. "

felixmoldovan

Have always used direct programming to the TP while minding the amount of communication involved. I might have done one first remote with a queuing module in the context of browsing an iPort media library, but even that proved to be an unstable experiment.

I believe that subsequently, with the release of ZigbeePro gateways and newer R4 firmware, AMX has stated the obsolence of the queuing module, and, honestly, I always felt that was a after thought McGyver way of overcoming some obvious initial shortcomings and not a proper way of using the remote.

I stay a fan of minimal transfer for an R4 and if I must specify one, then I try putting it where its hard buttons and non visual assisted operation makes sense, probably between a couch and a TV, and not where the user needs a proper touch panel to control a media library or the house scheduled features. (sorry for actually not having answered your question, but I always enjoy a little chat about the mighty R4 over my pizza

a_riot42

As mentioned its no longer needed, and I am not sure how much help it ever really was. I never sent enough commands to overflow the queue so I don't think it was much benefit to me. I use R4s with iPods, Kaleidescape systems, etc and don't see many problems where the queue is overrun but it can probably be done with commands sent from define_program or other freewheeling ways, but if you are reasonably careful you shouldn't have too many problems.
Paul

jjames

I believe the buffer size was also increased when the Zigbee Pro was introduced, and even then there's a command you can send to temporarily double it (though don't know it off the top of my head) to 500 I believe.

I'll second (or third) that they are fine when you're aware of their limitations.

John Nagy

jjames wrote: »

I believe the buffer size was also increased when the Zigbee Pro was introduced, and even then there's a command you can send to temporarily double it (though don't know it off the top of my head) to 500 I believe.

I'll second (or third) that they are fine when you're aware of their limitations.

It was increased from 150 to 300 commands when they went to 3.x firmware. The command to increase the buffer size is

BUFF DEVICE SIZE
This command increases the buffer size for a specific DEVICE to SIZE.
This change is temporary, and the buffer size will revert to its original size after 30 
seconds.

An energetic user can force a buffer overload by pressing buttons faster than the R4 can render, worst if scrolling a list.
I was unaware of this command. It was not in the old manual for the Pre-PRO version of the gateway. It may work on the old ones with new firmware... or not... it deserves testing, as it would be handy to send before larger page updates.

DHawthorne

I found that the module caused more issues than it fixed ... it really slowed feedback down a lot, and the R4 was never a zippy device to begin with. My solution is to pare back on feedback as much as possible when sending to the R4. I've not had a lockup since, unless I had a program glitch that was sending continuously.

I have found it helpful to always open up Notifications and watch what's going on on the R4's in a job while the system is being used. I've several times caught overdone feedback that way I wasn't aware was happening (ie., buried in a module and forgotten).