Nested Macros work sometimes

[mkmcgregor]

Trouble with nested macros; appears to be confined to transmitted values as opposed to internal state setting.

Macro M1, which contains all the codes of M2 and L2 combined in one macro with no nesting other than the DEV_, appears to run reliably.
Macro L2, contained in M2, runs reliably when pressed directly from the L2 key.
Macro M2 will work sometimes, but often fails many times in a row, then work a few times. It always fails, when it does fail, within the L2 nested macro. The parts defined directly in M2 run properly each time.

The idea of the M2 macro is to:
1) Set the device temporarily to the cable box
3) power on the cable box
4) Run L2
The idea of the L2 macro is to:
1) Set the device temporarily to the TV
2) Set the video input to a discrete device
3) Set the device temporarily to the AUDio amp
4) Set the audio input on the amp to a discrete device
5) Make cable the current permanent active device the cable box

I have tried placing delays between commands, swapping DEV_ to the real device ( DEV_TV to TV ). Finally, I moved all the contents of the nested macro and duplicated it in the M1 macro, and that finally works reliably. However, this is a big waste of space and I would like to reclaim it.

Any help would be appreciated. Thanks.

If anyone cares to look at the IR file:
http://www.hifi-remote.com/forums/dload ... le_id=2907

[mkmcgregor]

Turns out embedding the 2nd macro's keys into the first does not guarantee success. It fails like the embedded macro. Trying to repeat the bad step a few times to see if that helps.

[mkmcgregor]

Multiple input selection keys back to back in the macro appear to fix the problem with minimal impact on macro space, but I'm still curious why the L2 macro works outside of being embedded in the other macro. Odd.

[mkmcgregor]

I wish I could just erase this entire post. I'm still having other problems. It appears just a macro problem in general, and not an embedded problem necessarily.

Calling a discrete value more than once in a row, like input selection, fixes one of my main problems. However, now I'm having intermitent power on failure on some devices, but again only when the power button is in a macro. The button itself appears to work fine, like the input selection working fine from the button it was define to (even when that buttom itself was assigned to a macro), but when the transmitting button is in a macro its out come is hit or miss (missing a lot). Frustating.

Any extender clues or modifications that help clean up macro operation?

[Capn Trips]

Your string of posts makes it hard to determine whether the file linked in the top post is the current one you're working on.

I really see nothing leap out at me in that file as being a problem, but it's hard to pick which "button" sequence to follow to examine.

Can you try to more specifically determine where your failures are occurring? What remote do you have? If it's an LCD remoite, you should be able to see the LCD display cycle through every step of the macro. That may provide you some insight as to where the failure is occurring.

Barring that, upload your CURRENT IR file and at least describe the behavior of one or two of the macros that do not behave properly in detail - i.e. specifically which steps fail to execute (or provide the intended response) - i.e not just "Macro M2 won't work" but "The TV input selects properly, but the Amplifier doesn't power on".

P.S. I notice that almost all of your upgrades use the same device number (1000). As long as they are all different device types, there's nothing really wrong with that, but it makes one (well, at least .. ME) have to do a double-take almost every time I look at a particular keymove or upgrade in your IR file, to remind oneself what upgrade is being referenced. Normally, these upgrade numbers bear some resemblance to an existing device upgrade that is "close" in some way to a natural device setup code (like if built-in setup code TV/0056 sorta works, and you build an upgrade that works better, one might assign setup code TV/1056, or some such construct). Again - there is no requirement for any changes, it's just confusing to follow for me, Al Franken.

[johnsfine]

Have you looked at the discussion of button duration issues in the extender documentation?

Some timing problems are delay issues, but others are duration issues. Some extenders increase the duration of the last step of a macro as long as the original key is pressed, which is likely to be true only for very short macros, but if you hold the key long enough could be true for a the final step of a deep nesting.

I was confused by your IR file and description, so I really don't have much clue what is going wrong. I'm just making a suggestion regarding a common cause of things failing in long sequences that work in simpler cases.

[mkmcgregor]

Thanks, I'll review that part of the document again. I may have missed some tweak in there.

[mkmcgregor]

The extender docs do not really describe how to adjust duration, only how to detect if you have a duration vs. delay problem.

However, I stumbled across a few posts talking about the DeviceCombiner. I finally read/found how to access the protocol in RM. It appears fairly straightforward; I'm hoping so. I have a couple of questions.

