Print

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

[JimC]

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. 

[Charles Sullivan]

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.

[TakeTheActive]

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. 

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??? 

 

[TakeTheActive]

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)...

[Charles Sullivan]

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.)

[JimC]

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.

[TakeTheActive]

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...

[Charles Sullivan]

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.

[JimC]

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.

[Charles Sullivan]

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.)

[JimC]

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. 

[TakeTheActive]

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?

[Dan Lawrence]

I'd say to do nothing. Leave the threads as the are.  Those 3 posts don't add or detract.

[TakeTheActive]

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 »

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?

[JimC]

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.