X10 Community Forum
🖥️ActiveHome Pro => ActiveHome Pro General => Software Problems & Bugs => Topic started by: TakeTheActive on September 15, 2006, 04:10:49 PM
-
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?
-
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.
-
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.
-
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.
-
I got OnAlert about 3 days ago. Just checked my version of AHP and it says 3.206
-
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.
-
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?)
-
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
-
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.
-
Only RF, and *ONLY* under certain conditions (which I'm still in the process of compiling / verifying)...
-
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.
-
JimC,
Do you have a non-RR501 (TM751, RCA, Stanley, etc...) that you could swap with the RR501 on HC 'B'?
-
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.
-
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.
-
OK, I can duplicate this. With the PalmPad...
What's your PalmPad "talking" to (RF)?
-
Thanks, Charles I do have the smart macros. I tried the flags as you suggested and it worked for me. I will try incorporating this into some of my problem macros. :D
-
OK, I can duplicate this. With the PalmPad...
What's your PalmPad "talking" to (RF)?
I'm triggering the macro via RF directly to the CM15A. (My V572A transceiver is unplugged).
Hmm... I haven't tried RF directly to the CM15A _plus_ transceived PLC signal.
-
Thanks, Charles I do have the smart macros. I tried the flags as you suggested and it worked for me. I will try incorporating this into some of my problem macros. :D
The "problem" is the RR501 - would you mind testing the TM751 *BEFORE* you modify all your macros?
BTW, I thought that you didn't have "time" until this evening??? :o
:)
-
I'm triggering the macro via RF directly to the CM15A...
Hmm... I haven't tried RF directly to the CM15A _plus_ transceived PLC signal.
Well, what I was going to post, before you STOLE my thread, was that, IMO, the CM15A has a TIMING PROBLEM with the RR501. Add this to the fact that no matter what you set in Hardware Configuration for "Transceived Housecode(s)", the CM15A *ALWAYS* transceives RECEIVES everything (and displays it in the Activity Log) *AND* it *ALWAYS* TRANSCEIVES AND triggers macros (AFAICT, it doesn't control modules when the "Transceived Housecode" is not set).
Anyhow, I'll write this up in my FAQ later on...
UPDATED: Wording (for Charles)...
-
I'm triggering the macro via RF directly to the CM15A...
Hmm... I haven't tried RF directly to the CM15A _plus_ transceived PLC signal.
Well, what I was going to post, before you STOLE my thread, was that, IMO, the CM15A has a TIMING PROBLEM with the RR501. Add this to the fact that no matter what you set in Hardware Configuration for "Transceived Housecode(s)", the CM15A *ALWAYS* transceives everything (and displays it in the Activity Log) *AND* it *ALWAYS* triggers macros (AFAICT, it doesn't control modules when the "Transceived Housecode" is not set).
Anyhow, I'll write this up in my FAQ later on...
No, that's not correct. If the transceived box is unchecked, the CM15A does NOT transceive. However the Activity Monitor will still display the received RF signal. ("Transceiving" means to transmit the PLC corresponding to the received RF, regardless of what appears in the AM.)
It IS true that RF will trigger macros regardless of whether the transceived box is checked or unchecked.
(You need to install that "sofware which will not be named" on one of your systems so you can see what's really happening. And if you have a MR26A in that collection of yours, you can see the raw RF signals too.)
-
BTW, I thought that you didn't have "time" until this evening???
The particular macro I was talking about that uses the RR501 also uses smart macros and is set not to run until after dark. So therefore if I have time this evening I will replace the RR501 with the TM751. I will do this before I modify this particular macro. My test posted above did not require the use of any of the transceivers other than the CM15A.
-
No, that's not correct. If the transceived box is unchecked, the CM15A does NOT transceive. However the Activity Monitor will still display the received RF signal. ("Transceiving" means to transmit the PLC corresponding to the received RF, regardless of what appears in the AM.)
It IS true that RF will trigger macros regardless of whether the transceived box is checked or unchecked.
Yes, you're right - I'm sorry. I rushed and didn't 'proofread' it thoroughly. :-[
I went back and corrected my error...
(You need to install that "sofware which will not be named" on one of your systems so you can see what's really happening. And if you have a MR26A in that collection of yours, you can see the raw RF signals too.)
What are you - a "Peeping Tom"? How'd you know that I have a MR26A? Hmmm...
No, Mama's *VERY* upset with the performance of the CM15A (and she doesn't even know about it ;) ) so unless I want to keep hearing her yell "HEY YOU! The da*m light(s) came ON / went OFF *AGAIN*!" , I'll have to keep plugging with this AHP. Geez, I might even have to break down and (gasp!) REGISTER it *BEFORE* I get all the CM11A functionality transferred so that I can add the ?SMART? Macros. [The current HC50RX in the kitchen is missing some RF transmissions (not in the CM15A log - I walked upstairs and kicked off 3 MS's a minute or so apart) and sometimes it's PLC is not getting back to turn the BR Closet Light ON (and you *KNOW* that's not going to sit well with Mama), so I'd like to restore the existing RR501 back into service soon.]
[BTW, the program crashes that I described in my Winternals... thread have disappeared since I'm now only running 1 or 2 macros.]
About the MR26A, I have to install a more current "noname OS" *BEFORE* I can see the raw RF data, right? Now I'm using a HC60CRX with AH v1.32 with all of the macros deleted from the "tried-and-true" / DEPENDABLE setup. Too bad the log fills up so fast (especially when the CM15A loses "Collision Detection"). I can't remember the exact details, but v1.40, 1.41 and 1.42 all had some kind of problem with Win98SE on the Toshiba 550CDT laptop...
-
About the MR26A, I have to install a more current "noname OS" *BEFORE* I can see the raw RF data, right? Now I'm using a HC60CRX with AH v1.32 with all of the macros deleted from the "tried-and-true" / DEPENDABLE setup. Too bad the log fills up so fast (especially when the CM15A loses "Collision Detection"). I can't remember the exact details, but v1.40, 1.41 and 1.42 all had some kind of problem with Win98SE on the Toshiba 550CDT laptop...
You can view the raw output from the MR26A with any program which can display the incoming data on the serial port as hex bytes. (9600 bps, 8-N-1, no handshake). It's just that the other OS includes a utility which converts bin->hex and enables formatting the output in 5 columns for easy reading.
If you find such a program for Windows, you may need to connect the MR26A via a USB->Serial adapter to use it at the same time as AHP - the x10net driver seems to take control of all serial ports.
-
Substituting the TM751 for the RR501 made not difference. The problem was the same with either.
The test macro I ran before and reported the results on used neither the RR501 nor the TM751 and it had the problem.
I would think from that it would be safe to say , as Charles stated earlier, the problem is in the CM15A. :(
Fortunately the flag work around does work. :)
-
Substituting the TM751 for the PR501 made not difference. The problem was the same with either.
The test macro I ran before and reported the results on used neither the PR501 nor the TM751 and it had the problem.
I would think from that it would be safe to say , as Charles stated earlier, the problem is in the CM15A. :(
Fortunately the flag work around does work. :)
I'm seeing a difference.
I tried adding either a TM751 or a RR501. In both cases TTA's macro was triggered with an RF F6 Off. The CM15A Transceived Housecodes was set to "None". With the TM751 the macro operated correctly several times in a row. With the RR501 the macro failed several times in a row (with Tools>Purge delayed macros clicked between failures). TTA's macro had the two delays set to 1 minute and 10 seconds respectively, so I didn't have to wait all day for the results. My RR501 has date sticker 04A03.
Given the apparent CM15A firmware bug, this is probably to be expected - the RR501 is "polite" and doesn't send its PLC until after the first macro event. The TM751 is "rude" and sends immediately, and in this case the CM15A politely waits until the TM751's signal has cleared from the power line before executing the macro. (It would appear that the RR501 is more polite than the CM15A.)
-
I did some more testing later last night and found that with the RR501 the macro failure was very repeatable. With the TM751 plugged in failure seemed to be a matter of timing and was not at all repeatable until it failed. Once it failed, if the " purge delayed macros" was not used the problem became very repeatable.
I would have did more on this last night but the grandchildren were staying over and wanted my attention. They will win out over AHP every time. ;D ;D
-
I did some more testing later last night and found that with the RR501 the macro failure was very repeatable. With the TM751 plugged in failure seemed to be a matter of timing and was not at all repeatable until it failed. Once it failed, if the " purge delayed macros" was not used the problem became very repeatable.
Thanks for looking / experimenting further, JimC and Charles. I was concerned that everything was going to stop at the 'Smart Macro Flag Workaround' and the true underlying problem would never be fully fleshed out and agreed upon.
From my observations, it appears that the occurrence of the first failure depends on whether the CM15A sees the original (MSxx) RF or just the resulting RR501/TM751 PLC. (In my mind, this also correlates with the fact that the CM15A *ALWAYS* processes RF Macro Triggers, but not RF Module Commands.) Also, if you look closely at the Activity Monitor log, X10 commands CANNOT possibly work the way some of them are being reported as being processed, time-line-wise. [I wish the log were just a plain .TXT file that I could simply Cut-N-Paste examples from, but it's a .HTML. Later on I'll try re-loading it into a browser, saving as .TXT and then displaying it here as COURIER and see how it looks...]
Another difference, for me, is that once the failure occurs "Purge Delays Macros" doesn't help; sometimes even "Clear Interface Memory" and "Download Timers & Macros" doesn't and I end up doing the "CS Reset".
The problems with the CM15A are certainly challenging. Unfortunately for us, they should have been challenges for the X10 Programmers and *NOT* the X10 Users. But, this is the current situation and we are not going to change it any time soon. That's why I'm compiling my two BUG threads - to get myself a "mental picture" of what went before. Have either of you read them yet?
-
I'd say to do nothing. Leave the threads as the are. Those 3 posts don't add or detract.
-
I did some more testing later last night and found that with the RR501 the macro failure was very repeatable. With the TM751 plugged in failure seemed to be a matter of timing and was not at all repeatable until it failed. Once it failed, if the " purge delayed macros" was not used the problem became very repeatable.
Everyone:
Does anyone else have the resources and time to repeat this experiment?
I left the RCA HC50RX in place (instead of the RR501) and after a day with no problems, I'm seeing the same as what JimC reported - once it fails, it then fails repeatedly. I'm bumping the DELAYS up by 1 second each day to see if that makes a difference...
A side note is that my ActiveHm.Exe CRASHES,
[HELP] Any Winternals/SysInternals Gurus Here??? (Read 164 times) - Posted: « on: 2006-09-14, 22:35:39 » (http://www.x10community.com/forums/index.php?topic=10171.msg58628#msg58628)
appear to be very closely tied to these BUGs that I'm (as a CM15A Newbie) just discoverering (i.e. ActiveHm.Exe doesn't seem to CRASH / go to 99% CPU Utilization *UNTIL* after one of these BUGs surfaces).
Charles & JimC:
Does the FLAGS Workaround that Charles posted work 100% of the time?
-
Does the FLAGS Workaround that Charles posted work 100% of the time?
I have not had time to implement it in my macros yet but it did work 100% of the time in my test macro. I see no reason that it should not work provided AHP allways recognizes the flags.
OK if I delete the last three (nonsense, IMO) posts? [along with my original P.S.]
I took care of my two. If you find another feel free to delete.
-
A side note is that my ActiveHm.Exe CRASHES,
On occasion so does mine. I have learned to save often when making changes to macros.
-
For what it is worth, since I installed the V572A and removed all of my other transceiver modules I have not had any problems with macros executing out of order. I also have set all house codes in AHP to not be transceived although using the test macro did not show any problems with the house codes enabled.