Print

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

[azbaja]

My CM15A has been doing some real strange things.

1.  If I have a light on,  Like my pool table E3 and turn it on again with the PalmPad the pool table light will trun Off and then On again. 
2.  If I have a light on and use the blue dim buttons on the PalmPad.  Normaly the light would dim a step up or down but now it runs to 100% On or 100% Off
3.  For what ever reason the CM15A likes to give out an random all lights on with House code "E".  Will try to change to a new house code this week.

Might I be doing somting wrong as I have not had this kind of problem before.  I did send back 1 CM15A for replacment do to this problem, But it has not changed with the new one.

When I look at the Activity Monitor every thing looks and acts like it should with the buttons I push on the PalmPad remote. 
When I run with out the CM15A it seems every thing works like it should,  No random all lights on sent.  Dimmers work etc.

Any one else seen a problem like this before?  I have had this house wired as a X10 home for 6 plus years now and have not had any strange problems before adding Active Home Pro

[Puck]

When I run with out the CM15A it seems every thing works like it should,  No random all lights on sent.  Dimmers work etc.

By saying "without the CM15A" you mean with it unplugged, correct?

If so, do you have a second transceiver in your set up for the PalmPad to work?

[Tuicemen]

azbaja:

When you get the E all lights on check the AM to see if there are any other signals recieved prior to this!

Then do an Advanced Search with PLC noise

And one with RF noise if you notice a recieve of RF before the all on!

This seems like I'm making you do a lot of work and reading   but the reading will help you understand what is causing this and how to fix it!

[-Bill- (of wgjohns.com)]

I still think there is a bug in AHP when it comes to receiving RF!  I have written programs that watch the CM15A interface (through AHP) and see all kinds of random garbage logged when an RF signal is received by the CM15A.

My two cents.

[Brian H]

Bill; Could be as I have looked at the RF Receivers output and it is a constant white noise static. No squelch on the receiver.

[azbaja]

When I run with out the CM15A it seems every thing works like it should,  No random all lights on sent.  Dimmers work etc.

By saying "without the CM15A" you mean with it unplugged, correct?

If so, do you have a second transceiver in your set up for the PalmPad to work?

Yes a 2 RR501 that has been working fine for the last 5 or 6 years no

[Puck]

You could be getting multiple triggers to modules / macros in AHP.

If your remote signals are reaching the CM15A and the RR501 (that's set to the remote's house code), AHP will receive the RF first thru the CM15A, then it will receive the PLC signal (transceived thru the RR501 & picked up thru the CM15A).

When using multiple Transceivers, you have to take extra care in making sure AHP does not receive multiple triggers. One way of doing this is with flags.

Also, with regards to the other posts here, make sure noise is not your problem too. Try moving the CM15A to another electrical location (at least try to keep it off of the same one as the PC). As Tuicemen stated above, there's a lot of info on the topic of noise here.

Please post what you do and what did or didn't work for you. 

Also, keep an eye on this thread: ActiveHome Computer Interfaces (CM11A *AND* CM15A) Go Bananas!
It looks like someone else is having a simular problem.

[azbaja]

I have done the move about 2 weeks ago,  The computer was in the back room of the house,  Now I have placed the computer with the CM15A in the garage.

I have alos moved the most of my house codes of from "E" and on to "F"

I hope you all understand the problem, most all the lights on house code "E" just trun on. The Activity Monitor Shows nothing being sent out from the CM15A but somthing is turning lights on and that is only with the CM15A pluged in.

I will keep you posted, Thanks

[Dan Lawrence]

You could be getting multiple triggers to modules / macros in AHP.

If your remote signals are reaching the CM15A and the RR501 (that's set to the remote's house code), AHP will receive the RF first thru the CM15A, then it will receive the PLC signal (transceived thru the RR501 & picked up thru the CM15A).

When using multiple Transceivers, you have to take extra care in making sure AHP does not receive multiple triggers. One way of doing this is with flags.

