Stray X10 messages?

[logic]

Good day :-)

I recently embarked on my journey into the world of home automation. I am a software developer by day, so I decided to take the path of writing my own automation software to interface with a powerline-based network. To this end, I bought a 2413U PowerLinc modem, with which I have linked a dimmer switch and an I/O module so far. The projects for which I have done these links are working well, and I've generally enjoyed the experience of developing for the Insteon technology. :-)

There is one curiosity, though, that I'd like to sort out. The PLM is reporting the receipt of X10 messages. This happens at unpredictable but usually fairly frequent intervals -- between 3 and 10 minutes typically. Out of the blue, the PLM will send a byte sequence indicating that Raw X10 has been received, and the X10 data it reports is (in almost all cases) FF 80, which, if my references serve me correctly, indicates a status check being issued against the entirety of house code F == 'J'. (Though from what Wikipedia has to say about X10, it also seems like an incomplete command, because it doesn't contain any unit codes. I don't know much about X10, though..)

I've never worked with X10 before, and as far as I know I haven't purchased any X10-compatible devices, though I do have a wireless remote controlled outlet for my Christmas lights, as well as a timer switch for the lights in one room of the house. The remote control unit is a Woods 32555, if I'm remembering correctly, and the timer switch is a cheap unit with 4 presets (3m, 5m, 10m, 15m). I can't find any evidence that either of these would be designed to support home automation standards.

Has anyone else seen this behaviour? It's been suggested to me that this is the PLM reading its own outbound X10 messages, but this seems somehow unlikely to me. Could it be that I'm receiving (or partly receiving) signals from a neighbour's systems?

Thanks very much,

Jonathan Gilbert

[stusviews]

There are at least three possible culprits. The first is that some Insteon devices have X10 commands as part of the testing process. But, as newer Insteon devices dropping X10 support, that seems less likely.

The second possibility is that, due to more and more electronic devices being introduced into homes, more and more signals appear that resemble X10 house/unit codes resulting in unpredictable X10 responses. That's primarily why alternative solutions such as C-Bus, Insteon, Lutron, UPB, ZigBee, and Z-Wave now predominate in the home automation field.

And, finally, you are correct. The signal could be coming from a neighbor.

[BLH]

FF 80 is a J Status Request.

(4 MSB) F=J , (4 LSB) F=Status Request. The X10 Flag 80 indicates the LSB is a command. If the X10 Flag was a 0 then it would indicate a Unit Code.

Do you have a Smart Meter from the power company or a TED Power Monitoring system?

[BLH]

In the X10 signaling protocol. A J Status Request is all 1 bits.
There could be a power line noise maker that occasionally matches what would be an X10 J Status Request.

Could also be a noise source from a neighbor as Stu pointed out.
We had a user in the X10 forums. Getting noise from their neighbors home. Where an aging CFL was spewing all kinds of power line noise.

[logic]

Hmm, okay, yeah :-) That all makes sense. I'm guessing it is random, then. The absence of any sort of CRC or checksum with X10 makes it quite possible for unpredictable noise fluctuations to be picked up as a signal. Based on Wikipedia's X10 article, the noise would have to be modulating sufficiently for the X10 receiver in the PLM to think that it is getting a millisecond at the prescribed frequency followed by a millisecond without it, but if something were oscillating in a manner that slowly drifted, with some unpredictable deviations, across the zero-crossings of the power signal, then it could conceivably produce the signal the PLM is reporting, which would look something like 0000001110111111111. The extra '0' in the middle suggests that the false signal's integrity, with respect to being interpreted as X10, is borderline, so that sometimes it gets a 0 and sometimes it gets a 1 -- if it happens to get a string of 0's, and then another 0 after exactly 3 1's then that's, entirely by accident, an X10 start code. The next 9 bits can be absolutely anything and is always interpretable as an X10 signal. This idea of an unpredictable interpretation would tend to be supported by the fact that occasionally, other bits are zeroes as well; looking back in the logs, I see peppered here and there raw X10 data such as "00 00" or "BD 80" or "7F 80" or "FB 80".

Yep, seems like noise on the line is the most likely culprit. (BLH: Nope, I don't have a smart meter or a power monitoring system.)

So, if my Insteon stuff is behaving just fine, does anything need to be done about this, or is it probably just fine to leave it as is, given that Insteon's signalling is substantially more robust? If it would be advisable to do something about it, what exactly can be done?

Many thanks both of you!

[logic]

Also curious is that it doesn't happen all the time -- suggests that it is resulting from a particular device. While it's on, there's noise that occasionally matches the X10 spec, and then when it's off the line is clean(er).

[stusviews]

Is the errant signal there and gone or does it stick around on and off for a while?

[BLH]

JV Digital Engineering. Has a good set of tutorials on X10 noise and signal suckers. Though geared to X10. The ones on noise makers and that nasty cheap cell phone charger. Are very informative.

http://jvde.us/x10_troubleshooting.htm

[logic]

That's a really neat resource, thanks very much :-) Even though I'm not using X10 at all, I'm finding each of the articles to be a fascinating read!

@stusviews -- it appears to come and go. I have not yet had the opportunity to analyze my logs to find out if it's happening at specific times of day, but it does seem related to some device or equipment that does not operate all the time. As of right now, the past 14 hours have not shown any false X10 messages detected by the Insteon PLM.