Please login or register.

Login with username, password and session length

Author Topic: Questions about macro behavior and work-arounds  (Read 10421 times)

JoKer

  • Jr. Member
  • **
  • Helpful Post Rating: 0
  • Posts: 21
Questions about macro behavior and work-arounds
« on: December 09, 2011, 09:22:16 AM »

Hello,

I have not been using Smart Macros for long.  I thought I was doing OK, but then I started running into unexpected results that I don't understand.  I saw some things mentioned in the forum that may relate to my problems but I'm not clear about it all, so I'm looking for further help.  I apologise if any of this is repetitive, but please bear with me.  I hope someone can explain these things so that I understand them.

The problems I'm running into with my macros are in three general areas:  Chained macro conditions, subroutines (in other words, macros triggering other macros), and in-line delays.

First, the chained macro conditions:
Apparently, I don't get this stuff;  When I have chained conditions, I don't know how to control the order that the conditions will be tested, and also I don't know whether more than one macro in the chain will run under any particular conditions.  For example, I have several sets of macros that follow the same template, where the first macro's condition is that it's nighttime and a particular monitored code is OFF, and the second macro's condition is just that the particular monitored code is OFF.  My intended result is for neither macro to execute if the monitored code is ON, only the second macro to execute during daytime when the monitored code if OFF, and both macros to execute at night when the monitored code if OFF.  (A separate code is the trigger for these macros).  Unfortunately, not only can't I get this to work as I want, but I can't even get it to behave consistently from time to time.  Sometimes only one of the macros executes when the conditions are met for both, but it is not predictable as far as which one will execute.  I tried to change the conditions so that the first macro tests for only the monitored code and the second tests for only nighttime, but this also produced confusing results.

So, can someone please explain how chained macro conditions get evaluated?  First of all, what determines the order in which the chained conditions are tested?  (I assumed this would occur in the left-to-right order that they appear in the chain window, but apparently not.  Are they evaluated in the order that the macros were created, instead?)
Second, if the first macro's conditions evaluate as true, does it even test the conditions of the other macros in the chain?  Or, does it test the conditions for EACH of the chained macros, and try to execute ALL of the ones whose conditions are true?
Third, does the system support situations where the conditions for more than one of the chained macros can be true at the same time, or do they have to be designed such that the conditions are all mutually-exclusive?  (If so, how do I do this when there are a maximum of only three conditions available per macro?)  Or, am I totally misunderstanding how to use the conditions?  (I sure am confused!)

Subroutines:

What happens (or should I say, what is SUPPOSED TO happen) when a macro calls another macro?  Does it behave like a subroutine call, where the caller waits while called subroutine executes, or does it try to run both the caller and the called macros at the same time?  I really can't tell what it is doing in these cases, but it looks like things get REALLY fouled up.  Am I not doing this stuff properly?

Delays:
I have trouble with delays not occurring when expected.  This is especially true when a subroutine is involved.  Usually what happens is that it appears to blow right through the delays without producing any delay time between the previous and subsequent commands.  This seems to happen mostly with delays over five seconds.  By accident, I discovered that if two delays exist one right after the other, then things seem to work better.  For example, it may ignore a single nine-second delay, but if I put in a second delay of one second right after the nine-second delay, then I see an effective delay of 10 seconds.  Why is this necessary?  How do in-line delays work, anyway?

I'm VERY confused and frustrated over all this stuff.  Can anyone clear this up for me?

Thanks!
JK
Logged

Noam

  • Community Organizer
  • Hero Member
  • ***
  • Helpful Post Rating: 51
  • Posts: 2818
Re: Questions about macro behavior and work-arounds
« Reply #1 on: December 09, 2011, 01:08:08 PM »

First, the chained macro conditions:
Apparently, I don't get this stuff;  When I have chained conditions, I don't know how to control the order that the conditions will be tested, and also I don't know whether more than one macro in the chain will run under any particular conditions.  For example, I have several sets of macros that follow the same template, where the first macro's condition is that it's nighttime and a particular monitored code is OFF, and the second macro's condition is just that the particular monitored code is OFF.  My intended result is for neither macro to execute if the monitored code is ON, only the second macro to execute during daytime when the monitored code if OFF, and both macros to execute at night when the monitored code if OFF.  (A separate code is the trigger for these macros).  Unfortunately, not only can't I get this to work as I want, but I can't even get it to behave consistently from time to time.  Sometimes only one of the macros executes when the conditions are met for both, but it is not predictable as far as which one will execute.  I tried to change the conditions so that the first macro tests for only the monitored code and the second tests for only nighttime, but this also produced confusing results.

