Print

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

[marty619]

In a socket I have a chime addressed as B11. It sounds when motion is detected by my PR511 addressed at base B10 with switches +1 and +2 set IN.
In the SAME socket I have a CM15A. There is a "dummy" switch at B11 and B12. Also have a Macro at B12 ON. Neither switch or macro triggers when the PR511 isssues the signal that activates the chime. An appliance module in another socket at B12 activates! So the CM15A is not working. I have added an XPCR to the system with no improvment. Interestingly, a B11 or B12 sent from a Maxi controller or from a palmpad DOES trigger. I have don a hard reset of the CM15A (batteries out for 1 minute) and numerous downloads, and changes in monitored house codes etc. Nothing works. I have installed flag checking in the macros to avoid recursion problems, no help. SO can anyone please help?

[roger1818]

In a socket I have a chime addressed as B11. It sounds when motion is detected by my PR511 addressed at base B10 with switches +1 and +2 set IN.
In the SAME socket I have a CM15A. There is a "dummy" switch at B11 and B12. Also have a Macro at B12 ON. Neither switch or macro triggers when the PR511 isssues the signal that activates the chime. An appliance module in another socket at B12 activates! So the CM15A is not working. I have added an XPCR to the system with no improvment. Interestingly, a B11 or B12 sent from a Maxi controller or from a palmpad DOES trigger. I have don a hard reset of the CM15A (batteries out for 1 minute) and numerous downloads, and changes in monitored house codes etc. Nothing works. I have installed flag checking in the macros to avoid recursion problems, no help. SO can anyone please help?

My first guess would be either a powerline noise or signal absoption issue.  Both issues have similar symptoms and both can be fixed with an X10 noise filter.  Check out a tutorial I wrote on Noise, Noise Filters and Automatic Gain Control.

[marty619]

Roger,
Thanks for reply. For what you are telling me to be true then the CM15A has a much worse "front end" than say the chime or appliance module which, plugged into the same socket, both receive the PR511 signal without fail. Perhaps this is accurate since I have seen many other posts regarding the failure of CM15A's to deliver reliable macro execution. The CM15A sure does not log the events, so it sounds like it's missing the line transmitted signal, but I installed an XPCR and I am fairly sure that it's signal is full strength and the chime worked in the same socket without the XPCR so the PR511 was getting through to it. As a test, I moved the CM15A to a socket much nearer to the PR511 and still  no luck. Any other thoughts?

[roger1818]

Thanks for reply. For what you are telling me to be true then the CM15A has a much worse "front end" than say the chime or appliance module which, plugged into the same socket, both receive the PR511 signal without fail. Perhaps this is accurate since I have seen many other posts regarding the failure of CM15A's to deliver reliable macro execution. The CM15A sure does not log the events, so it sounds like it's missing the line transmitted signal, but I installed an XPCR and I am fairly sure that it's signal is full strength and the chime worked in the same socket without the XPCR so the PR511 was getting through to it. As a test, I moved the CM15A to a socket much nearer to the PR511 and still  no luck. Any other thoughts?

Oh, I thought (incorrectly) that the chime also wasn't working.  If it is working then you probably have a faulty CM15A.  Talk to technical support and see if you can get it replaced.  At first they may want you to pay to ship the old one back, but if you fight it, you will probably be able to get them to pay for that (especially if it was DOA).

[marty619]

Will do Roger.

What are your thoughts about the CM15A's ability to handle extended code inputs. I see that the PR511 can be polled and that means that it issues extended codes. Modules like switches and appliance modules might ignore the extended codes, but at some point to support the polling, the CM15A must recognize these codes. Since the codes from the PR511 are recognized by my modules but not the CM15A and I see that others have the same trouble ie. getting macros to run from a PR511 sent trigger, I suspect that there is something else going on, and extended code processing is one issue that I have not explored other than to put a flag condition in the macro to prevent recursive calls.

I invite anyone with knowledge on this to reply.

[roger1818]

What are your thoughts about the CM15A's ability to handle extended code inputs.

The CM15A should be able to handle extended codes without any problems.

I see that the PR511 can be polled and that means that it issues extended codes.

Not necessarily.  I am not overly familiar with the PR511 (does it support extended codes?) but STATUS_REQUEST, STATUS_ON and STATUS_OFF are standard (not extended) codes.  There is also an EXTENDED_STATUS_REQUEST which, if supported, will allow the module to return not only if it is on or off, but how bright it is. 

