Print

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

[Brian H]

The transmit antenna in a CM15A is a separate wire wrapped around the inside top piece of the case. Held on by what looks like hot glue.

The receive one is also a piece of wire. Threaded inside the external plastic tube. Unless X10 changed someting. About half of the receive antenna wire is also inside the case.  My early ones where in a random ball of knots. The later ones are at least wrapped neatly around the lower case and held again by the hot glue.

[Noam]

...and the gibberish in the AHP logs at times.

Can you give us an example of the "gibberish"? That might help us figure out where it is coming from.

You had mentioned motion sensors in your first post. If you aren't using X10's RF motion sensors, what ARE you using to trigger your macros?

The floodlight sensors - PR511, I believe.

I don't know if those are "polite" or not. I don't have one myself. Perhaps someone else here has that answer.

... The wire acts as a "reflector", which helps to "catch" the RF signals, and "bounce" them to the CM15A's antenna. (aprdon my simple terminology, I'm not an engineer). Most people see at least *some* improvement, and some have reported amazing results with this very simple mod.

Interesting!  I take it the added antenna does not hurt the CM15A's transmitter?  (Probably fouls up the FCC certification... but who's telling!  )

Nope. As Brian said (WHILE I was typing my response), The CM15A has separate antennas for transmitting and receiving. The external one is the receiving antenna.

Well, the TM751's (if you have any left) might still be causing problems. In fact, Any time you have multiple transceivers putting the same RF signals on the powerline, you have the potential for problems. Even double-triggering of a macro can wreak havoc, as the devices try to respond to a doubled set of commands.

I don't think there are any... if there are, then they'd only overlap one House Code (each), not the entire 16 House Codes... and here, they would be on House Codes that are not part of the camera system anyway.

Unless they are on separate power lines, ANY transmissions from a TM751 (on any house code) will step on a simultaneous transmission on the powerline.

My macros shoudn't be double-triggering -er, well, double-executing- because the motion sensor response macros' conditions use monitored House Code units to "lock-out" re-entrant execution.  Specifically, the response macros' test for a monitored code that goes with a "zone indicator" light specific to the respective motion sensor;  if the unit is already On, then the macro's condition is not met (so it does not re-execute).  Otherwise it does execute and immediately sets the unit On.  When the motion sensor sends its Off command another macro turns the unit off and thus allows the next On command to execute the macro.  Assuming the macros behave, this would prevent a given macro from executing more than one instance at a time.

I guess we would need to see a sample of what you are seeing in the Activity Monitor.
If the CM15A is picking up the signals from the PR511's, but isn't running the macros, that would lead us down a different path than if it isn't even seeing those commands at all.

Also, in case you weren't aware of it, conditional macros ignore all conditions when you manually trigger then from within the AHP interface. To properly test, you need to introduce the trigger signal some other way (like with a PalmPad, or another controller - or with the actual trigger device).

[MD Corie]

As Brian said (WHILE I was typing my response), The CM15A has separate antennas for transmitting and receiving. The external one is the receiving antenna.

That's good (I guess ) although I think there may be more need for increased transmission range than reception range here, anyway... because the "inputs" are via PLC.

Unless they are on separate power lines, ANY transmissions from a TM751 (on any house code) will step on a simultaneous transmission on the powerline.

Duh!  (I guess that's what happens when I try to think while I'm half asleep!  )

I guess we would need to see a sample of what you are seeing in the Activity Monitor.
If the CM15A is picking up the signals from the PR511's, but isn't running the macros, that would lead us down a different path than if it isn't even seeing those commands at all.

You're referring to the AHP log file?  If so, I don't have any saved (being such nonesense), and I'd have to capture some.

But, I'm puzzled:  Wouldn't the proper approach be to first understand the behavior/interaction of macros, as well as what commands are actually recorded in the logs (i.e. - "real" versus "virtual") - so that knowledge can be used to decipher the messes that show up in the log files?

Also, in case you weren't aware of it, conditional macros ignore all conditions when you manually trigger then from within the AHP interface. To properly test, you need to introduce the trigger signal some other way (like with a PalmPad, or another controller - or with the actual trigger device).

