I had to sell and program a MX-1200 yesterday. The customer wanted single room lighting control for a small theater, so it seemed like the best and most economical choice, since they have their own lighting control.

I usually programming program with slightly more-complicated-than-most macros. I use variables/flags to track what activity is being used in both zone 1 and zone 2, the power state of toggle devices, and if the system is on or off for delay times. In yesterday's case I also combined all of this with a press and hold on the activity buttons. If the activity button is held for more than 3 seconds, it was intended to adjust the lighting scene. If it was not held, then the lights would not be affected.

What I ran into was the same reason I switched away from URC. If the macro is too complicated, it will skip some of the steps (often whats inside of a if/else bracket), or do whats in the bracket no matter what. In yesterday's case, it was adjusting the lights on some activities without the press and hold and on other activities is was working as intended.

I double and triple checked my macros. It was a case of definitely the remote just doing what it wanted to do apparently. No matter how it was programmed.

This is a problem I never have with RTI and ProControl. Now if only they made their own lighting control. I have read there is a way to get them to work with the URC lighting, but have never tried it.

Odd. The only issue I ever had with urc was with the mx980/mrf350 combo that would often do similar things with macros not working reliably. I have never programmed an mx1200. if somehow it is the same issue, try putting .5s delays between all macro steps. Obviously this is not a solution, but at least a step in the right direction. I do not believe urc ever admitted to there being a problem with the 980/350, although many had the issue. But maybe if it pops up in the 1200, they will take it more seriously.

I thought urc lighting worked with rti.....maybe I read wrong.

I've never had issues with macros on URC especially after .5 sec delays added. I hear just as many whines about RTI as I do any other control system.

433 MHz URC lighting devices work with RTI's 433 MHz ONLY remotes. I believe the Zigbee remotes have issues. I did try programming a T2C+ to a URC lighting device once to see what would happen. The lighting device would occasional learn the ID from the remote, but would stop working shortly after. I have a T2C 433 MHz in my bedroom working a URC lamp dimmer just fine.

I did not try putting delays between everything, since that should not be needed, but if it'll fix it then I'll definitely do that when I go back out.

Interesting comment about the 980/mrf350 combo issue. That is pretty much all I ever did when I did URC, so I guess that is why the problem seemed so common to me.

The delays are definitely recommended. I have been using them for quite some time and haven't experienced any issues. I don't use too many variables though.

+1 on the delays. One of our old programmers was variable-happy and he ran into issues constantly on the MX980 if delays weren't in place.

Let me suggest something about time delays.

If you find that you need a particular time delay, you might need to change it at some time in the future. If the stuff ages, you might need a longer delay. And what I'm going to suggest lets you experiment in a wholesale way with time delays.

Somewhere in one of your devices create a command named toime or something else that distinguishes it from a normal time delay. Then assign a delay to that command.

When you make your macros, instead of putting in time delays, alias to the toime command. Now if you want to see what happens with longer or shorter delays, or if something changes, you can change the value of that time delay and it will change ALL of the time delays in all of the macros all at once.

This is an old Pronto TS1000 trick that Yamaha tuner and DirecTV channel macros forced me to discover.

I miss programming Prontos for customers. IMO they had the *best* programming software.

For personal use, I have backups upon backups of my TSU9400, RFX9400, and a couple of TSU9600's. I even use my Prontos to send IR commands to our Control4 system.

So sad when they shut that line down.

Delays should not be needed? Says who?

Its just a fact on the 980's especially when using the msc-400. Try it without them and you'll get it. No big deal AT ALL.

I almost agree with that until it's the hour of the download. RTI is amazingly fast and URC almost as fast. A Pronto download was usually two games of Freecell, which I never wanted to play in front of a paying customer, so.... boring was the download experience.


I say so. All equipment to which one might send repeated commands, such as for DirecTV channel 222, should have commands constructed with all the correct details within the commands so that no delays need be added. Ever.

However, I'll bet that nobody pays attention to integration here, either, so frinstance once they have a command that registers as "2," they don't consider whether the commands might come faster than a finger can repeat them.

Great minds think alike. See below. Who says you can't program a URC remote like a Pronto. :-)



Note as well per the above that my activity macros are made up completely of aliases to other buttons, the buttons located within the devices named "Links". I call this the Function layer. Those buttons in turn alias to the buttons within the Code layer (...the devices named "IR Codes" used to store each IR codeset) and GUI layer (...the devices under the "Watch" section of the tree intended to be displayed on the remote), the GUI layer in this case containing only aliases to the buttons within the Function and Code layers. Following this practice keeps the internal structure of the file intact. In the event something changes within the Code or GUI layers it then just becomes a simple task of updating the particular action list (...Pronto terminology) under the Function layer, all the while the activity macros and conditional use of variables for powering things on and off (...the devices named "Links [Pwr...]") remaining completely intact. This is the way I've always programmed Pronto remotes. CCP by design doesn't encourage this practice, but that doesn't stop those of us who know better anyway. :-P

Additional note...
For anyone interested in checking out the custom graphics I worked up per the above example feel free to hit up "Page 17, Post 246" of the thread found here.

 I too loved programming Pronto remotes and think that as of today it was the best software out there.

As for delays, they should not be needed. Just like bar-code, IR commands have a start and end functions built into the code. 
Receiving equipment (not all, but most) is smart enough and fast enough to handle it. 
Don't believe me? OK, press volume up or down and see if the TV or AVR crashes; what delay does OEM put in the remote for press and hold of those functions?
Oh, and yes, I do use delays because just like the rest of you I know what real world is like.

The use of delays primarily is to prevent the remote control solution from screwing things up, rather than the inability of a single device to reliably accept consecutive commands back to back.