>>With all due respect David, I don't believe either you or that other guy you reference fully understand the X10 protocol.
I think I understand it pretty well. As I said, the other guy is wrong. There is another version of the same theory out there that is accepted.
>>He is obviously clueless when it comes to the X10 encoding of house and unit codes, which you thankfully do understand.
Right.
>>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
I know about the repeated signal, but was unaware that the checksum scheme was part of the powerline transmissions. If so then in a perfect world there would be no need for a scheme like this.
>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 i>mplements 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.)
Right. It is not a perfect world. I'm not familiar enough with the hardware/firmware end of it to comment on these articles much further. I do think that it pays to think about how you organize your units per house code, especially if you insist on transceiving motion signals.
>But how then to account for the instances of lights flashing on and off apparently at random?
I don't know about flashing on and off, but motion sensors can cause odd things to happen. Just address a unit with your remote, forget about it and walk in front of a sensor on the same house code.
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.
Line noise. No kidding. Can definitely cause a module to come on for no good reason. Luckily I have virtually none of that here. X10 loves to blame everything on line noise when I call them though (even the macro and timer failures on the controller!)
>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.
Well, I don't really deem them anything. I read the article years ago and it seemed there were others in the X10 community who accepted it. I had a CM11a for years but I never ran it unhooked from the PC. Are those signals really received though? Are the checksums sent as well? Regardless, leaving the serial cable hanging isn't a good way to go.
>The TM751 Transceiver is susceptible to a mode whereby it transmits an endless stream of dim signals, thought to be due to RF feedback.
That's an easy one. Plug two transceivers in on the same house code on the same phase (or anywhere if you have a coupler.) Dims go all the way to off, brights go all the way to 100% every time. Big trouble.
>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.
No issues there as none of my neighbors have X10. Am quite familiar with the brightness sensors. Odd that AHP isn't.
>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,
If my neighbors ever get X10, I will make sure that there is no way for the signals to cross over into my house!
>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
Not sure what test equipment you mean. What in God's name is AHP doing on P at startup. Never mind as I don't start it up (I shut it down.)
>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.
Could be. Misinformation is not hard to find on the Internet. Seems like some discussion in one of these forums led me to those two documents (the "right" one and the patently wrong one.)
[Edited by CS to delineate quoted from original material]
[TTA Edit: Increased SIZE of QUOTED TEXT from 8pt to 10pt so that those of us with "Advanced Eyesight" could at least read it!]
Author
Topic: CM15A Strange Operations: Random ALL LIGHTS ON and more... (Read 15218 times)