The first question I have is whether I should just import the keys that I expect require delay, or take the entire upgrade based on the DeviceCombiner protocol and re-paste the device (deleting the old) into IR. It seems that if I have trouble with some codes in macros, others are soon to follow.

The second relates to the duration column located in the DeviceCombiner tab for each function/key. Is that actually used by the extender? All the extender documentation states that it ignores or minimizes the duration. Does this special protocol prevent that?

[johnsfine]

The extender docs do not really describe how to adjust duration, only how to detect if you have a duration vs. delay problem.

Because I found it too difficult to put duration control into the extender itself.

The second relates to the duration column located in the DeviceCombiner tab for each function/key. Is that actually used by the extender? All the extender documentation states that it ignores or minimizes the duration. Does this special protocol prevent that?

(Except for the last step in a macro) the extender leaves the duration entirely up to the protocol.

Without the extender, the remote may select a longer duration than the protocol specifies. The extender "minimizes" duration only by not overriding the protocol (to select a longer duration).

That DeviceCombiner feature is making the protocol specify a longer duration. The extender isn't even in control at that moment in the processing and couldn't ignore or override the DeviceCombiner actions even if it wanted to.

[mkmcgregor]

Great info. Thanks for the quick reply. I'll try working the device combiner a.s.a.p. for my troubling macro keys!

[mkmcgregor]

Ok. I played with duration, and from what I saw, I got it setup and installed correctly. Although it did help with the power on/off slightly (more reliable operation) it really ate into device/protocol memory. So much so that I had to remove some currently unused devices and protocols from the extender to make it fit. I was hoping to not have to move to extender 2, 3, or beyond, but that maybe necessary. I assume that there is no other fix for space other than using a modified extender that segments memory differently or delete any unused protocols. Are there any protocol or devices that come with the extender that are fobidden to remove; used or mapped beyond what I see in IR?

