Print

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

[TakeTheActive]

I've got to give you CM15A/AHP "Old-Timers" credit - this sure is one PITA combo to get working properly...

I've temporarily abandoned my CM11A "Import with New Macros" and started over in a brand new SETUP. I've created *ONE* macro, with *ONE* delay and it worked fine. I added the *SECOND* delay and it REVERSED - just like it does in my CM11A "Import". Here's the macro:

TRIGGER F6 OFF [MS13 Base Code +1]

• B6 OFF [LM15A]
  
• DELAY 5 Minutes
  
• F5 DIM by 30% [LM465]
  
• DELAY 2 Minutes
  
• F5 OFF
  

With only the one 5 Minute DELAY, it works properly. As soon as I add the second DELAY, it excutes the second DELAY *FIRST*, then the first DELAY *SECOND*?!?  This then produces an "Endless Loop" because I'm using the photocell on the MS13 to control the time (F6 OFF). When MS13/F5 ON (RF -> RR501 -> PLC) normally turns on the F5 lamp, the corresponding MS13/F6 OFF starts the macro. It should DELAY 5 minutes, DIM F5 by 30% (signal that time is running out - although the MS13 is set for 4 minutes, it runs for 6), DELAY 2 minutes, F5 OFF (insurance if MS13/F5 OFF RF didn't work).

Instead, MS13/F5 ON turns on the F5 lamp, MS13/F6 OFF starts the macro. After 2 minutes, MACRO F5 OFF turns off the F5 lamp, MS13/F6 turns back ON. After 5 Minutes, MACRO DIM F5 by 30% turns the F5 lamp back on, which causes MS13/F6 OFF RF, which starts another run of the macro. Weird, huh? Never had this much "fun" with the CM11A! Geez, you could make a CAREER out of trying to get this combo to work properly!!

