Do macros block other processes?

I have the following operation against the hard power button on my SmartRemote: I'm only using the living room at the moment so the macro that gets run is "power-off.livingroom"

In that macro I switch to a count down scene and wait for the TV to be completely off before switching off the amp and finishing:
What used to happen is that the remote would fire the "power-off.livingroom" macro, everything would turn off, then the remote would go back to the homescreen due to the "clientcmd|home" command.

Now the remote stays on the countdown transition screen. I wondering if something has changed and the running of the power off macro now no longer blocks the command on the remote so it's trying to go to the home screen immediately but then the power off macro sends it to the transition count down scene. In order for the remote to go back to the home scene I've had to add this to the end of the power off macro:
So has something changed as to whether macros are blocking or non-blocking?

I am seeing the same thing. All my activate-source macros begin with code to make sure the TV is on, the Receiver is on, and the TV is set to get input from the Receiver.

In an effort to clean up my code, I put this common code into its own macro, and call the new macro at the beginning of each activate-source macro. The common macro ends with a pause, to make sure the Receiver is fully powered on and ready to receive commands.

In the activate source macro, I set the input to the receiver to the correct source. But when everything runs, the receiver is still on the default input.

Reviewing the debug log, the commands are not being called in the correct order. While the common macro is paused, the commands in the activate-source macro continue to execute. The Receiver is being asked to change inputs before it is fully powered on.

I don't know if this is a change in behavior, but clearly, macros are now non-blocking.

I just updated and noticed the same thing.  Any hacks anyone has come up with to gain this functionality back?  Dave/David do you have any comments on this?  Is this a new feature?  Or maybe it's just a bug and you'll eventually patch it.

The only thing I could come up with is whenever I call a macro within another macro, the next command is a pause, to give the subroutine time to complete.

But if the subroutine contains conditionals that add pauses (don't wait for the AVR to turn on if it is already on) then the calling routine needs a conditional length pause.  At that point, it is easier for me to just not use a subroutine.

Yes, I modified macros to be non-blocking. Thought that would be a good thing.

Today's server update restores Macro|  to blocking.

If you're want a non-blocking flavor then use BackgroundMacro|  instead.


 

Awesome, thanks Dave! Now we have the best of both worlds.