One thing the duration test did not fix is the fact that for the special added protocols ( my xbox 360 and pinnacle showcenter ) I need to send an unmapped phantom character after the nested macro is finished. This is NOT true for the Scientfic Atlanta 3250HD box macro. It worked no matter what the situation was. If I don't send the trailing phantom key, that particular macro button won't activate the power (and only the power in the base macro (the input selection (in the called/nested macro) worked fine). This was true regardless if the second press turned the unit on or off (toggle only, no discrete power for these devices). It would very consitently not send power, although the light did light and the TV's IR feedback indicator noticed something being trasnmitted in addition to the input selection, on the second and subsequent presses of the macro button. Once the first press worked, all subsequent presses of that macro button would not send power. Pressing anyother key, even another macro key, would reset whatever state it was in and the troubled macro would send power again; but only once more and the cycle repeasted. I remember reading a post about this somewhere about adding a key to the end of the marco sequence, now all I have to do is find it agian .

Thanks again for input in moving forward. If anyone has any answers, I would appreciate hearing any more input. I will post my current file if anyone cares to check to see if I'm doing anything stupid.

http://www.hifi-remote.com/forums/dload ... le_id=2917

I've been moveing things over from RM, and had great success controlling devices, but that doesn't mean that I've done right

[Capn Trips]

OK, I think I see how you've set up your macro sequences. Correct me if I'm wrong:

(1) The M buttons will turn on a single component and line up your system for the TV speakers;
(1a) The shifted M buttons will do the same for you Receiver's speakers; AND
(1b) They call on the L macros.

(2) The L macros select inputs on the TV;
(2a) The shifted L macros select inputs for TV and Receiver; AND
(2b) They call on the Device button macros

(3) The Device Button macros assign the various keygroups to the desired device - some of this is direct, and some is by calling the phantom 1 "SET_XXX_KEYS" macro and then occasionally modified by subsequent modifications that follow the execution of the Phantom 1 sequence in one of the outer macros.

Other than the M macros - which are always outermost, and the HomeTheater macro (which seems to be an "All On/Off" macro) - which is also never invoked from within another key sequence or macro, you have no other "power" functions assigned anywhere. Correct?

Now you're saying that M2 and M3 (I presume the shifted versions as well?) when executed, will only send the power signal the first time you press M2 and/or M3, but on subsequent presses, the signal is not sent (or is at least not acted on by the Pinnacle or xBox) UNLESS you put a dummy signal at the END of the sequence? Since the Power signal is sent early on in the sequence, that is truly baffling!

Since they both use the MCE protocol, I suspect your problem is with the protocol and a toggle bit. Have you tested pressing the Power button for these devices (when the appropriate Keygroup is assigned to that device)to see if the behaviour is the same? I would expect that you would need to execute a different function in between consecutive presses of "power" directly, as well. You need the MCE protocol expert (Rob, are you reading this?) to jump in and help sort this out.

On to other matters. Regarding "removable" protocol/device upgrades. I nots that you are not using ANY of the special protocols other than Pause, and in fact I don't see you using those two pauses you've created anywhere either.

The only REQUIRED protocl/device for the extender to work is TV/1800 with 01 80. That upgrade IS THE EXTENDER.

The others can be removed if you don't use them, although you might want to - I don't know. They are identified in the extender readme:

SPECIAL PROTOCOLS
=================

This extender includes the following special protocols:

MISC/1103, portocol 1FC = Device specific Macro
MISC/1104, protocol 1FB = Pause
MISC/1106, protocol 1F9 = Long/Double Key Press
MISC/1107, protocol 1F8 = Custom Mode Name
MISC/1800, protocol 181 = ToadTog

I would really stay away from the other versions of the 8910 extender, as they were a one-off and have no real support, so you'd have to do a lot of tweaking and "inferring" to get them to work for you, since the rdf ID's are not distinct.

Finally, I wonder why you repeat the input selection commands three times in your M macros. Is one iteration simply not "taking"? That would appear to be a duration problem indeed.

[mkmcgregor]

Thanks for the indepth reply!

You are right on all calls in your interpretation of my setup. The power button for the device works flawlessly by itself when called upon by the power button in the correct device mode for both the Xbox and Pinnacle unit. The power only seems to fail in subsequent presses of the macro button, until another different key is pressed. That's why I assumed it was some sort of macro issue or macro/protocol issue. The M1, which controls the cable box and input selection, works everytime; well mostly, but nothing like the no power found with the M2 and M3. The two Pause functions that you noticed were used for testing delays in these problem macros, but did not appear to make a differnce. That's why they are defined but never used, at least for now. When I add Phantom2 to the end of the macro, the power again works properly in the M2 and M3 macros. I have to apologize that I did not send that file, which I meant to do. The version I sent you did not have two things in each macro; 1) the Phantom2 key at the end of the M2 and M3 macro (my temp fix for this problem) 2) a DEV_AUD;XXXXX before the final device activation in the L3 and L4 macros; where XXXXX is the key assigned to the input selection of the audio amp. The version you have is infact the "broken one" without the Phantom2 key added. I removed the audio amp keys, because I thought it was conflicting somehow with the other protocols, which it did not appear to do. I have reposted my "fixed" file for comparison, if you care to take a look.

http://www.hifi-remote.com/forums/dload ... le_id=2918

I was not as concerned about the shifted-macro versions, since they were just an extension to the other macro which added, as you mention, an additional feature of assigning the amp vol keys. To be honest, I did not try those, since they were more of a test.

As far as calling the input selection three times, yes you are correct that duration is probably to blame there, but that was the quick fix until I can rearrange memory and hook up the devicecombiner for all devices that are having problems and adjust the duration there; I have not found any other way to do that except in the devcombiner. Adding one more call to the input selection, since it was a discrete TV function, would not hurt. I added three, just because I'm paranoid; two good, three better! The time difference was negligable.

I was hoping to not have to use the extended macros for the reasons you mentioned based on the many posts I've read.

[Capn Trips]

Well, for that small handful of items that have the duration problem, your solution (repeat the discrete input command) is likely more efficient than using Device Combiner for just that. It's unclear what other duration problems you may have - or THINK you have, but it's always a trade-off as to what way to solve a particular challenge, and always YOUR choice (when there is one). All things being equal, six bytes for repeated commands is a LOT less than the DC protocol would consume!

As far as the MCE protocol devices and the Power function only exhibiting this "toggle-bit-like" behaviour when in a macro, but not "naturally. I really don't know. At this point, there are two schools of thought:

(1) If it works - at the relatively mild cost of a meaningless phantom2 command consuming a few Keymove bytes - don't fix it! ; or
(2) Wait and see if one of the MCE protocol guys has any ideas - I have none.