• Since F5/F6 is a MS13 located close by, the CM15A is seeing BOTH the 'Receive RF' from the MS13 and the 'Receive PLC' from the RR501 and triggering the macro twice. [But, I don't feel that is a problem - LOTs of other macros from the CM11A "Import" work fine like this, with RR501s doing the RF-to-PLC conversion instead of the CM15A.]
  .
• I had "Monitored House Code" set to 'F', but changed it to 'C' to see if it mattered - NO.
  .
• I have "Transceived House Code(s)" set to "None" (to STOP the CM15A from converting RF-to-PLC).
  .
• I've unplugged, removed 1 battery, plugged, replaced battery, re-downloaded - NG.
  .
• I always CLEAR INTERFACE MEMORY before DOWNLOAD TIMERS & MACROS - NG.
  

Mr. Sullivan - do you have the time to test this on your setup?  Any ideas or suggestions on something that I've overlooked?

[Charles Sullivan]

Mr. Sullivan - do you have the time to test this on your setup?  Any ideas or suggestions on something that I've overlooked?

I created your macro in AHP, downloaded it to the CM15A, triggered it by sending F6 OFF via a PLC command, and monitored the results with a CM11A  on a separate PC.  It works OK.

Are you seeing the same problem with just PLC triggering (omitting the RF complexity for the time being)?

One difference might be that my version of AHP is different.  It was upgraded to 3.205 when I installed the OnAlert Beta but I don't know if there are any differences other than that required to support the OnAlert plug-in.

I've emailed you the .ahx file from my system.  Let me know if that works any differently.

[Dan Lawrence]

3.205?

Does this version only come with the OnAlert Beta?   I'm running 3.204 and when I click "Check for Update", it returns the message I have version 3.204 and that no upgrade is necessary. 

[Charles Sullivan]

3.205?

Does this version only come with the OnAlert Beta?   I'm running 3.204 and when I click "Check for Update", it returns the message I have version 3.204 and that no upgrade is necessary. 

I assume this would also come if you purchase the released OnAlert.   I haven't seen any notice of a general AHP 3.205 upgrade in this Forum.  I do seem to recall a similar upgrade some months ago for one of the other plug-ins that wasn't a general AHP upgrade.

[KDR]

I got OnAlert about 3 days ago. Just checked my version of AHP and it says 3.206

[JimC]

I have a similar problem as that stated by TTA. I have a Macao that is triggered by a motion sensor. The macro is as follows.
m1 on (motion sensor)
turn L1 on
delay 5 min
turn L1 off
delay 5 seconds
turn L1 off

The macro without the second delay works fine and I had been using it this way for months with no problem other than the light on occasion staying on. I added the second delay and off command to try and help with this. Now the macro executes the second delay first. I had been running the macro for some time without a  problem. It was only after one of the updates, and I don't remember which one, that the problem started.

I had several other macros with a second delay and off command and the problem existed in all of them. I deleted the second delay and off command so that the macros were still usable.

[TakeTheActive]

I have a similar problem as that stated by TTA. I have a Macao that is triggered by a motion sensor.

I think I figured it out - do you have any TM751s or RR501s (or equivalent)? If yes, what HC(s)? What HC is your MS? (M?)

[JimC]

TTA,

For the macro that is causing me problems, the house code of both the motion sensor and the RR501 is set to B.

I have other motion sensors and two other RR501's but they are unrelated to the macro that is having the problem. They are on house codes M and A

[Charles Sullivan]

Hey TTA and JimC:
Are you guys seeing the delay problem when the macro is triggered with a PLC or only when triggered from the motion sensor?  I haven't seen this question answered yet.

[TakeTheActive]

Only RF, and *ONLY* under certain conditions (which I'm still in the process of compiling / verifying)...

[JimC]

Are you guys seeing the delay problem when the macro is triggered with a PLC or only when triggered from the motion sensor?  I haven't seen this question answered yet.

In my case the motion sensor signal gets into the wiring and to the CM15A through the use of a RR501. This then starts a smart macro which turns on a light only if at night and after a preset time turns it back off. I added a second delay and off command just to make sure the light turns off.

[TakeTheActive]

JimC,

Do you have a non-RR501 (TM751, RCA, Stanley, etc...) that you could swap with the RR501 on HC 'B'?

[JimC]

Do you have a non-RR501 (TM751, RCA, Stanley, etc...) that you could swap with the RR501 on HC 'B'?

I have a TM751 that I will try this evening if I get time.

I did try the following with some interesting results.
I made the following macro



Trigger A10
Lamp A11 on
delay 1min
Lamp A11 off
delay 5 sec
Light A11 off

I triggered the macro by presssing A10 on the HR12A and all worked fine. Repeated pressing of the A10 button caused the macro to execute the second delay and skip the first. I let the macro time out and pressed the A10 button once and the macro skipped the first delay and started with the second 5 second delay. This was repeatable. The only way to get this macro to work correctly again was to use the "purge delayed macro " function under tools on the menu bar. I tried this several times and the result was the same ...If I pressed the A10 button more than once the macro started with the second delay and any attempt to trigger the macro again even after waiting several minutes resulted in the second delay being executed first.

[Charles Sullivan]

Do you have a non-RR501 (TM751, RCA, Stanley, etc...) that you could swap with the RR501 on HC 'B'?

I have a TM751 that I will try this evening if I get time.

I did try the following with some interesting results.
I made the following macro



Trigger A10
Lamp A11 on
delay 1min
Lamp A11 off
delay 5 sec
Light A11 off

I triggered the macro by presssing A10 on the HR12A and all worked fine. Repeated pressing of the A10 button caused the macro to execute the second delay and skip the first. I let the macro time out and pressed the A10 button once and the macro skipped the first delay and started with the second 5 second delay. This was repeatable. The only way to get this macro to work correctly again was to use the "purge delayed macro " function under tools on the menu bar. I tried this several times and the result was the same ...If I pressed the A10 button more than once the macro started with the second delay and any attempt to trigger the macro again even after waiting several minutes resulted in the second delay being executed first.

OK, I can duplicate this.  With the PalmPad it doesn't require two presses, only holding down the button a little longer than a quick tap.  What I'm then seeing is the second event executing at time 0 + delay 2, then the first event executing at time 0 + delay 1, then second event executing again at time 0 + delay 1 + delay 2.

This appears to be a firmware bug since the same problem is observed with the USB cable unplugged.

A workaround for this problem (presuming you have the SmartMacro plug-in) is to condition the macro to trigger only if a flag is unset, then set the flag as the first step in the macro and unset it as the last step.  I tried this and it seems to work even when triggered by holding down the button on a PalmPad.

[TakeTheActive]

OK, I can duplicate this.  With the PalmPad...

What's your PalmPad "talking" to (RF)?