On a somewhat related note, SmartHome brand 2-way modules will transmit its brightness without using extended commands sending the obsolete PRESET_DIM command immediately after transmitting its status (although the TempLinc won't transmit a status message).  The AHP software doesn't support the old PRESET_DIM command so it ignores this message.  You can get the SDK to read this information, but it is kind of messy to do so.

Modules like switches and appliance modules might ignore the extended codes, but at some point to support the polling, the CM15A must recognize these codes.

FYI, X10's 2-way modules and some modules made by both Leviton and ACT support extended codes.

Since the codes from the PR511 are recognized by my modules but not the CM15A and I see that others have the same trouble ie. getting macros to run from a PR511 sent trigger, I suspect that there is something else going on, and extended code processing is one issue that I have not explored other than to put a flag condition in the macro to prevent recursive calls.

Although the CM15A does support extended codes, I don't think it does much with them.  If you define a module as a LM14A it will use an extended EXTENDED_PRESET_DIM to turn the lamp on and probably uses an EXTENDED_STATUS_REQUEST when you manually poll its status.  You can also manually transmit extended commands in macros.  Other than that it should ignore extended commands (other than storing them in the the history).

[roger1818]

I reread your original post and I have a few more thoughts.

What happens if you turn off the +1 and +2 switches and set the macro to B10 (or set the PR511 to address B12)?  Macros will only trigger if the address is immediately followed by the command.  I don't know what order the PR511 will send multiple commands, but if for example it were to send them in descending order (i.e. B12 - B11 - B10 - B_OFF) only a macro on B10 would be triggered but modules on all three addresses would switched.

Secondly, could the XPCR be causing you problems?  It is probably similar to the Levition HCA02-10E (it was designed and manufactured by X10) which is known not to play nicely with the CM15A, although you aren't seeing the symptoms that it caused.

[marty619]

GREAT IDEA ROGER!!

I have an experiment to run and will first set the macro to the highest PR511 UC then if that does not work to the lowest UC sent. I will make the trigger  unique to the macro and not shared with any device.

I'll share the results with you and all when available. If this fixes the problem, lots of users will want to know ( I have seen this issue raised many times over on the troubleshooting Forum).

I do not think that the XPCR is a problem because this same behavior (or lack of behavior to be exact) existed BEFORE it was installed.

Thanks much,
marty

[TakeTheActive]

What happens if you turn off the +1 and +2 switches and set the macro to B10 (or set the PR511 to address B12)?

I don't recall ever seeing the PR511s Base Address as being SENT by the PR511 in either my CM11A or CM15A logs. AFAIK, the Base Address is used *ONLY* to control the internal relay (which many use to control the floodlights - blue wire, IIRC).

Macros will only trigger if the address is immediately followed by the command.  I don't know what order the PR511 will send multiple commands, but if for example it were to send them in descending order (i.e. B12 - B11 - B10 - B_OFF) only a macro on B10 would be triggered but modules on all three addresses would switched.

roger1818 may be onto something here (i.e. another "BUG" in the AHP software), specifically related to X10's method of "abbreviating" transmissions - if an X10 transmitter (semi-smart that is, ABOVE the minicontroller/maxicontroller MANUAL w/ pushbuttons class) "thinks" that all the receivers that it's sending the same command to (let's say ON to keep it simple) are the SAME type of module, it will send:

• B 11
  
• B 12
  
• B 13
  
• B ON
  

Personally, I treat the MOTION and DUSK sensing features of my PR511s as another MSxx - by that I mean, I use BASE+4 for motion and BASE+5 for DUSK - two consecutive addresses. To go even a step further, on my second PR511 (installed decades after the first!), I don't even use the internal relay anymore (as I 'hinted at' above), but instead use an X10 wall switch module for the floods. Yet another "improvement" is that I added a non-X10 wall switch to control power to the PR511 so that on those evenings when we're sitting outside by candlelight (or moonlight) the floods aren't constantly triggering. (BTW, the 2nd PR511 is on the backyard deck, the 1st is on the frontyard driveway.)

Try using just BASE+4 and BASE+5. Using both BASE+1 and BASE+2 is redundant - AFAICS, it accomplishes nothing more than either one alone.

I put my floods on HouseCode 'C' (with all of my other above ground lights) and the PR511 on HouseCode 'F' (with all of my other Motion Sensors). Read the HouseCode discussion in my Troubleshooting FAQ for more ideas...

[roger1818]

I don't recall ever seeing the PR511s Base Address as being SENT by the PR511 in either my CM11A or CM15A logs. AFAIK, the Base Address is used *ONLY* to control the internal relay (which many use to control the floodlights - blue wire, IIRC).

Nice to know.  Not having ever actually used a PR511 I was just going by what I interpreted from the instruction manual.

(i.e. another "BUG" in the AHP software),

This has come up before (though not related to the PR511 and X10 claims that it isn't a bug but an intentional feature. 

specifically related to X10's method of "abbreviating" transmissions

X10 refers to this as group addressing.  It is actually a really nice feature but since RF remotes (and the modern mini controller) don't allow you to send addresses without commands it isn't available to most users (the AHP software uses it, but keeps it hidden).  That is one reason why I like IR remotes.

[marty619]

Thanks to Roger1818 I now have, after months of work, my PR511 and CM15A almost playing together.

First:
The knowledge that the PR511 issues group commands was essential. The macro started to trigger when I limited the PR511 to outputting only 1 address (+1 in my case). This assured reliable issuing of the pair sequence B11 BON. The macro at B11-ON then triggered. When I had the +1 and +2 switches set it would issue B12, B11, BON and as Roger1818 pointed out, a macro triggers only when address and command pairs are received so for the sequence B12, B11, BON the address/command pair is B11, BON not B12 BON required to trigger the macro.

Second:
I feel fairly certain that the "front end" of a CM15A is functionally less sensitive than an appliance module or a chime.  Both worked in a socket when triggered by the PR511, but when the CM15A was placed in the same socket with the above improvement, it still did not trigger!!! I got it to trigger when I moved it to a socket that was just 15 feet away from my XPCR (which I will now move to a location to allow me to relocate the CM15A to where I need it.

Third:
Even with the macro now triggering at B12-ON ( so I know it's getting the signal because it's doing it's thing), I still get no record of the event in the activity log. The log is set to monitor house code B, and transcieved codes to auto (A and B). Tomorrow I will add a phantom A switch, called from the B12 Macro to see if there is some reason why the activity monitor is not logging this event. The log is important to me because I want to keep track of visitors who pass by the PR511 in the driveway, that way, when someone charges me for 3 hours labor when I am away, I have the log to prove or disprove the statement.

Thanks Roger. If my test tomorrow gets the log working, I will post again to pass along the info to those who use PR511's.

[roger1818]

Thanks to Roger1818 I now have, after months of work, my PR511 and CM15A almost playing together.

My pleasure!  Glad to hear you have things almost working.  Lets hope that you can get the last little bit figured out so that it behaves the way you want it to.  If there is anything I can do to help, please let me know.

[marty619]

I have the last bit of my NO MACRO TRIGGER problem solved! It turns out that Roger1818's very first suggestion was an integral part of a complex problem, and each piece had to be solved to get it all to play together. His second observation was also crucial, so thanks Roger1818 for solving this all.

Here is a summary of what I just learned that may help others with CM15A problems.

My Goal
To have a PR511 motion detector at the end of a long driveway (300 ft) trigger my CM15A macros to conditionally turn on some lights, sound a chime and log the event to the activity monitor so that I could see dates and times of arrivals.

Problem
For a year I have not be able to get this to work

Solution Part A - Signal Interpretation
The transmissions from the PR511 were received at the wall socket where I want to have the CM15A (near my computer and at a place in the home where I get the best range to receive RF palmpad signals. When I plugged my CM15A into this socket it would not trigger. A Chime or an appliance module in the very same socket did respond to the PR511. Roger1818 pointed out that macros trigger when ADDRESS/COMMAND pairs are received  and that the PR511 issues group commands (see above posts). By limiting the PR511 to outputting just +1 ( as opposed to +1 (chime) and +2 (garage light) which I was using), the CM15A started to trigger.

This solved the triggering of Macros but the CM15A was still not logging of the event.

What other X10 devices issue group commands? This should be documented!  They too might cause Macro Triggering problems.

Solution Part B - Signal Reception

Roger1818 also identified this issue. Along the way I purchased an XPCR to receive then repeat and amplify the signals. With the code sequence cleared up, I had to move the XPCR  about 75 feet closer to the CM15A to get the logging to start to take place. Apparently the signals being received were still not clear enough. This does not speak well of the CM15A's "ears" since chime and appliance module worked without the need for an XPCR at all! I used the guideline to install the XPCR at the breaker panel, generally a central point that would be closest to all peripheral wiring runs, but in my case it was still too far from the CM15A to overcome what I guess is line noise from the computer or X10 signal corruption caused by the computer's surge suppressor.

In thinking about it, the CM15A "brain" needs not only ears to receive info, but also a voice to issue commands based on that info. So locating the XPCR "ear" relative to the CM15A would seem to be as important a consideration as placing it where it's "voice" can be commanded by the CM15A and then pass that same voice along so that it can be heard by all devices that are expected to obey the commands.

One more comment
As far as I am concerned, an XPCR and noise filter should be built into every CM15A to make it reliable. I mean these functions should be as effective as the separate individual devices of an XPCR and Noise filter.

The CM15A is designed to hook up to your computer placing it within 1 USB cable length of same. More often than not, that is within a few feet of a surge suppressor used for the computer and the computer's own line induced electrical noise, both of which can kill the CM15A's functionality. For reliability, the CM15A should work on it's own in that location!

[TakeTheActive]

ATTABOY roger1818! 

marty619: Thanks for following-up with your BEAUTIFULLY-formatted summary of events. It should be very helpful to many X10 Newbies.

[Dave4720]

I am late to this party, but this place is great.  I also had problems with a PR511 firing a module (sensor +1) and a macro (sensor +2).  I have worked for hours on this.

I finally tried only ONE switch IN, the one that caused the macro.  It then worked.

Coming here to search for support to my findings, I see the problem with multiple switches IN if one is a macro.

Solution confirmed.  I will move the direct addressed module to the macro, and call the macro (sensor +2) only.

Yep, another dweeb helped.

Dave