why does the button test option only come available after the standalone output has been selected for that button. can you not have a button test through a processor? can you program the macro and then go back and change the buttons output properties. thanks in advance. i have never used the press and hold feature.

This is why they call it a one way system.

The processor can see a sustained code issue but it can not see when a button is pressed and held on the remote nor can it make a variable decision based on the condition of the hold and change the state of the remote itself.

...in fact, most two way systems can't do this either... there has to be valid communication back to the controller before a change can be executed.

what you talkin bout willis?

you can click on any button and select properties, select output, select standalone.

when this is done, under macro options a new option appears for button test. if button is held down for x amount of seconds or double clicked within x amount of seconds.

Example.
press could be source select for great room av receiver
press and hold for 2 seconds could select that source for zone two
double press within 2 seconds could select that source for zone three

just an example.

what i am asking is why is this only available while button is selected as standalone operation. i just confirmed that this feature will work through processor, but i had to put button in standalone mode create macro then change button back to system default, RF mode.

why is the button test option not available while in system default mode?

I understand your question (and how to set properties) and I thought I answered it.

The button test is an event that only occurs on the remote, not the processor. In system mode, everything is directed to the processor... the remote becomes an extension of the processor.

I agree that there should be a way to manage page jumps and button tests even when in system mode but there may be many other issues to consider like recognition of direct IR and RF codes within a single macro etc...

obviously you did not read my last post.

i just confirmed that this feature will work through processor, but i had to put button in standalone mode to create macro then change button properties back to system default, RF mode.

i have a t1 in system mode press source buttons to select source in great room. press and hold to select that source for zone two.

press power off to shut great room down (all equipment) press and hold to shut zone 2 down.

I don't think you read Glack's post correctly. By putting the button in standalone mode you are allowing the remote to do button tests. These button tests have nothing to do with the processor. You can make them generate system macros on a button test which would be run on the processor, but any straight command that is put on the command line will execute in standalone (remote/IR) only nad not involve the processor.

Your question in your post "can you not have a button test through a processor?" was answered correctly in Glack's post.

eddizle,

The concept I know is sometimes hard to grasp. Took me a little bit before a light went off :).

Since the system is one way there is no way for the processor to know what button presses are made on the remote since they do not talk to each other. The remote only send a trigger comand to the processor. In turn the remote has no idea when a processor command finishes processing either. Thus as stated above, the processor has no way of knowing if you did a single press, press and hold, etc. Only the remote itself would know. ala the reason why you need to put buttons in standalone mode and then send system macros to run those commands from the processor. This is also why you have to manually figure out how long a system macro takes to run to add in enough delay before your standalone button/macro continues.

I did.... every word. I think we must have a conceptual divide.

This feature has NOTHING to do with the processor. When in standalone mode the remote is acting independently of the processor. What I mean by this is that it is sequencing and issuing individual codes (and page jumps) on the remote itself. Part of that process includes the ability to issue RF trigger codes for system macros but individual commands are sent line of sight. Regarding the button press test and page jumps... these are events unique to the remote and take place with no recognition from the processor. The remote decides the variable of the button press and the method of the page jumps and can also "reach out" to the processor with an RF trigger code.

The best way to think about it is that in system mode, the programming is much simpler and automatic. All actions in a button macro are automatically housed on the processor except the one page jump option which happens outside of the macro process. It is a quick method for programming with a RF receiver in the system. In standalone mode, you have the ability to control those features unique to the remote in sequence with direct IR, RF triggers, delays, etc... all stored directly on the remote.

It does, however, seem like it would be possible to have conditional button and page events automatically detected when in system mode.

I do many complex standalone operations including button tests and page jumps. Since I find it easier to program my activity macros on the processor I find it quite easy to manage the standalone scenarios. Basically, any button that requires a page jump, button test (usually the same button) or direct IR such as my main activity macro buttons or off buttons are always in standalone mode. All of my single event buttons are, of course, in system mode.

Putting it another way, when you have a remote in system mode (when you have a processor), the remote buttons are automatically set for a single operation. This single operation can be a single command, OR a macro (ir and/or rs232, etc.). Even though you program these commands on the remote, it is stored as a single command OR macro on the processor.

Setting the remote button properties to standalone is a function of the remote ONLY. It then gives you the increased flexibility of using the functions such as button test and page linking. IR commands will be issued directly from the remote, NOT the processor when in standalone. Any command(s) you want to be issued by the processor must be created in a system macro on the processor (a single command or macro). Then call these system macro(s) from within the standalone button macro.

If you change the button from standalone back to system mode, the standalone functions will not work.

I assume the remote automatically being in system mode (and all buttons) once a processor is added to a system would be intended to simplify the programming of the system. If you leave the system set to default, all commands are issued from the processor, and a programmer doesn't need to think about which device the commands are coming from.

Being able to change the button properties to standalone enables more advanced programming to be done, such as the press and hold function, as well as allowing the remote to send IR commands directly itself.

Groovit and the others who replied likely know far more than I do about this, and did a good job of explaining it; I've only broken it down a little differently. I hope it helps you.

I have no idea what you guys are talking about. The only intelligent thing I can think to ask is "is Groovit Glack's new name?" I see references to Glack but no posts from Glack...

:)

Groovit and Glack seem close enough to mistake!?!?

I just decided not to bother correcting him and let Glack get some love.

Man, that tgrugett guy sure seems like an ass hat wire pulling hack.