So, can someone please explain how chained macro conditions get evaluated?  First of all, what determines the order in which the chained conditions are tested?  (I assumed this would occur in the left-to-right order that they appear in the chain window, but apparently not.  Are they evaluated in the order that the macros were created, instead?)
Second, if the first macro's conditions evaluate as true, does it even test the conditions of the other macros in the chain?  Or, does it test the conditions for EACH of the chained macros, and try to execute ALL of the ones whose conditions are true?
Third, does the system support situations where the conditions for more than one of the chained macros can be true at the same time, or do they have to be designed such that the conditions are all mutually-exclusive?  (If so, how do I do this when there are a maximum of only three conditions available per macro?)  Or, am I totally misunderstanding how to use the conditions?  (I sure am confused!)
As far as I know, the conditions are evaluated for each tab of the "chained" macro (where each tab represents a macro with the SAME trigger) from left-to-right. If the first one is true, then it executes, and does not go further (I think).
In addition, conditions are ignored if you click on the macro in AHP to run it. You can't test the conditions this way, but you can test the execution of the commands, at least.
In order to test the conditions, you'll need to trigger the macro some other way (like with an RF or PLC remote or transmitter).

Quote
Subroutines:
What happens (or should I say, what is SUPPOSED TO happen) when a macro calls another macro?  Does it behave like a subroutine call, where the caller waits while called subroutine executes, or does it try to run both the caller and the called macros at the same time?  I really can't tell what it is doing in these cases, but it looks like things get REALLY fouled up.  Am I not doing this stuff properly?
It does not act like a subroutine. Both would try to execute simultaneously.
I don't know if it is still this way, but in order to call one macro from another, we used to need to add a "dummy" appliance module in AHP, set to the same HouseCode/UnitCode as the macro. That appliance module is what is called in the first macro, not the second macro itself. That may not be true anymore, though.

Quote
Delays:
I have trouble with delays not occurring when expected.  This is especially true when a subroutine is involved.  Usually what happens is that it appears to blow right through the delays without producing any delay time between the previous and subsequent commands.  This seems to happen mostly with delays over five seconds.  By accident, I discovered that if two delays exist one right after the other, then things seem to work better.  For example, it may ignore a single nine-second delay, but if I put in a second delay of one second right after the nine-second delay, then I see an effective delay of 10 seconds.  Why is this necessary?  How do in-line delays work, anyway?
There was a similar thing that many people noticed early on with macros. The workaround in that case was to place a delay (even a 0-second delay!) at the beginning of each macro. For some reason, that helped things execute more smoothly.
Logged

kenrad

  • Hero Member
  • *****
  • Helpful Post Rating: 3
  • Posts: 198
Re: Questions about macro behavior and work-arounds
« Reply #2 on: December 09, 2011, 08:49:39 PM »

Try looking into a program that is out there called Ihouse.  I was having the same issues and it lets the macros run far more reliably and smoothly and it has no limits to the if or else commands in a macro.  YOu should be able to find it in the third party applications.

 >!Kenrad
Logged

JoKer

  • Jr. Member
  • **
  • Helpful Post Rating: 0
  • Posts: 21
Re: Questions about macro behavior and work-arounds
« Reply #3 on: December 10, 2011, 05:35:14 AM »

As far as I know, the conditions are evaluated for each tab of the "chained" macro (where each tab represents a macro with the SAME trigger) from left-to-right. If the first one is true, then it executes, and does not go further (I think).

That's what I thought, too, but it sure doesn't seem to be working that way most of the time.


Quote
In addition, conditions are ignored if you click on the macro in AHP to run it. You can't test the conditions this way, but you can test the execution of the commands, at least.
In order to test the conditions, you'll need to trigger the macro some other way (like with an RF or PLC remote or transmitter).

Yes, I had a lot of confusion over that before I realized what was going on.  I didn't see it documented anywhere.  Either I'm missing the instructions for this stuff or else it is really poorly documented, because it's been pretty much figure it out by trial and error.  Is this stuff written up anywhere?


