Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[pomonabill221]

Well.... I have noticed a problem when I run a simple macro.
The macro is:

P12 on (trigger)
G16 on (a hot water recirc pump)
delay 10 minutes
G16 off

Simple enough huh?
Well I noticed that when the macro starts (monitoring using an XTBM), the code that is sent is Gxx NOT G16 on!!!
This results in the pump not turning on.
IF I add a 1 second delay at the beginning of the macro, IT WORKS!!!  I see G16 ON on the XTBM and the pump turns on.  IE:

delay 1 second
G16 ON
......

Is anyone else having this problem?
I also used this "technique" to solve another macro that was running in a loop when triggered.  It used a PR511 flood motion light to trigger.
G2 off  (trigger)
J1 off
J4 off
G10 off
  Without any delays, the macro would call itself and loop!
  Activity monitor showed G10 off as "bike parking/back yard motion"!!!  It should have been "bike parking" only!!!
  The "back yard motion" part would call itself and loop, even though the bike parking was G10 and the back yard motion was G2!!!   
  I solved this by adding a couple of second delays between each step, and the problem went away. 
  I proved this by removing power from the CM15a when the loop was running and it stopped.  I did this because I thought originally, that the motion detector was going nuts, but it was the macro! 
  The activity monitor was my first clue. 
  I don't know why the activity monitor showed that the G10 off was interpreted as bike parking AND back yard motion?
  A possible bug??

[Noam]

I guess you can call this a bug if want, but it has been there from the beginning.
There are plenty of posts here that advise adding a delay (it can even be a 0 second delay!) at the beginning of your macros, to improve reliability. I do this with my own macros, too.

When AHP executes a macro that turns on or off several devices on the same housecode, it tries to be efficient, and group those commands together. For example, if you have a macro that turns on C2, C3, and C4, you would see:

C2
C3
C4
C On

in the activity log, instead of :

C2
C On
C3
C On
C4
C On

If you add a delay (again, you can set it for "0", but it has to be in there somewhere), it forces AHP to send each one as a distinct command, which may prove to be more reliable for you.

[pomonabill221]

Oh sorry... I do remember seeing something about adding delays, but I didn't realize that this is what it was for, or that it would effect my macro this way.
So this would apply to even a single unit (like my macro)?
Well I will remember to add a "0" time delay just to prevent this from happening!
Thanks for the info!

[Noam]

Yes, even a macro that runs a single command.
For some reason, a delay at the beginning of the macro makes a difference. I'll have to ask the developers about that one.

[Tuicemen]

Yes, even a macro that runs a single command.
For some reason, a delay at the beginning of the macro makes a difference. I'll have to ask the developers about that one.

While mentioning that have them hard code the delay then user won't need to worry about it!
Of coarse that will affect all us long time users which the current Developers often fail to recognize.
 

[Noam]

Yes, even a macro that runs a single command.
For some reason, a delay at the beginning of the macro makes a difference. I'll have to ask the developers about that one.

While mentioning that have them hard code the delay then user won't need to worry about it!
Of coarse that will affect all us long time users which the current Developers often fail to recognize.
 

Instead of hard-coding the delay, why not just fix the problem?

[Tuicemen]

Hardcoding would fix it!.
As would hardcoding send action after each addressed module.
In any case the code needs to be changed!

[Noam]

I asked them about it. I'm still going back and forth with them, but the way I understand it so far, a delay (even a 0-second one) gives the CM15A a moment to "take a breath" during the execution of the macro. I've asked about hard-coding it, as well as maybe giving the option on a per-macro basis, to execute each command separately.
"Stacking" commands together is nice if you want a bunch of lights to come on at the same exact moment. Ideally, they SHOULD respond properly, but sometimes some modules (I've seen this with modules from other manufacturers) don't respond correctly to stacked commands.

[pomonabill221]

  I agree about hard coding a very short delay at the beginning of a macro.
  I AM impressed at how fast a macro runs!  I am used to the Smarthome's 1132CUP interface.  It is substantially slower, and the delay is adjustable, but the minimum is 400ms, and that is even longer than necessary.
  I just need to remember to add a 0 second delay at the beginning of any macro that I make, and add a delay between each step within a macro, to eliminate problems.
  It would be a VERY nice feature to be able to adjust a "default" delay for macro's in the hardware preferences, that would force a short delay if no delays are added to macros.  This would eliminate these problems.  The delay would not show up in the macro, but would be there when it is executed.
  This would help with "memory challenged" people like me! 
  It must be a marginal problem because I have other macros that run without delays.  hhmmmm...
  Could this problem be mentioned in a sticky somewhere (or is it already there)?  I did see it in passing in another thread, but it didn't "stick" in my brain.