Also, with regards to the other posts here, make sure noise is not your problem too. Try moving the CM15A to another electrical location (at least try to keep it off of the same one as the PC). As Tuicemen stated above, there's a lot of info on the topic of noise here.

Please post what you do and what did or didn't work for you. 

Also, keep an eye on this thread: ActiveHome Computer Interfaces (CM11A *AND* CM15A) Go Bananas!
It looks like someone else is having a similar problem.

Having a two RR501's on the same housecode is a problem source. They keep stepping on each other.  I have 1 RR501 (for the Stick-a-Switch by the front door) and another 501 in the breakfast room that also has a Stick-a-Switch.  The Living Room 501 and the CM15A are in the same room and 7 feet apart. but on two different breakers.  If I unplug the 501, the CM15 cannot receive the RF signals from the Stick-a-switch.

[Puck]

Might I be doing somting wrong as I have not had this kind of problem before. I did send back 1 CM15A for replacment do to this problem, But it has not changed with the new one.

azbaja: You had stated that everything was working OK before, and now you are on your 2nd CM15A for this same problem. So it's unlikely the problem is the CM15A.

Has anything new been added / changed to your system just prior to it not working (including AHP version)? Is the CM15A itself the new change?

Does anything show in the Activity Monitor when this occurs... I know you stated that is doesn't show anything being sent out, but I just want to make sure your not just referring to nothing for house code "E", and that it's not showing anything received.

How often does this problem occur?

A noisy RF environment could cause some strange things to happen, but always turning house code "E" lights out??? I doubt it could be that consistant. So that is an unlikely cause.

Since this only occurs with the CM15A plugged in, maybe try something... Clear the Interface and DO NOT download your Macros & Timers. Then see if the problem still occurs. If not, you may have a corrupt ".AHX" file and have to recreate a new one from scratch. If it does, then try unplugging the RR501's one at a time.

[Tuicemen]

azbaja:
Make sure you transceivers are set up in Active Home Pro correctly!

Did this just start to happen after doing an update or adding a plug-in?

If so then it is most likely a corrupt AHX file and you'll have to rebiuld it as Puck stated!

You stated you've had a x10 home for over 6 years AHP isn't that old so when did your problem start?

Right after adding AHP?
If so did you manualy build the ahx file (your configuration file) or did you import your setup from active home?
If you imported the active home configuration this is the problem as errors get created in the process you may need to go through the setup and inspect each and every macro or rebuild it from scratch!
Sorry for so many questions  but there are so many possiblities!

[David Mark]

CM15a's antenna sucks.  Noisy and in some cases doesn't work at all.  Don't send anything from its antenna to the power line.

Noisy environments, half-dead motion sensors, etc. will consistently make the same (bogus) commands show up.  All Lights On/All Off seem to be the easiest to slip by.

I use two WGL transceivers, one on the power line for remote control (for a couple of sticky switches) and one that connects to the serial port of a PC and sends the commands directly to Misterhouse (primarily for motion and brightness sensors.)  That way the constant chatter from the sensors does not step on manual intervention (pressing a button on a PalmPad, camera remote, etc.)  There is a very good article out there about how to pick which house codes to use.  There are only six of sixteen that are comfortably spaced (has to do with the raw codes received by the transceivers and how they differentiate them.)  Within these house codes, there are six units codes that are similarly spaced.  So if you can get by with 36 discrete codes, you will have virtually trouble-free operation.  How to get by like that?  Scenes.  How else?  IR control (PalmPads suck!)

Oh and watch out when looking up the "two bits apart" X10 address spacing page (that should Google it) as there are two.  One is correct, one is wrong.  They both had the same idea, but only one guy got it right.  Hopefully the other one has been taken down.  Seems like A, D, F, G, H and P are the "safe" ones, but don't quote me on that.  Despite using scenes and other tricks, I still can't condense my setup down to 36.  Sure enough, it is the few modules that reside on the "unsafe" codes that occasionally turn on/off by themselves.  The more motion sensors you have (especially the light colored models), the more "ghosts" you will have.

[Charles Sullivan]