Quote
It does not act like a subroutine. Both would try to execute simultaneously.

That seems more or less consistent with what I've been seeing.  Sometimes it does not look like the called macro ever runs, though.

If I need to have the calling macro wait for the called macro to run (i.e. - to behave like a subroutine), how can I do that?  I tried putting a long delay in the caller macro, right after the call of the subroutine macro, but that didn't always work, plus it caused some undesirable side effects, so it wasn't a good work-around.


Quote
I don't know if it is still this way, but in order to call one macro from another, we used to need to add a "dummy" appliance module in AHP, set to the same HouseCode/UnitCode as the macro. That appliance module is what is called in the first macro, not the second macro itself. That may not be true anymore, though.


That's the way I have been doing it.  I didn't see any other way.


Quote
There was a similar thing that many people noticed early on with macros. The workaround in that case was to place a delay (even a 0-second delay!) at the beginning of each macro. For some reason, that helped things execute more smoothly.

A zero-second delay?  (I didn't realize it was possible to set it to zero.  Anyway, I never would have thought to do that).  Does that delay have to go in both the caller and called macros, or just one of them (the called macro?)

I did notice that if I put a delay after the dummy call in the calling macro, then sometimes the called macro seemed to work better, but it was really inconsistent.

Is it just me, or is macro behavior pretty flakey?  I mean, am I doing something wrong, or is it just the nature of the beast to have all these bizarre problems and hassles?
Logged

JoKer

  • Jr. Member
  • **
  • Helpful Post Rating: 0
  • Posts: 21
Re: Questions about macro behavior and work-arounds
« Reply #4 on: December 10, 2011, 05:45:32 AM »

Try looking into a program that is out there called Ihouse.  I was having the same issues and it lets the macros run far more reliably and smoothly and it has no limits to the if or else commands in a macro.

Sounds good!  Have you run into any problems or incompatabilities when using that Ihouse?


Quote
YOu should be able to find it in the third party applications.

Um... third party applications?  Where's that?

Thanks!
Logged

kenrad

  • Hero Member
  • *****
  • Helpful Post Rating: 3
  • Posts: 198
Re: Questions about macro behavior and work-arounds
« Reply #5 on: December 10, 2011, 01:40:18 PM »

Try looking into a program that is out there called Ihouse.  I was having the same issues and it lets the macros run far more reliably and smoothly and it has no limits to the if or else commands in a macro.

Sounds good!  Have you run into any problems or incompatabilities when using that Ihouse?


Quote
YOu should be able to find it in the third party applications.

Um... third party applications?  Where's that?

Thanks!

I use it for everything timers,  macros  and I never have an issue with it.  The program is amazing and even allow for voice recognition and works well with touchscreen as well.  I use it along side Tuicemens PC Companion, and BLuewatch as well

Check this stuff out with can find Ihouse at www.ihousehomeautomation.com and Tuicemen.com  I house if freeware and the Tuicemen stuff is only a small donation found as www.tuicemen.com but trust me you will love this stuff

 >!Kenrad
Logged

JoKer

  • Jr. Member
  • **
  • Helpful Post Rating: 0
  • Posts: 21
Re: Questions about macro behavior and work-arounds
« Reply #6 on: December 10, 2011, 02:18:41 PM »


Check this stuff out with can find Ihouse at www.ihousehomeautomation.com and Tuicemen.com  I house if freeware and the Tuicemen stuff is only a small donation found as www.tuicemen.com but trust me you will love this stuff

 >!Kenrad

Ugh!  It's definitely not my week for computer stuff, I guess:  Everything I could find that might describe Ihouse seems to be in PDFs - and I'm having some problem accessing them.  (Probably some security setting gone haywire, although I think there was a problem last time my reader got updated, so maybe it's that, I don't know.  Anyway, I can't see any of those until I get the PDF stuff fixed).  So, is there any place else I can look in the meantime that will tell me what Ihouse is all about?

Thanks!
Logged

kenrad

  • Hero Member
  • *****
  • Helpful Post Rating: 3
  • Posts: 198
Re: Questions about macro behavior and work-arounds
« Reply #7 on: December 11, 2011, 10:55:09 PM »

just the link I posted above

Cheers Kenrad
Logged
 

X10.com | About X10 | X10 Security Systems | Cameras| Package Deals
© Copyright 2014-2016 X10.com All rights reserved.