Painfully aware of that... it's one of my pet peeves about macro debugging!  Right up there with my peeve about having to re-download "Run in Interface" macros in order to test them...
 

In fact, that raises a good question:  How do things foul up when the version of a macro that's in the interface's memory differs from the version of the macro that's in the PC's memory? (It's not clear from my observations as to even which copy executes in such cases... but clearly it makes something unhappy!)

[Noam]

As Brian said (WHILE I was typing my response), The CM15A has separate antennas for transmitting and receiving. The external one is the receiving antenna.

That's good (I guess ) although I think there may be more need for increased transmission range than reception range here, anyway... because the "inputs" are via PLC.

What commands are you SENDING via RF from the CM15A?

I guess we would need to see a sample of what you are seeing in the Activity Monitor.
If the CM15A is picking up the signals from the PR511's, but isn't running the macros, that would lead us down a different path than if it isn't even seeing those commands at all.

You're referring to the AHP log file?  If so, I don't have any saved (being such nonesense), and I'd have to capture some.

But, I'm puzzled:  Wouldn't the proper approach be to first understand the behavior/interaction of macros, as well as what commands are actually recorded in the logs (i.e. - "real" versus "virtual") - so that knowledge can be used to decipher the messes that show up in the log files?

You're assuming that someone here KNOWS the logic involved in how the CM15A processes multiple macro commands. As I've said, we are (nearly) all users, who volunteer our time to help each other out. While there are X10 employees (the developers included) who have access to these forums, they don't spend their days monitoring the forums, and it is a rare occasion when then chime in on a discussion. In the past I've asked them to get involved in specific discussions, as I have done here. I haven't heard anything back yet, though.
Unless you've cleared the AHP Activity Monitor, you should be able to open it, and export it to HTML.
You can then copy and paste (cleaning up the formatting would be helpful for us here, if you can) into a post here.
What you SHOULD be seeing is the trigger (from the floodlight), followed by the commands in the macro executing.
If you can show us the other "garbage," we might be able to help you determine where it is coming from, and maybe figure out a way to eliminate it.

Also, in case you weren't aware of it, conditional macros ignore all conditions when you manually trigger then from within the AHP interface. To properly test, you need to introduce the trigger signal some other way (like with a PalmPad, or another controller - or with the actual trigger device).

Painfully aware of that... it's one of my pet peeves about macro debugging!  Right up there with my peeve about having to re-download "Run in Interface" macros in order to test them...
 

In fact, that raises a good question:  How do things foul up when the version of a macro that's in the interface's memory differs from the version of the macro that's in the PC's memory? (It's not clear from my observations as to even which copy executes in such cases... but clearly it makes something unhappy!)

Again, I don't have that answer for you. Your best bet after making a change is to download it and test it using another signal source to trigger it.

[MD Corie]

You're assuming that someone here KNOWS the logic involved in how the CM15A processes multiple macro commands. ...
Unless you've cleared the AHP Activity Monitor, you should be able to open it, and export it to HTML.
You can then copy and paste (cleaning up the formatting would be helpful for us here, if you can) into a post here.
What you SHOULD be seeing is the trigger (from the floodlight), followed by the commands in the macro executing.
If you can show us the other "garbage," we might be able to help you determine where it is coming from, and maybe figure out a way to eliminate it.

I regularly clear the Activity Monitor - because it avoids having to go back and figure out where the latest test session starts (because it's hard enough to trace through when I know where the session starts ).

Anyway, I'm just saying that once multiple macros start running, there is so much inconsistency and nonsense showing up in the log that I'd need some idea of how the processing occurs to even start trying to figure out whether the logged commands are consistent with that.  I also don't know whether to expect to see "real" or "virtual" commands logged - or both.  Sometimes it seems that it's one way, other times not...

Just to clarify, though:  So long as only one macro gets triggered at a time, the log very nicely reflects only the commands that result from the execution of said macro.  The nonsense shows up only when another macro gets triggered while one is already running... and then things often become totally untracable.  It seems plausible that this stuff may be the consequence of collisions -due to two macros sending commands at about the same time or whatever- because things can get really bizarre - like commands that don't exist in any of the macros nor would be issued from any of the hardware involved.  But, without knowning just what the log would record in such cases, it's really hard to tell anything for sure.

Again, I don't have that answer for you. Your best bet after making a change is to download it and test it using another signal source to trigger it.

It appears that it does need to be downloaded (so that everything matches) in order to test the changes.  Unfortunately, this is a real time-waster when iteratively trying to work out a kink in some macro.  Oh, well...

[dave w]

Just to clarify, though:  So long as only one macro gets triggered at a time, the log very nicely reflects only the commands that result from the execution of said macro.  The nonsense shows up only when another macro gets triggered while one is already running... and then things often become totally untracable.  It seems plausible that this stuff may be the consequence of collisions -due to two macros sending commands at about the same time or whatever-

$0.02
"Collisions" is a term to describe two X10 commands transmitted by two different X10 transmitting devices putting commands on the homes powerlines at the same time, thus corrupting each other. Obviously this requires at least one "impolite" X10 transmitter in the equation (i.e. a TM751).

IMHO "collisions" created by the CM15A trying to send multiple commands at the same time, is absolutely impossible. One reason is because all X10 commands are serial, and sequential.  The CM15A powerline interface circuitry can only send one command at a time, and I must assume the running program handles that internally, correctly. I have seen NO comments from any users that would hint otherwise, which obviously would indicate a serious software bug. Software wonks like Noam, Tuicemen, and many others on the forum can confirm or correct me. But, you are not the only user that has the possibility of more than one macro executing at the same time. I think you are making incorrect assumptions about "internal collisions" which is leading you astray.

As a side rabbit trail: I use Homeseer which requires a computer running the program 24/7. Homeseer feeds all X10 commands to a cache for serial transmission. I have "events" (what Homeseer calls a macro) that sends 68 X10 "OFF" commands which obviously takes over a minute to run, hence the requirement to move X10 commands waiting to be fed to the powerline interface to be buffered, so Homeseer can go back to running the main program.

I have no idea how AHP works, especially when the limited memory CM15A is running standalone mode. It *might* be that the CM15A does have to "hold" when it must transmit X10 commands. Have you tried running everything from the computer?   

[Noam]

Just to clarify, though:  So long as only one macro gets triggered at a time, the log very nicely reflects only the commands that result from the execution of said macro.  The nonsense shows up only when another macro gets triggered while one is already running... and then things often become totally untracable.  It seems plausible that this stuff may be the consequence of collisions -due to two macros sending commands at about the same time or whatever- because things can get really bizarre - like commands that don't exist in any of the macros nor would be issued from any of the hardware involved.  But, without knowning just what the log would record in such cases, it's really hard to tell anything for sure.

Here's my suggestion:
1. Clear the Activity Monitor, then trigger one macro at a time, to get a "clean" log of each macro's events. Safe out that log to a file (I suppose you could save it out, and then clear it separately for each macro  - that's up to you).
2. Clear the log again, and try to replicate a real-world scenario of multiple macros triggering in sequence. Save THAT out to a file.
3. Post the files here, with a description of what each one is, and we can take a look at them.

You keep mentioning "garbage" and "nonsense" in the logs, but you haven't given us any examples. Are these commands that don't look like valid X10 commands? Are they *actual* gibberish (random numbers, letters, etc)? Are they *valid* commands, but are not supposed to be running at that time?

One other thought I had was that perhaps a neighbor of yours also has X10, and has their own macros that share some of the same trigger codes as yours. Your macros firing (or maybe the devices that the macros are controlling) might be causing some of their macros to run, sending back commands you don't expect. It is pretty unlikely, but you never know. (Dan is probably going to chime in here with a comment that it is such a remote possibility because X10 was never mass-marketed. )

It appears that it does need to be downloaded (so that everything matches) in order to test the changes.  Unfortunately, this is a real time-waster when iteratively trying to work out a kink in some macro.  Oh, well...

For testing you might try changing the macro so it is set to "run from PC", and then re-downloading one time (which should clear the macro from the CM15A). You can then make more changes, and test, and then change it back to "run from interface" and download when your testing is complete.

One other thing I thought of. I don't have a PR511, but I looked up the instructions (http://software.x10.com/pub/manuals/pr511-om.pdf). It looks like it has the ability to send on/off commands to four different Unit codes based on motion sensing, and then a separate 4 codes based on dusk/dawn. Are you (intentionally or not) using any of those other codes? Might some of those be triggering other macros or modules unintentionally? Is it possible that the lights are aimed such that the light from one floodlight (or reflected off a surface) is fooling the dusk/dawn sensor into thinking it is daytime?

You *might* be able to test that my temporarily disabling the macros (either by changing their HC/UC to one that is DEFINITELY not being used, or by creating a temporary "blank" AHX file, and downloading it to the CM15A), and then watching the activity Monitor as you try a "real world" test of triggering the motion sensors (just looking at what they do, and when, without any macros to muddle things up).

[HA Dave]

"Collisions" is a term to describe two X10 commands transmitted by two different X10 transmitting devices putting commands on the homes powerlines at the same time, thus corrupting each other. Obviously this requires at least one "impolite" X10 transmitter in the equation (i.e. a TM751).
IMHO "collisions" created by the CM15A trying to send multiple commands at the same time, is absolutely impossible.

I agree. However.... the OP in this case is using Floodlights (PR511)... which can send up to 4 impolite PLC's per motion sensing. I don't know how many Floodlights are in use... but since the OP is switching 16 cameras... I would guess more than 1 floodlight.

[dave w]

I agree. However.... the OP in this case is using Floodlights (PR511)... which can send up to 4 impolite PLC's per motion sensing. I don't know how many Floodlights are in use... but since the OP is switching 16 cameras... I would guess more than 1 floodlight.

I'm not sure, but since the PR511s have X10 transmit and receive capabilities, I think they are polite.
But MD is concerned that CM15 running two macros at same time is creating collisions....

[HA Dave]

..... MD is concerned that CM15 running two macros at same time is creating collisions....

Yeah... I can't imagine the CM15A tripping on itself.... I've never seen it.

[dave w]

..... MD is concerned that CM15 running two macros at same time is creating collisions....

Yeah... I can't imagine the CM15A tripping on itself.... I've never seen it.

No, I don't think it possible either. I think MD has much simpler problem that he isn't recognizing. His posts indicate the Activity Monitor is full of garbage, making him think the CM15A is trying to send multiple commands at the same time. That would be a software/hardware problem that would quickly be evident to all users, developers, and forum members. But I guess MD does not see it that way.

[MD Corie]

Wow!  Lots to reply to...  So, rather than trying to quote everyone, I'll just list my replies here that refer back to others' comments:

"Collisions":  I'm using this term rather loosely to describe any potential command collisions, whether they be hardware collisions in the PLC, or virtual command collisions somehow caused when multiple macros run at the same time - as seems to be implied by the logging that I've tried to decipher.  The possibility that stands out to me from these observations is because it sometimes looks like parts of a command from one macro are mingled with part or all of a command from another macro, it may be that conncurrent macros are somehow overlapping the discrete portions of their PLC commands.  This is the "gibberish" that I am referring to:  Not only are commands not occuring in the expected sequence, there are places where it looks like only half of a command pair is in the log, or it may be "split", with other commands being logged between the first and second part of a command.  (I'll emphasize that this is only speculation, since the stuff I saw is really hard to follow).  There is no "garbage characters" in the log, as far as I can tell - only "garbage commands".  My best guess may be that something is getting corrupted somehow, and the logging facility is mis-interpreting it as some other command... otherwise, it's just utter nonsense or literally random commands flying around.  And, yes, I will try to capture some examples to pass along, when time permits.

I make no claims about why this stuff occurs;  but it is obviously associated only with more than one macro running at a time... and I'm trying to figure out why.  Maybe my macros are bogus;  maybe my CM15A is fouling up; maybe AHP is fouling up; maybe there are PLC collisions that the log file (and the X10 devices) mis-interpret as something other than what they are... I really don't know.... it is all guesses at what may be going on here.

(By the way, would AHP or SmartMacros foul up if AHP logical devices have not been defined for each and every House/Unit Code used in the macros, or if more than one logical device exists for the same House/Unit Code, or if the logical device is not exactly the same device as the corresponding physical device?  (Due to revisions in my AHX, it is possible that some or all of these conditions exist, although I'm not specifically aware of any).)

Generally, I have not tried running everything from the PC;  that is mainly because the ultimate intention is to run everything stand-alone in the CM15A, so doing it on the PC may allow subtle differences to creep in - such as PC-only commands, or memory issues, or flag issues, or timing issues, or other unexpected glitches/nuances.  For a general troubleshooting effort, it would be worth a try - but I haven't done that as a matter of course because I figured it might introduce needless time-wasting execution-time problems.  (Of course, there are time-wasting development-time problems doing it the other way, so who knows which is better).

I have about a dozen PR511 Motion Sensors in use; they are configured for 24/7 operation, and do not have the dusk/dawn output codes enabled at all.  After going to AHP/SmartMacros, each PR511 is set to issue only one (unique) output code - although I suppose it is possible that there might be a problem with the device(s), or an overlooked setting switch, where some other code could be issued, too - but I have not seen any evidence of that during individual testing.  One thing that is a nagging question is whether having one PR511 issuing the base code of another PR511 would cause one of them to foul up somehow - but again, I have not seen any indication of that while testing "individually".

Actually, I was thinking myself of that deal to strip out everything from AHP and from the CM15A, and just run tests with the Monitor enabled, and see what goes on.  I was wondering whether the Log would work right if there were no logical modules defined, though.  Anyway, I have not done that, and I'm becoming less convinced that it is worth the effort the more I think about it... but it may still come to pass.

When I have logged the results of the single macros, they generally show as running exactly as prescribed in the macro definitions.  When two macros run at once, all bets are off:  The log shows commands that seem to be properly formed, but tend to be out of sequence in various ways - like delays that don't work, commands that seem to be bogus (based on the text placed in the log), macros that stop in the middle and never finish, and "split pairs" of commands.  It all becomes untracable, as far as I can see.

As for a neighbor having conflicting X10 commands, I tend to doubt that for several reasons:  There are no nearby neighbors; we have our own line transformer (nobody else feeds from it), there is some isolation filtering on the incoming line, I have never detected spurious commands when I am not using the macros, and the Find Other Computers has never reported any "foreign" stuff.

As for TM751's, I have confirmed that there is only one now in the system - and it is used only to control lights in a barn via macro action, and thus uses a House Code that is not being used by anything else in the system.  (Specifically, macros set to its House Code simply "transceive" commands from a hand-held and re-issue the correct actual House/Unit codes for the lights.  Thus, the TM751 should never issue any PLC except if I explicitly issue RF commands for its House Code - which has never happened since I tested the original installation because I have no longer use the old hand-held remotes.

One thing that worries me in regards to spurrious commands is the presence of an Active Phase-Coupler/Repeater in the system, but I don't see anything screwy when executing macros individually, nor when issuing PLC directly, so...

Regarding a simple problem that I'm not recognizing, I'm all ears:  please explain!  If there is a simple solution to this mess, then I'd love to know what it is.  If these issues actually do not afflict anyone elses' system, then it implies there is some problem specific to my system - but what?  I have tested everything to death, and nothing conclusive comes of it.  There is some slight suspicion that some of the X10 devices were "flakey", but testing - even replacing - them hasn't materially changed the situation, so I'm baffled.

[dave w]

Regarding a simple problem that I'm not recognizing, I'm all ears:  please explain!  If there is a simple solution to this mess, then I'd love to know what it is.  If these issues actually do not afflict anyone elses' system, then it implies there is some problem specific to my system - but what?  I have tested everything to death, and nothing conclusive comes of it.  There is some slight suspicion that some of the X10 devices were "flakey", but testing - even replacing - them hasn't materially changed the situation, so I'm baffled.

"If there is a simple solution to this mess, then I'd love to know what it is". Obviously there isn't or you would have found it by now....

What I would do in your situation:
1. Run everything from the computer. X10 isn't going to tell you how the CM15A handles multiple macros. By running from the computer (at least for testing) you can assume AHP has all the memory it needs to buffer, cache, run multiple threads, etc. etc. etc.
2. Using the Activity Monitor log, test all "inputs" one by one to verify their inputs are reliably getting to the CM15A all the time, (Motion sensors, PR511, etc.).
3. Using the Activity Monitor log, a Palm Pad and TM751, or wired controller, manually test each of your macros one by one by initiating the trigger via the Palm Pad or wired controller to verify they (singely) execute correctly.
4. Repeat # 3,  only now manually trigger multiple macros.
5. Assume your problem is external to the CM15A and not a "macro collision/execution" problem and troubleshoot on that basis. (Unreliable signal reception, noise, etc).
6. Don't look for a magic wand solution. There probably ain't one.  

[Noam]

What I'll add to Dave's suggestions:

Map out your ENTIRE process. On a big sheet of paper.

Each macro should get its own path, and draw lines where one macro triggers another, etc.

You mentioned that you might not have all devices defined, or not properly. That could certainly be causing problems.
Don't share the save HC/UC between device types (or between SoftStart and non-SoftStart devices). Ever. (The only exception would be a "dummy" appliance module set to the same HC/UC as a macro, and used to call that macro from another macro.)

Any command you are sending from a macro should be linked to a VALID (and properly defined) device in your AHP setup.

Clear your AHP trash can. Macros have been know to still run from the trash in some cases.

If you still can't make heads or tails of it, post your AHX file here. Give us a description (as detailed as possible) of what each macro SHOULD be doing, and what triggers it. Also give us a sample of the logs from those macros running (individually, AND concurrently). Maybe one of us will see something you might not have noticed.

[MD Corie]

Although I think we're getting beyond the scope of what I want to get a handle on, and have moved into the larger realm of trying to figure out the entire situation (which likely does involve other factors), let me report the findings I have so far relating to your proposed course of action:

What I would do in your situation:
1. Run everything from the computer. X10 isn't going to tell you how the CM15A handles multiple macros. By running from the computer (at least for testing) you can assume AHP has all the memory it needs to buffer, cache, run multiple threads, etc. etc. etc.
2. Using the Activity Monitor log, test all "inputs" one by one to verify their inputs are reliably getting to the CM15A all the time, (Motion sensors, PR511, etc.).
3. Using the Activity Monitor log, a Palm Pad and TM751, or wired controller, manually test each of your macros one by one by initiating the trigger via the Palm Pad or wired controller to verify they (singly) execute correctly.
4. Repeat # 3,  only now manually trigger multiple macros.
5. Assume your problem is external to the CM15A and not a "macro collision/execution" problem and troubleshoot on that basis. (Unreliable signal reception, noise, etc).
6. Don't look for a magic wand solution. There probably ain't one.  

1. I have not yet tried running things from the PC only, so -given some time to set it up- I can do that and see what effect it has on things.  (Off the cuff, my guess is that it will simply slow things down a bit, but... the proof will be in the pudding, as they say).

The rest are results that I have obtained while using "Run in interface" mode, but are still useful information:

2.  All inputs (and their macros) have been demonstrated to work properly, individually - although "all the time" is not really possible to tell.  So, the question would be how long do they need to work reliably in order to say they are "OK"?  (So far, I have not found any errors in the inputs).
3.  I have done essentially the same thing using either the Icon Remote (which, of course is transceived by the CM15A), and from the actual motion sensors.  (I don't know whether the transceived inputs from the Icon Remote via the CM15A are going to accurately reflect the "real world" situation, but things do work properly that way - at least when only one macro is triggered at a time).
4.  When I have done this via the Icon Remote, in general terms, the results are consistent with "real world" execution of multiple macros - that is, things screw up significantly.  I will say, though, that they often seem to get more mucked up when they come from real world triggers than from my attempts to run them manually.  In any case, the results are more or less consistent with the results from multiple real-world triggers: screwed up.
5.  Making that assumption seems that it would unreasonably lead down the proverbial "rabbit trail", because all testing to date does not reveal any such "external" problems AND all observed problems show up only while using macros.  So, to arbitrarily assume the opposite makes no sense.
6.  I'm not looking for magic wand solution;  my intention in starting this thread was to try to gain understanding of how the macros behave and interact with each other - so that I could apply that knowledge to troubleshooting and macro design.