Delay Next Command

Archives Configuration and Setup
1

I had some issues with activity switching. When making a cold start (from full power down) to an activity, the receiver (that’s generous - it’s a YSP-2200 soundbar!) and TV (Samsung LED from around 2009) would fail to input switch. They would only turn on. If the cold start activity differed from the activity on power off, the inputs were wrong. If I re-engaged the activity once all devices were fully powered on there were no input switching issues.

I read as much as I could from the FAQ and the forums, doing searches for “delay next command” and “delay” (among others). It appeared the issue was a need to delay input commands to these two devices (soundbar and TV). But that did not appear to resolve for everybody, and my experience was spotty. I’m setting all this up to ask a question (test a theory, really) and create what (hopefully) would’ve been the thread I needed.

How does “Delay Next Command” work? Does it:

  1. Wait the specified delay before issuing another command to that DEVICE?
    OR
  2. Wait the specified delay before issuing the next command in that ACTIVITY?

It appears to be choice #1, can someone confirm?

Here’s why this matters: I found at least one forum post where the person claimed setting the delay up to 10s (10,000ms) did not help. I have three devices in my “watch TV” activity:

  1. Yamaha soundbar (IR Control)
  2. Samsung TV (IR Control)
  3. DirecTV HR23-700 (IP Control)

All IR control is through the GC Itach wireless I just got from the Roomie store. My activity powers on the three devices and then switches to the needed inputs on soundbar and TV. As mentioned, my problem was from a cold start the inputs wouldn’t switch. Since everything worked fine once things were fully powered on, I concluded repeats were not the issue.

My activity commands are:

  1. Power on TV
  2. Power on Soundbar
  3. Power on DVR
  4. Switch to TV HDMI1 input
  5. Swtich to Soundbar HDMI1 input

I tried to add a delay to the ACTIVITY where I thought it made sense: between #3 and #4 (so I made the “Delay Next Command” to the IP controlled DVR have delay 10s). This did nothing to fix the issue. Further, when watching the top of the virtual remote to follow the commands being issued, there was no apparent delay between steps #3 and #4. To repeat: no matter what “delay next command” I put on the power up DVR command, it had no discernible effect on the activity.

Then, I decided to add the delay between steps #2 and #3. This seemed counterintuitive to me - might as well get the DVR powering up before hitting the delay. But, it worked. Further, when watching the commands issued at the top of the virtual remote, there was a discernable delay (of about 5s - what I’d set) before command #3 was issued.

Thus my question from above. If the “Delay Next Command” inserts a wait before issuing another command to a device, this explains the behavior I saw. There was never a second command to the IP controlled DVR in the activity, so Roomie saw no reason to delay. That would explain why I needed to put the delay after the Soundbar’s commmand (command #2)…because the soundbar has another command in the activity (input switching), and so Roomie behaved as I expected.

Again, if I’m understanding the behavior correctly I believe this would’ve helped other users. I could not find this explained clearly here on the forums anywhere.

Thanks!

2

Thank you for bringing up this issue. I had the same problem and used exactly the same logic you describe. For me two devices: ir controlled Denon and ir controlled 2010 Samsung TV.

Began using the 10 sec delay yesterday and so far in maybe 10 tests EVERYTHING WORKS, and your theory about which order to use seems untrue for me. The two activities are TiVo and Apple TV.

With 10 sec delay added to the second power on command, then both receiver and TV switch inputs as desired, whereas with 1 second delays they did not. Both devices seem to require the time before they are “warmed up” enough to accept input commands. Also as you noted, the repeat command seems irrelevant in my few tests of that. However, I turn on TV and then receiver with 10 sec delay, then I change input on the TV and then the receiver. But stay tuned while I watch what happens going forward with more activities. I am just getting started.

3

I have been battling these delay issues as well. It would be good to have an explanation from the Roomie people.

Bill

4

Delay Next Command inserts a delay before the next command to the same device type. If all of your devices were IR, that would mean all commands will be executed in the displayed sequence with delays between. If some devices are not IR or were to a different iTach, they would execute immediately and only delay within their own context.

For instance, a DirecTV receiver via IP would immediately receive commands even if IR commands existed before it in the sequence, but if Delay Next Command were set on a DirecTV command, it would delay the next command to that DirecTV device. All IP devices are independent. All IR devices are effectively a pipeline to a given iTach. Using multiple iTach adapters would create multiple pipelines.

5

Thank you Roomie. Your explanation is consistent with my experience because my delay works as expected, and all my commands go thru an iTach. In maybe one out of ten times or less the inputs are still messed up, but a system off followed by activity on again fixes things.

6

Yes, Roomie, thank you for clarifying. And thank you everyone else for sharing your experiences. Very helpful!

7

I learned something about ‘delay next command’ and I am sharing here for the benefit of others. Not sure if this is by design or I stumbled across something that can be fixed in a maintenance release.

I am using serial control for an older Denon receiver so I can get feedback. Serial works great for almost all commands on this older Denon receiver, and gives feedback, but the older Denon will not respond via serial control to one of the specific ‘input’ commands I need. No worries - I added an IR blaster as a ‘second device’ for the same Denon receiver specifically to select that particular input.

The Denon needs a ‘delay next command’ between ‘power on’ and ‘select input’ of 1500 nanoseconds to allow the Denon to sufficiently power up and recognize the ‘input’ selection command. But if I ‘power on’ via serial, and select ‘delay next command’ of 1500 under that same command, and then ‘select input’ via IR blast as a ‘separate device’, it will NOT delay the IR blast for 1500 nanoseconds after the serial command. The ‘delay next command’ is ignored. Apparently, the ‘delay next command’ only works if the next command is of the same type of device as the prior command.

I know this because, as a work around, if I ‘power on’ the Denon via IR blast instead of serial command, and select ‘delay next command 1500’ under that command, and then ‘select input’ also via IR blast, the ‘delay next command’ will work. This is also true if ‘power on’ is serial and ‘select input’ is serial for the other input selections - in that case the delay also works. It is apparently the mixing and matching of devices where delay will not work.

This was an hour long brain teaser so I am trying to ‘pay it forward’ and help the next guy here. Thanks.

8

Merged identical threads into one.

9

Here’s a solution for these kinds of problems.

Lets say you set up 2 devices for the same denon, in this example you have one IR and one Serial, but this would work for any two roomie devices for the same physical device. Let’s call them D1 (for device 1, the IR device), and D2 for serial.

The trick is to insert an extra harmless Serial command (for D2), with its OWN delay, immediately after the POWER ON of the IR. That extra Serial command will be chosen so that it doesn’t matter if it’s received or not. The commands should look like this.

  1. D1: POWER ON, Delay Before Next Command = 1500

2. D2: INPUT x, Delay Before Next Command = 1500

  1. D2: INPUT x

The extra harmless command is line 2, we don’t care if it’s seen or not, because the one we really want is line 3. Line 2 just causes a long enough delay for DEVICE 2, before line 3 gets executed. (the serial device in this case)