Print

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

[dhouston]

While there have been many reports of them blocking X10, I do not recall any reports of noisy CFLs causing random ONs similar to these.

Check Reply # 21.

I don't believe Reply #21 said anything about random ONs. In another post, Jeff wrote he had seen J-Status Request (1110101010101010101010 PLC) and also wrote about M13(1110010101010101010101 PLC). No combination of those two commands explain this situation which requires multiple address commands and multiple ON commands if the random events are indeed being triggered by valid PLC commands.

I believe it is slightly more plausible that the tooth fairy (by now getting quite long in the tooth), while on her nightly rounds, is turning on the lights to compensate for her failing night vision (another consequence of aging) and then, some nights, forgetting to turn them off (yet another consequence of her advanced age).  

[gfriedman]

Just reading thru so here is .02

I read a post from tuicemen that said motion detectors will start to send false triggers when the battery gets weak.   So, by same token maybe OP should replace the battery in his remote control pad.   Maybe would explain also why it takes longer to trigger devices from that remote as the signal is getting marginally weaker.   His system is 10 years old - has he ever replaced the battery?

Secondly, if it isnt the battery maybe the buttons on the remote are getting sticky.  After 10 years springs and contacts will deteriorate to where a replacement may be advisable.

[dhouston]

I read a post from tuicemen that said motion detectors will start to send false triggers when the battery gets weak.   So, by same token maybe OP should replace the battery in his remote control pad.   Maybe would explain also why it takes longer to trigger devices from that remote as the signal is getting marginally weaker.   His system is 10 years old - has he ever replaced the battery?

Secondly, if it isnt the battery maybe the buttons on the remote are getting sticky.  After 10 years springs and contacts will deteriorate to where a replacement may be advisable.

The security motion detectors, door/window switches do not send false triggers - they send a code to indicate the battery is low.

Also, in his first post...

...just about every nite at least one and most of the time all 3 go on in the middle of the night. It even does it without the battery in the switch pad.

Stick-a-switches have no mechanical springs.

[dave w]

While there have been many reports of them blocking X10, I do not recall any reports of noisy CFLs causing random ONs similar to these.

Check Reply # 21.

I don't believe Reply #21 said anything about random ONs. I believe it is slightly more plausible that the tooth fairy (by now getting quite long in the tooth), while on her nightly rounds, is turning on the lights to compensate for her failing night vision (another consequence of aging) and then, some nights, forgetting to turn them off (yet another consequence of her advanced age).  

No it is now reply 16 due to deletions.

However let me quote: "I also have an appliance module in my office/lab set to P1 that I use for testing.  It never triggers during the day, but occasionally switches at night when the set of 3 CFLs in my ceiling light (on the same circuit) is switched on.  The noise from those three CFLs beats together and creates random data patterns that occasionally match valid X10 strings."

But I can't accept the tooth fairy explaination. The 2010 movie "Tooth Fairy" starring Dwayne Johnson clearly indicates that tooth fairies are many, are on a rotational work schedule, and have early retirement benefits. So I doubt any tooth faiies "are long on tooth" as you suggest...or was that a pun? 













"

[dhouston]

No it is now reply 16 due to deletions.

However let me quote: "I also have an appliance module in my office/lab set to P1 that I use for testing.  It never triggers during the day, but occasionally switches at night when the set of 3 CFLs in my ceiling light (on the same circuit) is switched on.  The noise from those three CFLs beats together and creates random data patterns that occasionally match valid X10 strings."

But I can't accept the tooth fairy explaination. The 2010 movie "Tooth Fairy" starring Dwayne Johnson clearly indicates that tooth fairies are many, are on a rotational work schedule, and have early retirement benefits. So I doubt any tooth faiies "are long on tooth" as you suggest...or was that a pun?  

I would have to see the codes, captured with a storage oscilloscope or logic analyzer before I believe it's the three CFL'S noise magically combining into a P1 followed by POn. Occam's Razor would seem to support the hypothesis that whatever mechanism causes modules to turn on or off in response to spikes or sags is at work here.

Remember that two of the Cincinnati area users who saw random events related to smartmeters found that Smarthome made modules set to the same address were immune - that would seem to deflate the random codes from noise hypothesis. It would be of interest to see whether a Smarthome made module set to P1 in Jeff's office/lab will exhibit the same behavior.

I had an LM465 that would turn off whenever a 50 year old fluorescent fixture was turned on. There was nothing on the powerline that could be see with an ESM1 nor with my storage scope. Changing to an LM14A (at the same address) cured the problem.