David Marks:
Can you identify the page with the "two bits apart" info you mention?  Googling with that phrase turned up nothing related to X10 I could see.  Thanks.

[David Mark]

Charles,

A quick Google with "collisions" instead of "two bits" came up with the wrong one:

http://www.user.dccnet.com/middleton/home%20automation%20secret.htm

Doh!

The problem is the assumption he made about the codes.  Look at his table with the binary representations.  That is not reality.

I can't find the right one, but can recreate it:


HC UC Binary (X10 code, not literal translation!)
A   1   0110*
B   2   1110
C   3   0010
D   4   1010
E   5    0001
F   6    1001*
G   7   0101
H   8   1101
I    9   0111
J   10  1111*
K   11  0011*
L   12  1011
M  13  0000*
N  14  1000
O  15  0100
P   16  1100*

* Safe

So it looks like A, F, J, K, M, P rather than A, D, G, J, M and P.  Safe units are 1, 6, 10, 11, 13, 16.

You should use these 36 codes for scenes and the individual modules within the scenes.  Motion and brightness sensors can be put on any house code as you don't transceive them (or hopefully you don't!)  The idea is that when you push the button to send one of these codes, chances are very slim that they will be recognized as one of the other 35.  If you must transceive motion sensors (for lights that go on and off without the controller getting involved), put them on their own house code within these six (don't mix and match motions with manual and macro commands.)  With the indoor models you cannot keep them segregated to the safe unit codes (except for address 10, which puts the brightness signal on 11.)

[Charles Sullivan]

With all due respect David, I don't believe either you or that other guy you reference fully understand the X10 protocol.
 
He is obviously clueless when it comes to the X10 encoding of house and unit codes, which you thankfully do understand.

Now he says "... X-10 does NOT have an error correction system.", which is a true statement.  However X10 does use an error detection scheme - each bit transmitted is immediately followed by its complement.  If that pattern isn't detected the signal is flagged as an error and ignored.  Then each signal is repeated to double the chances of the receiver getting a correct code.   With this scheme the probability of noise or collided signals being received as a valid (albeit incorrect) code is very small, at least to the extent that a receiver module correctly implements the protocol.  (Granted, we can't be sure of this since we don't have access to the microcontroller source code for the modules, and X-10 hasn't received many awards for bug-free programming.)

But how then to account for the instances of lights flashing on and off apparently at random?

Several reasons:
The on/off operation of these modules  is nominally controlled by the microcontroller flipping on/off bits in the module's power control circuitry.  But the AC power line is a pretty dirty electrical environment and it's not uncommon to have voltage spikes and surges which can induce bit-flips directly in a module's power control circuitry, bypassing the microcontroller.  Evidence that the module is being controlled by other than X10 signals is that no signal is detected by a receiver like a CM11A at the time a random event occurs.

Another reason is that a flakey X10 controller is sending the wrong signals.  This is easy enough to see with a CM11A by disconnecting the serial cable at the computer end and leaving it dangling from the CM11A.  This happens a lot with me because I'm constantly fiddling with one or two CM11As between different PCs and serial ports.  Although anything is likely to be transmitted, in my case I often see a lot of 0x00 and 0xFF being transmitted, which unfortunately are received as several of what you describe as "safe" addresses and functions - M13, M-AllOff, J10, J-StatusRequest.  The TM751 Transceiver is susceptible to a mode whereby it transmits an endless stream of dim signals, thought to be due to RF feedback.

In addition to the above are the oft-heard complaints which turn out to be X10 signals sent from a neighboring house on the same power company transformer.  Or the motion sensor which transmits on the programmed unit+1 on light or dark.

In short I consider that table of "safe" house and unit codes worthless.  I would not use housecode A and unit 1 since that's the default for all modules and controllers and there's always the chance of a neighbor getting a new X10 toy for Christmas.  I would not use housecode P, especially units 1 or 16, since they're used by X10 test equipment and by AHP at startup.  In my own situation I would not use housecodes M or J for the reason stated earlier, but that wouldn't apply to most people.  Aside from that I consider any particular housecode/unit as no better or no worse than any other.