Device ID of R4
TurnipTruck
Posts: 1,485
Greetings,
I am working with an R4. I know that there is a way to use DEVICE_ID to return the type of device, probably in a DATA_EVENT? How exactly is this keyword used?
I am writing a module that has lots of variable text. I would like to use DEVICE_ID in a conditional to not send the text to R4 type remotes.
Any suggestions? Thanks!
I am working with an R4. I know that there is a way to use DEVICE_ID to return the type of device, probably in a DATA_EVENT? How exactly is this keyword used?
I am writing a module that has lots of variable text. I would like to use DEVICE_ID in a conditional to not send the text to R4 type remotes.
Any suggestions? Thanks!
0
Comments
If you know the actual deviceID of the R4 ($142 i think) then you can tell if the TP is the R4.
http://www.amx.com/techdocs/HelpFiles/AMX-ProductInformation/Public-FlashHelp/AMX_Product_Information_(AMX-PI).htm
You could always use the DEVICE_ID_STRING function. But then you would need a clue as to what this returns as well...
I was trying to run device id at start up on my TP array all load values into a TP type array to determine feedback. I figured I'd load an array with values at start up rather than call the device id function every time there's a need for feedback. That seems like it would be considerably more processor intensive.
Unfortunately I think device id only works if a device is online and the R4s if sleeping don't get a value returned. Actually the help file for device id says it main purpose is to show if a device is online and when aren't the R4s sleeping. So I had to put the device id call in the TP data event online handler to load the array to run if the current value was zero so it only has to run once.
Seem reasonable?
I also create several other arrays to control feedback. As I stated before I create an integer array to hold the results of the DEVICE_ID function since it has to be easier on the system to do once then on every send string or level for every UI device every time feedback needs to be sent. I know the iPort module does it that way but it can't be efficient. In the UI arrays below I only have R4s since I don't have TPs in these rooms but normally you would have keypads, R4's, TPs etc. I also posted a while ago that I couldn't find the ID for the Metreau keypas so in the code example I just made one up. I have a keypad and I was going to connect it and see what it is but my master didn't have the phoenix connecter on the Axlink port cuz the price we pay for these things isn't enough to cover the cost for connector on all the ports. So I got pissed and gave up.
I then create a data event for the real UI array like this:
Since all my arrays are in order when in comes time for feedback I run a for loop on the UI array and 1st see if its active on this devices page. If it is I'll test it further against the nUI_TypeArry to determine what feedback the "On Page" UI's should get.
// except for the double quotes. I would write this like this.
What would be the difference in operation?
As to Vining's response, I have stopped using the queing module. I have had no problems. Things even seem faster sometimes.
My thoughts exactly. Functionally, the R4 is not a carry-around-the-house device. The loss of throughput from having the repeaters is not acceptable to me.