And, I was referring to the real tooth fairy - not some modernistic Hollywood revisionist interpretation. 

[dave w]

I would have to see the codes, captured with a storage oscilloscope or logic analyzer before I believe it's the three CFL'S noise magically combining into a P1 followed by POn. Occam's Razor would seem to support the hypothesis that whatever mechanism causes modules to turn on or off in response to spikes or sags is at work here.

And, I was referring to the real tooth fairy - not some modernistic Hollywood revisionist interpretation. 

Yes, although If HCUC  P1 was the last command on the system, it would only take a morphed "POn" to trigger the module. The last addressed module remaines in "command mode" until a different HCUC is transmitted, doesn't it?

?Hollywood misleads?? I think I need to sit down.



[/quote]

[dhouston]

I assumed - perhaps in error - that the CFLs are X10 operated and turning them on would clear any previously addressed module. IIRC, a function command clears things. For example, you can send A1, A2, A3 and then send AOn to all of them.

The X10ded^TM Code documentation says...

Once addressed, a module responds to any command code. It becomes 'unaddressed' by the first 'address' message after a command, or by 'All Units Off'.

Anyway, P1=1110101001010110100101 and POn=1110101001010101011010. Not so easy to see how they are made from random noise that is somehow related to alternate cycles. And, it happens repeatedly? That really stretches credulity. I still vote for either an X10 design flaw (or the tooth fairy).

[JeffVolp]

I would have to see the codes, captured with a storage oscilloscope or logic analyzer before I believe it's the three CFL'S noise magically combining into a P1 followed by POn. Occam's Razor would seem to support the hypothesis that whatever mechanism causes modules to turn on or off in response to spikes or sags is at work here.

Remember that two of the Cincinnati area users who saw random events related to smartmeters found that Smarthome made modules set to the same address were immune - that would seem to deflate the random codes from noise hypothesis.

Dave, you've been talking about spikes for a long time.  While that may cause some of the problems, I don't believe that is the cause of problems for either my office/lab or the Echelon smart meters that have been installed in the Cincinnati area.  

I have watched the beat pattern from those CFLs create random decoded strings of 1’s and 0’s.  In years of testing, that P1 appliance module has never turned on unexpectedly during the day.  It has turned on several times at night while the CFLs were switched on.  We have a whole house surge protector, and I have never seen any significant spikes on our powerline.

The fellow who helped develop the Smart Meter Rejection kit used a Tektronix spectrum analyzer to understand exactly what the Echelon Smart meter was doing.  It produced very strong signals at two frequencies near the X10 passband.  His X10 modules were switching at random when those signals were being transmitted.  We added filters to block those transmissions, and the random actuations were eliminated.

The SmartHome devices use a different input stage compared with the X10 products.  They may have narrower bandwidth or AGC to ignore the continuous powerline noise.

The theory of P1 being the last “arming” command might be valid in the case of that appliance module.  Since I use the P housecode for testing, it is certainly possible that a P housecode was the last command sent on that circuit.  It is isolated from the normal automation circuits, so those commands may not override the last P command sent.  (The noisy CFLs are controlled by an ordinary wall switch.)

Jeff

[dhouston]

Jeff, does your Ocelot log these codes?

[JeffVolp]

Jeff, does your Ocelot log these codes?

No, that circuit is isolated from the normal house circuits to minimize interference when testing.  And even if it was on the same circuit, the XTB-523 would ignore the noise because the AGC would raise the detection threshold above it.

An interesting test would be to use an X10 TW523 logging the commands on that circuit.

Note that it is a very rare occurrence, but I have seen it happen several times over the past few years.

Jeff

[dhouston]

An interesting test would be to use an X10 TW523 logging the commands on that circuit.

In all of the reports over the years of random events attributed to noise morphing into legitimate codes, I cannot recall a single instance where the codes were logged by an X10 PLC interface.

[JeffVolp]

Today I set up HomeVision to log X10 commands received on that test circuit while the CFLs were switched on.  Most of them were the G16 ON and G16 OFF commands that cycle the hot water recirculation loop every 15 minutes.  There was one instance where HV logged G15 instead of G16.

I had seen X10 commands morphed from one command to another on several occasions when doing noise testing, and this was just another one of them.

Now I suspect the unexpected P1 actuations while those CFLs were on might also have been due to morphed home automation commands.  Since that is an isolated circuit for my testing, the incoming automation commands are not much above the noise generated by those CFLs.  P1 is the only module on that circuit, so it is not unreasonable that once in a blue moon a command is morphed into that bit pattern.

Jeff